Eight sections — from The Question No AI System Can Answer to What You Receive.
Ask any AI system deployed in a consequential domain — financial services, healthcare, legal, defense, critical infrastructure — one simple question:
No production AI system today can answer this question. Not partially. Not approximately. Not at all.
This is not a model quality problem. It is not a hallucination problem. It is not a prompt engineering problem. It is an architectural absence: the machinery required to classify, label, and gate claims by provenance before they enter the decision pipeline simply does not exist in current AI architectures.
Claims from fundamentally different origins — some derived from training, some retrieved from external sources, some declared by operators, some asserted by users with no verified credentials — enter the decision pipeline identically. They are not distinguished. They are not labeled. They are not subject to origin-specific admission rules. And when a decision goes wrong, there is no recorded evidence explaining why any particular claim was treated as credible.
This is the provenance gap. It exists at the decision layer — below prompt guards, below model alignment, below policy documentation. And it is precisely the layer where regulators, auditors, and litigators will look when they ask: why did this system act on this claim?
The provenance gap is abstract until it manifests in a specific decision, in a specific domain, with specific consequences. Here is what it looks like:
A credit risk model incorporates data from three market feeds, internal analyst overrides, and macroeconomic projections from a third-party model. During a review, auditors discover one feed served stale data for eleven days. The model continued producing assessments. No record exists of which assessments relied on the stale feed, because the system does not distinguish between its input sources. No mechanism flagged the contradiction between the stale feed and the live ones.
Which decisions were contaminated? The system cannot tell you. Neither can anyone else.
A clinical AI recommends a treatment protocol. The recommendation combines published guidelines, statistical patterns from training data, and patient-reported symptoms. The attending physician disagrees. Neither the system nor its operators can identify which claims supported the recommendation, where those claims originated, or whether patient-reported data was cross-referenced against clinical records.
On what basis should the physician trust — or override — this recommendation?
An autonomous platform receives conflicting inputs from multiple sensor arrays and a remote operator override. The decision engine treats all inputs identically. When one array disagrees with the others, the system has no mechanism to distinguish between input types, no ability to weight the disagreement, and no way to halt when the conflict exceeds a safety threshold.
What happens when the system acts on the wrong input? Who explains why it did?
These are not hypotheticals. They are the normal operating conditions of AI systems in consequential domains. The only variable is whether the system has the architectural machinery to handle them — or whether it silently acts on unvetted claims and hopes for the best.
The market offers three categories of AI governance. All three are valuable. None of them operates at the layer where provenance is actually determined.
Prompt-level controls intercept the system's output. They cannot see — let alone classify — the claims that entered the decision pipeline. A prompt guard can prevent the system from saying something harmful; it cannot prevent it from acting on an unvetted claim internally.
Model alignment and fine-tuning improve the model's average behavior across many interactions. They do not provide per-decision guarantees. A well-aligned model can still accept an unverified assertion from an external source and weigh it identically to a verified fact from a curated knowledge base.
Policy frameworks and documentation describe what the system should do. They produce model cards, risk assessments, and governance charters. They do not produce evidence artifacts for individual decisions. When an auditor asks "why did the system trust this specific claim in this specific decision," a model card cannot answer.
The gap is architectural, not procedural. No amount of documentation, prompt engineering, or model training can substitute for a decision-layer component that gates claim admission by provenance. The machinery either exists in the architecture, or it doesn't.
The Truth Arbitration Agent is a specification for a decision-layer component that closes the provenance gap. It operates as a gate between raw claims and governed decisions. Every claim that seeks to influence a consequential operation must pass through this gate. The gate determines whether the claim's origin and vetting status meet the requirements for admission — and records enough evidence for every determination to be fully reconstructed after the fact, by someone who was not present when the decision was made.
The agent does not decide whether a claim is true. It decides whether the claim is admissible — whether its origin and status qualify it for use in a governed decision. This boundary is fundamental. By constraining the agent's authority to admissibility, its guarantees become deterministic and verifiable.
The specification is ready-to-build and execution-neutral. It does not prescribe a programming language, framework, or runtime. An engineering team receives a complete behavioral specification; they choose how to implement it.
The agent decides admissibility, not truth. This is the architectural decision that makes the guarantees tractable.
TAA provides four guarantees. These are structural properties of the specification — they hold regardless of implementation choices.
How these guarantees are achieved — the contracts, logic, and machinery that produce them — is the content of the specification.
TAA is domain-agnostic. The specification defines provenance arbitration mechanics; the policy layer — configured per deployment — determines the domain-specific rules. TAA applies wherever AI decisions carry consequences that demand traceability:
Algorithmic trading, credit risk, AML — regulatory frameworks increasingly require decision provenance at the mechanism level. TAA provides the per-decision evidence artifacts that regulators are beginning to ask for.
Clinical decision support under strict liability. Every claim in the recommendation chain must be traceable to its source, with evidence sufficient for regulatory review.
Decision provenance as a mission-critical requirement. When provenance cannot be verified, the system halts rather than acts. Optional hardware trust pairing for environments where software-only assurance is insufficient.
AI-assisted research and analysis where every cited source must be traceable and distinguished from generated content.
SCADA, ICS, industrial AI — conflicting inputs must be detected and gated before they influence control decisions.
RAG, agent orchestration, multi-model architectures — TAA serves as the provenance gate ensuring every claim is classified before it enters the decision chain.
The §07 content reduces to a single configuration: Standalone. The agent is delivered as a Single-agent Pack: a complete specification document package, distributed free of charge. The pack contains the normative specification, the canonical semantic indices (D1–D4), the Conformance Tests, this whitepaper, and the README. Your engineering team builds the agent from the specification, integrates it with the systems it must observe, and operates it as the role that specification defines. The pack is execution-neutral; it does not prescribe a programming language, framework, or runtime.
TAA operates as an independent provenance gate. Self-contained specification. No dependencies. This is the entry point for organizations solving a specific provenance problem in a specific system.
Standalone solves a scoped provenance problem in a specific system
The Truth Arbitration Agent specification is a ready-to-build, execution-neutral normative document. It is not a concept paper, not a framework, not a set of guidelines, and not an architecture diagram.
It is the document you hand to an engineering team when you want them to build a provenance arbitration gate that produces the guarantees described in this whitepaper. The engineering team does not need to make design decisions about what the agent should do, how its logic should work, what it should record, or how it should fail. Those decisions are made. The specification contains them.
| Package | What you get | Best for |
|---|---|---|
| StandalonePKG-A | The complete agent specification — sufficient for independent implementation. | Solving a specific problem in a specific system. |
The specification includes everything necessary for implementation: the agent's identity and boundaries, its contracts with external systems, its complete internal logic, the rules governing every possible input, the evidence it must produce, the way it handles failures, the conditions for resuming after a failure, and the criteria your team uses to verify that their implementation is compliant.
Nothing is left undefined. Nothing is left to interpretation. Nothing requires your team to reverse-engineer intent from ambiguous prose.
Every whitepaper in the library is free to read. Every specification is distributed free of charge. Free to use, free to verify, free to publish about — free to implement and to embed in your own products, including commercially. The license sets out what is reserved. The whitepaper shows you the problem and the promise. The specification gives you the solution.
Independent Research · Specification-Grade AI Governance.
This whitepaper describes the problem the Truth Arbitration Agent solves and the outcomes it guarantees. It does not describe the agent's internal mechanisms, design decisions, or specification structure. The specification is a separate deliverable, distributed free of charge.