Core Concepts

Four ideas carry the whole system: local hashing, stamps, proof files and opt-in identity.

Local hashing

Everything starts with a SHA3-256 hash computed inside your process. The Core Service, and any infrastructure behind it, only ever sees the hash.

const proof = await ledger.stamp('quarterly report, final draft')
// What leaves the process:
// 41b1a0649752af1b28b3dc3892d7e1e7f9a7e9c3f3e0a2d... (the hash)
// What never leaves the process:
// 'quarterly report, final draft'

proof = ledger.stamp('quarterly report, final draft')
# What leaves the process:
# 41b1a0649752af1b28b3dc3892d7e1e7f9a7e9c3f3e0a2d... (the hash)
# What never leaves the process:
# 'quarterly report, final draft'

Two consequences:

• Privacy by design. Sensitive content, personal data, trade secrets: none of it is uploaded anywhere. This is what makes the system GDPR-friendly.
• You must keep the original data. A proof shows that something specific was recorded at a point in time, not what it was. A proof without its data is a receipt without the purchase.

If you pass a 64-character hex string, the SDKs treat it as a precomputed hash and pass it through. Binary data is always hashed.

Stamps

A stamp fixes a hash to a point in time in a way that cannot be quietly revised later. Stamps from all clients are batched into a single append-only accumulator per account, and the accumulator’s current fingerprint is anchored on a public ledger. Anchoring is what makes the timestamp independent: it does not rely on Sarek’s word, or yours.

Practical properties:

• A stamp takes around 10 seconds, dominated by waiting for the anchor to be confirmed. SDK calls block; the AI Accountability logger does this in the background instead.
• Batches are cheap: stamping a list produces one transaction and one proof per item.
• Stamping the same data twice produces a new, independent stamp. Old proofs are never invalidated by new stamps.

Monitor

Wrapping an AI client with monitor() intercepts every call transparently. The original client is unchanged; the wrapped version behaves identically from the caller’s perspective.

Practical properties:

• monitor() detects the provider automatically. Pass any supported client and Sarek figures out the rest.
• Every call produces a log entry and a proof. Hashing and stamping happen in the background; the AI response is never delayed.
• The raw prompt and completion never leave your process. Only the hashes are recorded.

Proof files

Every stamp returns a proof, a small binary .ldgp file (also returned base64-encoded in API responses; the encoded form always starts with TERHUA). The proof is self-contained: it carries everything needed to verify the stamp, including the anchor reference.

That makes proofs portable. You can hand a proof file and the original data to a third party, an auditor or a counterparty, and they can verify it without an account, without your systems being online, and without trusting you. See Verification.

Store proofs like you store backups. The SDKs keep them under sarek-core/ (or ai-accountability/ for the AI logger) next to a JSONL index of every stamp.

Identity

Identity is opt-in. If you only need timestamps and integrity, you never touch it.

When you do need “who”, an agent registers a P-256 key pair once. After that it can sign data offline, and anyone can verify the signature against the registered identity. Registration stores a commitment derived from the public key and a client-held salt; the commitment alone reveals nothing about the key.

await ledger.register()                    // once per agent
 
const sig = ledger.sign('release approved: build 2026.06.10')
const check = await ledger.verify(sig)
console.log(check.valid)
// true

ledger.register()                          # once per agent
 
sig = ledger.sign('release approved: build 2026.06.10')
check = ledger.verify(sig)
print(check.valid)
# True

Identities can be revoked. Revocation is itself stamped, so the moment of revocation is provable too.

The AI Accountability SDKs use a simpler, local variant: each agent gets a key pair on disk and signs every log entry with it. Those identities are not registered with the Core Service.

Six layers of proof