What exactly does the signature cover?

A stored canonical text payload, produced under RFC 8785 (JSON Canonicalization Scheme) at decision time. Verification re-checks that exact text against the signature and public key — it never depends on the database faithfully round-tripping a row back into the same bytes. That distinction is what makes offline verification trustworthy.

Can someone with database access rewrite history?

They can try — a trigger blocks updates and deletes on the ledger — but the guarantee doesn’t rest on the trigger. Any altered record fails signature verification, and the failure is visible to anyone holding the public key, including an auditor working entirely offline from a Trust Packet export.

What’s in a Trust Packet?

Three things: a manifest describing scope, thresholds, and the verdict breakdown; the signing public key; and every decision event with its exact canonical payload and signature, one record per line. It’s self-contained — your auditor re-verifies every record with the CLI, without dashboard access and without trusting us.

Where do the signing keys live?

In development, a key is auto-generated on first boot so the quickstart just works. In production, the signing key loads from a KMS or HSM — the private key never sits in application config. We’d rather say that plainly than let a quickstart default become a production posture.

Signed evidence

Signed at decision time. Verifiable offline.

Every verdict the gate issues becomes a decision event signed with ECDSA P-256 over RFC 8785 canonical JSON and appended to an immutable ledger. When the auditor asks “says who?”, the answer is a signature they verify against the public key — not a dashboard they have to trust.

Get started — it's free View on GitHub

The mechanisms

Why this evidence holds up

Audit evidence usually rests on trust in whoever produced it. Signed evidence rests on math — these are the four properties that make the difference.

ECDSA P-256 over canonical JSON

The signature covers a stored RFC 8785 canonical text payload — not a database row — so verification never depends on how the database serializes things back. A changed byte anywhere breaks the signature.

Append-only by trigger, tamper-evident by math

A database trigger blocks updates and deletes on the ledger. But the real guarantee is cryptographic: even someone with direct database access can’t alter a record without breaking its signature.

Graded on the DEMM ladder

Each record carries its Decision Evidence Maturity Model grade, L1 Ad-hoc to L5 Reconstructable. A quarterly screenshot never leaves L1; a record AnchorGate signs is built to replay who, what, which policy, and why.

One schema, three languages

The Decision Event Schema is a single JSON Schema from which the Go, Python, and TypeScript types are generated and drift-checked in CI — the proxy, engine, and dashboard can’t quietly disagree about what a decision record is.

Governance & evidence

Evidence that survives the question “says who?”

One export: a manifest of scope and thresholds, the signing public key, and every decision event with its exact canonical payload and signature. Your auditor re-verifies each record offline — against the key, not against our word. If a byte changed anywhere, verification fails. Every record maps onto EU AI Act, ISO/IEC 42001, and SOC 2 control catalogues.

No dashboard access required — the packet is self-contained.
Signatures cover a stored canonical payload, so verification never depends on database round-tripping.
Each record carries its DEMM grade: how far up the ladder from “screenshot” to “reconstructable” it stands.

In the box

What ships today

ECDSA P-256 signature on every decision event
RFC 8785 canonical JSON — signature covers stored canonical text
Append-only ledger on a TimescaleDB hypertable
Database trigger blocks updates and deletes
DEMM grade L1–L5 on every record
Trust Packet export: manifest, public key, signed events
Offline verification: anchorgate verify events.jsonl --key public_key.pem
Decision Event Schema generates Go, Python, and TypeScript types
Dev signing key auto-generated; production keys load from a KMS or HSM

As shipped in AnchorGate v0.1 — every line above is checkable against the repository.

L5: DEMM evidence grade — signed, re-verifiable offline
P-256: ECDSA curve, signing RFC 8785 canonical JSON
1: JSON Schema generating the Go, Python, and TypeScript types

Signing scheme and schema pipeline as shipped in AnchorGate v0.1.

Works with the rest of the gate

Compliance Posture

Control catalogues for the EU AI Act, ISO/IEC 42001, and SOC 2 map directly onto decision evidence. Posture is computed from what the gates actually did — not from a policy document.

Learn more →

Policy Enforcement

A deterministic policy DSL — IF condition THEN redact, alert, or block — compiled, human-approved, and evaluated before a request leaves. No LLM judging LLMs: the same input always gets the same verdict.

Learn more →

FAQ

Signed evidence questions

What exactly does the signature cover?: A stored canonical text payload, produced under RFC 8785 (JSON Canonicalization Scheme) at decision time. Verification re-checks that exact text against the signature and public key — it never depends on the database faithfully round-tripping a row back into the same bytes. That distinction is what makes offline verification trustworthy.
Can someone with database access rewrite history?: They can try — a trigger blocks updates and deletes on the ledger — but the guarantee doesn’t rest on the trigger. Any altered record fails signature verification, and the failure is visible to anyone holding the public key, including an auditor working entirely offline from a Trust Packet export.
What’s in a Trust Packet?: Three things: a manifest describing scope, thresholds, and the verdict breakdown; the signing public key; and every decision event with its exact canonical payload and signature, one record per line. It’s self-contained — your auditor re-verifies every record with the CLI, without dashboard access and without trusting us.
Where do the signing keys live?: In development, a key is auto-generated on first boot so the quickstart just works. In production, the signing key loads from a KMS or HSM — the private key never sits in application config. We’d rather say that plainly than let a quickstart default become a production posture.

One gate. Every decision on the record.

Stop assembling audit evidence after the fact. Route the traffic through the gate and the evidence writes itself — signed, graded, and exportable.

Deploy the stack

or email hello@anchorgate.ai