A practical architecture for making AI decisions verifiable
A loan is denied. A resume is filtered. A medical image is misread. Someone asks: why, and can you prove the decision was compliant? For most AI systems deployed today, neither question has an answer. The Trust Stack is a proposed architecture for closing that gap — not by auditing AI better, but by building a separate layer beside it whose only job is to verify.
AI is moving into consequential decisions — credit, health, hiring, justice — faster than the tools that make it accountable. Today's compliance rests on three fragile answers. The first is a post-hoc narrative: someone reconstructs what probably happened. The second is a vendor assurance: "our model is tested and certified." The third is silence.
None of these survive a serious regulator, a determined plaintiff, or a skeptical auditor. The EU AI Act, Australia's emerging AI governance frameworks, and equivalent legislation worldwide are converging on a common demand: demonstrable, traceable, accountable AI decision processes. The compliance requirement has moved from discretionary to mandatory. The tooling has not caught up.
AI vendors cannot expose proprietary model weights. Regulators cannot accept "trust us." Users have privacy rights over their data. Existing audit frameworks require at least one of these to yield. The Trust Stack is designed so that none need to.
The accountability gap isn't closed by building better AI. It's closed by building something beside AI whose only job is to verify. The AI vendor (the Data Plane) does what it does well: intelligence, pattern-matching, content generation. The Trust Layer (the Control Plane) does something entirely different: it verifies that outputs were produced within agreed-upon rules, and issues a cryptographic record when they were. It has no generative capability. It cannot make a decision — only certify one.
This separation is the foundational move. It makes the liability question assignable without forensic reconstruction. If a Trust Token was validly issued and harm still occurred, the Data Plane carries the risk. If a Trust Token was issued in error, the verifier carries it — and the slashing mechanism applies. Courts still adjudicate; regulators still penalise. But the argument stops being "what happened?" and starts being "who is responsible for what the record shows?" That is a very different conversation. No more "we tested it," "the model is proprietary," "we can't reconstruct what happened." The rules are either checked or they aren't, and there is a cryptographic record either way.
No, and the difference matters. ISO 42001 and SOC 2 are process certifications — they attest that an organisation follows a governance framework, not that any individual decision complied with any specific rule. Constitutional AI and RLHF are training-time techniques for shaping model behaviour. They work on the model; they produce no record at inference time. Model cards and audit frameworks describe systems; they don't certify decisions. The Trust Stack is a runtime protocol that produces a per-decision cryptographic record. It composes with all of the above rather than replacing them. The analogy: ISO certifies that your factory has a quality system. The Trust Stack stamps each part that leaves the line.
The Trust Stack is five layers stacked together. Each one fixes a problem that, left alone, would sink the whole system. None of them stand alone. The power is in the composition.
L0 — Governance. A standards body (an "IETF for AI") maintains the protocol. Jurisdiction-specific regulatory modules load at runtime. Certified auditors are licensed to operate validator nodes.
L1 — Legal Engineering. A domain-specific language (DSL) translates legal text into machine-verifiable atomic constraints. "Protected attribute was not used as a model input" becomes a function, not an opinion.
L2 — Validation. Zero-knowledge proofs verify constraint compliance without exposing model internals or user data. Multi-party consensus between independent validators issues the Trust Token. Validators are paid to check; they are slashed if they check wrong.
L3 — Execution Interface. Handles the speed/security tradeoff. Low-stakes decisions use optimistic validation (act now, audit after). High-stakes real-time decisions operate within pre-certified Validity Windows.
L4 — Trust Token. A cryptographic proof of process, traceable to the specific constraint version and model state at the moment of decision. Immutable. Queryable. The record that ends "we can't reconstruct what happened."
The abstractions above are doing a lot of rhetorical work. Here is what actually happens the moment a single consequential decision is made.
The setup. A regional bank runs an AI-assisted credit decisioning model. The bank's jurisdiction is Australia, so the AU Regulatory Module is loaded; the module contains a curated library of Atomic Constraints written by Legal Engineers. The model is licensed from a third-party vendor and runs in the bank's own infrastructure. A loan application from one Ms. Nguyen arrives through the online channel.
The decision. The model scores the application at a decline threshold. Before the denial is issued to the customer, the decision is routed through the Control Plane. The Trust Layer does not see Ms. Nguyen's protected attributes. It does not see the model's proprietary weights. It sees only the inputs required to run the verification circuit: the constraint specification (versioned, signed), a zero-knowledge proof from the model that the constraint circuit executed over the actual inputs used, and the resulting boolean for each constraint.
The verification. Three Atomic Constraints are checked against this particular decision: (1) no protected variable was used as a direct model input; (2) the confidence score exceeded the bank's internal decision threshold for adverse action; (3) for adverse actions in this tier, a human review trigger was fired before execution. All three return true. The three validator classes — government-adjacent, academic, industry — co-sign. A Trust Token is issued.
The record. The Trust Token references the exact constraint version, a hash of the model state at decision time, the ZK proof hash (not the proof itself, which may be large), the three validator signatures, a timestamp, and the jurisdiction module. It does not contain the decision inputs, the decision output, or anything about Ms. Nguyen. Those remain with the bank under its data obligations. The token is small, queryable, and immutable.
The consequence. Six months later, Ms. Nguyen files a discrimination complaint. The regulator requests proof of constraint compliance for the specific decision. The bank produces the Trust Token. The regulator verifies the signatures, checks the constraint version, and confirms the three constraints returned true at the moment of decision. The matter moves from "reconstruct what probably happened" to "here is the record." If the record is challenged, the argument is about the constraints themselves — not whether compliance was checked.
Nothing in this example is science fiction. Each piece — constraint DSLs, ZK circuits for structured computations, multi-party signature schemes, immutable record stores — exists in production today. The Trust Stack's contribution is the composition.
The hardest failure to engineer around isn't technical — it's political. If one company or one government controls the verification layer, you've rebuilt the 2008 rating-agency problem in a new wrapper: opaque judgment, single point of corruption, perverse incentives. The Trust Stack avoids this by requiring three independent validator classes to agree before a Trust Token is issued for any high-stakes decision.
Government-adjacent nodes are operated by regulators or accredited public institutions. They bring jurisdictional legitimacy. Industry-standard nodes are operated by certified auditors accredited by the standards body. They bring operational competence and scale. Academic nodes are operated by accredited universities or research institutions. They bring independence from commercial incentives.
Collusion requires compromising three structurally different institutions simultaneously — exponentially harder than corrupting a single clearinghouse. The structure is politically viable precisely because no single party controls it: each class endorses a standard knowing the other two check them.
None of this works without people who can translate legal text into atomic constraints. The closest historical analogy is the actuary, who emerged when insurance needed to price risk mathematically rather than by intuition. The Legal Engineer occupies the same translator role for AI governance — neither pure lawyer nor pure engineer, but the bridge between them.
Their work is incremental. Rather than formalising an entire regulation at once, they identify Atomic Constraints — narrow, verifiable rules that can be specified, versioned, and composed. A regulatory module is a curated library of atomic constraints; the same validation engine runs all modules.
"Protected variable X was not used as a model input."
"Output confidence was above threshold Y before decision was executed."
"Human review was triggered for decisions above risk score Z."
The commercial logic follows the model of every other trust infrastructure in the economy. Cost sits with the deploying enterprise (the party that benefits from issuing verifiable decisions), analogous to how merchants pay card-network fees or issuers pay certificate authorities. Validators earn fees for each Trust Token issued, priced per decision class — cheap for batch low-stakes verification, material for real-time high-stakes issuance. The standards body is funded by certification fees and a small levy on token issuance, closely modelled on how ICANN or the IETF sustain themselves. Slashed validator stakes fund a restitution pool. None of this is novel — it's the same architecture that underwrites SSL, interbank clearing, and aviation certification. The protocol just ports it into AI.
A 30-second multi-party consensus handshake cannot sit between a self-driving car's sensor and its brake. Nor should it sit between a content recommender and its next suggestion. The Trust Stack resolves the speed/security tradeoff by tiering decisions by reversibility and latency tolerance, and applying a different verification pattern to each.
Borrowing from Layer 2 blockchain scaling (Optimistic Rollups), low-stakes reversible decisions proceed immediately and post their proofs to the audit layer asynchronously. If post-audit reveals a constraint violation, slashing and rollback mechanisms activate. Appropriate for reversible decisions: content recommendations, document classification, pre-approvals.
For irreversible real-time decisions, the protocol does not audit individual decisions — it audits model state. At a cadence calibrated to the use case (illustratively, ~60 seconds for a real-time triage system; longer for systems with slower drift), the model's current state is certified against its constraint specifications. Any decision made within a valid Window inherits that certification. This is also the answer to an objection that ZK-proof skeptics will raise immediately: individual zero-knowledge proofs over non-trivial model computations are expensive, and the latency is non-trivial. True — which is why we don't prove individual decisions at real-time speed. We prove the envelope once, then issue many decisions inside it. The cost and latency of verification amortises across every decision within the Window.
If the model drifts outside constraints, the Window expires and decisions require explicit re-certification before execution resumes. This is how you run real-time AI safely at scale: not by auditing every decision, but by auditing the envelope within which decisions can occur.
Aircraft cross international borders safely because ICAO separated two things that seem inseparable: the standard (physics of flight, safety minimums, communication protocols — universal and technically determined) and the regulation (how each country implements and enforces those standards — variable and politically determined).
The Trust Stack adopts this architecture. The protocol is universal. Regulatory Modules are jurisdiction-specific constraint libraries loaded at runtime. A multinational bank runs one Trust Stack instance and swaps modules by jurisdiction — the same ZKP engine, the same Trust Token format, the same validator network, different specification files.
The obvious objection: aviation standards work because there's hard physics underneath. AI does not have hard physics in the same sense — many of its hardest questions are contested values, not safety minimums. True. That is precisely why the governance architecture matters more, not less. Physics handles itself; values require structure. The Trust Stack doesn't pretend to resolve the contested values — it forces them to be specified, versioned, and contested in the open.
This architecture is politically viable precisely because no single party controls it. Governments, industry bodies, and academic institutions can each endorse a standard that requires the others to collude before it can be corrupted.
Four forces are converging to make this moment — the transition from the AI "wild west" era into the regulatory era — the one where an AI trust layer becomes necessary rather than theoretical. Three of them are already in motion. The fourth is the catalyst: when it lands, it activates the other three simultaneously.
Regulation is the floor. The EU AI Act enters enforcement in August 2026; Australia's AI governance frameworks follow. Compliance has shifted from discretionary spend to mandatory overhead. This is the slowest force but the most durable.
Insurance is the accelerator. AI liability coverage is emerging as a required purchase for enterprises deploying in consequential decisions. Underwriters need structured audit trails to price risk intelligently. The first insurer to offer a material premium discount for Trust Token compliance reshapes the commercial logic overnight — risk officers respond to premium pricing before they respond to regulatory threat.
Procurement is the propagator. A single NHS, Federal agency, or Tier-1 bank procurement requirement mandating verifiable AI audit trails forces every vendor in that supply chain to comply. One large enterprise customer can reshape an entire vendor ecosystem.
Litigation is the punchline. The first significant AI harm case where the defendant cannot produce a verifiable audit trail — and plaintiff counsel makes that absence central — changes the calculus for every general counsel watching. That case is coming, and probably soon.
The internet didn't destroy industries — it destroyed the information asymmetry those industries were built on. AI is doing the same to expertise asymmetry. The second-order consequence of both disruptions is identical: when the capability becomes infrastructure, value migrates to the trust layer.
The Trust Stack is proposed as that trust layer for the AI era — not a compliance dashboard, not a better audit tool, but a protocol. With a governance model, a standards body, a validator network, and a shared language that separates infrastructure from product.
The components already exist. Zero-knowledge proofs are production-ready for structured constraint verification. Distributed consensus is proven at scale. Open-source audit logic is precedented. Outcome-agnostic fee structures with slashing are implementable. What has not yet been done is assembling them into a unified, coherent protocol with governance robust enough to achieve the political legitimacy that standards require.
The opportunity is not to build the best AI. It is to build the layer without which no AI can be trusted to make consequential decisions at scale.
"The goal is to move the question from 'Do I trust this company?' to 'Do I trust this protocol?' Protocols outlast companies; infrastructure outlasts products. That's the bet."