differential-review

Use to stress-test a research proposal before committing to implementation

Differential Review

Overview

Adversarial review of research proposals. The goal is to catch fatal flaws before spending time on implementation.

When to Use

  • Before implementing any novel algorithm or approach
  • When a research proposal looks "too good to be true"
  • When the team has a history of implement-then-discard cycles

Process

1. Read Independently

Read the proposal fresh. You should NOT have been involved in creating it. Independence = no confirmation bias.

2. Stress Test — False Positives

  • Enumerate 5-10 common patterns that would trigger false positives
  • Estimate: "On 100 real projects, how many FPs?"
  • Are the proposal's FP estimates realistic or optimistic?

3. Stress Test — False Negatives

  • Enumerate evasion patterns or edge cases the approach would miss
  • Estimate: "What % of real issues would we miss?"
  • Does the approach handle indirect/dynamic patterns?

4. Feasibility Check

  • Is this tractable on real-world codebases (>10K LOC)?
  • Does it require information we don't have?
  • Can it be implemented in reasonable time?

5. Prior Failure Pattern Check

  • Not a heuristic disguised as real detection
  • Not overly optimistic in estimates
  • Not severity-inflated
  • Compliant with honesty-first rules

6. Alternative Comparison

  • Is there a simpler approach with 80% of the value and 20% of the risk?

7. Issue Verdict

VerdictWhenEffect
PROCEEDSound, realistic→ Implement
REVISEFixable issues (Rounds 1-2)→ Researcher fixes specific points
REJECTFundamentally flawed (Rounds 1-2)→ Researcher pivots approach
ESCALATERound 3, no path forward→ Human decides

Output Template

## Differential Review: {proposal title}

### Round: {N} of 3

### FP Risk Assessment
{patterns that would false-trigger, estimated rate}

### FN Risk Assessment
{patterns that would be missed, estimated rate}

### Feasibility
{tractable? dependencies? timeline?}

### Prior Failure Patterns
{checklist results}

### Alternative Approaches
{simpler options considered}

### Verdict: {PROCEED/REVISE/REJECT/ESCALATE}
{Rationale in 2-3 sentences}

### Required Changes (if REVISE)
{Numbered list of specific changes}