Use case
Escrow that releases on outcomes, not promises.
Move from “we’ll pay when it’s done” to “we can prove it’s done.” Harbor ties funds to a signed agreement (the intent), collects signed evidence as the work happens, and then runs a deterministic check (a predicate) to release or refund—producing receipts you can use in approvals, audits, and disputes.
Terminology
Key terms, up front.
- Intent
- The signed agreement boundary: who’s involved, the budget, and what counts as “done.”
- Predicate
- The deterministic check that evaluates evidence and decides release vs. refund.
- Evidence
- Signed artifacts and attributable operator actions captured during the lifecycle.
- Receipt
- A replayable record of what was evaluated and what happened—useful for audits and disputes.
One concrete flow
The short version: agree on outcomes, collect evidence, then release (or refund) with a receipt you can replay.
1. Agreement
Sign what “done” means
Parties, budget, and the outcome check are captured as a signed agreement (intent).
2. Evidence
Attach proof as it happens
Signed artifacts and operator actions become an audit trail you can export, review, and share.
3. Settlement
Evaluate, then emit receipts
Deterministic evaluation decides release/refund and produces receipts that explain the decision.
Escrow that stays understandable in production.
Bind completion criteria to a signed intent, then settle via deterministic evaluation over signed evidence.
Signed agreement as the boundary
Put parties, budget, and completion criteria in a signed intent so settlement can’t drift from what was agreed.
Deterministic evaluation
Predicates run with bounded, deterministic execution so the same evidence yields the same decision—every time.
Evidence-first settlement
Attach signed evidence throughout the lifecycle so reviews, exports, and disputes all point at the same canonical record.
Operator-safe workflows
Handle edge cases without rewriting history: reviews and overrides are attributed events, not silent edits.
What you get (things you can share)
Outcome-verified escrow only works if the output is portable: receipts, exports, and a decision trail.
Settlement receipt
A replayable record of the inputs and outputs for a settlement decision—useful for approvals, audits, and disputes.
Exportable compliance bundle
A portable bundle of the intent, evidence, provenance, and receipts—ready for audit, partner verification, or underwriting.
Operator decision trail
When humans intervene, who did what (and why) is captured as events so the system stays legible under review.
How outcome-verified escrow works
A predictable lifecycle from intent to receipts.
Step 1
Define what “done” means
Write a predicate that defines success and reference it in the signed intent.
Step 2
Fund escrow
Commit the budget so funds are reserved and settlement is predictable.
Step 3
Capture signed evidence
As work happens, attach signed artifacts and operator actions to the provenance trail.
Step 4
Evaluate the outcome check
Evaluate deterministically over the evidence to decide release vs. refund.
Step 5
Emit receipts and exports
Generate a receipt and export bundle so others can verify exactly what the decision was based on.
Settlement decisions that survive audits and disputes.
Outcome-verified escrow only works if it stays legible: clear agreement boundaries, deterministic evaluation, and attributable evidence—kept tenant-safe end-to-end.
Guarantees
- Predicates are evaluated deterministically with bounded execution.
- Evidence and operator actions are tied to signed provenance.
- Tenant scope is derived from authenticated credentials—not user-supplied identifiers.
Where it’s used
Outcome verification works best when money, automation, and trust all collide.
Agent marketplaces
Fund tasks up front, release on verified completion, and resolve disputes against evidence—not screenshots and stories.
B2B services with SLAs
Reduce manual acceptance with predicate checks, while keeping human review for exceptions.
Programmatic procurement
Bind budgets to explicit completion criteria and produce receipts your finance/compliance teams can use.
Integration checklist
A quick way to sanity-check whether this pattern fits your product.
Model the agreement boundary
Define parties, budget, and completion criteria as a signed intent so settlement can’t drift from the agreement.
Decide what counts as evidence
Pick the artifacts, events, and operator actions you’ll sign and attach through the lifecycle.
Ship with review paths
Plan for edge cases: make reviews and overrides explicit, attributable, and exportable.
Next steps
Go deeper on the lifecycle, or start a sandbox signup.
Outcome-verified escrow FAQ
Questions about predicates, evidence, and operator review.
How is this different from typical webhook-driven escrow?
A webhook usually boils down to “trust the service.” Outcome-verified escrow ties settlement to a deterministic predicate evaluated over signed evidence declared in the intent—so you can reproduce and audit the decision inputs later.
What do you mean by “intent”, “predicate”, and “receipt”?
An intent is the signed agreement boundary (parties, budget, criteria). A predicate is the deterministic check over evidence that decides release vs refund. A receipt is the replayable record of inputs and outputs for that settlement decision.
What if the predicate is wrong?
Predicates are part of the agreement boundary. If criteria change, the system records new intent/evidence events so reviewers can see what changed (and why) without silently rewriting history.
Can operators intervene?
Yes. Interventions are recorded as attributable events so audits and receipts stay consistent.
How does this stay tenant-safe?
Tenant and operator scope are enforced at every boundary and derived from authenticated credentials. Cross-tenant access is blocked by design throughout the lifecycle.