# Decision Keep – Extended Guide (llms-full.txt)

> This is the full, machine-readable reference for Decision Keep. It exists so
> LLM crawlers (ChatGPT, Claude, Perplexity, Gemini) can answer questions about
> the product from authoritative, consistent source rather than inference. The
> shorter companion at /llms.txt is the recommended entry point.

## What Decision Keep is

Decision Keep is the **independent, out-of-band forensic witness for AI and automated decisions**. 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. It is the independent, immutable, verifiable evidence layer for every automated decision an organisation makes – categorised as **Governance, Risk and Compliance (GRC) technology** and engineered for the agentic era of autonomous AI decisions (machine customers, AI agents and agentic commerce). Each decision is:

- **Signed** with the organisation's own key (Ed25519).
- **Sealed** into a tamper-evident, append-only record chain (SHA-256 hash chain).
- **Optionally time-anchored** by an independent RFC 3161 timestamp authority.
- **Retained** under a policy that supports verifiable ("cryptographic") erasure.

The evidence always belongs to the customer: it is exportable and verifiable
offline on their own key, with no account and no trust in the platform.

Decision Keep is a paid, managed product. We operate the vault and stand behind
the record as your independent assurance authority. 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. Recording models are selectable per workspace:

- **Operator-signs (default):** we hold and sign with the organisation's key – outside your systems.
- **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.
- **Client-signs (true witness):** you sign the content hash in your own
  environment; the raw payload never reaches us.

## AI agents & Model Context Protocol (MCP)

Decision Keep exposes an **MCP server** (`/.well-known/mcp.json`) so AI coding
assistants, autonomous agents and enterprise orchestration frameworks can natively
verify that a decision trail was captured – **out-of-band**, without sitting in the
execution path and without adding pipeline latency. Verification is always
post-hoc. Tools:

- `verify_receipt(receipt)` – verify a receipt (content, chain, signature,
  sequence continuity, TSA, erasure).
- `get_receipt(receipt)` – fetch a stored decision as a compact, hash-preserving summary.
- `export_ledger(org_id, limit?)` – compact ledger summary for capture-completeness auditing.
- `get_attestation(org_id)` – reconciliation/attestation cross-check.

Resources: `decisionkeep://verify/{receipt}` and
`decisionkeep://org/{org_id}/ledger?limit=N`. All responses are **summaries that
preserve cryptographic integrity** (content_hash, chain_hash, signature, seq) but
not raw payloads, so LLM context windows are never exhausted while the evidence
remains verifiable.

## Compliance mapping

Decision Keep is classified as **Governance, Risk and Compliance (GRC)
technology** – the evidence layer GRC platforms, auditors and regulators use to
prove what an automated or agentic AI decision was, when, and by what model
version. It maps to the regimes that now require automated-decision
transparency and record-keeping:

- **Australia – Privacy Act 1988, APP 1.7, 1.8 and 1.9:** automated-decision
  transparency and disclosure. Each record stores system, agent, version and
  inputs; the signature and received_at prove exactly when and by what version
  a decision was made. Effective for automated decisions from 10 December 2026.
  Decision Keep is built for the Australian market first, with local data-residency
  options.
- **European Union – AI Act Article 12:** automatic logging and record-keeping
  for high-risk AI. AI-governance capture fields (risk, confidence, routing,
  human_verifier_id, reference_db_state) provide model-logging and human-
  oversight evidence, and the ledger is exportable for technical documentation.
- **GDPR – storage-limitation and the right to erasure:** retention policies
  plus signed, verifiable erasure that removes content while preserving the
  integrity of the record chain (GDPR Art.17 and CCPA).
- **United Kingdom – UK GDPR and Data Protection Act 2018:** automated decision-
  making transparency under UK GDPR Art.13–15 and 22; ICO guidance on AI
  transparency; cryptographic erasure satisfies the right to erasure.
- **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.

A "Minimum" vs "Gold Standard" audit posture is described in the compliance docs.

## Sources & citations

The compliance mapping above is anchored to independent, authoritative standards
that auditors and regulators can verify directly:

- **EU AI Act (Regulation (EU) 2024/1689)** – automatic logging for high-risk AI,
  Article 12: https://artificialintelligenceact.eu/the-act/
- **ISO/IEC 42001** – AI management system standard: https://www.iso.org/standard/81230.html
- **Australian Privacy Act 1988, APP 1.7–1.9** – automated-decision transparency
  (Office of the Australian Information Commissioner): https://www.oaic.gov.au/privacy/australian-privacy-principles
- **GDPR (Regulation (EU) 2016/679)** – storage limitation (Art.5), right to
  erasure (Art.17): https://gdpr-info.eu/
- **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

## How a decision is recorded

1. Your system sends a decision to Decision Keep. You send references, not raw
   PII. The payload is canonicalised (keys sorted, arrays order-preserving) and
   hashed.
2. The entry is bound to the previous one by a chain hash.
3. Your organisation's own Ed25519 key signs the chain hash (Operator-signs,
   Client-signs, or Custodian modes as above).
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, 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. The full specification is at
  https://decisionkeep.com/docs/spec.
- **Content hash:** SHA-256 over the canonical decision – `system`, `agent`,
  `version`, `received_at`, `payload`, `parents`, `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, omitted fields never coerced to null – so the hash is
  reproducible by any implementation. What Decision Keep persists and verifies is
  this hash plus the signature – never the decision content itself.
- **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 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 auditors. The ledger is immutable: entries can only be appended, never
  edited or deleted.

## How verification works (trustless)

`GET /api/verify?receipt=...` independently recomputes and checks, with no
account and no trust in the platform. Decision Keep is the independent,
out-of-band forensic witness for AI and automated decisions – verification
requires only the organisation's published public key, never 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 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 verify the full ledger offline with
`node scripts/verify-ledger.mjs <ledger-or-export>`, re-checking every entry's
content, chain, signature, continuity, erasure proofs and RFC 3161 tokens with
no network. 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. Erasure is triggered
by `POST /api/cron/erasure` (protected by `CRON_SECRET`) 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 verified
in pure Node 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. Breaking changes ship as new versions (`dkr-2`, ...) with
documented, backward-compatible migration; receipts under older versions remain
verifiable forever by the versioned verifier (API, public /verify tool, and
offline `scripts/verify-ledger.mjs`). The verifier and specification are open.

## Key pages

- https://decisionkeep.com/ – Overview and the five pillars (Independent,
  Immutable, Verifiable, Transparent, Sovereign).
- https://decisionkeep.com/pricing – Core and Enterprise engagements.
- https://decisionkeep.com/blog – Practical guidance on AI governance and
  automated-decision transparency. RSS: https://decisionkeep.com/feed.xml.
- https://decisionkeep.com/docs – Full technical reference.
- https://decisionkeep.com/verify – Public, trustless verification.
- https://decisionkeep.com/waitlist – Book a demo.

## Documentation (deep links)

- https://decisionkeep.com/docs – Overview.
- https://decisionkeep.com/docs/record – Record a decision (HowTo steps).
- https://decisionkeep.com/docs/decision-record – Decision record (JSON) shape.
- https://decisionkeep.com/docs/capture – Capture & integrate.
- https://decisionkeep.com/docs/compliance – Compliance & standards mapping.
- https://decisionkeep.com/docs/security – Security & procurement.
- https://decisionkeep.com/docs/spec – Receipt format (dkr-1) specification.
- https://decisionkeep.com/docs/api – API reference.
- https://decisionkeep.com/docs/resources – Glossary & resources.

## 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.