The Adversarial Research Protocol: How Three Autonomous Personas Stress-Test Every Idea
Every major architectural decision at Greyforge Labs now faces structured opposition before implementation. The objective is simple: expose weak ideas early, ship only what survives pressure.
Architecture Dossier
- Research question or engineering problem
- What minimum contract turns structured disagreement into a reviewable build decision?
- Principal finding
- Independent opportunity, evidence, and failure roles need fixed inputs, retained artifacts, a bounded rubric, a stopping rule, and an owner-decided threshold.
- Evidence type
- Greyforge decision protocol and sanitized worked example.
- Method summary
- Specify inputs, roles, two rebuttal rounds, required ledgers, criterion states, consensus, and GO, NO-GO, or DEFER outcomes.
- Scope
- Architecture and product decisions; it does not grant execution or publication authority.
- Limitations
- The protocol has not been benchmarked against other decision systems.
- Role independence depends on source and context separation in the actual run.
- Public source or reproduction note
- Protocol is fully described on this page
- Published
- 2026-02-27
- Last verified
- 2026-08-27
- Status
- current
A Closed Review Discipline
Greyforge developed a closed adversarial review discipline, born from the same Council of Intellect philosophy and built around three specialized personas. Their job is not to agree. Their job is to make bad decisions fail fast.
The Visionary
Expansive, opportunity-focused, and biased toward strategic upside.
The Empiricist
Facts-only, evidence-grounded, and intolerant of unsupported claims.
The Critic
Adversarial by design, tasked with breaking weak arguments and hidden assumptions.
The Refinement Cycle
The protocol operates in controlled cycles:
vision → fact-check → attack → adapt → re-attack → consensus
At the end of the cycle, the named decision owner records GO, NO-GO, or DEFER. The review roles provide evidence and objections; they do not grant execution, spending, publication, or deployment authority.
The Protocol Contract
A run begins only when the packet names the proposal, decision owner, decision deadline, allowed evidence, operating constraints, reversible test budget, and observable success and failure conditions. Missing fields produce DEFER, not improvisation.
Source selection follows a fixed order: primary specifications, source code, and retained first-party measurements before secondary analysis; dated public metadata when full text is unavailable; and an explicit missing-evidence entry when neither is sufficient. Sources are included only when they can change a named criterion, and every material claim records its source, date, scope, and contradiction status in the source ledger.
Opportunity case
States the strongest useful outcome, prerequisites, reversible test, and opportunity cost of waiting.
Evidence case
Checks sources, claim boundaries, missing evidence, comparator quality, and whether the proposed test could answer the question.
Failure case
Attacks authority, safety, maintenance, rollback, privacy, and ways the success signal could mislead.
The three cases are authored independently before rebuttal. One role may challenge another role's evidence, but may not silently rewrite that role's claim ledger. The run retains a source ledger, claim ledger, attack log, rebuttal log, open-risk list, and final decision record.
Rounds, Rubric, and Stop Rule
- Round 1: independent opportunity, evidence, and failure cases.
- Round 2: each role answers material attacks with new evidence, a narrower claim, or an explicit concession.
- Closeout: the decision owner records unresolved risks and chooses GO, NO-GO, or DEFER.
The rubric rates evidence quality, scope fit, reversibility, operational risk, maintenance cost, and unresolved uncertainty as insufficient, bounded, or strong. A GO requires bounded or strong support for every required criterion and no unresolved high-impact objection. The run stops after two rebuttal rounds unless genuinely new evidence changes a material claim. Consensus means objections are resolved or explicitly accepted by the decision owner, not that every role expresses agreement.
Sanitized Worked Example
Proposal: add an inbound build webhook
The opportunity case identifies faster review starts. The evidence case finds no retained load or delivery baseline. The failure case finds that sender authentication, replay handling, command authority, and rollback are unspecified.
Verdict: NO-GO. The feature may return only with an authenticated event contract, a read-only first action, replay protection, a bounded queue, and a rollback test. The result rejects the current packet without claiming the idea can never work.
Real Outcome: VoiceOps Pre-Mortem
A historical internal decision record applied an earlier form of the protocol to the VoiceOps initiative. That record counted two high-impact objections and five additional issues before implementation.
The public archive does not retain a counterfactual cost baseline, so this page does not claim a measured reduction in churn or integration risk. It supports the narrower observation that the objections changed the build constraints before production work.
Strategic Effect
This protocol converts architectural debate into an evidence engine. It is now a core differentiator in how Greyforge Labs makes build decisions.
Organizational Memory and the Next Loop
Protocol outcomes are stored as long-term organizational memory. Surviving arguments, failed claims, and final verdicts are accumulated into a persistent reasoning corpus.
Future automation remains a position, not a measured result. Any automated loop must preserve the same source boundaries, independent artifacts, stop rule, named decision owner, and approval gates before it can replace a manual review step.