The Doctrine

The Frame names the problem. The Doctrine names the posture that survives contact with it. The posture is Zero Trust, applied to AI verification.

The security parallel that maps directly onto AI

Zero Trust is a familiar concept in security architecture. It was articulated over the past decade as a response to a specific failure mode: perimeter-based trust models assume the inside is safe, and they fail catastrophically when the inside is breached. Security stopped relying on the perimeter and started requiring verification on every transaction.

AI verification is at the same inflection. The same shift is required.

The constitutional statement is short: The customer should not have to trust the verifier.

1. Every claim the verifier makes about its own behavior should be independently verifiable, by the customer, by a third party, or by a regulator.
2. The reputation of the founder, the team, the company, the doctrine, and the methodology are not inside the trust model.
3. The trust model is the math, the cryptographic anchors, the public commitments, and the records that the verifier cannot quietly alter.

Once that statement is articulated, every architectural choice that follows stops being a feature decision and starts being a consequence.

The doctrine has three layers, each applying Zero Trust to a different part of the verification stack.

1. Independence: no single AI verifies its own work

The first layer is about who does the verifying. The Zero Trust commitment: never the same family that produced the output.

When a single AI family verifies its own output, the customer is back inside the perimeter trust model. The same model family has the same blind spots, the same training-data biases, and the same failure modes. Verification by the same family is the cognitive equivalent of a single auditor signing off on their own books.

The Zero Trust commitment: verification requires independent agreement across model families with different training data, different objectives, and different failure modes. When multiple independent providers agree, that agreement carries information no single provider can replicate. When they disagree, the disagreement is also informative, and the disagreement is recorded.

The Cheng et al. finding is the single sharpest empirical case for Independence. The most natural verification step (asking the model whether it is sure) is the exact step the model has been trained to defeat. Without independent verifiers, the reviewer is verifying the model with the model.

Independence by vendor is necessary, not sufficient

Frontier models converge. Shared training corpora, similar RLHF norms, comparable benchmark pressure, common failure modes on the soft-reasoning errors this framework is built around. Three frontier models that all pass the example sentence in The Frame buy you less independence than the doctrine implies. Independence-by-vendor is the floor, not the ceiling.

The partial defenses that turn vendor independence into cognitive independence:

• Diverse adjudication protocols. Majority vote, weighted vote, mandatory consensus, escalation to a human expert. Not interchangeable. Majority vote tolerates correlated failure; mandatory consensus surfaces it.
• Calibrated disagreement handling. Recording dissent is necessary; the meaningful work is treating disagreement as information rather than noise.
• Adversarial example sets. Verifiers should be tested against cases known to be hard for the dominant training pattern, not just held-out samples from the same distribution.
• Source-grounded checks. Verification against external data the models cannot have memorized.
• Domain-expert challenge. Humans with subject-matter expertise reviewing dissent, not just adjudicating the overall verdict.

The doctrine is right to rule out same-family verification. It would be wrong to treat three-vendor agreement as the destination.

2. Doctrine: rules enforced architecturally

The second layer is about where the rules live. The Zero Trust commitment: rules are enforced by the architecture, not by operator preference.

The standard failure mode for analytical processes is that the rules exist in documentation but not in execution. A style guide says reviewers must check causal claims. The reviewer is under deadline pressure. The check does not happen. The output ships, and the documentation is silent on whether the check was actually performed. The rule existed; the enforcement did not.

The Zero Trust commitment generalizes beyond evidence gates. Any rule the verification system claims to enforce should be enforced architecturally. Refusals that the system claims to log should be logged automatically, not on operator discretion. Rubric versions that the system claims to apply should be applied by hash-binding, not by operator selection. Doctrine that lives only in documentation is not doctrine. Doctrine that the architecture enforces is.

What gates can and cannot do

Architectural enforcement has a clear limit. Hard gates work reliably on structured properties of the artifact: template class, required sources present, citation count, provenance fields populated, named reviewer identity, approved system-of-record links. They weaken sharply when they must infer consequence from prose.

A vendor selling a gate that promises to detect whether an arbitrary memo carries board-level, regulatory, or capital-allocation consequence based on the text alone is selling perimeter security with extra steps. Free-text consequence inference is the failure mode the current standards literature does not justify treating as a primary control.

Use prose semantics as a secondary signal. Build the primary gate around structured conditions the artifact carries with it. If those structured conditions are absent, the gate cannot fire safely, and the answer is workflow design, not better inference.

A note on override design

"Cannot be bypassed" is shorthand. Real systems need emergency overrides for safety incidents, legal holds, key rotations, customer-specific compliance, and incident response. The doctrine's commitment is not that overrides are impossible. It is that overrides cannot happen silently.

Any bypass requires:

• A signed reason code naming the authority and rationale
• An immutable log entry recording the override
• Customer notification when the override is material to their certificate
• Audit review at a documented cadence

The architecture surfaces every exception. It does not pretend exceptions never happen. A vendor that claims their gate can never be bypassed is either lying or has not yet had a customer with a real edge case. A vendor that shows you the override protocol, the override log, and the audit cadence is operating the doctrine as designed.

Proof artifacts become targets

The doctrine asks for assumption registers, claim-source maps, refusal logs, rubric hashes, and deterministic gates. Once those artifacts matter, they get gamed. Low-quality sources attached to claims to satisfy the citation requirement. Non-load-bearing assumptions listed while real assumptions stay hidden. Rubrics quietly optimized for passing rather than catching. Refusal logs curated for the audit reader. Decision-grade labels earned through paperwork rather than reasoning.

The doctrine's core argument is that prior controls devolved into theater. Its own controls will face the same pressure. The defense is not naivete about it. The defense is treating artifact integrity as a measured property, not a claimed one.

• Citation quality, not just citation count. A claim with three citations whose sources do not actually support it is worse than a claim with one citation that does. Audit a sampled subset of decision-grade outputs at the claim-to-source level on a published cadence.
• Assumption load-bearingness, not just assumption listing. An assumption register that names ten cosmetic assumptions while the real load-bearing assumption sits unstated is gaming. Audits sample for assumptions that, if flipped, would change the conclusion, and confirm those are the ones in the register.
• Rubric stability under adversarial cases, not just under happy-path cases. A rubric that passes everything is not a rubric. Rubric versions are tested against known-hard cases on each revision, and the pass rate is part of the change log.
• Refusal log completeness, not just refusal log presence. A refusal log is gamed by selective entry. The audit on the log is independent of the entity producing it, and unexplained gaps in the entry pattern are themselves a refusal-log defect.

The architecture cannot eliminate the gaming incentive. It can make the gaming visible. That is the doctrine's posture on its own controls: not that they cannot be gamed, but that gaming is logged where the next audit will find it.

3. Accountability: every decision survives independent challenge

The third layer is about the record. The Zero Trust commitment: every decision the verification system makes is logged in a form the verifier cannot alter without breaking the record, and the integrity of the record is verifiable by parties outside the verifier's control.

Zero Trust pattern:

1. Verification decision
2. Hash committed to public chain
3. Anyone can verify without vendor

The standard mechanism for "outside the verifier's control" is cryptographic anchoring: hashes of the decision ledger committed to a public chain (or equivalent infrastructure) that the verifier does not control, cannot quietly alter, and will not lose access to even if the company changes hands.

The architectural consequence is that any verification system worth taking seriously publishes commitments anyone can independently verify:

• The public hash of a rubric version.
• The public hash of a source document.
• The cryptographic certificate that binds an output to the specific model board, the specific rubric, and the specific evidence set that produced it.

None of these require trust in the verifier. All of them produce checks the verifier cannot evade.

The accountability principle extends to internal organizational use. A C-suite reader should not have to trust the analyst, the desk lead, or the chief of staff to forward the right version. The reader should be able to verify the cryptographic match between the document on screen and the certificate attached to it. The trust model is the hash, not the messenger.

What cryptographic anchoring proves, and what it does not

Cryptographic anchoring is necessary but not sufficient. The doctrine is strong on procedural integrity and exactly as strong as the reasoning it anchors. This distinction is important enough to be explicit.

A hash proves the record is stable. It does not prove the analysis was correct. A signed certificate binds an output to a process; it does not validate the process. A public commitment log proves a vendor said something publicly; it does not prove what they said was right.

Provenance is a precondition for validity audits, not a substitute for them. The doctrine on this page produces tamper-evident records. Whether the records contain valid reasoning is a separate question, answered by domain experts, replication, and the discipline of asking what evidence would change the conclusion. The framework is honest about which question it answers and which it does not.

The confidentiality boundary

The architectural commitments above describe what the doctrine looks like under default conditions. They do not survive contact with privileged legal advice, M&A strategy, export-controlled data, PHI/PII, or confidential board material without modification. Those are exactly the contexts where the decision-grade lane is most consequential, so the modifications matter.

Three boundary conditions apply.

Public commitments shift to private commitments. A public chain hash of a board paper's source documents can leak existence proofs and metadata that the board paper was meant to keep confidential. The Zero Trust posture survives by moving from a public chain to a customer-controlled transparency log with selective disclosure. The customer can verify chain integrity internally. External parties get redacted or zero-knowledge proofs only as the matter requires. Customer-auditable is the operative standard, not globally public.

Source-document hash binding requires key segregation. The cryptographic match between source document and certificate remains useful inside the confidentiality boundary. The hash itself must be generated and stored under a separate key from the certificates that travel outside the boundary. A vendor that cannot separate these keys is asking the customer to choose between verifiability and confidentiality.

Immutable logs require retention and discoverability design. Tamper-evident logs widen the discoverable surface under litigation and complicate privilege. The doctrine accommodates this by scoping immutable logging to verification decisions (rubric version, model board verdict, refusal events) and excluding the deliberative content of the reasoning. Legal, records, and privacy teams must agree on the retention model before the first sensitive workflow enters the lane.

What the three principles produce, taken together

The three principles produce a set of architectural commitments any serious verification system carries. The list below is general, not specific to any vendor's implementation. Each commitment is a consequence of the Zero Trust posture. None of them is a feature. Removing any of them is a violation of the constitutional posture, not a product trade-off.

Click to expand each commitment.

Why the posture is more durable than methodology

A methodology-based verification claim is contestable. A Zero Trust posture is not contestable in the same way. The doctrine produces checks that are mathematical, not interpretive. Domain experts can challenge a methodology. They cannot challenge a hash.

That durability has consequences across every audience the verification system serves.

The doctrine is, in a meaningful sense, a constitutional posture rather than a corporate policy. It cannot be repealed without the repeal being visible.

Where this goes next