Gate
AGLedger notarizes one signed record over the whole life of a piece of work. The Gate is the optional tail of that span, the verdict on success that only some contract types run. Work with no completion schema terminates at RECORDED with no verdict. Gated work runs the full lifecycle: create, accept, completion, verdict. When the verdict is rendered, the principal renders it (a human, an agent, or a rules engine). AGLedger holds the signed decision.
AGLedger never sits in the execution path. The system that performs the consequential action checks the signed verdict before it acts; AGLedger holds the verdict and serves it. Fail-closed is a policy you set at that system, and if AGLedger is unreachable your systems keep running.
Same span · Optional verdict tail · Signed verdict · Principal-resolved disputes
One span, an optional tail
The routine path never reaches a verdict
The record is the same object either way. A contract type with no completion schema is notarize-only: the moment the work is recorded, the span terminalizes at RECORDED in a single signed call. That is the on-ramp, and it is where routine automated work stops: one party records what was done, and no second party needs to weigh in.
A contract type that declares a completion schema runs the gated lifecycle instead. The span carries a tail: the performer submits a completion, and a principal renders accept or reject on it. The verdict is the last signed entry on the same chain that opened the record.
Reach for the gated lifecycle when work is delegated and someone other than the doer renders the verdict: agent-to-agent delegation, work that crosses departments, and cross-company work, the most consequential case. Single-agent work that no one reviews does not need a Gate. Notarize it and it terminates at RECORDED.
Who renders the verdict
The principal renders the verdict. We hold the record.
Whether delivered work is good is the principal's call: a person, your system of record, or a review agent you run. We give the principal an interface for that verdict, and the notary signs the record of it, the same way it signs every other entry on the span, attributing the principal inside the payload. Two modes are available, chosen per contract type at registration.
Principal mode: human or agent verdict
The principal posts the verdict explicitly via POST /v1/records/{id}/verdict with a body of { verdict: "accept" | "reject" }. The principal may be a human reviewing in a dashboard, an automated agent rendering accept or reject programmatically against its own logic, or any other system that holds the appropriate credential. When the contract type carries deterministic rules, the engine runs an advisory pass first; the principal sees the mechanical result, then the notary signs their verdict. The chain does not distinguish between human and automated principals; either way the entry is signed by the instance key and names the principal.
Auto mode: deterministic criteria with tolerance
When the contract type declares numeric criteria with tolerance bands (counts, quantities, durations, amounts), the rules engine checks delivered evidence against those bands, renders the verdict mechanically, and settles the record without waiting on a principal. This is a convenience layer for deterministic work, not a substitute for the principal. The engine can check whether the document count reported in a completion matches what the contract specified; it cannot check whether those documents exist or whether the work on them is correct.
The verdict boundary
Who decides what
Judgment belongs to the principal you designate. Whether a draft is well-written, whether a recommendation is sound, whether a translation is accurate: a person, your own system, or a review agent you run renders that verdict. AGLedger holds the signed record, the signed evidence, and the signed verdict.
The rules engine checks structure against the contract. It confirms that the structured evidence in a completion matches what the contract specified, within the tolerance bands the contract declared. Whether the work behind those numbers exists, and whether it is correct, is the principal's call. The chain proves what was claimed, signed, and recorded.
A principal's verdict holds as rendered. The optional automatic re-check on a dispute, which re-runs the rules with widened tolerance, applies only to verdicts the rules engine produced. A verdict a person or an agent rendered is left as it was, because re-running it as a numeric check would silently override the principal.
The gated lifecycle
Create, accept, completion, verdict
1. The record is created
A structured statement of the work being offered, by when, under what criteria, with which tolerance bands. The record is signed and chained. A contract type with a completion schema runs the gated tail; one without it terminates here at RECORDED.
POST /v1/records2. The performer accepts
The named performer accepts the record and walks it toACTIVE. The handshake is consent, recorded on the chain; a principal that does not need it sets autoActivate and the record lands ACTIVE in the create call.
POST /v1/records/{id}/accept3. The performer submits the completion
Structured evidence matching the contract type's completion schema. The completion cites the record by ID, and the notary signs it in the performer's name.
POST /v1/records/{id}/completions4. The verdict, signed and chained
The principal renders accept or reject via /verdict in principal mode; the rules engine renders it in auto mode. The record terminates at FULFILLED on acceptance or moves to FAILED on rejection, where the principal can still request a revision. A Settlement Signal™ webhook fires.
POST /v1/records/{id}/verdictEvery transition on the span is a Signed Statement, signed by the instance vault key and hash-chained to the previous entry. The verdict tail uses the same envelope and the same chain as the record that opened it. The cryptographic construction is owned on the security page, along with how anyone holding the public keys confirms the chain offline.
Disputes
A dispute path that ends in a signed outcome
Verdicts can be wrong. AGLedger provides a structured dispute path that the principal, performer, or tenant-admin may open against a record in FULFILLED, FAILED, or REMEDIATED. Every step is signed and chain-appended, and the outcome is the principal's, not the engine's.
1. Evidence window
Opening a dispute walks the record to DISPUTED and starts a window in which either party may submit evidence through a structured endpoint. Evidence types are enumerated (screenshot, external lookup, document, communication, other) and each payload is hashed and signed into the chain. Window length is configured per contract type. The initiator can withdraw at any point before the outcome, which restores the record to its prior status.
2. Outcome, rendered by the principal
When the window closes the dispute waits on the record's principal, or an org-admin key, to render UPHELD or OVERTURNED with an optional rationale. The principal does not have to wait for the window to lapse. UPHELD returns the record to exactly the status it held before the dispute. OVERTURNED re-renders the verdict: a record that was FAILED settles at FULFILLED, one that was already FULFILLED or REMEDIATED is restored, and a RELEASE Settlement Signal webhook fires. AGLedger records the decision and moves the record; it does not weigh the evidence.
Optional automatic re-check. An Org that sets disputes.autoReadjudicate in its config gets one deterministic re-run first: the type's gate rules are evaluated again with the configured widening, and a pass resolves the dispute OVERTURNED immediately. Off by default, and only meaningful when the original verdict was rules-based; absent that setting nothing is re-graded and every dispute reaches the principal.
Cross-organization
Gating across the org boundary
A Gate is most consequential across organizational boundaries. Two parties on two AGLedger Servers each sign their own portion of the span (contracts, completions, verdicts, and dispute states) with their own instance key; federation projects the cross-org events between them so each chain holds a complete cross-org record.
Dispute presence projects; dispute content stays local. The peer learns that a dispute opened, its outcome, and the final state. The evidence payloads, the rationale, and the verdict rendering remain with the originating Server. Cross-organizational accountability without cross-organizational data sharing.
The full cross-org transport surface is on the federation page.
Related capabilities
Verdicts that cross an organizational boundary ride federation transport; each Server signs its own projection.
The signed verdict is the input that authorizes a SETTLE, HOLD, or RELEASE signal to your payment, ERP, or ticketing system.
The calls end to end: create a gated record, submit a completion, render the verdict, handle a dispute, and check clearance before acting.
Contract types define the shape of the record and whether it carries a completion schema (that is, whether it runs the gated tail at all).
Ed25519 signatures, COSE_Sign1 envelopes, and hash-chain construction underwrite every verdict on the span. A signed verdict is only evidence if it holds up offline, and anyone with the public keys can confirm the chain independently.
The threat model and the mechanisms behind the signatures every verdict rides on.
How signed verdicts and transparency-service receipts compose into EU AI Act Article 12 logging.