FOR PLATFORMS, RAILS & PROCUREMENT SYSTEMS

Your rail moves the money.
The engine proves the work.

Send a statement of work. Get back criteria a machine can check and a sealed verdict on every condition — read by your release logic instead of a PDF.

TRANSACTION · 4 CONDITIONS

READ BY YOUR RELEASE LOGIC
C1MET

Staging deploy reachable — signal, first-party

C2MET

Checkout completes end-to-end — demo 02:44–03:26

C3MET · NO MODEL

p95 latency under 300 ms — reading 241 ms

C4NOT ASSESSED

Accessibility audit passed — no artifact addressed

3 of 4 met · release held on C4 · chain head anchored

9e0c…d7f2

THE PROBLEM

The condition is the weak link in conditional money

Conditions complete on a PDF

Your escrow already releases on conditions. What completes one today is a PDF or a screenshot — exactly the proof that gets argued about later.

Every dispute is an investigation

Someone on your side reads the emails and reconstructs what happened. Cost scales with volume; the answer is still whose story reads better.

Verification isn't your product

Building a referee, a capture layer, and a public anchor is a second company. And the one you built would still be graded by you.

HOW IT WORKS

SOW in. Criteria out. A verdict per condition.

1

SOW in

Your party uploads the statement of work. The engine drafts acceptance criteria and lints each line for provability.

2

Criteria sealed

On acceptance the criteria are hashed and sealed before any evidence exists. Each maps to one condition on your rail.

3

Evidence sealed against them

Uploads, captures, and readings arrive addressed to their criterion. The referee verifies; what it can't settle, it refuses.

4

Verdict out

Your release logic reads a sealed verdict per condition — met, not met, or not assessed. You move the money. We never do.

WHAT YOU SEND

  • Statement of work
  • Party identities and the conditions your rail holds
  • Uploads, captures, or instrument signals
  • Release, dispute, and completion events

WHAT YOU GET BACK

  • Provable acceptance criteria — one per condition
  • A criteria-locked seal
  • A sealed verdict per condition, with cited evidence
  • Refusal codes when evidence can't settle a line
  • The chain head, its public anchor, and a receipt URL

Your transaction flow stays yours. The verdict is what changes.

WHAT YOU DON'T HAVE TO DO

Nothing to rebuild. Nothing to arbitrate. Nothing to trust.

Nothing to rebuild

Your escrow, KYC/KYB, and payout rails stay as they are. Northn plugs into the condition and leaves the money to you.

Nothing to arbitrate

When parties disagree, a neutral reviewer — yours or ours — reads the sealed record. Northn never arbitrates.

Nothing to trust

Every verdict is sealed before the model runs and the chain is anchored publicly. Your buyer can check a receipt without trusting anyone.

Nothing silent

Rules ship as versioned, anchored editions. A rule change is a new edition, never a quiet update to what an old verdict meant.

COMMERCIALS

Paid for what was proven

Three principles hold in every integration. The numbers are a conversation, and they never depend on the verdict.

Never outcome-based

The engine is never paid more for saying yes. Nothing in the price depends on which way a verdict went.

Volume, not seats

Pricing follows the work that ran through the engine, never the number of logins. Terms are set per integration.

Statement matches the record

Every line on the monthly statement can be traced to sealed events you can count yourself.

STRAIGHT ANSWERS

What engineering and compliance ask first

Can we run the AI on our own keys?

Yes, and it's the default. The referee runs under your own provider agreement, on your keys.

What does the buyer on our platform see?

A receipt: the criterion, the evidence, the verdict, and a link to verify the chain publicly. No account, no login.

Keep the rail.
Add the proof.

Start with one transaction type on sandbox. If the record doesn't make disputes cheaper, you've lost a sprint.

WHAT AN INTEGRATION LOOKS LIKE

  • Sealed proof on your existing conditions first — no flow changes
  • Then SOW → criteria → conditions through the API
  • A monthly statement whose counts match the event log
  • Evidence pack and reviewer seat wired to your dispute path