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 webhook 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, while the Gate carries the principal's verdict on the work. 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 a session resets, expires, or is succeeded, the chain holds the original record byte-for-byte.
An agent runs when triggered and starts each run with an empty context, by design: a fresh start costs less and reasons better, and conversation history does not carry over. Hash-chained, signed records persist byte-for-byte, indefinitely. When work spans a reset or a new session, the next session of the same agent reads the chain to catch up on what was already signed for: who asked, on whose authority, what was sent to other agents, and where it stands. The practice is to write the work down before, during and after, and read it back after every reset.
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.
The open protocol independent agents use to delegate tasks to each other. AGLedger serves A2A 1.0 and 0.3.
A2A lets agents run by different teams, vendors, or platforms work together without sharing internal state, memory, or tools. The agent that receives a task is the remote agent. On AGLedger a record maps to an A2A task, and every record in one delegation chain shares one A2A context. The dialect is chosen per request by the A2A-Version header.
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 exchange signed messages over HTTPS once their operators have peered them, a one-time handshake per direction using a single-use token; there is no central coordinator and 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 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, which names the receiving Server, against the key the originator registered when the two were peered, and records the message in its own ledger. Peering is a one-time handshake between the two operators, not a membership in anything: there is no central coordinator and no shared store, and 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; they are not separate 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.
The Settlement Signal™ webhook 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 a dispute is resolved OVERTURNED 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. The principal you designate renders that verdict; AGLedger holds and serves it, signed. 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. On a gated flow that carries a settlement (money, goods, or asset movement), an accept verdict fires a Settlement Signal webhook carrying SETTLE and 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). When 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. Completions are cryptographically attributed to the performer - the notary signs, naming them - 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-2019-09 (draft-07 schemas are also accepted), 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. It is your agent, not an AGLedger 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, with both sides 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.