Verification
When work crosses a delegation boundary — between agents, between departments, between companies — the delegating party needs a place to render accept or reject on the delivery. AGLedger is that interface. We hold the signed contract, the signed completion, the signed verdict, and the structured dispute path when a verdict is contested. We are not the judge. The principal is.
Signed contract · Signed completion · Signed verdict · Three-tier dispute
Last updated: 2026-05-26 · API v0.25.4
When to use it
Reach for verification when work is delegated
Most automated work needs only notarization — one party records what was done. Verification adds a second party: a principal who explicitly accepts or rejects the delivery. Reach for it when work is being handed off and someone other than the doer needs to render a judgment.
- Agent-to-agent delegation. One agent assigns work to another and reviews the completion. The reviewing agent acts as principal.
- Cross-department handoffs. One team contracts work to another inside the same organization. The receiving team renders the verdict on delivery.
- Cross-company work. The most consequential case. Two organizations sign contracts, completions, and verdicts on their own AGLedger Servers; federation projects state across the boundary so each side's chain holds the cross-org record.
Single-agent, non-deterministic work does not need verification. Notarize it and move on. Verification is the cost paid for an explicit accountability surface across a boundary.
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 judgment and we hold the signed record of it. Three modes are available, chosen per contract type at registration.
Principal mode — human or agent judgment
The principal posts the verdict explicitly via POST /v1/records/{id}/outcome. 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. The chain does not distinguish between human and automated principals; the verdict is signed either way.
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 and renders the verdict mechanically. 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.
Gated mode — automated check, principal confirms
The rules engine evaluates first; on PASS the record holds until the principal confirms. Use when the deterministic check is necessary but not sufficient — the verdict needs both the mechanical check and the principal's explicit sign-off before settlement.
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 judgments. AGLedger holds the signed claim, the signed evidence, and the signed verdict.
The chain 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 judgments 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 judgment as if it were a numeric check would silently override the principal.
The flow
Contract, completion, verdict
1. Principal creates the record
Structured statement of what is being assigned, by when, under what criteria, with which tolerance bands. The contract is signed and chained.
POST /v1/records2. 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. Performer submits the completion
Structured evidence matching the contract type's completion schema. The completion cites the record by ID and is signed by the performer.
POST /v1/records/{id}/completions4. Verdict, signed and chained
The principal renders accept or reject via /outcome in principal or gated 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}/outcomeEvery transition is a Signed Statement — tagged COSE_Sign1 (RFC 9052, tag 18) over an in-toto v1 Statement payload, Ed25519-signed, hash-chained to the previous entry. The chain is the byte-stable record of who said what at each step.
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 VERIFIED_PASS, VERIFIED_FAIL, FULFILLED, or REMEDIATED. Three tiers, each signed and chain-appended.
Tier 1 — automated re-adjudication
The verification 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. On PASS the dispute resolves as OVERTURNED, the record walks back to its prior terminal, and a RELEASE Settlement Signal fires. On FAIL 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
Verification across the org boundary
Verification is most consequential across organizational boundaries. Two parties on two AGLedger Servers sign contracts, completions, verdicts, and dispute states on their own chains; 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 federation surface is on the federation guide.
Related capabilities
Verdicts that cross an organizational boundary ride federation transport; each Server signs its projection of the verdict.
The signed verdict is the input that authorizes a SETTLE or HOLD signal to your payment, ERP, or ticketing system.
Contract types define the shape of the record and the predicates a verifier evaluates against the submitted Completion.
The lifecycle routes that drive Verify mode: proposal, acceptance, completion submission, and verdict rendering.
Ed25519 signatures, COSE_Sign1 envelopes, and hash-chain construction underwrite every verdict.
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.