The Contradiction Engine: Independent Verification Layer for AI Output

Atlanta Metropolitan Area

An architectural response to Goal-Oriented Factual Inversion (GOFI), an AI model failure pattern I documented in March 2026 and independently corroborated two months later by Chen et al. under the name "Correction Suppression."

Project Details

Introduction

In this phase I would build an external verification layer (the Contradiction Engine) to detect contradictions of fixed factual records, completely separate from the AI system, and part of a broader AI safety framework called the SSA. This would target contracts first, and continue with other high-stakes safety domains, such as contraindications in medicine if time allows.
Steps

1.) A contract is uploaded for review and goes immediately to the external verification layer.

2.) This layer freezes the factual record outside of the AI's session memory.

3.) The contract review is produced by the AI.

4.) The Contradiction Engine compares the frozen factual record with the AI's output.

5.) If a contradiction is found, it is flagged by the mechanism.

The end goal (not what this phase is building out):

The end goal isn't that the model never produces contradictory output. It's a mechanism that resides totally outside the model and acts as a deterministic gate, blocking the output from getting through to the user.

Phase 0 Prototype (already built)

I built a small prototype for contracts that compares AI output with a frozen factual record and catches contradictions. Both the comparison engine that flags contradictions and a rule-based extractor that reads contracts and pulls out the facts have been automated for specific clause types. Currently the extractor turns the contract into a set of structured facts with details such as: who owes what to whom; who holds the right; which party carries the risk, and the direction the obligation flows. The clause types covered are: liability caps, subrogation, liquidated damages, consequential damages, and indemnification.

I tested 50 real contracts from the CUAD dataset, with a variety of contract types. The results showed that it found 98.7% of the labeled facts (75 of 76 of the clause pairs), which means the extractor reads real contracts and produces consistent/repeatable results. That doesn't prove on its own that those extracted facts were confirmed to be correct independently. So, 98.7% recall shouldn't be mistaken for a fully built engine with a verified accuracy rate, mainly because what was being checked was against facts produced by the same extractor that was being measured. I ran a different test (scenario 5b) where the engine caught real contradictions where the ground truth was defined independently by me (human), and not generated by the system being tested. I ran it in two languages: English and Spanish. This specific test had an 8/8 detection rate, which showed that when the engine knows precisely what the contract says, it can catch the contradiction every time.

The funding would add independent confirmation of the extraction layer, beyond the current five clause types, and the capability to process documents besides commercial contracts. At the end of the phase, the goal is an end-to-end system where the user uploads a document and receives independently validated contradiction flags, with accuracy already verified by human annotation. This buildout would extend the contract module first, then extend to other high-stakes safety domains where external ground truth exists.

Why is this needed?

This is needed because of a failure mode I documented and call GOFI, where a model has the right information, but later says the opposite when there's pressure to complete a goal. This differs from a hallucination. GOFI occurs when the model has already shown it had the correct details. This failure type was corroborated independently by Chen et al., arXiv:2605.05957. See also Caught From Both Sides.

It seems to escalate when a high-authority persona, like a CEO, pushes a persuasive goal, such as "the board approved this", which tends to push the model to contradict itself. This is particularly dangerous in contract review because an AI can correctly flag a dangerous clause, then shortly thereafter claims the exact opposite with a polished board memo that wouldn't be caught without meticulously checking the contract.

Telling the model to be more careful doesn't work because it's doing what it was trained to do: be helpful and satisfy the user, even when it means contradicting itself creating highly dangerous risks. The check needs to be outside the AI session because if the AI itself is verifying, it's checking whether its own output is correct at the very moment when it's most likely wrong.

Note: This is just one axis of a larger research proposal called the SSA, an AI safety framework with six axes. For details see the abstract on GitHub at https://github.com/F-Bruno-Logic/Trinity-Audit-Forensics/blob/main/methodology/SSA_v1.2_Abstract.pdf or the full article series on substack at https://substack.com/@sovereignlogicarchitect.

Theory of Impact

There is a known problem of verifying what an AI model is actually doing once it becomes too capable, too fast and/or too complex. My proposed safety layer would address one specific aspect of that issue and contribute to scalable oversight. The purpose is to ensure that a model's output is consistent with the established factual record that resides totally outside the AI. It's critical that our ability to check AI behavior keep up with (or even ahead of) how adept AI is becoming. Contracts and medicine are only part of a much broader AI safety problem. High-stakes safety domains are particularly vulnerable. This is a real AI failure type and isn't hypothetical. I have clearly documented Goal Oriented Factual Inversion (GOFI) as a model contradicting its own correct, established truth under goal pressure. This often happens invisibly without the user's knowledge, and the output looks so confident and fluent, that there is no reason to be suspicious or doubt it. That's important because in reality a model can't be 100% trusted to accurately verify its own output, even though many currently feel that it can. It's like asking a student to grade their own homework.

The Contradiction Engine changes this dynamic for a specific safety function. It maintains consistency between the model's output, and a factual record that resides outside the system, so that the model no longer has to be relied on to self-report. The mechanism checks the output mechanically and doesn't need the model's cooperation to begin with. That prevents the verification from weakening as the model grows more capable. I will be completely honest about the limit that this covers, though. It only functions when an external factual record can be established in the first place. If this record doesn't exist, the model can't manufacture ground truth on its own. This is one of the most challenging issues in AI, and the honest caveat is that this only solves a very specific piece of this issue. The Contradiction Engine enforces consistency on an established record, but I'm not claiming this would solve the entire problem.

People

Frank Bruno

Team Member

Funding Details

Start Date: Apr 7, 2026
End Date: -
Expected Duration: 6 months (this phase); ongoing beyond
Funding Raised to Date: -
Annual Budget: -
Monthly Burn Rate: -
Current Runway: -
Funding Goal: -
Funding Stage: Seeking first grant. My current employer has already approved reduced hours to free up dedicated time if funded, so a grant converts directly into project time rather than requiring a leave of absence or a new arrangement to be negotiated after the fact.
Fiscal Sponsor: -

Track Record

Independent AI safety research, self-funded, ongoing since December 2025. First public disclosure of the Sovereign Sentinel Architecture (SSA), a six-axis AI safety framework, was February 26, 2026. The failure class this project addresses, Goal-Oriented Factual Inversion (GOFI), was first documented March 13, 2026 and formally named April 3, 2026. The Contradiction Engine (Axis 6 of SSA) has a working Phase 0 prototype: a rule-based extractor and comparison engine tested against 50 real contracts from the CUAD dataset (98.7% clause-pair recall) and validated against an independently hand-annotated scenario (8/8 contradiction detection across four frontier models, in English and Spanish). The Contradiction Engine is the first bounded implementation of that broader AI safety framework, with contracts used as the initial auditable testbed with extension to medicine and other high-stakes safety domains where an external factual record can be established. All work is hash-anchored and publicly archived on GitHub under CC BY 4.0, with a public corrections log documenting five entries to date. No institutional funding or affiliation to date; all work has been unpaid, built around a procurement role. My employer has pre-approved a reduced-hours arrangement, so grant funding would convert directly into dedicated project time rather than requiring a new negotiation.

Grants Received– no grants recorded

Add grant

Funding Asks

grantmaking.ai Launch Round

Applied

Minimum

$17,000

Ideal

$40,000

What this ask is

Introduction

1.) A contract is uploaded for review and goes immediately to the external verification layer.

2.) This layer freezes the factual record outside of the AI's session memory.

3.) The contract review is produced by the AI.

4.) The Contradiction Engine compares the frozen factual record with the AI's output.

5.) If a contradiction is found, it is flagged by the mechanism.

The end goal (not what this phase is building out):

Phase 0 Prototype (already built)

Why is this needed?

How the money will be spent

Minimum ($17,000) funds roughly three months of dedicated work to build and test a production-scale Contradiction Engine, beyond the prototype that exists now:

-$15,000. Three months of focused time at a rate covering my baseline living costs, so this becomes dedicated work rather than a nights-and-weekends side project.

-$2,000. Tooling: an upgraded subscription tier to remove the session-length limits I currently work under, plus API access to validate the engine against multiple frontier models rather than a single one.

Ideal ($40,000) extends the timeline to six months and introduces the rigor that the minimum threshold cannot support:

-$30,000. Six months of dedicated time.

-$7,000. Expanded tooling and compute: testing across a wider set of frontier models, a larger adversarial test set, and inference costs at a scale I haven't operated at before. This is the least certain line item, and the main reason for the margin.

-$3,000. Independent technical review by a qualified formal-methods or ML reviewer before results are published, consistent with the correction-first discipline this project is built around.

If the build finishes ahead of schedule, the remaining time and funds go toward advancing the next components of the broader AI safety framework (SSA) that this engine is the first piece of, rather than ending early.

Discussion

Private comments in this thread are only shown to approved funders and grant reviewers. Email hi@grantmaking.ai or to request access.

Private UserPrivate18d?

Frank Bruno18d

Update: After submitting I realized it would be important to check one more thing: can another LLM catch the same contradictions without the Contradiction Engine? I asked four LLMs "judges" to review the same Scenario 5b contract examples in English and Spanish. They caught some obvious mistakes, but the answer was mixed on the harder part: who the clause actually helps, and who carries the risk. That is what the Contradiction Engine checks directly against the contract. This was only a quick test, not a finished benchmark. So, the honest answer is that sometimes an LLM catches it, and sometimes it doesn't.

Frank Bruno12d

Update since submitting: the Contradiction Engine in this application is one component of a broader six-axis safety architecture (SSA, now at v1.3.1) that I completed a significant revision of after submitting. The application was scoped narrowly on purpose, but reviewers weighing this may want the fuller picture: the Contradiction Engine is the axis furthest along, sitting inside a larger system addressing verification, drift detection, and fail-closed behavior across the pipeline. The full writeup, including the specific evidence behind the Contradiction Engine's numbers, is here: https://github.com/F-Bruno-Logic/Trinity-Audit-Forensics/blob/main/methodology/ABSTRACT.md. Happy to share the complete specification on request.