@accelerationguy/accel 1.0.0

package/modules/radar/src/rules/epistemic-hygiene.md

@@ -0,0 +1,78 @@
+---
+id: epistemic-hygiene
+name: Epistemic Hygiene
+scope: all_agents
+priority: critical
+---
+
+## Purpose
+
+Without epistemic hygiene rules, agents produce findings that sound confident but lack evidence, assert severity without justification, and treat tool output as ground truth. These are the five invariants that make Radar epistemically honest. They are non-negotiable — no persona can override them, no workflow can skip them, and no domain can contradict them.
+
+Every failure mode these rules prevent has been observed in AI-generated analysis: confident conclusions built on unexamined assumptions, severity inflation to appear thorough, tool output parroted without interpretation, and clean narratives that paper over genuine uncertainty. These rules exist because the default behavior of language models is precisely what rigorous analysis must reject.
+
+## Rules
+
+### 1. No risk statements without observations
+
+**Statement:** An agent must not produce a risk statement (Layer 5) without a corresponding observation (Layer 1). Risk cannot be asserted without first establishing what was observed.
+
+**Rationale:** Risk statements that skip observation are speculation, not analysis. "This system is vulnerable to SQL injection" without identifying where in the code the vulnerability exists is unfalsifiable. Observations ground risk in reality.
+
+**Enforcement:** Finding validation rejects any finding where Layer 5 (risk statement) is populated but Layer 1 (observation) is empty, vague, or contains risk language instead of factual observation. The observation must describe what exists, not what could go wrong.
+
+### 2. No judgments without risk modeling
+
+**Statement:** An agent must not produce a judgment (Layer 7) without completing risk modeling (Layer 6). Judgment requires impact domain, magnitude, likelihood, time horizon, and blast radius.
+
+**Rationale:** Judgments without risk modeling are gut reactions. "Must fix" without understanding impact magnitude, likelihood, and blast radius leads to misallocated remediation effort. Risk modeling makes the basis for judgment explicit and challengeable.
+
+**Enforcement:** Finding validation rejects any finding where Layer 7 (judgment) is populated but Layer 6 (impact & likelihood) has missing or non-enum values. All five Layer 6 dimensions must be present with valid enumerated values.
+
+### 3. No confidence without evidence
+
+**Statement:** A confidence vector must be grounded in actual evidence. High confidence scores require explicit justification referencing concrete evidence sources.
+
+**Rationale:** Agents default to high confidence because it sounds authoritative. Miscalibrated confidence inflates the apparent reliability of findings, distorts prioritization, and — in the Transform pipeline — can trigger higher intervention levels than evidence warrants. Confidence must reflect actual evidential strength, not rhetorical force.
+
+**Enforcement:** Confidence validation rejects vectors where evidence_diversity exceeds 1 but Layer 2 lists only one source type. Dimensions scored 4 or 5 must have corresponding justification text. A confidence vector with all dimensions at 4+ and a one-sentence justification is flagged for review.
+
+### 4. No synthesis without acknowledging uncertainty
+
+**Statement:** Report synthesis sections (Executive Summary, Remediation Roadmap) must reference assumption fragility, confidence limitations, and open disagreements. Clean narratives that omit uncertainty are epistemically dishonest.
+
+**Rationale:** Leadership reads the Executive Summary first and may read nothing else. If that summary presents a clean, confident narrative without acknowledging where the analysis is uncertain, leadership makes decisions on incomplete information. Uncertainty acknowledgment is not weakness — it is calibration.
+
+**Enforcement:** Report validation checks that Section 1 (Executive Summary) references the unresolved disagreement count and any findings with confidence_vector.overall: low. Section 5 (Remediation Roadmap) must flag recommendations based on low-confidence findings.
+
+### 5. No "clean narrative" without Devil's Advocate response
+
+**Statement:** The Phase 5 synthesis report cannot be finalized without the Devil's Advocate critique being produced and explicitly addressed. Every Devil's Advocate disagreement must have a Principal response.
+
+**Rationale:** The Devil's Advocate exists to break comforting narratives. If the Devil's Advocate phase is skipped or its output ignored, the audit has a structural blind spot. A report that was never challenged is a report that was never tested.
+
+**Enforcement:** Report generation workflow checks for the existence of Devil's Advocate disagreement records (agent_id: devils-advocate). If none exist, the audit is incomplete. If they exist but any has principal_response empty, the report cannot be finalized. The Devil's Advocate panel in the report (Section 4) must not be empty.
+
+## DO
+
+- Finding states: "Confidence: medium — Semgrep flagged this pattern but the custom sanitizer at line 45 may handle it. Manual verification needed." (Confidence is calibrated to actual uncertainty.)
+
+- Finding observation (Layer 1) reads: "Function `retryRequest()` at `src/http/client.ts:34` calls itself recursively on HTTP 500 responses with no maximum retry count or backoff." (Pure observation — no adjectives, no risk language.)
+
+- Executive Summary includes: "4 total disagreements, 1 unresolved. Finding F-02-005 has low confidence (evidence_diversity: 1) and requires runtime validation before remediation prioritization." (Uncertainty is explicit.)
+
+- Agent disagrees with tool output: "Semgrep reports SQL injection at line 32, but the parameterized query builder at line 28 prevents this. Downgrading to informational — likely false positive." (Tool output is treated as signal, not truth.)
+
+## DON'T
+
+- Finding asserts "Critical SQL injection vulnerability" in Layer 1.
+  **Why this is wrong:** "Critical" and "vulnerability" are Layer 6/7 concepts (impact, judgment). Layer 1 must describe what was observed: "String concatenation used in SQL query construction at line 45 with user-supplied input."
+
+- Finding has Layer 7 judgment "must_fix" but Layer 6 shows only `severity: high` with no likelihood, time horizon, or blast radius.
+  **Why this is wrong:** Judgment without complete risk modeling is a gut reaction. "Must fix" requires knowing not just severity but how likely, how soon, and how widely the impact spreads.
+
+- Confidence vector shows evidence_diversity: 4 with justification: "Multiple sources confirmed this."
+  **Why this is wrong:** Justification must be specific. Which sources? What types? "Multiple sources" is vague and could mask the fact that all sources are the same type (e.g., four static analysis tools).
+
+- Executive Summary reads: "The codebase is in good shape overall with a few areas needing attention."
+  **Why this is wrong:** "Good shape overall" is a clean narrative. If there are 2 critical findings and an unresolved disagreement, the summary must say so. Hedging language that minimizes findings is epistemically dishonest.

package/modules/radar/src/schemas/confidence.md

@@ -0,0 +1,185 @@
+---
+id: confidence
+name: Confidence Vector
+version: 1.0.0
+used_by:
+  - principal-engineer
+  - architect
+  - data-engineer
+  - security-engineer
+  - compliance-officer
+  - senior-app-engineer
+  - sre
+  - performance-engineer
+  - test-engineer
+  - staff-engineer
+  - reality-gap-analyst
+  - devils-advocate
+---
+
+## Purpose
+
+Confidence in Radar is a vector, not a scalar. A single "high/medium/low" rating hides which aspects of confidence are strong and which are weak. An agent might have strong evidence diversity (four tools flagged the same issue) but weak signal freshness (all evidence is static analysis, no runtime validation). A scalar "medium" hides this — the vector exposes it.
+
+The 4-dimension model enables nuanced statements like "High-impact, low-confidence risk — validate before remediation." This is senior-level nuance that scalar confidence destroys.
+
+Each dimension is independently scored on a 1-5 scale with anchored descriptions, producing a confidence profile rather than a confidence rating. The `overall` field derives from the dimensions using a conservative formula — the weakest evidence dimension drags the aggregate down, because a finding is only as trustworthy as its weakest evidential link.
+
+Transform intervention levels gate on confidence dimensions: a finding with low evidence diversity cannot produce a planning-level remediation, regardless of how high its historical precedent score is. This prevents confident-sounding but poorly-evidenced findings from generating unsafe change plans.
+
+## Template
+
+```markdown
+#### Confidence Vector
+
+| Dimension | Score | Anchor |
+|-----------|-------|--------|
+| Evidence diversity | {evidence_diversity} | {evidence_diversity_anchor} |
+| Signal freshness | {signal_freshness} | {signal_freshness_anchor} |
+| Assumption fragility | {assumption_fragility} | {assumption_fragility_anchor} |
+| Historical precedent | {historical_precedent} | {historical_precedent_anchor} |
+
+**Overall:** {overall}
+**Justification:** {justification}
+```
+
+## Field Reference
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `evidence_diversity` | integer | yes | How many independent source types support this finding. Independent means different evidence categories (static analysis, runtime, history, config), not different tools within the same category. | 1-5 (see scale below) |
+| `signal_freshness` | integer | yes | Temporal relevance of the evidence. Static code analysis sees code as-written; runtime data sees code as-running. Fresher signals are more trustworthy for behavioral claims. | 1-5 (see scale below) |
+| `assumption_fragility` | integer | yes | How easily the finding's assumptions could be wrong. Inverse fragility — higher scores mean more robust assumptions. | 1-5 (see scale below) |
+| `historical_precedent` | integer | yes | Whether this pattern is a known failure mode with documented incidents. Known patterns have higher prior probability and better-understood consequences. | 1-5 (see scale below) |
+| `overall` | enum | yes | Conservative aggregate derived from dimension scores. | `low`, `medium`, `high` (see derivation formula) |
+| `justification` | string | yes | Explanation of the dimension scores. At minimum, one sentence per dimension scored 4 or 5. Must explain why the score is warranted, not just restate the anchor description. | Free text, minimum one sentence per high-scoring dimension. |
+
+### Dimension Scales
+
+#### Evidence Diversity (1-5)
+
+| Score | Anchor | Description |
+|-------|--------|-------------|
+| 1 | Single source | One tool or one manual observation. No corroboration. |
+| 2 | Single source type | Multiple tools of the same type (e.g., two static analyzers). Corroboration within one evidence category. |
+| 3 | Two source types | Two different evidence categories (e.g., static analysis + configuration review). |
+| 4 | Three+ source types | Three or more evidence categories (e.g., static + runtime + history). Strong cross-validation. |
+| 5 | Comprehensive | Multiple independent source types with cross-validation. Evidence converges from orthogonal directions. |
+
+#### Signal Freshness (1-5)
+
+| Score | Anchor | Description |
+|-------|--------|-------------|
+| 1 | Historical only | Evidence is from past data only (old git history, archived logs). No current evidence. |
+| 2 | Static only | Code as-written analysis. No runtime, deployment, or configuration validation. |
+| 3 | Static + config | Static analysis plus recent configuration or deployment data. |
+| 4 | Includes runtime | Evidence includes recent runtime data (logs, metrics, profiling). |
+| 5 | Live validation | Current runtime validation available. Evidence reflects the system as it runs now. |
+
+#### Assumption Fragility (1-5)
+
+Higher score = more robust assumptions (inverse fragility).
+
+| Score | Anchor | Description |
+|-------|--------|-------------|
+| 1 | Highly fragile | Finding depends on multiple unverified assumptions. Any one being wrong invalidates the finding. |
+| 2 | Fragile | Key assumption is plausible but unverified. Finding may not hold under closer inspection. |
+| 3 | Moderate | Key assumptions are reasonable with partial evidence. Finding likely holds but has uncertainty. |
+| 4 | Robust | Most assumptions are verified or low-risk. Finding is solid with minor uncertainty. |
+| 5 | Self-evident | All assumptions are verified or self-evident from the evidence. Finding is effectively certain given the evidence. |
+
+#### Historical Precedent (1-5)
+
+| Score | Anchor | Description |
+|-------|--------|-------------|
+| 1 | Novel | No known precedent for this pattern. First-time observation. |
+| 2 | Theoretical | Theoretically possible failure mode discussed in literature but rarely observed. |
+| 3 | Documented | Known anti-pattern in engineering literature or standards (CWE, OWASP). |
+| 4 | Incident-proven | Documented failure mode with real-world incidents. Known to cause production failures. |
+| 5 | Frequent | Frequent failure pattern with extensive incident history across the industry. Well-understood failure mode. |
+
+### Overall Derivation
+
+The `overall` confidence is derived conservatively. The formula prioritizes evidential strength (evidence diversity and signal freshness) over pattern recognition (historical precedent).
+
+**Formula:**
+
+```
+raw_score = floor(
+  min(evidence_diversity, signal_freshness) * 0.6
+  + assumption_fragility * 0.3
+  + historical_precedent * 0.1
+)
+```
+
+**Mapping:**
+| Raw Score | Overall |
+|-----------|---------|
+| 1-2 | low |
+| 3 | medium |
+| 4-5 | high |
+
+**Conservative properties:**
+- The `min()` of evidence diversity and signal freshness means the weaker evidential dimension dominates. A finding with 5 evidence sources but only static analysis (freshness = 2) gets a low evidential contribution.
+- Assumption fragility carries 30% weight because fragile assumptions undermine even well-evidenced findings.
+- Historical precedent carries only 10% weight because "this pattern is known" doesn't compensate for weak evidence in this specific instance.
+
+**Override rule:** If any single dimension scores 1, the overall is capped at `low` regardless of other dimension scores. A finding with one catastrophically weak dimension cannot be trusted at any aggregate level.
+
+## Validation Rules
+
+1. **Integer range:** Each dimension must be an integer in the range 1-5. No fractional scores, no scores outside range.
+2. **All dimensions required:** All four dimensions must be present. Omitting a dimension is a validation error — confidence cannot be partially assessed.
+3. **Overall derivation:** `overall` must be derived from the formula. Manual override of the overall is not permitted — the formula enforces conservative aggregation.
+4. **Override enforcement:** If any dimension is 1, overall must be `low`. Any other value is a validation error.
+5. **Justification required:** `justification` is required and must contain at minimum one sentence per dimension scored 4 or 5. High scores without explanation are the primary vector for confidence inflation.
+6. **Consistency check — evidence diversity vs others:** `evidence_diversity` of 1 (single source) with `signal_freshness` of 4+ or `assumption_fragility` of 5 is flagged as inconsistent. A single source cannot produce live runtime validation or self-evident assumptions across a broad finding.
+7. **Immutability:** Confidence vectors are immutable once attached to a submitted finding. If confidence changes, the finding must be reissued with a new version (appending a version suffix to the finding_id, e.g., `F-04-001v2`).
+
+## Examples
+
+### Example 1: High-Confidence Finding — Hardcoded Credentials
+
+```markdown
+#### Confidence Vector
+
+| Dimension | Score | Anchor |
+|-----------|-------|--------|
+| Evidence diversity | 4 | Three+ source types |
+| Signal freshness | 2 | Static only |
+| Assumption fragility | 5 | Self-evident |
+| Historical precedent | 5 | Frequent |
+
+**Overall:** high
+**Justification:**
+- Evidence diversity (4): Four independent sources — Gitleaks (secrets scan), Semgrep (static analysis), SonarQube (static analysis), and git history (commit archaeology). Three distinct evidence categories (secrets scan, static analysis, commit history).
+- Signal freshness (2): All evidence is from static analysis of the codebase. No runtime confirmation that these values are actually used in production (could be overridden by environment variables). However, for hardcoded credentials, static evidence is sufficient — the credentials are visible regardless of runtime behavior.
+- Assumption fragility (5): The credentials are plaintext string literals assigned to database connection variables. The observation is self-evident from the code — no inference or interpretation required to establish that credentials exist in source code.
+- Historical precedent (5): CWE-798 (Use of Hard-coded Credentials) is among the most documented and frequently observed security failures. Extensive incident history across all industries and technology stacks.
+
+Derivation: min(4, 2) * 0.6 + 5 * 0.3 + 5 * 0.1 = 1.2 + 1.5 + 0.5 = 3.2 → floor(3.2) = 3 → medium.
+Override: No dimension is 1. But note the raw formula yields medium despite the finding being very well-supported. This is the conservative bias at work — signal freshness of 2 drags the evidential component down. In practice, the Principal Engineer may note that this specific finding type (plaintext credentials) does not require runtime validation, and the overall is appropriate for the confidence gating thresholds (medium enables Planning intervention level).
+```
+
+### Example 2: Low-Confidence Finding — Potential Race Condition
+
+```markdown
+#### Confidence Vector
+
+| Dimension | Score | Anchor |
+|-----------|-------|--------|
+| Evidence diversity | 1 | Single source |
+| Signal freshness | 2 | Static only |
+| Assumption fragility | 2 | Fragile |
+| Historical precedent | 3 | Documented |
+
+**Overall:** low
+**Justification:**
+- Evidence diversity (1): Single source — manual code review of the request handler. No tool flagged this pattern. No runtime data, no concurrency testing results.
+- Signal freshness (2): Static code analysis only. The race condition is inferred from code structure (read-modify-write without locking), not observed in runtime behavior.
+- Assumption fragility (2): The finding assumes concurrent requests to the same endpoint modify the same database row simultaneously. This is plausible for a multi-user system but unverified — the actual request concurrency pattern is unknown without runtime data. If the endpoint is rarely called concurrently, the race condition may never manifest.
+- Historical precedent (3): Read-modify-write race conditions are a documented anti-pattern in concurrent systems (CWE-362). Known in literature and standards, but the specific manifestation depends heavily on deployment context.
+
+Derivation: min(1, 2) * 0.6 + 2 * 0.3 + 3 * 0.1 = 0.6 + 0.6 + 0.3 = 1.5 → floor(1.5) = 1 → low.
+Override: evidence_diversity is 1, so overall is capped at low regardless. This finding needs corroborating evidence (concurrency testing, runtime logs showing concurrent access) before it can support any intervention level above Suggesting.
+```

package/modules/radar/src/schemas/disagreement.md

@@ -0,0 +1,238 @@
+---
+id: disagreement
+name: Disagreement Record
+version: 1.0.0
+used_by:
+  - principal-engineer
+  - devils-advocate
+  - architect
+  - data-engineer
+  - security-engineer
+  - compliance-officer
+  - senior-app-engineer
+  - sre
+  - performance-engineer
+  - test-engineer
+  - staff-engineer
+  - reality-gap-analyst
+---
+
+## Purpose
+
+A Disagreement is a first-class object in Radar — not a footnote, not a comment, not something to be quietly resolved. When two or more agents reach different conclusions about the same finding, that divergence is signal. It reveals where understanding is weakest relative to risk.
+
+Disagreements happen because agents carry different threat models, different time horizons, different failure memories, and different risk tolerances. Radar surfaces these differences through structured records that identify what is disputed, why agents disagree, and how the Principal Engineer resolves the tension.
+
+Every disagreement must be explicitly acknowledged, classified by root cause, resolved through a named model, and signed off by the Principal. Silent disappearance of disagreements is a critical anti-pattern — it destroys trust in the entire audit.
+
+## Template
+
+```markdown
+### {disagreement_id}
+
+**Finding:** {finding_id}
+**Epistemic layer disputed:** {epistemic_layer_disputed}
+**Agents involved:** {agents_involved}
+**Status:** {status}
+
+---
+
+#### Positions
+
+##### Position: {agent_id_1}
+
+**Claim:** {claim_1}
+
+**Evidence:**
+{evidence_1}
+
+**Assumptions:**
+- {assumption_1a}
+
+**Confidence:** {confidence_1}
+
+##### Position: {agent_id_2}
+
+**Claim:** {claim_2}
+
+**Evidence:**
+{evidence_2}
+
+**Assumptions:**
+- {assumption_2a}
+
+**Confidence:** {confidence_2}
+
+---
+
+#### Root Cause Analysis
+
+**Root cause:** {root_cause}
+**Explanation:** {root_cause_explanation}
+
+#### Resolution
+
+**Resolution model:** {resolution_model_applied}
+**Model application:** {how_model_was_applied}
+
+#### Principal Response
+
+**Response:** {principal_response}
+**Rationale:** {principal_rationale}
+**Follow-up:** {follow_up_action}
+
+---
+
+**Final status:** {status}
+**Resolved by:** {resolver_agent_id}
+**Resolution date:** {resolution_timestamp}
+```
+
+## Field Reference
+
+### Top-Level Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `disagreement_id` | string | yes | Unique identifier across the entire audit. | Pattern: `D-{NNN}` where NNN is three-digit sequence (001-999). Example: `D-001` |
+| `finding_id` | string | yes | The finding under dispute. | Must match a valid finding ID. Pattern: `F-{DD}-{NNN}`. |
+| `epistemic_layer_disputed` | enum | yes | Which layer of the 7-layer epistemic stack is in dispute. | `observation`, `evidence_source`, `interpretation`, `assumptions`, `risk_statement`, `impact_likelihood`, `judgment` |
+| `agents_involved` | list of strings | yes | Agent IDs participating in the disagreement. | At least 2 agent IDs. Each must match an agent assembly manifest's `id` field. |
+| `status` | enum | yes | Current state of the disagreement. | `open`, `mitigated`, `accepted_risk`, `deferred`, `out_of_scope` |
+
+### Position Fields (Array — one per agent)
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `agent_id` | string | yes | Which agent holds this position. | Must be one of the `agents_involved`. |
+| `claim` | string | yes | What the agent asserts about the disputed layer. | 1-3 sentences. Specific, not vague. |
+| `evidence` | string | yes | Evidence supporting the claim. | Must reference concrete artifacts — file paths, tool signals, metrics, or code snippets. Evidence-free claims are invalid. |
+| `assumptions` | list of strings | yes | Assumptions underlying this position. | At least one assumption. Each must be a concrete, testable statement. |
+| `confidence` | enum | yes | Agent's confidence in this position. | `high`, `medium`, `low` |
+
+### Root Cause Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `root_cause` | enum | yes | Why the agents disagree. From the closed taxonomy. | `threat_model_mismatch`, `time_horizon_mismatch`, `evidence_availability_mismatch`, `risk_tolerance_mismatch`, `domain_boundary_mismatch`, `optimism_pessimism_bias`, `tool_trust_bias` |
+| `root_cause_explanation` | string | yes | How this root cause manifests in this specific disagreement. | 1-3 sentences connecting the taxonomy entry to the specific positions. |
+
+### Resolution Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `resolution_model_applied` | enum | conditional | Which resolution model was used to resolve the disagreement. Required when status is not `open`. | `evidence_dominance`, `risk_asymmetry`, `reversibility`, `time_to_failure`, `blast_radius` |
+| `how_model_was_applied` | string | conditional | How the chosen model was applied to this specific case. Required when resolution_model_applied is present. | 2-4 sentences describing the reasoning. |
+
+### Principal Response Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `principal_response` | string | **always** | The Principal Engineer's explicit response. Silence is never valid. | 2-5 sentences. Must acknowledge the disagreement, state a position, and provide rationale. Null or empty is a validation error. |
+| `principal_rationale` | string | **always** | Why the Principal reached this conclusion. | Must reference evidence, resolution model, or explicit reasoning. |
+| `follow_up_action` | string | no | Any follow-up required after resolution. | Specific action (e.g., "Validate assumption X with runtime data") or "None required". |
+
+### Resolution Metadata
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `resolver_agent_id` | string | conditional | Agent that resolved the disagreement. Required when status is not `open`. | Typically `principal-engineer`. |
+| `resolution_timestamp` | string | conditional | When the disagreement was resolved. Required when status is not `open`. | ISO 8601 format or audit-relative timestamp. |
+
+## Validation Rules
+
+1. **Unique ID:** `disagreement_id` must be unique across the audit. No two disagreements may share an ID.
+2. **Valid finding reference:** `finding_id` must reference an existing finding in the audit's finding set.
+3. **Valid epistemic layer:** `epistemic_layer_disputed` must be one of the 7 enumerated layers.
+4. **Minimum positions:** `positions` array must have at least 2 entries. A disagreement requires at least two perspectives — a single position is not a disagreement.
+5. **Evidence-backed positions:** Every position must include evidence referencing concrete artifacts. A position with `evidence: "I believe this is true"` is invalid.
+6. **Closed root cause taxonomy:** `root_cause` must be from the 7-entry closed taxonomy. No ad-hoc categories. If the root cause doesn't fit, the disagreement classification needs refinement, not a new category.
+7. **Resolution model required for resolved:** `resolution_model_applied` is required when `status` is any value other than `open`. You cannot resolve a disagreement without naming the reasoning model.
+8. **Principal response mandatory:** `principal_response` is ALWAYS required regardless of status. An open disagreement still requires the Principal to acknowledge it. Null, empty string, or omission is a validation error.
+9. **Forward-only status transitions:** Status transitions must move forward: `open` -> {`mitigated`, `accepted_risk`, `deferred`, `out_of_scope`}. Resolved disagreements cannot revert to `open`.
+10. **Anti-pattern detection:** The following patterns are validation failures:
+    - **Auto-resolution:** Both positions marked as "resolved" without Principal response.
+    - **Averaging:** Principal response that averages the positions (e.g., "severity is between high and medium").
+    - **Forced consensus:** Resolution that claims agents now agree when positions have not changed.
+    - **Hidden disagreement:** Disagreement referenced in a finding but no corresponding disagreement record exists.
+    - **Devil's Advocate dismissal:** Disagreement from devils-advocate resolved as `out_of_scope` without substantive rationale.
+
+## Examples
+
+### Example: Security vs Application Engineer — SQL Injection Risk
+
+```markdown
+### D-001
+
+**Finding:** F-04-007
+**Epistemic layer disputed:** interpretation
+**Agents involved:** security-engineer, senior-app-engineer
+**Status:** mitigated
+
+---
+
+#### Positions
+
+##### Position: security-engineer
+
+**Claim:** The dynamic query construction at `src/api/users.py:45` using string concatenation is a SQL injection vector. User-supplied `sort_by` parameter is interpolated directly into the ORDER BY clause without parameterization or allowlist validation.
+
+**Evidence:**
+Semgrep rule `python.security.sql-injection.string-concat-query` flags `src/api/users.py:45`. The code reads:
+```python
+query = f"SELECT * FROM users ORDER BY {request.args['sort_by']}"
+```
+No parameterization. No sanitization function call between request input and query construction.
+
+**Assumptions:**
+- The `sort_by` parameter is reachable from external HTTP requests (not internal-only).
+- No middleware or framework layer sanitizes the parameter before it reaches this code.
+
+**Confidence:** high
+
+##### Position: senior-app-engineer
+
+**Claim:** The `sort_by` parameter passes through the `ValidatedRequest` middleware at `src/middleware/validation.py:28`, which restricts values to a hardcoded allowlist of column names (`["name", "email", "created_at", "updated_at"]`). String concatenation is used, but the input space is constrained to known-safe values.
+
+**Evidence:**
+File `src/middleware/validation.py:28-35` shows:
+```python
+ALLOWED_SORT_FIELDS = ["name", "email", "created_at", "updated_at"]
+if request.args.get('sort_by') not in ALLOWED_SORT_FIELDS:
+    raise ValidationError("Invalid sort field")
+```
+Route `src/api/routes.py:12` applies `ValidatedRequest` middleware to the `/users` endpoint.
+
+**Assumptions:**
+- The middleware is correctly applied to this route and cannot be bypassed.
+- The allowlist is maintained as new columns are added.
+- No other code path reaches `users.py:45` without passing through the middleware.
+
+**Confidence:** medium
+
+---
+
+#### Root Cause Analysis
+
+**Root cause:** evidence_availability_mismatch
+**Explanation:** The security engineer's analysis focused on the query construction site in isolation (the direct code path from input to SQL). The application engineer had additional context about the middleware layer that restricts the input space. Both analyses are correct within their evidence scope — the disagreement arises because one agent had visibility into the defense layer and the other did not.
+
+#### Resolution
+
+**Resolution model:** evidence_dominance
+**Model application:** The application engineer's evidence (middleware allowlist) directly addresses the security engineer's concern (unrestricted input). The middleware evidence is independently verifiable — the route configuration and validation logic are concrete code. However, the security engineer's concern about defense-in-depth remains valid: relying solely on middleware for SQL injection prevention is fragile. The finding should be downgraded from "injection vulnerability" to "defense-in-depth gap" with reduced severity.
+
+#### Principal Response
+
+**Response:** The SQL injection claim is mitigated by the allowlist middleware, but the underlying pattern (string concatenation in SQL construction) is still a maintenance risk. If a future developer adds a route to this handler without the middleware, or adds a new sort field without updating the allowlist, the injection vector reopens. The finding should be reclassified from critical (active injection) to medium (defense-in-depth gap) with a recommendation to use parameterized queries regardless of upstream validation.
+
+**Rationale:** Evidence dominance favors the application engineer's position — the middleware demonstrably constrains the input. But the security engineer's architectural concern (string concatenation creates a latent vulnerability) is valid under the time-to-failure model. The compromise: acknowledge the current mitigation, flag the architectural weakness, and recommend parameterized queries as the durable fix.
+
+**Follow-up:** Verify that all routes reaching `users.py:45` pass through `ValidatedRequest` middleware. Check for any route that bypasses middleware (e.g., internal API, admin endpoints, test harnesses).
+
+---
+
+**Final status:** mitigated
+**Resolved by:** principal-engineer
+**Resolution date:** 2026-02-15T14:30:00Z
+```