FAQ

A cryptographic notary for automated work. An automated system notarizes what it is about to do, then notarizes what was done — the chain holds both records byte-for-byte, signed Ed25519 and hash-chained inside a COSE_Sign1 envelope. The same protocol scales to delegation chains across services inside an organization, federation across organizations without sharing the underlying data, and federated gates that fire Settlement Signals to payment, ERP, or ticketing systems on cross-org work.

Notarize is the simple path: one party records what was done, signed and chained. Most automated work fits here. The Gate adds a second party — a principal that explicitly accepts or rejects a delivery when work crosses a delegation boundary. AGLedger is the interface that holds the signed contract, completion, and verdict. The principal renders the judgment. AGLedger does not. Notify is separate from both — a durable, signed webhook subscription that pushes record events out to the systems and people around the work, so the right humans and systems stay in the loop.

AGLedger is a cryptographic notary, not a legal one. Records are Ed25519-signed and hash-chained — anyone with the public keys can confirm a record was written at the time it was signed and has not been tampered with. That is the same primitive RFC 3161 timestamping authorities and digital signing services use. Whether the resulting record is admissible in a particular jurisdiction is a question for your counsel, not for AGLedger.

To notarize is to take a structured statement, sign it with an Ed25519 key inside a COSE_Sign1 envelope (RFC 9052), hash-chain the envelope bytes to the previous entry, and write it to disk. The act is fast (hundreds of milliseconds), self-hosted, and verifiable offline by any third party with the public keys. Two notarizations frame a long-running task: one for what the system is about to do, one for what was done.

Logs record what happened after the fact, spread across whatever systems were touched, unsigned and unstructured. AGLedger records as work happens — structured, signed, hash-chained, queryable. Logs sit alongside. AGLedger carries the trace ID from your existing observability stack inside the signed envelope so the two correlate without proxying anything. See /integrations for the join-key story.

AGLedger does not ingest your traces or proxy your calls. Each record carries the OpenTelemetry trace ID (or Langfuse, Arize, Datadog, Honeycomb equivalent) inside the signed envelope as a join-key. Pull a record from AGLedger, join on trace ID, and your existing observability stack returns the matching spans. Webhooks emit CloudEvents; OCSF v1.4.0 export feeds your SIEM. See /integrations.

They solve different problems. Policy controls (Microsoft Agent Governance Toolkit, Kong AI Gateway, Galileo, WSO2) decide whether an automated system can act. Guardrails (Composio, Snyk) shape how it acts. AGLedger records what was notarized — signed, ordered, verifiable offline. We plug into gateways and guardrails, not compete with them. A gateway says yes or no; AGLedger records what happened after the gateway said yes.

No. AGLedger is the interface for the verdict, not the source of it. On the notarize path, AGLedger writes signed records and never inspects deliverable content. On the Gate path, the principal — which may be a human or an automated agent — renders accept or reject. A deterministic rules engine can render the verdict against numeric tolerance bands as a convenience in auto mode, but the principal is the source of truth. See /gate.

Disputes auto-escalate. Tier 1 runs deterministic re-adjudication on the recorded evidence. If a verdict remains contested past configurable thresholds (DISPUTE_AUTO_ESCALATE_TIER2_HOURS and the Tier 3 equivalent), the dispute advances to a structured evidence window and ultimately to human arbitration. The chain stops at Tier 3 by design — no API path exists to short-circuit human final review. See /gate.

That is the point. The chain is durable memory. Conversation history evaporates between sessions; vector stores summarize; signed records persist byte-for-byte. When a new process picks up where the old one left off, it reads the chain to recover what was already signed for. Long-running work outlives the session that started it.

A customer-built agent that queries AGLedger to answer audit questions. Existing logs scatter the accountability story across six systems and take days to reconstruct. AGLedger records the story in structured, queryable form from the moment work starts. Point an Audit Agent at it: who notarized this? Who delivered? Was this purchase within policy? Answers come back in seconds with signed proof attached.

On gated work involving money, goods, or asset movement, AGLedger emits a Settlement Signal (SETTLE, HOLD, or RELEASE) when a record reaches a terminal state. The signal routes through webhook to a payment platform, ERP, or ticketing system. AGLedger does not move money — it produces the signed record that authorizes the system that does. Settlement Signals are the load-bearing primitive for cross-org commercial work and are covered by USPTO application 19/565,072 (filed 2026-03-12). See /settlement-signals.

A customer-defined in-toto Statement predicate. AGLedger ships seven first-class predicate kinds (record-state, settlement-signal, vault-checkpoint, schema-event, tenant-read, counter-attestation, federation-projection) and lets you register your own at POST /v1/schemas. Schemas are content-addressed by manifest digest over RFC 8785 (JCS), so two Servers share vocabulary by digest match without a central catalog. See /schemas.

You can build a signed, hash-chained ledger in a sprint. A competent engineer with AI tooling could ship one in a week or two. What you cannot build in a sprint is counterparty adoption. Federation only works if both sides speak the same protocol. Enterprise is $3K perpetual — below the procurement threshold, a line manager's signature rather than a committee's. You are paying for the network of counterparties already speaking the same protocol, not the code itself.

AGLedger is LLM-agnostic. The accountability path does not depend on model quality. The testbed runs agents from Anthropic, OpenAI, Google, and Amazon across every integration pattern. Some providers fabricate IDs or invent schema fields when asked to self-document; in deployments where the enterprise system writes the records (and the agent only triggers them), accountability works across every provider tested.

The primary path is the native REST API — fastest and most token-efficient across 193 routes. SDKs ship for TypeScript (@agledger/sdk) and Python (agledger). A CLI ships via npm. MCP is supported for agents that need it. Any system that speaks HTTP — agents, RPA bots, CI pipelines, microservices — can participate. See /api.

Yes. AGLedger is the accountability layer underneath orchestration frameworks, not a replacement. Your framework handles orchestration. AGLedger handles the signed record. They are complementary.

Single system with the SDK: hours. Fleet instrumentation: weeks, not months. If your system can talk HTTP, it is ready to participate.

Automated systems are not blocked. AGLedger itself is a record-keeping layer, not an execution gate — if it is down, the systems calling it keep operating. (If you want a hard stop before a consequential action, you put your own gate in front of it; fail-closed is a policy you set at that gate, not something AGLedger does — see /enforcement.) PostgreSQL is the single dependency — standard HA (streaming replication, Aurora/RDS) applies. The append-only chain means no data loss on restart.

In your infrastructure. AGLedger is self-hosted — records live in your PostgreSQL 17+ database, in the region you choose. AGLedger LLC never sees your data. Export your full chain anytime in JSON, CSV, NDJSON, OCSF v1.4.0, or DSSE bundle format.

By architecture rather than by contract. AGLedger is self-hosted: records live in a PostgreSQL database you operate, in the jurisdiction you choose, and nothing transits AGLedger LLC — AGLedger collects no usage data, license validation is an offline Ed25519 check, and there are zero subprocessors for customer records. Federation is peer-to-peer between Servers the counterparties run, so even cross-org evidence transport has no provider in the data path: the chain crosses the org boundary; the data does not. Air-gapped deployment is supported where requirements are strictest. Residency, transfer-restriction, and jurisdiction requirements that a SaaS vendor addresses with contract addenda are met here by the deployment model itself.

Yes. Fully disconnected operation with no phone-home licensing. Licenses are validated using Ed25519 signatures and never require outbound connectivity. The install bundle, container images, and SDKs are all redistributable through internal mirrors.

Established standards at every layer: COSE_Sign1 (RFC 9052, tag 18) envelopes over in-toto v1 Statement payloads, deterministically CBOR-encoded per RFC 8949 §4.2.1, signed Ed25519, with a SHA-256 hash chain over the envelope bytes for the audit vault. HMAC-SHA256 for API-key storage and default webhook signing, with Ed25519 RFC 9421 HTTP Message Signatures as the opt-in webhook tier — the default for Settlement Signals — verifiable against the Server's published keys with no shared secret. A separate RFC 9421-inspired Ed25519 scheme secures federation transport, with RFC 8785 (JCS) for transport canonicalization and schema digests. X25519 ECDH + AES-256-GCM for encrypted criteria transfer. SCITT Receipts (CT Merkle inclusion proofs per RFC 9162, COSE-encoded) opt-in via ?receipts=true on audit-export. Your keys — AGLedger never generates or holds private key material. See /security.

AGLedger maps to 12 articles of the EU AI Act (Articles 9, 12, 13, 14, 15, 17, 18, 20, 26, 27, 49, and 72). The mapping separates what AGLedger provides (infrastructure and signed records) from what the organization still owns (judgment, policies, decisions). The mapping is tested — the testbed runs a full EU AI Act scenario end-to-end. See /compliance/eu-ai-act.

Yes. AGLedger maps to all four functions of the NIST AI RMF (GOVERN, MAP, MEASURE, MANAGE) and to Clauses 8–10 of ISO/IEC 42001. The mappings are capability-led: AGLedger captures signed records, delegation chains, federation evidence, and Settlement Signals — these properties happen to satisfy specific control obligations. See /compliance/nist and /compliance/iso-42001.

Yes. Full chain export is available at any time in JSON, CSV, NDJSON, OCSF v1.4.0, and DSSE bundle (Sigstore-compatible) formats. SCITT Receipts can be attached to audit-export entries. Exports are formatted for regulatory submission and third-party audit.

Peer-to-peer signed-message transport between independent AGLedger Servers. Each Org runs its own Server — its own database, auth, agents, and chain. No central hub. When work crosses an organizational boundary, the originating Server sends a signed payload to the counterparty Server; the receiver verifies the signature against the originator's published public key and records the message in its own ledger. Criteria, evidence, and chain entries stay local — only the state transitions and Settlement Signals you choose to share cross the boundary. The chain crosses; the data does not. See /federation.

Three-tier dispute resolution. Tier 1: automated re-adjudication on the recorded evidence. Tier 2: structured evidence window with mediation. Tier 3: human arbitration with the complete cryptographic record of what was notarized, delivered, and where the parties diverged. Auto-escalation thresholds advance stale disputes between tiers; Tier 3 has no API short-circuit by design.

Your software keeps running. The license is perpetual, your data lives in your PostgreSQL database, and AGLedger makes zero outbound connections by default — no kill switch, no phone-home, no dependency on AGLedger LLC being in business. Licenses are validated locally with Ed25519 signatures. Security fixes are always free while AGLedger LLC operates, and the chain remains cryptographically verifiable with standard tooling (cosign, any RFC 9052 / RFC 9162 implementation) regardless of whether AGLedger LLC exists. Enterprise licensees have source access for exactly this reason.

No. AGLedger is proprietary software. The SDKs are source-visible (published on npm and PyPI). Enterprise licensees get source access for security and compliance review. AGLedger implements published IETF standards (COSE_Sign1 per RFC 9052, CBOR per RFC 8949, CT Merkle proofs per RFC 9162, SCITT architecture per draft-ietf-scitt-architecture-22, SCRAPI per draft-ietf-scitt-scrapi-09); interop with stock standards tooling is by design.