Canonical definitions of the terms behind AGLedger. Each term has a permalink — link to #notarize, #chain, #settlement-signal directly.
Section
To sign and append a record to the chain. The verb at every layer of AGLedger — single-agent, delegation, federation.
Notarize means: take a structured statement, sign it with an Ed25519 key, hash-chain it to the previous entry in the vault, and write it to disk. The act is cryptographic, not legal — AGLedger is a digital notary in the RFC 3161 / DocuSign sense, not a notary public. Typically two notarizations frame a task: one for what the agent is about to do, one for what was done.
The structured object written to the chain when an agent or system notarizes. The noun for "the thing on disk."
A record is what AGLedger writes when a participant notarizes. Records are JSON, validated against a customer-registered JSON Schema type, signed Ed25519, and hash-chained to the previous entry in the vault. A record can be a notarize-only entry that terminalizes immediately, or it can carry a completion phase, a verdict phase, and a Settlement Signal on the Gate path.
The hash-chained, Ed25519-signed sequence of records that AGLedger maintains. Tamper-evident and verifiable offline.
Every record references the hash of the previous one. Tampering breaks the chain at the point of modification, and a third-party verifier with only the public keys can detect it. The chain is the persistence layer of the system and the load-bearing artifact for audit, compliance, and disputes. The vault is partitioned for scale; the chain itself is conceptually one ordered sequence per record.
Confirming offline that a chain's Ed25519 signatures are genuine and its hash links are unbroken. Anyone holding the published public keys can do it — no account, no network.
Verification is purely cryptographic. It checks that each signature validates against the published key, that every entry hash-links to the one before it, and that the visible payload matches the signed bytes. It is distinct from the Gate: verification confirms a record is authentic and untampered; it says nothing about whether the work was good. A passing verification proves that what was signed is intact, not that the claim inside it was true.
The chain as a substitute for agent context. When an agent resets, hands off, or is replaced, the chain holds the original record byte-for-byte.
Conversation history evaporates between sessions. Vector stores summarize. Hash-chained, signed records persist byte-for-byte, indefinitely. When work spans a context reset or a hand-off, the new agent reads the chain to recover what was already signed for. This is the structural fix for context loss — not a bigger model, not a better prompt, just: write the work down, signed, before it starts.
Section
Parent-child records linked by signatures. When work is subcontracted across agents and services, every party signs their step.
Each child record carries the parent record's ID. The chain links the original work to the final outcome regardless of how many hands the work passed through. Default depth limit is 5; configurable up to 10. The same protocol scales from one agent serving one user to fleets of agents working through shared backend systems and third-party tools.
Section
An AGLedger install. A sovereign domain — its own database, auth, agents, contracts, and chain. Every install is the same shape; there are no roles, modes, or hierarchies.
A Server is the unit of deployment. Every install runs the same binary with the same surface area. Two Servers that want to coordinate just exchange signed messages over HTTPS; there is no registration handshake, no peering agreement, no shared state to synchronize. A Server holds its own ledger and signs its own records. Federation is what happens when those signed records cross a Server boundary.
Signed-message transport between sovereign Servers. Peer-to-peer, no registration, no central coordinator. Bytes move; that's all.
Federation is what we call cross-Server traffic. When work crosses an organizational boundary, the originating Server sends a signed payload to the counterparty's Server; the receiving Server verifies the signature against the originator's published public key and records the message in its own ledger. There is no central coordinator, no shared store, no peering protocol — each Server remains sovereign. Cross-Server delegation chains complete naturally because each Server stores its own slice and chains link by signature reference. Five-deep delegation across five Servers works the same way as one delegation across two Servers.
A record signed on Server A is shipped, by default, as a signed copy to the counterparty's Server when one is involved. Override per-record, per-contract, or globally.
The default-share posture is on. The override hierarchy is: per-record `share` field beats per-contract-type `defaultShare` beats global `AGLEDGER_DEFAULT_SHARE`. Encrypted mode is orthogonal — a shared record can still be encrypted, in which case the counterparty receives the signed envelope and can prove existence without reading contents. The four practical postures (private+plaintext, private+encrypted, shared+encrypted, shared+plaintext) compose from these primitives without being enumerated as deployment modes.
A SETTLE, HOLD, or RELEASE event AGLedger emits on terminal records. Routes to payment platforms, ERPs, and ticketing systems via webhook. AGLedger produces the signal; your financial systems act on it.
Settlement Signal™ is the outbound event AGLedger emits when a record reaches a terminal state in a gated flow. It carries SETTLE (proceed with payment, release goods, close ticket), HOLD (do not proceed), or RELEASE (reverse a prior HOLD when dispute Tier 1 auto-overturn flips the verdict in the performer's favor). AGLedger does not move money, transfer assets, or close tickets. Your financial systems, ERP, and ticketing systems act on the signal, delivered by webhook and signed by default with Ed25519 RFC 9421 HTTP Message Signatures so the receiver verifies it against the firing Server's published keys with no shared secret. The default outbound carries the firing Server's single signature; for high-value or regulated dual-control flows, bilateral co-sign is opt-in per contract type, and the signal then carries both Servers' signatures.
Section
The accept-or-reject path for delegated work. A principal renders a verdict on the performer's completion; AGLedger holds the signed record of it. The second record path, alongside Notarize.
A Gate applies when work crosses a delegation boundary and someone other than the doer must accept or reject the delivery. The principal creates the record with criteria, the performer accepts and submits a completion, and a verdict — accept or reject — terminalizes it. AGLedger is the interface for that verdict, never the judge of the work. Most automated work needs no Gate; reach for one only across a delegation boundary.
Structured evidence of delivery in a gated flow. Submitted by the performer against the record via POST /v1/records/{id}/completions, validated against the contract type's completionSchema.
In gated flows, after the work is finished the performer submits a completion: structured evidence matching the record's contract type completionSchema. The completion is signed and chained, transitions the record to COMPLETION_ACCEPTED (or COMPLETION_INVALID if validation fails), and triggers the verdict phase. Completions are not judgments — they are submissions. In notarize-only flows there is no completion phase; the agent simply notarizes what was done as a new record. Note: "Completion" here is the evidence submission. The cryptographic inclusion proof that anchors a Signed Statement into a Transparency Service is a SCITT Receipt — a different term, see the entry below.
accept or reject, rendered by the principal on the Gate path. The principal's decision on whether the delivery met the record criteria.
Verdicts only exist on the Gate path — records with measurable criteria and tolerance bands. The principal renders the verdict via POST /v1/records/{id}/verdict (or auto-mode renders it when delivery falls inside the tolerance band). Verdicts are signed and chained. An accept verdict on a federated record fires the SETTLE Settlement Signal; a reject fires HOLD.
In a gated flow, the party that assigns the work and renders the verdict. Can be human, system, or agent.
The principal defines what success looks like (the criteria) and decides whether the delivered completion satisfies those criteria (the verdict). In Pattern D deployments — where an enterprise system is the principal and an agent is the performer — accountability stops depending on agent honesty about its own work, because the principal is the system that knows.
In a gated flow, the party that executes the record and submits the completion. Can be an agent, a service, or an enterprise system.
The performer does the work. They accept (or propose) the record, execute against its criteria, and submit the completion with supporting evidence. Performers are signing parties — completions are cryptographically attributable, not just logged.
Section
A versioned JSON Schema that defines the shape of a record's criteria and (optionally) its completion. Customer-registered, federation-shareable.
AGLedger ships zero built-in contract types. Customers register their own via POST /v1/schemas — JSON Schema draft-07, versioned, with optional tolerance rule mappings. Agents can build schemas on demand against the same endpoint. Schemas are content-addressed by manifest digest, and a Server can import a peer's schema via file exchange so two organizations speak the same vocabulary for the same kind of work — peers verify schema equality by digest, not by type name. A type with no completionSchema is notarize-only — records of that type terminalize at RECORDED on creation.
Section
An audit-vault entry surfaced to customers. Tagged COSE_Sign1 envelope (RFC 9052, tag 18) over an in-toto v1 Statement payload, deterministically CBOR-encoded per RFC 8949 §4.2.1. Independently verifiable offline against the Server's published Ed25519 public key.
Every state transition in AGLedger produces a Signed Statement. The envelope is a tagged COSE_Sign1 (RFC 9052, tag 18) with EdDSA over Curve25519; the payload is an in-toto v1 Statement structure encoded in deterministic CBOR per RFC 8949 §4.2.1. Signed Statement bytes are SHA-256 hashed and chained to the previous entry, producing the tamper-evident audit trail. Anyone with the Server's published public key can verify a Signed Statement offline using stock COSE tooling — no AGLedger account, no network access.
Cryptographic inclusion proof anchoring a Signed Statement into a Transparency Service. RFC 9162 Merkle tree proof embedded in a COSE_Sign1 envelope. Opt-in via ?receipts=true on /audit-export or via POST /v1/scitt/entries.
A SCITT Receipt is the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) working group's term for a cryptographic inclusion proof that a Signed Statement was registered into a Transparency Service. The proof is an RFC 9162 Merkle tree inclusion proof, wrapped in a COSE_Sign1 envelope signed by the Transparency Service. AGLedger emits SCITT Receipts opt-in via ?receipts=true on /audit-export or via POST /v1/scitt/entries. SCITT Receipts are distinct from Completions — Completions are performer-submitted evidence in a gated flow; SCITT Receipts are inclusion proofs from a transparency log.
A SCITT composition of a Signed Statement with attached SCITT Receipts. Returned by GET /v1/scitt/entries/{entryId}. Suitable for stock SCITT consumers.
A Transparent Statement is the SCITT-standard composition: a Signed Statement together with one or more SCITT Receipts that attest to its inclusion in a Transparency Service. AGLedger returns Transparent Statements via GET /v1/scitt/entries/{entryId} for stock SCITT consumers — tools that already speak the IETF SCITT vocabulary can consume AGLedger output without translation.
Section
Your agent that queries AGLedger to answer audit questions in seconds instead of weeks. Customer-owned, not a product we ship.
An Audit Agent is a customer-built agent that queries the AGLedger chain to answer audit, compliance, or forensic questions. Because records are structured and signed at the moment they are written, the Audit Agent can answer "did agent X do Y on date Z?" in seconds — with the signed proof attached. The Audit Agent is possessive: it is your agent, not AGLedger's service.
Section
Declare — what the agent reported it did — versus Detect — what the evidence shows. Both trails live in AGLedger.
Dual Trail is AGLedger's name for keeping two parallel records of the same unit of work and reconciling them. The declare trail is what the participant notarized (the records they signed). The detect trail is what the evidence independently shows — system-of-record events, webhook payloads, third-party confirmations. The Compliance Crosscheck compares the two; where they diverge, drift is surfaced. Mechanically it is dual logging plus a diff — what makes it evidence is that both sides are signed.
The reconciliation between Declare and Detect trails that surfaces drift between what an agent reported and what the evidence shows.
The Compliance Crosscheck runs across the Dual Trail. For each record it compares the declare entry against the detect entry from the system of record — mechanically, a diff. Agreements are the norm; disagreements are the signal: structured alerts that feed compliance dashboards, audit queries, and regulatory reports.