Inherited Blind Spots (Part 2)
Closing the Aperture
BLUF: An AI auditor can narrow what a person is presented with in a review portal, but if that person cannot rely on the outcomes of the audit, then that creates a risk. An AI auditor with a similar lineage prefers the output of its own lineage, and unflagged silence carries no information. It is not the clean bill of health it appears to be. A clean audit from that auditor returns the entire package to the reviewer with a note stating the pages are fine, and the reviewer either believes the note or reads the pages. With Alchemist AI Pro™, the auditor comes from a different vendor lineage than the generator. That separation is what makes a flagged findings list worth anything: it is the only filter standing between the decision-maker and the raw output.
The Aperture
The conclusion of Inherited Blind Spots Part 1 was that a model should not audit another model from its own lineage. Lineage was used as a term to identify two models created by the same vendor labs. The auditing model shares the transformer architecture, the web-scale pre-training corpus, the alignment methods, and the system-level guardrails of the model that wrote the output. When placed in the judge’s seat, it recognizes its own writing and prefers it at rates exceeding chance (Panickssery et al., 2024). This is why the paper concluded that a review conducted by a single vendor is not a second opinion to be trusted (Edwards, 2026). While part 1 focused on the lineage separation as a technical imperative, this paper pivots to the human cost in terms of workload and trust.
Most of the objections to that paper were about staffing rather than about bias research. When a second vendor’s model raises additional flags, someone has to work through them. The reviewer was already the constraint. Adding volume to the constraint looks like the wrong direction.
This kind of objection assumes that a reviewer’s burden is measured by the number of flags raised that reach their desk. It is not. The burden is measured by how many pages a person must read personally before signing. Those are different quantities, and independence is what separates them.
What Happens When a Model Reads Its Own Output
When the development of Alchemist AI Pro™ was underway, a requirement set produced by a frontier model was sent back to that same model for audit. Call it Model A. Over several cycles, gaps appeared in the results. The examples were not subtle, because the platform can generate dozens of use cases for a single feature and the volume makes a pattern visible quickly. The taxonomy was the platform’s own: ambiguity, overlap, contradiction, lack of information, weak testability, traceability gaps, and unstated assumptions.
Model A kept missing things.
The same file, unchanged, went to a model from a different vendor. Call it Model B. Model B returned substantially more flagged findings in the audit, including ambiguities and unstated assumptions in passages Model A had read twice and commented on.
A model generating requirements selects the sequences of characters that it scores as most likely to fulfill its goal. Ask that model whether the result is clear, and it produces a sequence similar to what it would have generated in the first place. High likelihood reads as clarity. Model A was not measuring the requirement against the taxonomy. It was measuring the requirement against its own expectations, and the output met those expectations because the output came from Model A.
The research has measured pieces of this:
-
Wataoka et al. (2024) tie self-preference to perplexity, which reflects familiarity rather than quality.
-
Panickssery et al. (2024) found that a model’s preference for its own output rises in step with its ability to recognize that output as its own.
-
Tsui (2025) injected an identical error into 14 open-source non-reasoning models twice. Of those two submissions, the models attributed the output to a human in one and itself in another. Only the conversational role was changed between the two. Correction rates on self-attributed output fell below the human-attributed sets by an average of 64.5% under supervised error injection.
-
Even erasing the unique style and hiding the source of the output, a model can still recognize its own work. Even minor modifications such as synonym replacements were shown to predictably reduce self-preference in review. However, if you rewrite all submissions in the equivalent tone, the recognition and biases return. Why does this bias return? The evaluator moves focus from how it is written to what is written (Mahbub & Feng, 2026).
Routing the output through a second agent will convert an internal error into an external error (Tsui, 2025). Modifying the reader, the one auditing, will change the attribution of the output. A second instance of the same model will read the output as external but still register it as familiar, as if the output were its own. A model from a second vendor would not be immediately familiar and would not be biased towards the output.
Tsui traces blind spots to what takes place post-training. Human preparations of content tend to be polished, error-free output rather than the entire process of drafting, correcting, reviewing, and completing that a human would use to get to that finished result. The work of catching errors and fixing them is absent. That pattern is never modeled, and LLMs can inherit that gap. Fine-tuning a model based on around 5000 error-correction examples cuts blind spots down by 76%. This research provides evidence that data and not architecture cause the issues. Tsui likens the researched results to the way people have similar bias blind spots, especially the tendency to see bias more readily in others than in oneself (Pronin et al., 2002). Tsui argues the model's version is inherited from human instruction through the training pipeline.
If the problem is not the base corpus that most models align with, then it’s in the post-training alignment and guardrails. That is why a different vendor is a clear path to solving this problem. Model B doesn’t have the same weights, biases, blind spots, or even recognition of the output that Model A would have if it audited its own output.
One development cycle is not a controlled trial and is not being offered as an independent piece of evidence. The research shows that this is a measurable outcome which exposes underlying bias. The anecdote’s value would be only a way to express how failure presents in practice. When Model A audits itself, the most dangerous outcome would be a clean report back and when it shows that nothing was overlooked. A clean report from a compromised reviewer is a report that can’t be trusted. The failure is silent, and that silence is the problem. It is what an independent audit would eliminate.
Why a Clean Report Is an Expensive Answer
Put the requirements engineer back in the chair. On one side of the desk sit 50 pages of generated requirements. On the other side sits the same-lineage audit. That report might look manageable. That report looks like the smallest thing on the desk.
The problem is that the omission of flagged items could be the most expensive item on this desk. It is expensive because it is marked completed as an entire audit well done. Unless the human reviewer has reassurance in the quality of it, a green checkmark can lead them toward a misguided outcome. Approving that audit as an endorsement of work that nobody checked presents risk. The alternative is to read all 50 pages of the requirements manually and review each item on its own merits, which is precisely the problem the AI auditor was meant to solve. Neither option leaves the engineer better off than having no auditor at all.
A flagged findings list during audit is valuable by virtue of what is not highlighted: the items that were verified. In a 50-page baseline with nine flagged items, the load-bearing claim is not the nine. It is the assertion about the remaining items that allows an engineer to focus on those nine. A same-lineage auditor cannot credibly make that assertion. The same property that produced the omissions produced the output.
Figure 1. The difference between same-lineage and cross-lineage audits.
Human factors research is clear about what a poor filter does to the person relying on it. Skitka et al. (1999) classified operator errors alongside an automated aid as omissions, in which a problem the aid failed to flag goes unnoticed, and commissions, in which the operator follows the aid despite contrary evidence. Parasuraman and Riley (1997) attribute reliance to workload and complacency rather than to carelessness. Picture a tired engineer with dozens of pages of items and an audit that reports only a handful of items. If the audit and the engineer both miss something, then that is the textbook omission and commission the studies describe.
Review capacity has never kept pace with generation capacity, and this has been a problem for longer than the current generation of models has existed. Fagan (1976) set inspection rate limits for design and code at IBM because detection effectiveness falls once reviewers move faster than those limits allow. Volume degrades review. This has always been the case.
The aperture is not what is shown as flagged items found. It is the number of pages a person must read personally in order to sign. Fifty pages reduced to a couple dozen decisions is the whole benefit. An unaudited baseline and a clean same-lineage report cost the reviewer the same once trust is gone. Only a cross-lineage audit narrows the aperture.
A second model from a different lineage will typically return more flagged items than a same-lineage model auditing the same output. The higher count of flagged items is not a burden for the human reviewer. The extra items flagged land in passages the same-lineage auditor went silent on. That silence is what exposes its validation to a single interpretation of its own output. The whole purpose of AI audits is to prevent a human from trying to match the output of AI; that is untenable. Pages will drive fatigue and cause schedule slips, all while the latent cost of every unnoticed defect grows as development moves forward. If left uncorrected, trust will be eroded, and the audit doesn’t solve the aperture problem it was supposed to prevent.
748 to 21
Separation is an architectural choice and not a feature of any one vendor model. Proof of “narrowing the aperture” can be found within the Replacing our own CRM with the Alchemy SDLC™ case study (ACC3 International, 2026). Cross-vendor verification with human disposition authority 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 carried by the human Away Team.
That last line captures the ratio of hard-to-solve items that Alchemy SDLC™ needs human support for. Roughly 97% of task execution ran automated, with human effort reserved for the cases that required judgment. The deterministic estimate for the 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.
This is one build, inside the vendor, offered as an instance of the pattern rather than as a number any program should expect to reproduce. Results elsewhere will depend on the complexity of the requirements, the training data for both the generating and auditing models, the maturity of the defect taxonomy, how well the approach meshes with established workflows, and the reviewers’ experience. Programs should calibrate against their own environment.
How Alchemist AI Pro™ Runs the Audit
Alchemist AI Pro™ runs eight stages, from capture and elicitation through framework selection, elaboration, user journeys, the alchemy stage, the audit, and export. The audit is the stage that carries the independence claim. 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.
Engineers can put the same separation into their own workflows without using our platform. Select one vendor’s model to generate the requirements. Select a different vendor’s model to audit them. Connect both through the document management or requirements tool already in use, so requirements are generated and stored as they are today, then submitted to the second model for audit, with flagged findings returned for review and disposition. What changes are necessary for the workflow definition: add the cross-lineage step, record which model served which role at each stage, and train reviewers to work on cross-vendor flags. Anyone can reproduce the pattern with any two vendors. More information is available at https://alchemistaipro.com.
The lack of bias that independence affords is what makes the flagged audit items trustworthy. Two further design choices are what make them usable:
-
Timing. The defect taxonomy is written by people and settled ahead of the audit runs, so every finding lands in a category rather than in an opinion. The classification comes from IEEE Std 1044-2009, which has been inactive since 2020 (IEEE, 2010), with timing and traceability added. An auditor working to a taxonomy records defects. A review conducted without one records preferences, which is the second way a review reverts to a question of volume.
-
Location. A flagged finding names a specific artifact flagged for a person to review and approve. It arrives with a proposed disposition, so the engineer either accepts or rejects it. A flagged conflict nobody can locate is not a finding. It is a risk.
After an AI has audited the output for problems, then it is up to a human in the loop to decide what happens next. Annex C of IEEE Std 1012-2024 defines reviewer independence through independence parameters and the forms independence can take (IEEE, 2024). The taxonomy and the disposition record are what make that independence auditable.
Figure 2. These components are necessary to place trust in your AI audited process.
Governance of this kind matters because the underlying tools are uneven. A systematic review of 238 articles on generative AI in requirements engineering identified reproducibility (66.8%), hallucinations (63.4%), and interpretability (57.1%) as the most frequently discussed challenges, and concluded that adoption depends on coordinated progress in technical robustness, methodological maturity, and governance integration (Cheng et al., 2026). Generated output needs governing. Governing it at scale requires an independent filter in front of the people doing the governing.
Downstream, if the Alchemy SDLC™ is used, every Alchemy Crew commit tags the specifications and test cases. That way, a disposition recorded during the audit carries into production code instead of expiring when the review closes, allowing a complete full cycle of traceability within your standard development lifecycle when using Alchemy SDLC™.
Conclusion
Part 1 was about answering a straightforward question: was the review truly independent? This paper leaves a numerical one: How many pages did a person read before approval?
An audit nobody can trust does not stop at the requirements engineering stage. It travels downstream, and repair costs rise the longer development progresses. A system that misses legitimate defects in generated output puts a project schedule and credibility at risk. Accepting an audit as clean relieves the engineer of nothing. Reviewing the audit will now mean validating all the requirements manually regardless.
Model A wrote the requirements, audited the requirements, and missed obvious defects. What surfaced them was not better prompting or longer reasoning. It was a second vendor.
Before approving the full set of requirements, a program should be able to say who audited it and how much of it a person reads.
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
Cheng, H., Husen, J. H., Lu, Y., Racharak, T., Yoshioka, N., Ubayashi, N., & Washizaki, H. (2026). Generative AI for requirements engineering: A systematic literature review. Software: Practice and Experience, 56(2), 141-170. https://doi.org/10.1002/spe.70029
Edwards, N. (2026). Inherited blind spots (Part 1): Eliminating common-mode failure through dual-model audits. ACC3 International. https://alchemistaipro.com/library/inherited-blind-spots-part-1
Fagan, M. E. (1976). Design and code inspections to reduce errors in program development. IBM Systems Journal, 15(3), 182-211. https://doi.org/10.1147/sj.153.0182
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
Parasuraman, R., & Riley, V. (1997). Humans and automation: Use, misuse, disuse, abuse. Human Factors, 39(2), 230-253. https://doi.org/10.1518/001872097778543886
Pronin, E., Lin, D. Y., & Ross, L. (2002). The bias blind spot: Perceptions of bias in self versus others. Personality and Social Psychology Bulletin, 28(3), 369-381. https://doi.org/10.1177/0146167202286008
Skitka, L. J., Mosier, K. L., & Burdick, M. (1999). Does automation bias decision-making? International Journal of Human-Computer Studies, 51(5), 991-1006. https://doi.org/10.1006/ijhc.1999.0252
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
Wataoka, K., Takahashi, T., & Ri, R. (2024). Self-preference bias in LLM-as-a-judge. arXiv. https://doi.org/10.48550/arXiv.2410.21819
