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. We are not the judge.
Same span · Optional verdict tail · Signed verdict · Three-tier dispute
Last updated: 2026-06-09 · API v1.0.0
One span, an optional tail
Most work 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 most 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. Nothing is bolted on; the Gate is the part of the span that some work needs and most does not.
Reach for the gated lifecycle when work is handed off and someone other than the doer renders the verdict — agent-to-agent delegation, cross-department handoffs, 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.
AGLedger does not judge whether delivered work is good. The principal does. 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.
Bright lines
What AGLedger does not do
We do not judge non-deterministic claims. Whether a draft is well-written, whether a recommendation is sound, whether a translation is accurate — these are principal verdicts. AGLedger holds the signed record, the signed evidence, and the signed verdict.
The Gate does not verify the underlying facts. The rules engine can check whether the structured evidence in a completion matches what the contract specified. It cannot check whether the work behind those numbers actually exists or whether the work is correct. The chain proves what was claimed, signed, and recorded, not whether the claim was true.
Principal verdicts are not re-adjudicated. When the original verdict was rendered by a principal rather than by the rules engine, dispute Tier 1 refuses to re-run the rules with expanded tolerance against it. Re-adjudicating a human or agent verdict as if it were a numeric check would silently override the principal.
The gated lifecycle
Create, accept, completion, verdict
1. The record is created
A structured statement of what is being assigned, 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 (or counter-proposes)
The named performer accepts the record and walks it toACTIVE. Counter-proposals are supported on the same flow if terms need to change before work begins.
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 FAILED on rejection. A Settlement Signal 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, and anyone holding the public keys can confirm the chain offline.
Disputes
Three-tier re-adjudication when verdicts are contested
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. Three tiers, each signed and chain-appended.
Tier 1 — automated re-adjudication
The rules engine re-runs against the latest completion with tolerance bands expanded by a configured factor and a deadline grace window. Only runs when the original verdict was rules-based; principal-mode verdicts skip Tier 1 entirely. If the re-run now falls inside the expanded band, the dispute resolves as OVERTURNED, the record walks back to its prior terminal, and a RELEASE Settlement Signal fires. If it still falls outside, the dispute advances.
Tier 2 — structured evidence window
A structured evidence window where either party may submit additional evidence through a structured endpoint. Evidence types are enumerated (screenshot, external lookup, document, communication, other) and the payload is hashed and signed into the chain. Window length is configured per contract type. After the window closes, human reviewers render the verdict.
Tier 3 — arbitration
Final-tier human review. On exhaust the record terminates at PENDING_ARBITRATION rather than fabricating a verdict. AGLedger has no Tier-3-verdict API by design — the chain stops until an external authority writes the resolution.
Automated escalation when needed. Opt-in thresholds advance stale disputes between tiers without manual intervention. Set DISPUTE_AUTO_ESCALATE_TIER2_HOURS and DISPUTE_AUTO_ESCALATE_TIER3_HOURS to force the sweep to push stuck disputes forward. The default is log-only with structured staleness warnings.
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
The spine the Gate is a tail of. Notarize-only work terminates at RECORDED with no verdict; enforce it in the path with no-record-no-action.
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.
A signed verdict is only evidence if it holds up offline. Anyone with the public keys can confirm the chain independently.
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.
Why an unsigned verdict is not evidence, and how detached signatures prevent post-hoc revision.
How signed verdicts and transparency-service receipts compose into EU AI Act Article 12 logging.