The verifiable AI-decision glossary

Glossary

Append-only ledger

A record that can only be added to, never edited or deleted. In Decision Keep each decision is one line; erasure appends a new, signed line. Tampering with any prior line breaks the cryptographic chain for every entry after it, so alteration is detectable by your auditors.

Tamper-evident (hash chain)

Each entry is bound to the one before it by a SHA-256 hash. Changing an earlier entry changes its hash, which breaks the link to every later entry. The chain is 'evident' because any modification is immediately and permanently visible.

Content hash (SHA-256)

A fixed-length fingerprint of a decision's canonical content (system, agent, version, time, payload and AI-governance fields). What Decision Keep stores and verifies is this hash plus the signature - never the decision content itself. Minimisation is enforced by the customer: send references, not raw personal data, and the ledger stays PII-free. With client-side signing the hash is computed and signed in your own environment before anything leaves it.

Chain hash

A SHA-256 over the previous entry's hash, the content hash, the receipt id and the organisation id. It is what cryptographically binds one decision to its predecessor and to its signer.

Ed25519

A modern, fast elliptic-curve signature algorithm. Each organisation holds its own Ed25519 root of trust; decisions are signed with the org's private key and verified against its published public key. Verification needs only the public key - never trust in Decision Keep.

RFC 3161 trusted timestamp

A signature from an independent timestamp authority (TSA) that proves exactly when a decision was signed, anchored outside your control. It removes self-asserted timestamps as the only proof of 'when', adding forensic, admissible evidence of time.

Cryptographic erasure

Lawful deletion that redacts the content of an expired decision and stores a signed erasure proof, while preserving the chain anchor. Storage-limitation and right-to-erasure (GDPR Art.17 / CCPA) are satisfied without losing auditability.

Root of trust

The cryptographic anchor an organisation controls. In Decision Keep it is the org's own Ed25519 key pair: signing happens with your key, and auditors verify with your published public key at /.well-known/record-public-key.

Verifiable / trustless verification

Checking a receipt with no account, no access request and no trust in the platform. An auditor recomputes the content hash, the chain hash and the signature, and (if used) the RFC 3161 token - entirely offline against the exported ledger.

Payload minimisation

The rule that you send references, not raw personal data. What Decision Keep persists and verifies is the hash and signature, not the decision content - keeping the ledger clean, portable and privacy-safe while still proving what was decided. The strongest guarantee comes from client-side hashing and signing: the content hash and signature are produced in your environment, so raw decision content never has to leave it.

Gold Standard (audit readiness)

Decision Keep's in-dashboard posture view. It exposes what is present (signed records, active hash chain, published key, retention policy, audit trail) and what is still missing (independent timestamping, external auditor, live activity, AI-governance metadata) for an evidence-ready posture.