Skip to content
← Log
NiraNexus

NiraNexus Log

The operational record of building a governance-first AI platform.

Log #15

The Handshake: Why Your AI Reviewer Needs the Same Source of Truth

September 1, 2026·Architecture·9 min read
Rakesh MaheswaranLogged by Rakesh Maheswaran, Founder, NiraNexus-OS

In brief

Fourteen years of QA taught me one non-negotiable rule: the person who writes the code does not sign off on the test. But the rule nobody writes down is the one that matters more. The tester and the developer must read the same specification before either touches the keyboard. A tester receiving a full spec while the developer sees only a Jira ticket title is not a gap in process. It is a structural information asymmetry. The same defect class appeared in the Model Council. Early versions gave Opus a truncated debate summary instead of the full transcript. It produced confident verdicts that missed the one claim that survived cross-examination. A model grading work it cannot read is not a critic. It is a rubber stamp with stronger prose. The fix was the same in both systems: shared inputs, separated outputs. The acceptance-criteria handshake. Every model reads every word every other model wrote. The orchestrator gets the full debate transcript. The handshake is not a prompt instruction. It is the architecture that makes the Consensus Lie visible instead of invisible.

Contents


I spent 14 years in quality assurance. The rule everyone knows is the one nobody questions: the person who writes the code does not sign off on the test. Maker-checker. Separation of duties. It is the oldest rule in the book for a reason.

The rule nobody writes down is the one that matters more.

The tester and the developer must read the same specification before either touches the keyboard.

That sounds obvious. It is not. In practice, the tester receives a detailed functional specification. The developer receives a Jira ticket title. The tester writes a thorough bug report with reproduction steps, expected behaviour, and screenshots. The developer sees "Login broken" in the sprint board and guesses. Both are working from the same system. They are getting different inputs.

I watched this happen across multiple teams, multiple companies, multiple years. The pattern was so consistent I stopped thinking of it as a process failure and started thinking of it as a structural defect. The tester and developer were operating with asymmetric information. The tester had more of it. The developer had less. The developer was being graded on a rubric they could not read.

The fix, when we finally institutionalised it, was not a prompt upgrade. It was not a meeting. It was not a memo. It was the acceptance criteria document. Tester and developer both read it before either touched the keyboard. Same document. Same words. Same source of truth. The handshake.

Key Takeaways

  • The acceptance-criteria handshake is not a prompt instruction. It is an architectural rule: the critic and the fixer must read the same specification before either touches the keyboard.
  • Information asymmetry between reviewer and reviewed is the single most common defect class in multi-agent verification systems. A critic grading work it cannot read is not a critic. It is a rubber stamp with stronger prose.
  • The Model Council's early versions suffered from exactly this defect. The orchestrator received a truncated transcript and produced confident verdicts that missed surviving claims.
  • The fix: every model reads every word every other model wrote. The orchestrator receives the full debate transcript. Shared inputs, separated outputs.
  • Independence is not a prompt trick. It is a system property. The handshake makes the Consensus Lie visible instead of invisible.

The Council made the same mistake

Get new entries by email

One or two emails a week. New Log entries only. No noise, unsubscribe any time.

When I built the first version of the Model Council, I reproduced the exact same defect class I had spent 14 years diagnosing in QA. I did not realise it until the evidence was staring at me from the debate transcript.

The orchestrator was supposed to read the full debate and synthesise a verdict. But in the early builds, what it actually received was a truncated summary. Not every claim. Not every rebuttal. Not every refined position that survived cross-examination. A compressed version that prioritised conciseness over completeness.

The verdicts were confident. They cited the right models. They identified consensus and dissent. And they missed the one claim that survived cross-examination intact while every other claim was challenged into refinement.

I had built a system that was grading work it could not read. The orchestrator was not a critic. It was the tester receiving the full spec while the developer saw a ticket title, except in my version, both roles were played by the same model, and the spec it was missing was the debate it was supposed to synthesise.

Log #10 documented what happened when the Council diagnosed its own consensus as the Consensus Lie at 36% confidence. What that article did not cover was the engineering fix that made that diagnosis possible in the first place.

The fix was the handshake. Shared inputs, separated outputs. Every model reads every word every other model wrote. The orchestrator receives the full debate transcript. The acceptance-criteria document, the debate record, is visible to every participant before any of them produce their output.

The Consensus Lie diagnosis was only possible because the orchestrator had the same evidence as the deliberating models. Had it received a truncated summary, it would have reported agreement, because the summary had been compressed to show consensus rather than the dissent that was the real signal.

What the literature confirms

The academic record got there before I did. It just did not give the defect the name it deserves.

Berkeley's EECS-2026-264 dissertation, "Resolving Information Asymmetry in Multi-Agent Systems," established that agents in multi-agent systems hold private information that other agents lack, and that the dynamics of interaction are the mechanism for resolving that asymmetry. The finding is structural, not domain-specific. Agents with asymmetric information produce asymmetric outputs. The resolution is not a better prompt. It is communication protocols that eliminate the asymmetry.

Facio.bot's 2026 analysis of HITL epistemic asymmetry named five dimensions: reasoning chain opacity, uncertainty distribution asymmetry, alternative consideration blindness, calibration history unavailability, and decision trajectory isolation. Their conclusion is exactly one sentence: "The reviewer cannot catch what the reviewer cannot see."

The ICML 2026 adversarial code review work by Qiu and Gill found what they called "false consensus", agents converging on agreement without sufficient evidence, and proved that three agents with structured disagreement outperform five agents without it. The constraint that forces evidence-grounded disagreement is not a prompt word. It is an architectural choice. The structure of the review determines whether the review catches real bugs.

Figure 2: The handshake makes information asymmetry visible

None of this is theoretical. Every single paper is documenting the same pattern I saw across 14 years in QA: when two parties operate from different information, agreement is not verification. It is noise. The fix is not telling them to agree less. It is giving them the same evidence and letting the disagreement surface naturally.

The practitioner I spoke with in August 2026, documented in Log #14, hit the identical defect from the other direction. His critic judged the diff against the issue's acceptance criteria while the fixer received a one-line summary of the gap. "It was being graded on a rubric it could not read." Same defect class. Same root cause. Same fix, arrived at independently: shared inputs, separated outputs.

The architecture that makes the lie visible

The handshake is not a prompt instruction. It is not "tell the model to be fair" or "provide more context." Those are bandaids over a structural wound.

The pipeline itself is the evidence. Every participant reads the same spec before producing output. Fixer and critic produce independently from the shared baseline. The orchestrator receives both outputs and compares against the baseline, not against each other.

Figure 1: Shared inputs, separated outputs

The handshake is three rules.

One. The specification is read by every participant before any of them produce output. The acceptance criteria document. The debate transcript. The diff against the requirements. Whatever constitutes the source of truth, every agent that will evaluate the work must see the same version.

Two. Outputs are produced independently from the shared input. The critic reads the spec and the evidence. The fixer reads the spec and the evidence. Neither sees the other's output until both are committed. Independence is enforced architecturally, not prompt-level.

Three. The comparison happens against the shared baseline, not against each other's output. The question is not "does the critic agree with the fixer." The question is "does the critic's assessment of the work differ from the fixer's, given that both read the same specification." Disagreement that emerges from a shared baseline is data. Agreement that emerges from asymmetric information is noise.

The Council implements this with the full debate transcript. Every model sees every round. The orchestrator sees the complete record. The verdict is not a vote. It is an assessment of the claims that survived cross-examination, made by a model that read the same evidence as the models whose work it is evaluating.

The handshake does not prevent the Consensus Lie. It makes it visible when it happens. The orchestrator can see that all four models agreed because it can read what all four models wrote. It can see that the agreement is suspicious because it can read the parts where they backed down, hedged, or adopted each other's language. The handshake is the lighting that shows the strings.

The next question

The handshake answers what the critic must read. It does not answer what the critic must check.

In QA, the acceptance-criteria handshake was followed by deterministic test suites. The spec was shared. Then the tests ran. The tests could not be talked out of a failure. The developer who shipped on a Friday afternoon and commented out the failing test was caught by the CI pipeline, not by a reviewer reading the diff, but by a script that diffed the test count before and after the commit and refused to merge.

The handshake answers what the critic must read. The instrument answers what the critic must check. A script that diffs the test suite before and after the fix and refuses to merge if a test was deleted. That is Log #16.

Provenance

Frequently Asked Questions

+What is the acceptance-criteria handshake?

A structural rule: the critic and the fixer read the same specification before either touches the keyboard. Not a prompt instruction. An architecture. In the Council, every model reads the full transcript of every round before the orchestrator synthesises the verdict. The orchestrator receives the complete debate transcript, not a summary.

+What happens when the handshake breaks?

The critic grades work it cannot read. Fake confidence. Missed claims. In QA, a tester writing detailed bug reports against a full spec while the developer received only a ticket title. In the Council, an orchestrator receiving a truncated transcript producing verdicts that missed the one claim that survived cross-examination. The same defect class, two decades apart.

+How is this different from just showing the reviewer everything?

It is not about volume. The question is whether both sides share the same source of truth. Shared inputs does not mean the fixer sees the critic's verdict before forming its own position. It means both read the same specification of what the work is supposed to be. Then their outputs can be compared because they were produced from the same baseline. Independence is not a prompt trick. It is a system property.

Get new entries by email

One or two emails a week. New Log entries only. No noise, unsubscribe any time.

The Handshake: Why Your AI Reviewer Needs the Same Source of Truth : Log