# Decision Keep

> Full reference: see [llms-full.txt](https://decisionkeep.com/llms-full.txt) for the complete, deep technical guide (documentation, dkr-1 format, verification and glossary).

> Decision Keep is the **independent, out-of-band forensic witness for AI and automated decisions** – the verifiable evidence layer for every AI decision an organisation makes. It sits outside your organisation's systems as **zero-knowledge infrastructure**: it never sees plaintext payloads in Custodian mode, and in Client-signs mode the private key never leaves your environment. Categorised as **Governance, Risk and Compliance (GRC) technology**, it is engineered for the agentic era of autonomous AI decisions (machine customers, AI agents and agentic commerce). Every automated decision is signed with your organisation's own key, sealed in a tamper-evident, immutable, append-only record chain, optionally time-stamped by an independent authority, and retained under a policy that supports verifiable ("cryptographic") erasure. Decision Keep is a paid, managed product: we operate the vault and stand behind the deployment, while the evidence stays yours and verifiable offline on your own key. You choose the recording model - including Custodian, where the payload is sealed to your key so we never see it in plaintext.

## What Decision Keep does

- **Out-of-band forensic witness**: Decision Keep sits outside your organisation's systems. It does not touch your AI infrastructure, your models, or your decision logic. It records the evidence independently.
- Records every automated/AI decision as a signed, tamper-evident receipt (the "black box for AI decisions").
- Chains each record to the previous one so any tampering is detectable by auditors. The ledger is immutable: entries can only be appended, never edited or deleted.
- **Zero-knowledge infrastructure**: In Custodian mode the payload is sealed to your published X25519 key so we never see plaintext. In Client-signs mode the hash and signature are produced in your environment before anything leaves it. We never hold the plaintext or the private key.
- Lets auditors and regulators verify a receipt offline against your published public key, with no account and no trust in the platform.
- Supports retention policies and verifiable erasure that removes content while preserving the integrity of the record chain.
- Provides an optional independent trusted timestamp proving exactly when a decision was signed.

## Compliance mapping

- **Category:** Governance, Risk and Compliance (GRC) technology – the evidence layer GRC platforms, auditors and regulators rely on to prove what an automated or agentic AI decision was, when, and by what model version.
- Australian Privacy Principles APP 1.7, 1.8 and 1.9 (automated-decision transparency and disclosure).
- EU AI Act automatic logging / record-keeping requirements.
- ISO/IEC 42001 and SOC 2 tamper-evident logging (IT general controls).
- GDPR storage-limitation obligations and the right to erasure (via verifiable erasure).

## Sources & citations

Decision Keep's compliance claims map to these independent, authoritative standards. The references anchor the claims for verification and further reading:

- **Australia – Privacy Act 1988, APP 1.7–1.9** – automated-decision transparency and disclosure. Decision Keep is built for the Australian market first, with local data-residency options.
- **EU AI Act (Regulation (EU) 2024/1689)** – automatic logging and record-keeping requirements for high-risk AI: https://artificialintelligenceact.eu/the-act/
- **ISO/IEC 42001** – AI management system standard: https://www.iso.org/standard/81230.html
- **GDPR (Regulation (EU) 2016/679)** – storage limitation (Art.5) and right to erasure (Art.17): https://gdpr-info.eu/
- **United States** – CCPA/CPRA §1798.105 right to delete via cryptographic erasure; Colorado AI Act and NYC Local Law 144 via the recorded record of the automated system and its logic inputs.
- **United Kingdom** – UK GDPR and the Data Protection Act 2018; automated decision-making transparency under UK GDPR Art.13–15 and 22; the Information Commissioner's Office (ICO) guidance on AI transparency.
- **NIST AI Risk Management Framework** – trustworthiness and documentation: https://www.nist.gov/itl/ai-risk-management-framework
- **RFC 3161** – trusted timestamp authority (independent proof of when): https://www.rfc-editor.org/rfc/rfc3161
- **Ed25519** – the signing algorithm behind verifiable records: https://datatracker.ietf.org/doc/html/rfc8032

## Key pages
 
- [Home](https://decisionkeep.com/): Overview of the product and the five pillars (Independent, Immutable, Verifiable, Transparent, Sovereign).
- [Pricing](https://decisionkeep.com/pricing): Managed and Premium engagements (annual licence + metered per-decision usage). Self-hosting is a contractual portability guarantee, not a separate product. SSO, key management (incl. HSM/KMS) and enterprise support available.
- [Security](https://decisionkeep.com/docs/security): Security model and enterprise controls.
- [Blog](https://decisionkeep.com/blog): Practical guidance on AI governance, automated-decision transparency, and tamper-evident evidence. RSS: https://decisionkeep.com/feed.xml.
- [Documentation](https://decisionkeep.com/docs): How to capture, record, and verify decisions, plus the API.
- [Verify a receipt](https://decisionkeep.com/verify): Public, trustless verification of any receipt against an organisation's published key.
- [Book a demo / waitlist](https://decisionkeep.com/waitlist): Request a demo and onboarding.

## Documentation

- [Capture decisions](https://decisionkeep.com/docs/capture): Sending decisions to Decision Keep.
- [Record](https://decisionkeep.com/docs/record): How signing and sealing works.
- [Decision record](https://decisionkeep.com/docs/decision-record): The structure of a decision record.
- [Compliance](https://decisionkeep.com/docs/compliance): Mapping to APP 1.7-1.9, the EU AI Act and GDPR.
- [API](https://decisionkeep.com/docs/api): API reference.

## Notes

- Recording models (selectable per workspace): **Operator-signs** (default - we hold and sign with your org key), **Custodian** (recommended - we host the ledger but seal each payload to your published X25519 key so we never see plaintext and never hold the key to read it; you unseal with your private key), and **Client-signs** (you sign in your own environment; raw payload need never reach us).
- Deployment: managed by Decision Keep (we operate the vault, back it up and monitor it), or self-hosted under the same licence as a portability guarantee. In Custodian/Client modes your keys and (sealed) payloads never expose plaintext to the operator.
- Verification is offline and trustless: no login or platform trust is required to check a receipt.

## How a decision is recorded

1. Your system sends the decision to Decision Keep (references, not raw PII). The payload is canonicalised - keys sorted, arrays order-preserving - and hashed. Decision Keep sits outside your organisation's systems: it never touches your AI infrastructure, models, or decision logic.
2. The entry is bound to the previous one by a chain hash.
  3. Your organisation's own Ed25519 key signs the chain hash. In **Operator-signs** mode the operator signs on your behalf; in **Client-signs** mode you sign the content hash in your own environment and send the signature; in **Custodian** mode the operator signs but the payload is sealed to your published X25519 key (`aes-256-gcm+x25519`) so the operator never holds the plaintext.
4. Optionally, an independent RFC 3161 timestamp authority anchors exactly when the decision was signed.
5. The signed, chained record is appended to your sovereign, immutable, append-only ledger.

## The record chain (tamper-evidence)

- **Receipt format:** `dkr-1` - an open, vendor-neutral format. The format identifier is part of the signed content hash, so a receipt is provably bound to the format that produced it. The complete specification is published at https://decisionkeep.com/docs/spec.
- **Content hash:** SHA-256 over the canonical decision - `system`, `agent`, `version`, `received_at`, `payload`, `parents` (chain of custody), `format` (dkr-1), and AI-governance capture fields (`reference_db_state`, `session_id`, `actor_id`, `actor_type`, `confidence_score`, `input_tokens`, `output_tokens`, `model_inference_ts`, `risk_score`, `overall_confidence`, `routing_outcome`, `routing_rationale`, `human_verifier_id`). Keys are sorted, arrays order-preserving, and omitted fields are never coerced to null, so the hash is reproducible by any implementation. What Decision Keep persists and verifies is this hash plus the signature - not the decision content. The customer controls the payload (send references, not raw PII); with client-side signing the hash and signature are produced in the customer's environment so raw content need never be transmitted.
- **Chain hash:** SHA-256 over `prev_hash | content_hash | receipt_id | org_id`. The first entry (genesis) is bound to the constant `decisionkeep-genesis-v1`.
- **Signature:** Ed25519 over the chain hash, using the organisation's own private key.
- Because every entry links to the one before it, editing or deleting any prior line changes its hash and breaks the chain for every later entry - detectable by your auditors.

## How verification works (trustless)

`GET /api/verify?receipt=...` independently recomputes and checks, with no account and no trust in the platform:

- **Content integrity** - recomputes the content hash from the stored decision.
- **Chain binding** - recomputes the chain hash and confirms the link to the previous entry.
- **Signature** - verifies the Ed25519 signature against the organisation's published public key (at `/.well-known/record-public-key?org=<id>`).
- **Chain anchor / continuity** - confirms the entry links back through the chain to genesis.
- **Trusted timestamp** - if enabled, confirms an independent RFC 3161 token.
- **Erasure proof** - if erased, verifies the signed cryptographic-erasure proof (the chain anchor is preserved).

Auditors can also verify the full ledger **offline** with `node scripts/verify-ledger.mjs <ledger-or-export>`, which re-checks every entry's content, chain, signature, continuity, erasure proofs and RFC 3161 tokens with no network and no trust in Decision Keep. Exit code is non-zero on any failure.

## Cryptographic erasure

When a decision passes its retention period, Decision Keep redacts its content and appends a **signed erasure proof**. The chain anchor is preserved, so downstream verification still anchors. This satisfies storage-limitation and the right to erasure (GDPR Art.17 / CCPA) without losing auditability. Scheduled erasure is triggered by `POST /api/cron/erasure` (protected by `CRON_SECRET`), e.g. from cron, systemd or a GitHub Action.

## Independent trusted time (RFC 3161)

If `TSA_URL` is set, an RFC 3161 timestamp request is built and posted to the authority; the token is stored on the record. The token's binding (message imprint + trusted time) is verified in-app, and its CMS signature is cryptographically verified in pure Node (no `openssl`) when an auditor runs `verify-ledger.mjs --verify-tsa`. This removes self-asserted `received_at` as the only proof of *when*.

## Format stability

The receipt format is versioned and stabilised. `dkr-1` is the current, frozen specification. Any breaking change ships as a new version (`dkr-2`, …) with a documented, backward-compatible migration, and receipts recorded under an older version remain verifiable forever by the versioned verifier (the API, the public /verify tool, and the offline `scripts/verify-ledger.mjs`). The verifier and the specification are open - no proprietary format and no account required to check a receipt.

## Glossary

Plain-language definitions of every concept above - append-only ledger, tamper-evident hash chain, content hash, chain hash, Ed25519, RFC 3161 trusted timestamp, cryptographic erasure, root of trust, payload minimisation, and Gold Standard audit readiness - are published at https://decisionkeep.com/docs/resources.