Independent review protocol

A multi-model review can simulate parts of peer review, but the role of a reviewer is to challenge a change against its intended behaviour—not to vote on whether the implementing agent sounds confident.

Inputs for each reviewer

• Agreed product behaviour relevant to the change.
• Current architectural decision and behavioural contracts.
• Scope of the completed phase.
• Changed source files or actual diff, plus tests.
• Any explicitly unresolved questions.

Give reviewers the source and design, not just a generated summary. Hide prior reviewers’ conclusions initially where feasible so their findings are less socially anchored. Reviewers may still share training-related blind spots.

Reviewer A — architectural integrity

Prompt for a separate model:

Review the supplied change against the architectural decision and contracts. Identify changes to responsibilities, forbidden dependencies, invented state or unauthorised interface modifications. For every concern, cite the exact code path and contract or design statement. Separate verified violations from questions. Do not redesign the system unless a violation requires it.

Reviewer B — adversarial behaviour

Prompt for a separate model:

Examine failure behaviour, duplicate delivery, invalid input, partial failure, concurrency assumptions and externally observable edge cases. Focus on ways the code could satisfy happy-path tests while breaking the stated contract. Propose the smallest executable test that could confirm each finding. Do not claim a defect without pointing to the mechanism.

Reviewer C — test and evidence completeness

Prompt for a separate model:

For every acceptance criterion, identify the strongest available evidence and what remains unverified. Inspect whether tests assert observable behaviour rather than mirror the implementation. Identify high-impact missing tests. Do not treat agreement between reviewers as proof.

How findings are resolved

A reviewer can raise a concern, but a concern is not automatically a defect. Assign a finding ID, reproduce or inspect evidence, and classify it as:

• Confirmed issue — observed mismatch with agreed behaviour.
• Contract ambiguity — interpretation or missing design decision requires escalation.
• Proposed improvement — legitimate option, not within current scope.
• Not reproducible — insufficient evidence; note remaining risk if relevant.

When models disagree, inspect the exact contract and run the smallest confirming test. Do not resolve by majority vote.

Guardrails

• Do not give a model unlimited authority to modify the code while reviewing.
• Keep review budgets proportionate to risk; three models on every typo is wasteful.
• Record tools, versions and tests used if review findings materially influence release.
• Ensure confidential source is only sent to approved providers/environments.

Human responsibility

A person or authorised engineering policy decides whether a contract change is accepted, whether a risk is tolerable and whether product evidence justifies continued work. Models can contribute analysis; they do not own those decisions.