Why we run four LLMs against every finding.

The simple version

For every finding that Labs ships in a Board-Ready deliverable, four independent frontier models read the evidence chain and produce a verdict. The verdicts are not averaged. They are made to argue with each other in writing. The founder reads the argument, decides which model was right and which was wrong, and signs the adjudication.

The output is the finding plus a Challenge Log — a redacted record of the disagreement and the resolution. The buyer can read the Challenge Log. The buyer's CISO can audit our reasoning, not just our conclusion.

This is what Labs sells. The rest of this article explains why.

Why majority vote is wrong for security

The intuition behind multi-model consensus is correct in one direction and dangerous in another.

It is correct that if four models agree, the probability that all four are wrong is lower than the probability that any single one is wrong. This is true and useful.

It is dangerous because the failure mode security buyers care about is not the false negative on the easy case. It is the false negative on the case that looks easy and is not. Majority vote optimises for the first. It is actively bad for the second, because when a finding is genuinely subtle, the same shared training-distribution priors lead multiple models to the same wrong answer. They agree. They are still wrong. The vote ratifies the error.

The fix is not more models voting. The fix is structured disagreement.

The protocol in five steps

The Labs AI-Alliance Challenging protocol is intentionally narrow. It is not a research artefact. It is an operational procedure that the founder runs on every finding.

Step 1 — Independent judgment. Each of the four models receives the same evidence pack: the artefact, the chain that led to the finding, the impact hypothesis, and nothing else. No model is told what the others said. Each produces a verdict — confirms, partial, rejects — with reasoning.

Step 2 — Steel-manning. Each model is then shown the verdicts of the others and asked to produce the strongest version of the opposing arguments, in writing. The model that confirmed is asked to make the strongest case for rejection. The model that rejected is asked to make the strongest case for confirmation.

Step 3 — Founder adjudication. The founder reads the four original verdicts and the four steel-manned counter-arguments. The decision is the founder's. The role of the models is to surface arguments the founder might not have generated alone. The founder is the auditor of record.

Step 4 — Remediation challenge. Once the finding's remediation runbook is drafted, the same four models are asked to attack the runbook. The output is "ways the proposed fix can fail in production, escape the surface, or be regressed by a follow-up change." The founder iterates the runbook until the attacks are weak.

Step 5 — Retest attestation. After remediation is applied by the client, the finding is re-evaluated by the same four models. A signed attestation is produced if all four agree the surface is closed for that specific class.

What the Challenge Log looks like

The Challenge Log appendix to a Board-Ready deliverable contains, for each finding:

• The four original verdicts, with model identifiers.
• The four steel-manned counter-arguments, in full.
• The founder's adjudication, with the explicit reason for which argument won.
• The remediation challenge round, with the strongest attacks and the runbook iterations that survived them.
• The retest verdicts.

What the log does NOT contain:

• Client-identifying details. The artefact references are redacted to the level where the pattern is preserved but the engagement is not pattern-matchable.
• Specific model prompts. The prompts are a trade secret of the methodology and Labs does not publish them in the deliverable.
• Cost or token-usage metrics. The buyer is buying the conclusion, not the operational economics.

A redacted Challenge Log sample is available under reciprocal NDA on request. The standard format is published on /proof so a prospect can inspect the shape of the artefact before commissioning an engagement.

Why this is defensible against the obvious objection

The first objection from any technical reviewer is "you are still relying on AI to make the call." That is incorrect.

The founder is the auditor of record. The models surface arguments. The decision attribution is to the founder. If the founder is wrong, the founder is wrong — and the attestation carries the founder's signature, with the founder's professional standing on it, not an AI's.

The second objection is "four models is arbitrary; why not three or five." The answer is operational. Three is too few to break a tie in a useful direction; five adds operational latency for a small marginal information gain in our experience. Four is what the founder runs; it can be revisited if the model landscape shifts.

The third objection is "what if all four models share a blind spot." This is the real concern, and the protocol does not fully eliminate it. Two compensating controls help: (a) the four models are selected to have meaningfully different training distributions, not four checkpoints of the same family; (b) for high-stakes findings, the founder forces a manual adversarial review pass that does not use the same four — a fifth, off-loop reviewer, who reads only the founder's adjudication and is asked to find the hole.

Nothing is bulletproof. The point of the methodology is to make the failure mode visible, not to claim it does not exist.

What this is not

This is not "AI-powered" marketing copy. It is a protocol that exists because the founder ran the alternative — single-model review — and found the false negative rate unacceptable for an attestation product.

It is not a substitute for the founder. It is the founder's leverage.

It is not a tool we sell. It is the discipline behind the engagement. The tooling required to run it is documented enough that a serious team could replicate the spirit. The discipline is what survives audit.

What the buyer can verify

A prospective Labs buyer evaluating the protocol can verify three things before signing:

• Read a redacted Challenge Log sample on /proof.
• Ask for a reciprocal-NDA reference call with a prior client who has gone through the protocol end-to-end.
• Inspect the /proof page for the current public artefact set, including the protocol description and the founder's signature on the methodology page.

If after those three checks the protocol does not feel defensible to the buyer's CISO, the engagement is not for the buyer. That is fine. Labs is not for every buyer.