TunnelMind Compliance Ledger v1

A tamper-evident, customer-configurable record of agent decisions · Ed25519 + RFC 8785 JCS + SHA-256

Every time an agent asks TunnelMind to verify a destination (/v1/verify, /v1/explain, /v1/preflight, /v1/profile) it receives a signed Receipt. The Compliance Ledger retains those decisions as a per-customer, append-only, hash-chained log, and lets you export them — mapped to your regulatory regime, signed, and independently verifiable — as the evidentiary record a regulation like the EU AI Act, DORA, or NYDFS Part 500 requires. self-serve

You configure it. Pick your regime, your retention period, and your export formats — no bespoke engineering, no sales call. The format your auditor wants is a setting, not a feature request.

1 · Configure (your knob)

PUT /v1/compliance/profile        (Authorization: Bearer <key>)
{ "enabled": true,
  "regime": "ai_act_art12",
  "retention_days": 365,
  "export_formats": ["signed_json","csv","eat"] }

GET /v1/compliance/profile returns your config plus the catalog of supported regimes and formats. Anonymous callers get no ledger — it is an authenticated, opt-in record.

2 · The ledger entry & the chain

Each enabled verdict appends one entry with a per-customer monotonic seq. Tamper-evidence comes from a hash chain: every entry binds the content hash of its decision and the previous entry's hash.

record_hash = "0x" + sha256( JCS(decision_record) )
entry_hash  = "0x" + sha256( JCS({
   seq, customer_id, receipt_id, endpoint, node, verdict,
   trust_score, confidence, decided_at, record_hash, prev_hash
}) )
prev_hash   = entry_hash of (seq - 1), or "0x0" at genesis

Altering or deleting any entry changes its entry_hash, which breaks prev_hash linkage for every entry after it. The chain is the proof.

3 · Signed checkpoints

Periodically (and on every export) TunnelMind signs the current chain head with the receipt signing key (Ed25519): {customer_id, seq_high, entry_count, chain_head_hash, signed_at}. A checkpoint is a portable proof that your ledger held N entries with head H at time T — so even TunnelMind cannot rewrite history before a checkpoint without detection.

4 · Regimes

The chosen regime maps each entry to your auditor's field names and citation. Extensible — adding a regime is one mapping entry.

5 · Export

POST /v1/compliance/export?format=csv&regime=ai_act_art12&from=&to=

Every export carries a manifest: the time window, entry count, first_seq/last_seq, the live chain-integrity result, and the latest signed checkpoint.

6 · Verify it yourself

An auditor can confirm an export is authentic and complete without trusting us:

1. For each record, recompute record_hash and entry_hash from the formulas in §2 and confirm they match.
2. Confirm each entry's prev_hash equals the prior entry's entry_hash, and seq increments by 1 with no gaps.
3. Verify the manifest's signed checkpoint signature against the published receipt key, and confirm its chain_head_hash equals the last entry's entry_hash (for records up to seq_high).
4. Or simply call GET /v1/compliance/verify — TunnelMind recomputes the whole chain and returns { intact, entry_count, chain_head_hash }, or { reason, first_break_seq } if any record was altered or removed.

Tombstoned entries (content purged after your retention window) keep their record_hash and chain hashes, so the proof that a decision occurred survives even after its detail is minimised away.