For selected AI-assisted actions, TCD checks the expected policy and control path before the workflow proceeds. It then leaves a signed, policy-bound receipt of the actual governed outcome — without exposing raw customer data, prompts, or model answers.
Why TCD Proof
Transaction data, KYC records, OSINT, RFI responses, notes, policy records, and model outputs may all exist. What often fails to travel with the action is the connection between the trigger, the declared rationale, the supporting and contrary evidence, the source context, and the applicable guidance. A QC or FIU reviewer may then have to reopen systems, request clarification, or reconstruct the case before deciding whether the action should stand.
The receiving reviewer needs the right information, not simply more information: what triggered the concern, the relevant customer and KYC context, the transaction and counterparty context, what expected activity or benign explanations were checked, which evidence references support the declared rationale, and which policy or guidance applied at the time.
Instead of rebuilding the decision trail from logs, screenshots, and case notes, TCD creates a bounded receipt and verification path at the time of the action.
The public verifier recomputes signed bytes, verifies an illustrative Ed25519 receipt, and checks expected policy and build bindings outside the product UI.
Public materials use synthetic data, redacted identifiers, references, hashes, bounded metadata, and explicit production boundaries — not raw customer payloads.
Primary wedge
TCD is most relevant when an AI vendor's customer may later question a selected decision, recommendation, escalation, hold, or block. The initial wedge is not every AI interaction. It is the smaller set of high-impact actions that create customer-assurance, model-risk, security-review, or audit friction.
A vendor helps a financial institution review a business, alert, onboarding case, sanctions signal, fraud indicator, or enhanced-due-diligence trigger. When the institution asks what governed one specific action, TCD provides a receipt-backed path from proposed business action to actual terminal outcome and verification.
The buyer does not need another general AI-governance framework. They need a defensible record for a selected action: what was proposed, what policy applied, what the runtime actually required, what evidence references were attached, and what another reviewer can verify later.
Two-week non-production design study
For one selected AML/KYB handoff, define what the receiving reviewer must be able to
determine: the action trigger, declared rationale, relevant customer and transaction
context, bounded evidence references, checks of expected or benign activity, applicable
policy or guidance, and the receipts expected for independently identified eligible actions.
Using synthetic or already-redacted cases, the study evaluates whether a signed,
policy-bound evidence package can reduce the need to reopen systems or request
clarification. No production connection, raw customer data, or effect on a real
customer decision is required.
Select one bounded investigation-to-QC or FIU handoff and identify the actions, receiving reviewer, and review decision the study will examine.
Define the trigger, declared rationale, required context categories, bounded evidence references, expected or benign-activity checks, applicable guidance, and receipt expectations the reviewer should be able to inspect.
Exercise the proposed contract without production access or raw customer payloads. The study evaluates the handoff and evidence structure, not the correctness of a real customer decision.
Design study scope
The study asks whether the proposed reviewer contract makes selected actions easier to inspect and reconcile. It does not claim regulatory compliance, prove that an AML conclusion is correct, or assume that a separate assurance product is needed.
Separated public proof paths
The v0.1-pilot pre-release provides illustrative Ed25519 receipts, public-key
material, strict positive and negative test vectors, and completeness reconciliation
that any reviewer can run without the private runtime.
The historical AML/KYB artifacts are a separate track generated by an authorized
local execution of the current private runtime. They use HMAC-SHA256 and local SQLite.
The private runtime has not yet been integrated with the public Ed25519 profile.
The proof package documents an actual local execution, not only an expected story. It includes provenance-labeled artifacts, a customer-facing assurance packet, explicit integration gaps, and a validation gate. All three synthetic actions were actually blocked; the historical result was not rewritten into a more attractive distribution.
What the reviewer receives
The receipt is the shareable proof artifact. Behind it sits the policy match,
actual terminal outcome, signing and key status, configuration bindings,
durable evidence references, and verification result.
The receipt proves how a selected action was governed. It does not prove that
the underlying model judgment was correct.
Buyer-facing flow
TCD sits beside a selected AI-assisted workflow. It does not replace the model, the policy owner, or the human reviewer. It establishes the action context, applies the configured controls, records the actual outcome, and produces a proof path another reviewer can check later.
Technical architecture
Once the buyer understands the action, review moment, and assurance output, the underlying implementation can be inspected in more depth. TCD connects hardened request intake, policy and decision controls, authenticated receipts, durable evidence, and verification into one lifecycle.
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
Policy, safety, calibration, risk, route, authentication, and security signals resolve into an enforceable outcome — allow, degrade, or block — which TCD records as a Terminal Contract.
Evidence layer
Receipt issuance, signing and key policy, durable evidence commits, binding checks, audit views, and restart-safe lookup make the governed action checkable outside the original application response.
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 policy, decision, or evidence components trust the event.
Reveals deeper implementation controls without exposing private source inventory.
Capabilities
The homepage stays focused on the buyer moment and the proof output. The deeper capabilities remain available for technical review once the workflow, action set, and assurance requirement are clear.
TCD establishes a bounded request surface for the selected action, including identity, transport context, idempotency, request budgets, rate controls, and stable event identity before downstream systems trust it.
A selected action can be tied to request identity, tenant, subject, workflow, route, policy reference, policy digest, receipt settings, configuration fingerprints, and runtime build identity.
Detector, calibration, multivariate, and AlwaysValid controller state can be recorded separately from the final business outcome so reviewers can inspect the control context without confusing it with the action itself.
TCD combines policy, authentication, rate, route, detector, and security signals into a concrete allow, degrade, or block instruction with enforcement mode, decision identity, route plan, and reason code.
TCD builds canonical receipt material and records the receipt head, signing algorithm, key identity, key-policy status, and verification result. The public v0.1-pilot verifier currently operates on illustrative Ed25519 vectors; the historical runtime-derived AML/KYB evidence remains HMAC-based. Deployment-specific KMS/HSM evidence can be added where configured and validated.
Receipt references, audit references, ledger or commit references, storage references, and evidence identity can be persisted without storing raw customer payloads. The demonstrated local profile supports receipt-reference verification after restart.
Verification can check receipt integrity or authentication, expected policy and configuration context, build or image bindings where supported, key status, and evidence-chain state. A genuine receipt can still fail when an expected governance binding is wrong.
TCD supports idempotent evidence flow, replay-safe lookup, bounded chain traversal, explicit failure states, and audited changes to policies, configurations, keys, calibration, patch gates, and evidence-delivery state.
Bounded metrics, structured logs, runtime diagnostics, health and readiness checks, and privacy-aware telemetry can support production review without turning operational logs into another location where customer content or secrets leak.
Two-week non-production design study
For one selected handoff, define what QC or FIU must be able to determine from the action package. Measure systems reopened, clarification requests, missing context, claim-to-evidence coverage, expected or benign-activity checks, source and guidance traceability, review time, and receipt completeness relative to an independently supplied eligible-action population — without a production connection, raw customer data, or effect on a real customer decision.