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
When a regulated customer asks how a specific action was governed, internal logs
are often difficult to share or verify independently. Engineering exports logs,
product explains configuration and policy versions, and compliance reconstructs
the review path from screenshots and case notes.
TCD turns that evidence into an automatic output of the workflow rather than a
manual reconstruction project after the fact.
The model output may be available. The logs may be available. The case notes and policy record may also exist. But the buyer still needs one reviewable record showing which policy controlled the action, what outcome the runtime actually enforced, and whether the proof remains valid outside the original application.
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.
Verification checks the authenticated receipt and expected binding context independently of the original application response and product interface.
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 pilot
The pilot is designed to answer one narrow commercial question: can a selected set
of AI-assisted actions produce evidence that a regulated customer can review without
exposing raw customer data?
Synthetic or redacted data is accepted. No production deployment is required.
Select one bounded workflow such as AML/KYB alert review, onboarding control, underwriting review, or claims escalation. The pilot does not attempt to govern the entire product.
Define the proposed business actions, expected policy context, evidence references, and buyer-facing workflow consequences. The actual runtime outcomes are preserved rather than forced into a predetermined demo story.
The pilot can begin without real customer payloads. Public-safe artifacts exclude raw prompts, model answers, documents, signing secrets, private logs, and runtime source code.
Pilot scope
The goal is not to claim full regulatory compliance or prove that the AI answer is correct. The goal is to demonstrate whether selected actions can be governed, authenticated, challenged against expected bindings, and verified after restart.
Run-derived public proof
The public repository now separates illustrative product-shape examples from
run-derived artifacts generated by an authorized local execution of the current
private runtime.
The latest pilot executed three synthetic actions. All three were blocked under
the current runtime profile. That result was preserved rather than rewritten to
create a more attractive allow/degrade/block distribution.
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.
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. 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 pilot
Use synthetic or redacted data. No production deployment is required. The pilot maps the workflow and action set, generates run-derived receipts, demonstrates successful verification and a real binding failure, verifies again after restart, and delivers an assurance packet with integration gaps and production boundaries.