Review panel
Up to ten reviewers.Blind, across models, decided by rule.
Every change is reviewed by a panel you compose: each reviewer through its own lens, on its own engine and model, blind to the others. Then a gate written in code decides whether the change goes back.
Compose the panel
Each with its own lens and its own model.
Compose the panel for the organisation, a project or a single run. Reviewers work in parallel as separate sessions and never see each other's verdicts, or the plan, so agreement means something.
- Mix vendors, so no single model is a blind spot
- Repeat a lens across vendors where it matters most
- Limits on self-checks and fix rounds, set by you
- Choose who re-checks in fix rounds
Fourteen lenses
Specialists, not one generalist.
Choose up to ten reviewers from fourteen specialist lenses. Two security reviewers on two different models disagree in useful ways.
- 01
Correctness
The change read against what the story asked for.
- 02
Security
Vulnerability classes, authorisation, tenant isolation and data handling.
- 03
Quality
Conventions, naming, duplication, complexity and fit with the codebase.
- 04
Generalist
One broad pass across correctness, security and quality.
- 05
Completeness
Every stated requirement traced to the code that delivers it.
- 06
Performance
Behaviour at realistic production volume.
- 07
Concurrency
Races, idempotency and multi-instance behaviour.
- 08
Resilience
Failure paths, retries, timeouts and partial failure.
- 09
Test quality
Whether the tests prove the change and can actually fail.
- 10
Architecture
Where responsibilities live and what depends on what.
- 11
Data and migrations
Persisted-data compatibility, schema, indexes and migrations.
- 12
API contract
Endpoints, messages and schemas, and the consumers that rely on them.
- 13
Frontend and accessibility
User experience and accessibility of interface changes.
- 14
Standards
Conformance to your own guidelines and engineering standards documents.
The severity gate
Computed, not argued.
The gate counts the panel's findings by severity, removes duplicates and decides whether the change goes back. A confident verdict cannot talk its way past it. Blocking findings go to a developer agent, which reproduces and fixes them, and the whole panel reviews again.
- Repair rounds are capped by you, so the loop always ends
- Anything still blocking at the cap is printed on the pull request
Decided by code- Any critical findingRework
- Too many high findingsRework
- Too many medium findingsRework
- A reviewer says it blocks productionRework
The review panel at work
0:30One reviewer proved a full IBAN was reaching the logs
Blind review across vendors, the gate, and a fix reviewed again until all five approved.
Proof, not a promise
Two security reviewers. Two vendors. Only one caught the leak.
A recorded run on a synthetic payments API (Java, Spring Boot). Every round below is as the platform recorded it.
- architects on three engines
- 3
- reviewers across three vendors
- 5
- review rounds
- 3
- automatic repair rounds
- 2
- first plan to pull request
- 1 h 47 m
- Review round 1Gate sends it back
- CCorrectnessClaudeApprove
- CSecurityClaudeApprove
- CQualityClaudeApprove
- XSecurityCodexRequest changes
- DGeneralistDeepSeekApprove
The Codex security reviewer sent a malformed request line and showed the full IBAN reaching the server’s log, with a stack trace, then flagged a reachable component with known vulnerabilities. It reproduced the leak with a probe of its own. GateTwo must-fix findings. The gate sends it back.
- Repair 1 of 3
The developer agent reproduced the leak first, pinned the loggers, disabled the unused parser, upgraded the vulnerable component and added a regression test.
- Review round 2Gate sends it back
- CCorrectnessClaudeApprove
- CSecurityClaudeApprove
- CQualityClaudeApprove
- XSecurityCodexRequest changes
- DGeneralistDeepSeekApprove
The Codex reviewer found a second path: the container’s own error page echoed the IBAN back in its response and log, bypassing the service’s error handling. Again it reproduced it over real HTTP. The other security reviewer approved for the second time. GateOne blocking finding. The gate sends it back again.
- Repair 2 of 3
A dedicated error controller and filter now return sanitised problem responses with no path, for every failure the container can produce.
- Review round 3Gate clear
- CCorrectnessClaudeApprove
- CSecurityClaudeApprove
- CQualityClaudeApprove
- XSecurityCodexApprove
- DGeneralistDeepSeekApprove
All five reviewers approve. The pull request is raised with the review record attached. GateGate clear.
Code Assurance on the pull request
- Critical
- 0
- High
- 0
- Medium
- 9
- Low
- 18
PaymentGuard is a synthetic service built to demonstrate the mechanism, recorded on Brunelly's production platform in October 2026. It shows how the process responds to disagreement; it is not a benchmark of speed or cost.
Keep exploring
The rest of the platform.
How it works
The governed engineering process, step by step
Code Assurance
Six lenses on any code, including code you did not write
Planning and context
Boards, stories and what Brunelly knows about your code
Engines and integrations
Your models, repositories and trackers
Governance
Your standards enforced at merge, with exceptions on the record
Security and trust
How we protect your code, credentials and the record
Get started
Make software engineering repeatable.
Every engagement starts with a scoped pilot on one problem that matters, measured against how your team works today.