Verifiability
Why completion is a function of verifiable facts, and how the release condition is built rather than trusted.
Verification by construction
Trust in an autonomous system should be a property of how it is built, not of how confident it sounds. Elpis makes the release condition a fact about the world, so the guarantee survives swapping the model underneath it.
| Property | How it is guaranteed |
|---|---|
| A payment happened | The chain is re-read independently after execution. |
| A job’s work is done | A deliverable hash is compared to the agreed commitment. |
| A person decided | An approval record with the control that asked for it. |
| Nothing is assumed | A null or unverifiable result is pending, never success. |
No field for an opinion
The completion evidence passed to the decision function has no place to put a model’s confidence. What it contains instead:
| Evidence | Rule |
|---|---|
| Deliverable vs the commitment | A mismatch is a reject, not a debate. |
| Treasury controls | A failed control is never authorised past. |
| Required counter-signature | Missing → hold. Nothing moves. |
| Human decision above a threshold | A person’s “no” is a reject; their absence is a hold. |
| The deadline | Past it → reject, and the refund path belongs to the client. |
Three outcomes
complete release the escrow — the commitment was met
reject refund the client — it was not
hold not yet — nothing movesA hold is not a failure. It is the system saying “not yet”, and it sends no transaction, which is precisely why defaulting to it is safe. The full primitive — commit, verify, settle, replay — is in Settle on proof; the exact hashing is in Canonicalization.
The ERC-8183 evaluator
Elpis takes the evaluator seat in ERC-8183 and makes that decision deterministic, in contrast to a model’s self-reported confidence deciding whether money moves. The mapping, the endpoint and the evidence shape are in Payments standards. An attestation reason accompanies every on-chain release, so the decision is reproducible.
What on-chain verification cannot do
It confirms execution, not intent: a transfer happened with a given amount and status. It cannot tell you the payee was the right one. That is a document-side failure, answered by the document anchor and recipient change control. See Security for the limits, stated plainly.