Inherited Blind Spots (Part 1)

Eliminating Common-Mode Failure Through Dual-Model Audits

BLUF: Independent cross-vendor review with human disposition authority is the minimal defensible standard for AI-assisted audit. Alchemist AI Pro™ operationalizes that standard.

Common-Mode Failure in AI Audits

In safety engineering, there is a concept that safety checks only reduce risk if they fail independently. Using only one model, or a family of models, introduces a common-mode failure.

When models share a training recipe, or lineage, they can fail together because there is no independent check if they are all of the same mind. Think about the problems experienced with technology that you might own, like TVs, cameras, and cell phones. You might buy two similar brands (models), but they all have the same problems because their key components come from the same component vendor; therefore, they carry the same pros and cons.

This is not a new concern, only a new source of it. Prepared for the U.S. Nuclear Regulatory Commission, NUREG/CR-6303 outlines a method for locating points in computer-based protection systems where credible common-mode failures lack compensation from diversity or defense-in-depth (Preckshot, 1994). The report notes that this class of vulnerability grew as software content increased, because engineers could no longer rely on the older assumption that common-mode failures come from slow physical processes such as corrosion or wear. Models are the newest source, and the mechanism by which they share failure modes is not corrosion. It is lineage.

Bias in a shared foundational corpus can travel. Tracing gender-occupation associations from the Dolma pre-training corpus through the OLMo models, Thaler et al. (2024) found those associations amplified in what the model generated. That study covers one bias type in one open model family, and it leaves open whether logical or technical blind spots propagate the same way. What it establishes is the mechanism: what sits in the foundation reappears, amplified, in the output.

A model's failure to catch errors in its own output is not incidental. It is measurable. Across 14 open-source non-reasoning models, an injected error was corrected reliably when it arrived from an external source but was missed an average of 64.5% of the time when the model had produced it itself (Tsui, 2025). Omission is only half of the failure. Placed in the judge’s seat, a model can distinguish its own writing from another model’s. The strength of its preference for its own output rises in step with that recognition, even where human annotators rate the candidates as equal in quality (Panickssery et al., 2024).

One objection deserves a direct answer. Tsui also reports that appending a single "Wait" token reduces the blind spot by 89.3%, which invites the conclusion that self-review is fixable by prompting rather than by architecture. Two things limit that reading. The benchmark appends the marker after a known injected error, so the intervention is applied at a location already identified as wrong. A live requirements audit has no such marker because finding the error is the whole point. The intervention also addresses omission only. It leaves the second failure untouched, where a model in the judge’s seat recognizes and prefers its own output. Prompting can wake a reviewer up. It cannot make the reviewer independent.

Two claims sit behind lineage separation, and they rest on different footing. The self-review literature establishes that a model cannot reliably check its own output, which is why a second model is required at all. Lineage separation goes further than that finding requires. It is a conservative extension of the same principle, adopted because the transfer question is open rather than because it is answered. Whether a sibling model from the same lab inherits its relative’s blind spots intact has not been measured. Until it has, the defensible assumption for a safety-relevant audit is that it might.

A model checking its own work is a measured failure. A model checking a sibling’s work is an unmeasured risk. Neither is a second opinion in the sense an audit requires.

A Defensible Verification Architecture

Independent review is an established engineering discipline with a published standard behind it. Annex C of Institute of Electrical and Electronics Engineers (IEEE) Standard 1012-2024, the current standard for system, software, and hardware verification and validation, defines independent verification and validation in terms of independence parameters and the forms independence can take (IEEE, 2024).

Separation of duties fails when a single LLM performs all three of the following roles:

• Generating the requirements or acceptance criteria.
• Writing the code.
• Reviewing and approving both.

No one would let a contractor both build the house and serve as the inspector who signs it off.

To maintain a defensible architecture, three tenets are as follows:

1. Independence of the reviewer: The auditor must be outside the generator’s lineage.
2. Criteria authored before the review: IEEE Std 1044-2009, inactive since 2020, provides a classification for software anomalies (IEEE, 2010). What we add to that classification is timing and traceability: the taxonomy is authored before the review begins, and every finding attaches to a specific artifact a person can locate and contest.
3. Human disposition that survives the decision: A person decides, and the decision carries into coding and testing within the SDLC.

In practice, draw the generator and auditor from different labs, such as OpenAI, Google, Anthropic, xAI, or Meta. Different labs mean different lineages, and therefore different alignment regimes and architectures.Independent Dual-Model Architecture

To eliminate common-mode failure, the separation between vendors buys different training pipelines, different alignment regimes, and a different set of failure modes. Blinding does suppress self-preference up to a point, which invites the conclusion that a single lineage is workable if the audit is blinded. Mahbub and Feng (2026) close that door: once further perturbation neutralizes the stylistic cues, self-preference recovers because self-recognition operates on semantic features rather than surface style alone. Stripping the byline hides the author from the reader. It does not hide the output from the model that wrote it.

Alchemist AI Pro^™ splits those roles across two vendors. Our Audit stage is an independent second AI model reviewing the first. Google generates the requirements, OpenAI audits them, and a human engineer holds disposition authority over every finding. While this is what we have chosen as our commercial offering, the system itself is vendor agnostic; different models can serve as the generator and auditor. The auditor sits outside the generator’s lineage, so it cannot inherit vendor-specific blind spots, and nothing in the pipeline grades its own homework.

Short of training a model in-house, vendor separation is the most complete lineage separation available to a commercial buyer.

Governed Automation in Production

Cross-vendor verification puts an independent auditor in front of every candidate output and a human architect in front of every finding it raises. The auditing model challenges the generating model’s assumptions, and the human architect verifies the result. Applied to a full production build in the Replacing Our Own CRM with the Alchemy SDLC™ case study (ACC3 International, 2026), that discipline produced the following verified results:

• 125 of 125 specifications (100%) referenced directly in shipped code.
• 105 of 105 use cases (100%) verified and functional.
• 228 of 229 test cases (99.6%) functionally covered.
• 748 tasks executed by the automated Alchemy Crew, with 21 tasks carried by the human Away Team.

The deterministic estimate for this build was 2,978 story points, or 11,912 hours of manual development effort, which is 74.5 team-weeks. The delivered system consumed 61.8 tracked human hours in its final mile.

Disposition authority stays with a human being. Separation changes only how much reaches that person, from every artifact down to the contested ones.

Operationalizing Independent Review

Alchemist AI Pro™ runs eight stages, from capture and elicitation through framework selection, elaboration, user journeys, the alchemy stage, the audit, and export. The stage that carries the independence claim is the audit.

The platform produces requirements ready for development. Downstream, if Alchemy SDLC™ is used, every Alchemy Crew commit tags to its spec and test case, ensuring the human disposition from the audit survives into production code.

Alchemist AI Pro™ has been assessed Awardable through the Tradewinds Solutions Marketplace, the Department of War’s post-competition repository for AI, data, and analytics solutions (Chief Digital and Artificial Intelligence Office, n.d.). Awardable is a procurement-readiness signal following independent assessment. It is not an award, endorsement, or contract.

Conclusion

IEEE Std 1012-2024 already defines what independence requires of a reviewer. What has changed is that the generator is now a model, and the reviewer that is cheapest to reach for sits inside the same lineage that produced the work. That is a choice worth making on the record, with a rationale a program can defend under scrutiny, rather than one that gets made by procurement convenience.

Programs should be able to answer one question: Was the review truly independent?

Reach out to the author below for a briefing or find out more about Alchemist AI Pro™ and Alchemy SDLC™ at https://alchemistaipro.com.

References

ACC3 International. (2026, July). Alchemy Pro CRM: Replacing Our Own CRM with the Alchemy SDLC™. https://alchemistaipro.com/library/replacing-our-crm-using-alchemy-sdlc

Chief Digital and Artificial Intelligence Office. (n.d.). Tradewinds. U.S. Department of War. Retrieved August 11, 2026, from https://www.ai.mil/Industry/Tradewinds/

Institute of Electrical and Electronics Engineers. (2010). IEEE standard classification for software anomalies (IEEE Std 1044-2009). https://doi.org/10.1109/IEEESTD.2010.5399061

Institute of Electrical and Electronics Engineers. (2024). IEEE standard for system, software, and hardware verification and validation (IEEE Std 1012-2024). https://doi.org/10.1109/IEEESTD.2025.11134780

Mahbub, T., & Feng, S. (2026). Mitigating self-preference by authorship obfuscation. Proceedings of the AAAI Conference on Artificial Intelligence, 40(44), 37701-37708. https://doi.org/10.1609/aaai.v40i44.41105

Panickssery, A., Bowman, S. R., & Feng, S. (2024). LLM evaluators recognize and favor their own generations. Advances in Neural Information Processing Systems, 37, 68772-68802. https://proceedings.neurips.cc/paper_files/paper/2024/hash/7f1f0218e45f5414c79c0679633e47bc-Abstract-Conference.html

Preckshot, G. G. (1994). Method for performing diversity and defense-in-depth analyses of reactor protection systems (NUREG/CR-6303, UCRL-ID-119239). U.S. Nuclear Regulatory Commission. https://www.nrc.gov/docs/ML0717/ML071790509.pdf

Thaler, M., Köksal, A., Leidinger, A., Korhonen, A., & Schütze, H. (2024). How far can bias go? Tracing bias from pretraining data to alignment. arXiv. https://doi.org/10.48550/arXiv.2411.19240

Tsui, K. (2025). Self-correction bench: Uncovering and addressing the self-correction blind spot in large language models. arXiv. https://doi.org/10.48550/arXiv.2507.02778