1The Missing Protocol
Parts 1–5 of this series built the architecture: five principles, nine sub-agent archetypes (including the checkpoint-verifier and premise analyst), externalized state, adversarial validation, and structured audit trails. Part 6 generalized beyond security review to testing, API review, migrations, and performance auditing. The Introduction identified sixteen failure modes across four priority tiers, and Parts 7+ added structural remediations—including a Phase 3.5 auto-completion loop that catches skipped checklist items before the output reaches you. The architecture now produces seven files per review:
review-[date]/
├── checklist.md # What was planned
├── plan.md # How it was executed (with OBJECTIVE line)
├── findings.md # What was found (with provenance chains)
├── premise-report.md # Premise analysis (shared premises, contradictions, dependencies)
├── remediation-log.md # What was changed
├── audit-report # Completeness + goal-fidelity assessment
└── verification-report # Checkpoint-verifier resultsThat's a lot of output. The architecture has been built to be thorough and auditable, but it has implicitly assumed something it never stated: the human reviewer knows what to do with all of this.
Without a protocol, the human either reads everything (which defeats the purpose of automation) or skims randomly (which defeats the purpose of human oversight). Both approaches miss the meta-level signals that the Tier 1 and Tier 2 remediations were specifically designed to produce. The checkpoint-verifier's verification rate, the auditor's goal-fidelity assessment, the premise analyst's shared premises and blast radius counts—these are triage signals that should determine how much of the findings document you need to read in detail.
The danger is automation complacency. The first time a developer reviews an agent's output, they read every line. By the twentieth, they're spot-checking. By the fiftieth, they're rubber-stamping. The silent corruption modes in Tiers 1 and 2 exploit exactly this gap—they produce output that passes the casual review that catches everything else. The triage protocol below exists because human vigilance degrades predictably, and the workflow needs structural defenses against that degradation.
The runbook is structured as a triage funnel. Start with the signals that can tell you in two minutes whether the whole review is trustworthy, then drill into findings only where the triage signals indicate you need to. The human's time should be spent on judgment calls—validating premises, assessing severity in context, deciding on implementation—not on verifying that the agent read the right files, which is what the checkpoint-verifier already did.
2The Five Stages
Every review follows the same five-stage structure regardless of domain. The stages are ordered from broadest triage (is the output trustworthy at all?) to narrowest action (was the specific fix applied correctly?). Each stage has a clear purpose, a time estimate, and decision criteria for whether to proceed or re-run.
| Stage | Purpose | Time | Key Output |
|---|---|---|---|
| 1. Health Check | Is the output trustworthy enough to act on? | 2–5 min | GO / RE-RUN decision |
| 2. Premise Triage | Were the agent's interpretive decisions reasonable? | 5–10 min | Validated or overridden premises |
| 3. Findings Review | Are the findings accurate, correctly prioritized, and actionable? | 10–60 min | Disposition per finding: IMPLEMENT / DEFER / REJECT / INVESTIGATE |
| 4. Implementation Readiness | Is it safe to let the implementer act? | 5 min | Scoped implementer instructions |
| 5. Post-Implementation | Did the changes work without breaking anything? | 5–10 min | Archived, verified review |
If any stage fails its criteria, the correct action is usually to re-run the workflow (or the affected portion) rather than to try to salvage unreliable output. The whole point of automation is that re-running is cheap; the expensive thing is the human's time.
3Stage 1: Health Check
Determine whether the review output is trustworthy enough to act on at all.
If the health check fails, re-run the workflow rather than trying to salvage the findings. This is always your first stop. Open the audit report—it contains all three trust signals.
Note: By the time you see this output, the Phase 3.5 auto-completion loop has already run. SKIPPED checklist items (where the orchestrator lost track of the plan) have been automatically re-scanned. Any remaining gaps are either BLOCKED (scanner tried and failed) or EMPTY (scanner ran, found nothing). This means a completion rate below threshold is a real signal, not an easily fixable oversight.
What percentage of checklist items have a corresponding finding or an explicit N/A justification? This is the first number in the audit report. Remember: the auto-completion loop has already re-scanned any SKIPPED items, so remaining gaps are structural.
Above threshold — The scanner covered the domain. Proceed.
Below threshold — Something went wrong in execution that auto-completion couldn't fix. Check the auto-completion summary in the audit report to see what was recovered and what remains.
Look specifically for unjustified skips: checklist items marked as skipped without explanation. Each skip should have a reason (N/A for this stack, deferred to manual review, blocked by access restriction). Skips without reasons are a red flag—they often indicate premature convergence or silent failure.
Also check for orphan findings: findings in findings.md that don't trace to any checklist item. Orphans aren't necessarily wrong, but they indicate the scanner went off-plan. If there are more than a few, the workflow may have drifted from its objective.
Before Re-Running: Completion Rate Diagnostics
The auto-completion summary tells you what type of gaps remain. Use this to determine what to fix before re-running:
Mostly BLOCKED items: The scanner tried and failed repeatedly. Check the error recovery log for the BLOCKED entries—they include what was tried and what failed. Common causes and fixes:
- Tool configuration issue (e.g., npm audit not available, linting tool not installed) → Install the missing tool or adjust the checklist to use alternative verification methods.
- Access permission issue (e.g., scanner can't read certain directories) → Fix permissions or exclude those paths and note as out-of-scope.
- Project structure incompatibility (e.g., scanner expects a Rails project but it's a monorepo with multiple frameworks) → Add framework-specific context to the scanner prompt describing the actual project structure.
Mostly SHALLOW items (found by completion quality check): The scanner ran but produced superficial findings that don't meet the completion criteria. This usually means the scanner is covering too many categories per invocation and quality is degrading. Fix: split into more focused scanner invocations with fewer categories each, or add explicit depth instructions ("you must examine every controller file, not just a sample").
Mix of BLOCKED and EMPTY with low overall count: The domain may be genuinely clean in those areas. Review the EMPTY categories to confirm they're reasonable before re-running—if they are, the completion rate may be acceptable despite being below the default threshold.
This is the single most important trust signal the architecture produces. The checkpoint-verifier's verification rate tells you what percentage of spot-checked findings were actually grounded in the codebase.
Above 90% — High trust. Focus your review on severity assessment and implementation decisions rather than evidence verification.
70–90% — Moderate trust. Review MISMATCH and NOT_FOUND findings individually. They may indicate a systematic pattern (the scanner misinterpreted a framework convention) or isolated errors.
Below 70% — Low trust. The scanner's output is unreliable. Do not proceed to implementation. Re-run the scanner for the affected categories, or if the problem is pervasive, re-run the entire workflow.
Before Re-Running: Verification Rate Diagnostics
The MISMATCH and NOT_FOUND findings are themselves diagnostic. Look at them before re-running to determine what to change:
MISMATCHes cluster around a specific pattern: The scanner is consistently misinterpreting a framework or language convention. For example, it flags async/await patterns as synchronous blocking calls, or it misidentifies a middleware chain as missing authentication. Fix: add framework-specific context to the scanner prompt: "This project uses Express.js middleware. Auth is applied at the router level via app.use(), not per-endpoint."
NOT_FOUND findings (file exists but described behavior isn't there): The scanner may be hallucinating code patterns. This often happens when files are too large for the scanner's effective context window. Fix: reduce the number of files scanned per invocation, or split large files into separate scanning passes.
Errors spread evenly across categories: No single pattern—the scanner may be covering too many categories in a single invocation and quality is degrading across the board. Fix: increase the number of scanner invocations with fewer categories each.
Errors concentrated in one or two categories: Re-run only those categories rather than the entire workflow. The scanner may need a more capable model for those specific categories (e.g., complex authentication flows or metaprogramming patterns may require a higher-capability model).
This tells you whether the review answered the question that was actually asked. It's in the auditor's output.
Review the OBJECTIVE line at the top of plan.md. Does it accurately capture what you wanted?
What percentage of findings are classified as RELEVANT versus TANGENTIAL or SUBSTITUTE?
Above 80% RELEVANT — The review addressed the right question. Proceed.
Below 80% RELEVANT — The review may have answered a different question than the one you asked. Look at the SUBSTITUTE findings specifically—they tell you what question the agent actually answered, which is diagnostic for improving the prompt on re-run.
Before Re-Running: Goal-Fidelity Diagnostics
The SUBSTITUTE findings tell you what question the agent actually answered. Use this to diagnose the substitution pattern and fix the prompt:
Agent cataloged instead of assessed: Asked to "identify backward compatibility risks" but instead produced an endpoint inventory. The objective is too abstract—the agent defaulted to the easier descriptive task. Fix: rewrite the OBJECTIVE with concrete evaluation criteria and add negative examples to the orchestration prompt: "Do NOT catalog endpoints. DO assess what would break for existing consumers if each endpoint changed."
Agent described instead of evaluated: Asked to "analyze error handling quality" but instead documented what error handling exists. Fix: add explicit evaluation criteria to the checklist items—not just "review X" but "evaluate whether X meets Y standard, flag cases where it doesn't."
Agent answered a related but easier question: Asked about security risks but produced a code quality review. The agent substituted a goal it's more confident about. Fix: tighten the validator's rule zero check and consider adding a worked example to the scanner prompt showing what a goal-faithful finding looks like versus a goal-substituted one for this specific domain.
Mostly TANGENTIAL rather than SUBSTITUTE: The agent addressed the right question but went on tangents—real findings that are true but don't help with the stated objective. This is a milder form that often indicates the checklist is too broad. Fix: narrow the checklist to focus on the specific objective rather than covering the entire domain.
If any of the three checks fail (completion below threshold, verification below 70%, or goal-fidelity below 80% RELEVANT), stop and address the structural issue before reviewing individual findings. Use the diagnostic guidance in the expandable sections above to determine what to change before re-running—a blind re-run with the same prompts will usually produce the same failures. Re-running with a corrected prompt is almost always faster than trying to salvage unreliable output.
4Stage 2: Premise Triage
Validate the agent's interpretive decisions before reviewing findings that depend on them.
The premise analyst has read all scanner reasoning chains and produced premise-report.md with shared premises, contradictions, ungrounded inferences, and blast radius counts. Your job is to validate the high-impact premises—not all of them.
Scan the shared premises section, but focus your attention on entries where the premise analyst flagged them as high-impact. Check the "Blast Radius" section for premises that affect multiple findings or that would invalidate entire categories if wrong.
The premise analyst extracts these from reasoning chains rather than self-reported assumption logs, which means they capture premises the scanner doesn't recognize as assumptions—training-data priors that feel like "just knowing."
Is the assumed interpretation correct for your specific context? The agent chose the most likely interpretation based on training patterns, but you know things about your project that the agent doesn't—team conventions, historical decisions, planned migrations, business constraints.
If the premise is wrong, which findings are affected? The premise analyst's "Dependencies" section lists the finding IDs that depend on each premise. If you override the premise, those findings need to be re-evaluated or removed.
Does the alternative interpretation change the severity of anything? A premise that's wrong but only affects LOW-severity findings is less urgent than one that could elevate something to CRITICAL.
For each high-impact premise, note whether you CONFIRMED, OVERRODE, or flagged as NEEDS INVESTIGATION. This creates a record that's useful both for this review and for tuning future prompts.
Pay special attention to premises flagged in the "Contradictions" section—these indicate the premise analyst found reasoning chains that make incompatible assumptions about the same ambiguity.
If you override more than two or three high-impact premises, the scanner lacks domain-specific context. Before the next review cycle, update the scanner prompt with the context you used to override the premises. For example, if you overrode a premise about naming conventions, add the correct convention to the scanner's context. If you overrode a premise about what's public-facing versus internal, add your deployment architecture to the prompt. The premise analyst makes these context gaps visible in a way that self-reported assumption logs never could—it surfaces what the agent actually assumes, not what it thinks it should report.
5Stage 3: Findings Review
Assess findings for accuracy, severity, and actionability.
The health check told you the output is trustworthy. The premise triage told you the interpretive decisions are sound. This stage is about severity assessment, prioritization, and implementation decisions.
Start with CRITICAL findings, then HIGH, then MEDIUM. LOW and INFO findings can usually be accepted or deferred without detailed review. For each CRITICAL and HIGH finding:
Read the evidence. The verbatim code quote and line range should let you see the issue without opening the file. Does the code actually exhibit the problem described?
Check provenance. Was this finding verified by the checkpoint-verifier? If the verification result is PENDING, this finding bypassed verification—apply extra scrutiny. If it's MISMATCH, it was flagged as problematic and should have been removed or re-investigated; its presence in findings.md is itself an error.
Assess impact in context. The finding's stated impact is based on the code in isolation. You know the deployment context, the user base, the risk tolerance, the release timeline. A "CRITICAL" finding in a feature branch that hasn't been deployed yet is different from the same finding in production.
Individual findings are useful, but patterns are more valuable:
Cluster analysis. Are there many findings in the same file or module? This might indicate a systemic design issue rather than isolated bugs.
Type repetition. Are there many findings of the same type across different files? This suggests a project-wide convention problem.
Suspicious zeros. Are there categories with zero findings? Sometimes the code is clean in that area; sometimes it indicates scanner failure. Cross-reference with the audit report's completion data.
First-principles hits. Did the first-principles check from the validator produce anything the standards-based review missed? These findings are often the most valuable because they're specific to your codebase.
For each finding (or group of related findings), assign a disposition:
IMPLEMENT — Approve for the implementer sub-agent to fix. Include any constraints (e.g., "fix but preserve backward compatibility," "use approach X rather than Y").
DEFER — Valid finding, but not for this review cycle. Note the reason and target milestone.
REJECT — Finding is incorrect, not applicable, or acceptable risk. Note the reason—this is valuable training data for prompt refinement.
INVESTIGATE — Finding might be real but needs more context than the review provides. Assign to a human for manual investigation.
6Stage 4: Implementation Readiness
Verify it is safe to let the implementer sub-agent act.
This is the last gate before automated code changes. Every check here is a safety measure against the failure modes the earlier stages may not have caught.
Review the findings you marked as IMPLEMENT against the domain's stop conditions (enumerated in the domain sections of Part 6 and the domain adaptation section below). If any finding triggers a stop condition, remove it from the IMPLEMENT queue and route it to manual handling.
Do any IMPLEMENT-queued findings depend on premises you haven't validated? Cross-reference the premise dependencies in the provenance section of each finding against your decisions in Stage 2. Do not implement findings that rest on unvalidated premises.
How many files will the implementer touch? Are any of them shared infrastructure, configuration, or database schemas? Findings that modify widely-imported modules or configuration files deserve extra scrutiny because implementation errors will compound.
Write explicit constraints on what the implementer should and should not change. The more specific the instruction, the less room for the implementer to drift.
Good "Fix the SQL injection in user_controller.rb lines 45–52 by using parameterized queries."
Vague "Fix finding SEC-F-07."
7Stage 5: Post-Implementation Verification
Confirm the changes work without breaking anything, then archive.
After the implementer and verifier sub-agents have run, the human closes the loop.
Each implementation should have an entry in remediation-log.md documenting what was changed, what finding it addresses, and whether the verifier sub-agent confirmed the fix. Scan for entries where the verifier flagged a problem or where the implementer noted it deviated from the original instruction.
Don't review every change, but verify at least one CRITICAL fix by reading the actual diff. This catches cases where the implementer technically addressed the finding but introduced a new issue. Which implementation to spot-check depends on your domain—see the domain adaptation section below.
If the domain has a test suite, run it after all implementations are complete. This is the simplest way to catch regression from implementer changes. For domains without test suites, use the domain-specific regression test described in the adaptation section.
The review directory (checklist, plan, findings, premise-report, remediation-log, audit report, verification report) is the audit trail. Keep it versioned alongside the codebase. It answers the question "what was reviewed, what was found, and what was done about it" for any future audit.
8Adapting the Runbook to Specific Domains
The five-stage structure is domain-independent—it works for any workflow that uses the sub-agent architecture. But each domain has specific signals, red flags, and review priorities that the human reviewer should know about. The adaptation isn't about changing the runbook's structure (the five stages always apply); it's about filling in domain-specific guidance within each stage.
Adaptation Point 1: Health Check Thresholds
The verification and completion thresholds aren't universal. Some domains tolerate lower verification rates because their findings are harder to spot-check; others demand higher rates because the consequences of acting on a false finding are severe.
| Domain | Min. Verification | Min. Completion | Rationale |
|---|---|---|---|
| Security Review | 80% | 90% | False negatives are more dangerous than false positives—you need high completion. False positives waste time but don't cause harm. |
| Test Generation | 70% | 80% | Tests that fail to compile are immediately caught downstream. The test runner provides a second verification layer. |
| API Review | 85% | 85% | API findings often drive breaking changes. A false finding that leads to an unnecessary breaking change is costly. |
| Migration Review | 90% | 95% | Highest stakes. A false finding that leads to an unnecessary migration change can cause data loss. |
| Performance Audit | 70% | 75% | Performance findings are inherently probabilistic. Impact depends on runtime conditions the scanner can't observe. |
Adaptation Point 2: Premise Review Focus
Different domains produce different kinds of ambiguity. The reviewer should know which premise categories are most dangerous in their domain.
Highest-risk premises are about authorization scope—"I assumed this endpoint is internal-only because it's not in the router's public prefix." If wrong, a finding might be dismissed that should be CRITICAL. Priority-review any premise about what's public-facing versus internal.
Highest-risk premises are about test framework conventions—"I assumed this project uses factory_bot for fixtures because I found a few factory files." If wrong, generated tests won't integrate cleanly. Priority-review any premise about project conventions.
Highest-risk premises are about intentional versus accidental inconsistency—"I assumed camelCase is the intended convention." Many API inconsistencies are deliberate (different microservice teams, different API versions). Priority-review any premise about what constitutes a "standard" in the project.
Virtually all premises are high-risk. The reviewer should validate every premise in premise-report.md, not just the ones flagged by the premise analyst. The cost of a wrong premise in migration review is production downtime or data loss.
Highest-risk premises are about expected scale—"I assumed this endpoint handles fewer than 100 requests per second based on the lack of caching." Performance findings are meaningless without accurate load premises. Priority-review any premise about traffic volume, data size, or concurrency.
Adaptation Point 3: Findings Review — Domain-Specific Red Flags
Within Stage 3, the reviewer should watch for domain-specific patterns that indicate the scanner may have missed something important or mischaracterized something.
Watch for findings that describe a vulnerability but recommend a mitigation that doesn't fully close it. A common scanner error is recommending input validation when the real fix is parameterized queries, or recommending HTTPS when the real issue is broken authentication. The recommendation should match the vulnerability class.
Watch for tests that test the framework rather than the application—asserting that the ORM can save a record rather than testing business logic. Also watch for tests that mock away the thing they're supposed to test. Both are common patterns in AI-generated tests that pass the auditor's completeness check but provide no actual coverage.
Watch for findings that flag inconsistencies that are actually versioned evolution. If endpoints in /v1/ use one convention and /v2/ uses another, the scanner may flag this as inconsistency when it's intentional migration. Cross-reference findings against the project's versioning strategy.
Watch for findings that assess lock impact without knowing table sizes. The scanner can identify that an ALTER TABLE will acquire an ACCESS EXCLUSIVE lock, but it can't know whether the table has 100 rows or 100 million. Every lock-related finding needs manual validation against production table sizes.
Watch for findings based on static analysis that may not reflect runtime behavior. A function that looks like it has O(n²) complexity may only ever be called with small inputs. Performance findings without load context are hypotheses, not bugs—make sure the severity rating reflects this.
Adaptation Point 4: Implementation Readiness — Domain Stop Conditions
Stage 4 references "when to stop" conditions. These are specific to each domain (they're enumerated in the domain sections of Part 6), but the reviewer should also apply a meta-rule: if you're uncertain whether a finding should be implemented, it shouldn't be. The cost of deferring a valid finding is another review cycle. The cost of implementing a false finding ranges from wasted time (test generation) to data loss (migration review).
Any finding that modifies shared infrastructure, configuration, or data schemas should get INVESTIGATE rather than IMPLEMENT unless the evidence is unambiguous and the fix is narrowly scoped.
Adaptation Point 5: Post-Implementation — What to Spot-Check
In Stage 5, the runbook says "spot-check one or two implementations." The choice of which to spot-check should be domain-informed:
Spot-check the fix for the highest-severity vulnerability. Security fixes have the highest blast radius when done wrong. Regression test: run existing security tests plus SAST/DAST if available.
Run the full test suite and check coverage deltas. This is the domain where post-implementation verification is most automated—if the tests pass and coverage improved, the implementation is probably correct. Regression test: the test suite itself.
If any breaking changes were implemented, verify them against a consumer. The scanner can identify a breaking change, but only a consumer integration test (or manual test) can confirm the migration path works. Regression test: consumer contract tests or integration suite.
Never rely on the verifier alone. Run the migration against a staging database with production-like data. Check that rollback works. This is the domain where automated verification is least sufficient. Regression test: full migration + rollback on staging.
Run a before-and-after benchmark. Performance fixes that look correct in code review sometimes have no measurable impact—or make things worse due to unexpected interactions. Regression test: load test or benchmark suite.
9Adapting the Runbook to a New Domain
When adapting the runbook to a domain not covered above, the five-stage structure does not change. Only the thresholds, focus areas, and red flags within each stage change. Fill in the template below before your first review in a new domain.
| Runbook Element | Your Domain's Guidance |
|---|---|
| Verification rate threshold | What minimum rate makes findings trustworthy enough to act on? Consider: what's the cost of implementing a false finding? |
| Completion rate threshold | What minimum completion rate indicates the scanner covered the domain? Consider: what's the cost of a false negative (missing a real issue)? |
| Highest-risk premise categories | What kinds of ambiguity produce the most dangerous wrong answers in this domain? |
| Domain-specific red flags in findings | What patterns indicate the scanner mischaracterized something? What does a plausible-but-wrong finding look like? |
| Stop conditions for implementation | When should a finding be routed to manual handling rather than automated implementation? |
| What to spot-check post-implementation | Which implementation is most important to verify manually? Where do implementer errors cause the most damage? |
| Domain-specific regression test | What test or check confirms implementations didn't break anything? |
Use the domain adaptations in Section 8 as worked examples. The security review adaptation shows what a high-stakes, false-negative-sensitive domain looks like. The performance audit adaptation shows what a probabilistic, runtime-dependent domain looks like. Most new domains will fall somewhere between these poles.
Threshold Selection Guide
If you're unsure where to set thresholds for a new domain, use these two questions as a decision framework:
If acting on a wrong finding causes data loss, security exposure, or breaking changes → set verification threshold high (85–95%). If acting on a wrong finding wastes time but is otherwise harmless → set verification threshold moderate (70–80%).
If a false negative means an exploitable vulnerability, data corruption, or production outage → set completion threshold high (90–95%). If a false negative means a missed optimization or a minor inconsistency → set completion threshold moderate (75–85%).
The two questions are independent. Migration review scores high on both (high cost of false positives and false negatives). Performance audit scores low on both (probabilistic findings, optimization-focused rather than safety-focused). Security review is asymmetric—moderate cost of false positives, very high cost of false negatives—which is why its verification threshold is lower than its completion threshold.
10Frequently Asked Questions
No. The runbook is structured as a triage funnel. Stage 1 (Health Check) tells you in 2–5 minutes whether the review output is trustworthy at all. If the checkpoint-verifier's verification rate is above 90% and the goal-fidelity assessment shows more than 80% RELEVANT findings, you can focus your review on CRITICAL and HIGH severity findings, disposition decisions, and implementation constraints. You should only deep-read the full findings document when trust signals are low.
If the health check passes, a typical review takes 15–20 minutes: 2–5 minutes for the health check, 5–10 minutes for premise triage (focusing on high-impact premises only), and 5–10 minutes for findings disposition on CRITICAL and HIGH items. If the health check fails, the correct response is usually to re-run the workflow rather than spend time salvaging unreliable output.
Use the verification rate as your primary signal. Below 70%, re-run the entire workflow—the scanner's output is systematically unreliable. Between 70–90%, investigate the MISMATCH and NOT_FOUND findings to determine if they indicate a systematic pattern (re-run the affected categories) or isolated errors (remove and proceed). Above 90%, fix individual findings. If more than 20% of findings are goal-substituted (TANGENTIAL or SUBSTITUTE), re-run with a tighter scoping prompt rather than filtering findings manually. In all cases, use the diagnostic guidance in Stage 1's expandable sections to determine what to change before re-running—a blind re-run with the same prompts will usually reproduce the same failures. For completion rate issues, note that the auto-completion loop has already re-scanned SKIPPED items, so remaining gaps are BLOCKED or EMPTY and need targeted fixes.
Always start with the audit report, not the findings document. The audit report contains three critical trust signals: the completion rate (what percentage of checklist items were addressed), the checkpoint-verifier's verification rate (what percentage of spot-checked findings were grounded in the actual codebase), and the goal-fidelity assessment (what percentage of findings actually address the stated objective). It also includes the auto-completion summary, which shows whether any SKIPPED items were recovered and what gaps remain as BLOCKED or EMPTY. These numbers tell you in under two minutes whether the rest of the output is worth reading in detail.
Thresholds reflect the cost of acting on a false finding versus the cost of missing a real one. Migration review demands the highest thresholds (90% verification, 95% completion) because both false positives and false negatives can cause data loss. Security review needs high completion (90%) but tolerates moderate verification (80%) because false positives waste time without causing harm. Performance audit accepts the lowest thresholds (70%/75%) because findings are inherently probabilistic. Test generation tolerates lower verification (70%) because tests that fail to compile are caught immediately by the test runner.
The five-stage runbook structure applies to every domain. Fill in the seven-element domain adaptation template in Section 9: verification rate threshold, completion rate threshold, highest-risk premise categories, domain-specific red flags, stop conditions, spot-check guidance, and regression test. Use the two-question threshold selection guide (cost of false positive, cost of false negative) to calibrate your thresholds. The existing domain adaptations serve as worked examples spanning the full spectrum from high-stakes (migration) to probabilistic (performance).
Before premise analysis existed, you had to evaluate every finding from scratch—assessing both whether the evidence was correct and whether the interpretation was right. Now, premise analysis separates these concerns. Correctness is handled by the checkpoint-verifier. Interpretation is surfaced in premise-report.md. You only need to validate the high-impact premises flagged by the premise analyst, which dramatically reduces the number of findings you need to deep-read. The premise analyst extracts these from reasoning chains rather than self-reported assumption logs, which means it captures premises the scanner doesn't recognize as assumptions. If the premises are valid, the findings that depend on them can be assessed on severity and actionability alone.
REJECT decisions are valuable training data, not waste. Document the reason for each rejection. If you see repeated rejection patterns (e.g., the scanner consistently flags a framework pattern as an anti-pattern), update the scanner prompt or checklist template to exclude that pattern. Over multiple review cycles, your rejection rate should decline as the prompts improve. A consistently low rejection rate across reviews is a signal that the workflow is well-calibrated for your codebase.