Skip to main content

Evidence & Verification

Every Trinitite-governed decision is hashed, signed, and Merkle-chained into a tamper-evident ledger. Any third party can reproduce the proof in a browser — without trusting Trinitite, and even if Trinitite went offline tomorrow.

What it is​

The evidentiary layer is the substrate every Trinitite surface writes to. It has four parts:

  • The Glass Box Ledger — an append-only, Merkle-chained record of every verdict, every correction, every governance decision. Each entry carries the input hash, policy hash, outcome, corrections, and actor id; each block's hash chains to the prior block.
  • Bit-exact replay — under batch_invariant determinism, the same (input, guardian_version, policy_hash) triple always produces the same verdict, same correction_diff, same chain_hash — byte-for-byte, across batches, nodes, and restarts. A past decision can be re-executed and the resulting receipt will match.
  • External anchoring — Merkle roots are anchored via RFC 3161 timestamps and Sigstore Rekor entries. Public, externally verifiable; nobody can backdate a report.
  • Public verifier — time-limited, no-login shareable links that let an auditor recompute a Merkle root, verify KMS signatures, and resolve the anchor receipt in a browser.

Why it matters​

  • "Are we compliant?" needs evidence, not logs. A dashboard render is not evidence. A signed, anchored, reproducible receipt is.
  • Non-repudiation. The chain hash links each verdict to the prior one; altering any byte in any past block breaks the current hash. You can prove a decision happened, exactly as recorded, at the time it was recorded.
  • Auditor-portable. The verify bundle is self-contained — your auditor reproduces the proof without a Trinitite account, without API access, without trusting the vendor.
  • One ledger, every surface. Chat, proxy, MCP tool calls, CLI commands, skill loads, sampled audits, continuous-assurance events — all append to the same ledger with the same Merkle chain and the same external trust anchors.

How it works​

  1. Every governed call writes a ledger entry (ledger_id, latency_ms, policy_hash, determinism_mode, chain_hash).
  2. The entry is SHA-256 hashed over its canonical envelope and KMS-signed; the block's hash chains to the previous block.
  3. Job / day / attestation Merkle roots are anchored externally (RFC 3161 + Sigstore Rekor).
  4. A verify bundle (per-item attestation + chain hashes, recomputed Merkle root, KMS signature, anchor receipt id) is handed to the auditor.
  5. The auditor opens the public verifier link, recomputes the root, verifies the signature, and resolves the anchor — all in a browser.

Get started​

→ Glass Box Ledger — the architectural deep-dive. → Compliance Architecture — how evidence maps to frameworks. → Public Verification API — shareable, browser-verifiable receipts.

Last updated on