When an AI workflow makes or recommends a decision — for example KYB review,
lending triage, or claims escalation — TCD Proof records what policy applied,
what action was required, which evidence references were used, and whether the
receipt verifies.
It does this without storing the user’s raw question or the model’s answer.
Why TCD Proof
Logs can show that an AI request happened. They usually do not show, in one place,
which policy or SOP version applied, what action was allowed or blocked, what evidence
references were used, and whether the record can be checked outside your product.
TCD Proof packages those details into a signed receipt, without storing raw prompts,
answers, or customer payloads.
Imagine your AI product helps review a business for KYB. The customer does not just ask for the model score. They ask which SOP was active, which policy version applied, whether human review was required, and whether the receipt can be verified outside your product surface.
TCD Proof binds selected AI actions to identity, route, decision, policy, configuration, risk-control state, and receipt metadata so the event can be reviewed as a governed systems event.
Policy, routing, safety, security, and risk signals collapse into a normalized allow, degrade, or block contract with enforcement mode and reason semantics.
TCD separates public proof, verification surface, audit view, storage reference, and ledger state. The proof surface is designed around references, hashes, bounded views, and sanitized metadata.
Technical architecture
TCD Proof adds a control layer around high-stakes AI workflows. It connects the action, governing policy, decision path, human review state, and signed evidence so selected AI actions can be checked later without exposing raw customer or case data.
Inference layer
A hard ingress boundary establishes identity, transport context, request budgets, rate controls, and envelope validity before downstream components are allowed to trust the event.
Decision layer
Safety detection, conservative calibration, AlwaysValid risk control, policy binding, strategy routing, and security orchestration resolve into a single enforceable Terminal Contract.
Evidence layer
Attestation, receipt issuance, durable evidence commits, chain verification, audit views, and replay surfaces make the governed event externally checkable.
The ingress plane receives live AI traffic through hardened HTTP and gRPC surfaces. It establishes request identity, authentication context, rate limits, body/header budgets, idempotency, and a strict envelope before downstream risk or evidence components are allowed to trust the event.
Reveals deeper implementation controls without exposing source inventory.
Receipt layer
A receipt is a compact verification artifact, but it is backed by a broader control plane: request identity, policy binding, calibrated risk state, Terminal Contract, attestation metadata, storage references, and verification evidence.
Governed flow
TCD Proof is designed around a receipt-first, evidence-safe lifecycle: a governed AI action enters through a hardened request envelope, passes risk and policy control, resolves into a Terminal Contract, commits durable evidence, and returns a verification surface that can be checked outside the app.
Runnable proof path
The Quickstart exercises the complete local proof path: a governed /diagnose
request enters through the HTTP surface, PolicyStore and SecurityRouter resolve a
Terminal Contract, TCD issues signed decision and commit receipts, persists receipt
references and evidence-chain state in SQLite, and verifies the result by receipt
reference, verification bundle, top-level receipt material, storage-window chain
traversal, and after process restart.
This is the fastest way for reviewers to see what TCD Proof actually produces: not just a diagram or policy claim, but a signed, committed, restart-safe receipt path with independent verification outputs.
Use cases
TCD Proof is useful when a bank, insurer, lender, compliance team, or public agency needs to review what happened after an AI-assisted action. It gives the vendor a signed record showing which policy or SOP applied, what action was allowed or blocked, which evidence references were used, and whether the record can be checked outside the product UI.
A vendor helps a bank review a business: ownership, sanctions exposure, adverse media, fraud signals, or escalation risk. The bank’s compliance team asks: “For this specific AI-assisted review, which SOP was active, which policy version applied, what action did your system require, what evidence did it reference, and can we verify the receipt ourselves?”
Platform teams often run several models, customer-specific policies, and different review workflows. Without one receipt format, every customer review becomes custom work. TCD Proof gives them a shared way to record the request identity, active policy, route decision, signature, build/config state, evidence references, and verification result.
Capabilities
A TCD receipt is backed by checks before, during, and after an AI-assisted action: request limits, identity, policy version, risk state, route decision, signature, evidence references, verification results, replay behavior, and runtime changes. Reviewers can see what was checked, what was recorded, and what can be verified without exposing raw prompts, answers, cookies, auth headers, or customer payloads.
TCD checks each HTTP or gRPC request before downstream systems trust it: body size, header size, vector size, chain length, authentication context, rate-limit zone, idempotency key, and stable event identity. If the request is malformed, oversized, overloaded, or unsafe to process, the failure path is explicit.
Each selected action can be tied to the request identity, event identity, tenant, subject, route, policy reference, policy digest, receipt settings, config fingerprint, and runtime build identity. This lets a reviewer ask: “Which rule set was active for this action?”
TCD converts risk signals into controller state, including e-process and alpha-wealth values. The receipt can record the controller mode, guarantee scope, selected source, and risk-budget state separately from the final business decision, so reviewers can see both the outcome and the statistical guardrail behind it.
Detector outputs are deterministic for the same request and configuration. Calibration state is recorded through stable digests, evidence is sanitized and bounded, and timeout or error paths can fail closed instead of silently passing through.
TCD combines policy match, authentication result, rate-limit result, detector evidence, route choice, and security signals into one Terminal Contract. Downstream systems receive a concrete instruction — allow, degrade, or block — with enforcement mode, route plan, decision identity, and reason code.
TCD builds a canonical receipt body, records the receipt head, signing-key identity, key policy, signature status, and rotation or revocation readiness. Where available, deployments can add hardware-root or HSM/KMS-backed signing evidence and return a report that can be checked outside the app.
TCD can persist receipt references, audit references, ledger heads, commit references, storage references, outbox state, and evidence identity. The evidence record avoids raw prompts, completions, cookies, auth headers, and customer payloads; it keeps references, hashes, and bounded metadata instead.
TCD can produce a verification result for the receipt body, receipt head, signature, policy binding, expected config/build/image fingerprints, chain window, and evidence references. A reviewer can check the receipt without relying only on your product UI.
TCD keeps receipt lookup, idempotent writes, prepare/commit evidence flow, restart-safe access, replay-safe lookup, chain traversal, and explicit failure states. A receipt should still be checkable after restart, retry, or recovery.
When policies, configs, keys, calibration settings, patch gates, trust settings, or evidence-delivery retries change, TCD records the change as an audited action. The system can track rollback or compensation paths and keeps the business result separate from the evidence result.
TCD can export bounded metrics, structured logs, runtime diagnostics, health and readiness checks, hardware/runtime evidence, and privacy-aware telemetry. The goal is to make operations reviewable without turning logs into a place where customer content or secrets leak.
Async demo
The async demo pack includes a short screen recording, redacted full-chain summary, minimal Quickstart, sample signed receipt, verification report, and an architecture walkthrough covering request envelope, Terminal Contract, evidence commit, and external verify.