@accelerationguy/accel 1.0.0

package/modules/radar/src/transform/rules/change-risk-rules.md

@@ -0,0 +1,87 @@
+---
+id: change-risk-rules
+name: Change Risk Rules
+scope: transform_agents
+priority: critical
+---
+
+## Purpose
+
+Without change-risk rules, Transform agents produce remediation plans that ignore the collateral damage of fixes. A technically correct fix that touches 30 files, introduces 3 new dependencies, and modifies untested code paths is not a good fix — it is a new source of risk that may exceed the original finding's impact. These rules enforce that every remediation is assessed for its own risk, not just for its correctness.
+
+Change-risk rules prevent two specific failure modes. First, optimistic risk assessment — agents that claim "low blast radius" without actually tracing the dependency chain, or "low regression risk" without checking test coverage. Second, risk-intervention disconnect — agents that produce high-risk change plans at high intervention levels, creating authoritative-sounding remediation that is actually dangerous to apply.
+
+Every risk claim must be backed by evidence. "This change is isolated" is not a risk assessment — it is an assertion. "This change modifies `config/database.py` which is imported by `config/__init__.py` and consumed by 3 modules (`app.py`, `workers/sync.py`, `scripts/migrate.py`)" is a risk assessment. The difference is that the second statement is falsifiable — someone can verify the import chain.
+
+Every rule in this file has `priority: critical`. Violations invalidate the output.
+
+## Rules
+
+### 1. Mandatory Blast Radius Assessment
+
+**Statement:** Every remediation playbook must include a blast radius assessment with a score (1-5), evidence citing specific files and dependency chains, and a complete list of affected files. No playbook may claim "this change is isolated" or "low blast radius" without enumerating what the change touches and tracing at least one level of downstream consumers.
+
+**Rationale:** Blast radius is the most commonly under-estimated risk dimension because it requires tracing dependencies, which is tedious. Agents naturally default to "this is a small change" without verifying the claim. A one-line change to a utility function imported by 40 modules has a blast radius of 40, not 1. Without mandatory enumeration, blast radius assessments are wishes, not measurements.
+
+**Enforcement:** Playbook schema validation (@schema:playbook) rejects any playbook where `blast_radius_evidence` is empty or contains no file path references. The `affected_files` list in the corresponding change-risk assessment (@schema:change-risk) must contain at least one entry. If the blast radius score is 1 or 2, the evidence must explain why downstream impact is limited (e.g., "no downstream consumers" or "interface unchanged, only internal implementation modified"). Low scores without explanation are flagged for review.
+
+### 2. Coupling Analysis Before Structural Changes
+
+**Statement:** Any remediation that adds, removes, or modifies dependencies between modules, packages, services, or external systems must include a coupling analysis. New dependencies must be justified — why this dependency is necessary, what alternatives were considered, and what happens if the dependency fails or is removed. Changes that tighten coupling (increase the dependency count or create bidirectional dependencies) must acknowledge this in the risk metadata.
+
+**Rationale:** The most dangerous remediation patterns are those that "fix" a finding by introducing a new dependency. Externalizing configuration into a secrets manager fixes hardcoded credentials but introduces a runtime dependency on an external service. This is often the right tradeoff — but it must be an acknowledged, assessed tradeoff, not an invisible side effect. Without coupling analysis, Transform optimizes for finding resolution at the expense of system simplicity.
+
+**Enforcement:** Change-risk assessment validation (@schema:change-risk) checks that `new_dependencies` is populated (even if empty, indicating no new dependencies). If `new_dependencies` contains any entries and `coupling_risk_score` is below 3, the evidence must explain why the new dependency does not significantly increase coupling. The coupling risk evidence must reference the specific interfaces or import relationships affected.
+
+### 3. Regression Probability with Evidence
+
+**Statement:** Every change-risk assessment must state the regression probability with evidence grounded in test coverage data. If test coverage data is available, cite the coverage percentage for the affected files. If test coverage data is unavailable, state this explicitly — "no test coverage data available" is valid evidence; "low regression risk" without data is not. Changes to files with zero test coverage must include an explicit warning: "UNTESTED CODE PATH — no existing tests cover this modification."
+
+**Rationale:** Regression probability without test coverage data is speculation. An agent that claims "low regression risk" for a change to an untested module is not being conservative — it is being dishonest about its knowledge. The presence or absence of tests is the single strongest predictor of whether a change will introduce regressions. Requiring evidence forces agents to check rather than assume.
+
+**Enforcement:** Change-risk assessment validation (@schema:change-risk) checks that `regression_probability_evidence` contains either a coverage percentage reference or an explicit "no coverage data" statement. If `test_coverage_pct` is 0 and `regression_probability_score` is below 3, the evidence must justify why zero test coverage does not indicate elevated regression risk (e.g., "generated file, not executed directly"). If `test_coverage_pct` is 0 and no justification is provided, the minimum valid `regression_probability_score` is 3 (medium risk).
+
+### 4. Unsafe Context Downgrade
+
+**Statement:** If any single risk dimension in a change-risk assessment scores 4 or higher (out of 5), the change is flagged as unsafe and automatically downgraded to Suggesting intervention level regardless of finding confidence or severity. The unsafe flag must identify which dimension triggered it and provide the specific evidence. A change can only exit unsafe status through re-assessment that brings all dimensions below 4.
+
+**Rationale:** High-risk changes at high intervention levels are the most dangerous output Transform can produce. An Authorizing-level playbook with blast radius 4/5 is telling the system "this change is ready for execution" while simultaneously acknowledging that it ripples widely through the codebase. The unsafe context downgrade is a circuit breaker — it ensures that changes with any extreme risk dimension are constrained to informational output only, where the cost of a mistake is lowest.
+
+**Enforcement:** Workflow validation checks all four risk dimensions in the change-risk assessment (@schema:change-risk). If any dimension's score is ≥4: (1) the playbook's intervention level is overridden to `suggesting`, (2) the playbook must include an unsafe context flag identifying the triggering dimension, score, and evidence, (3) the change-risk assessment's `recommendation` must be `human_review_required` or `reject`. This override is not optional and cannot be bypassed by the agent.
+
+### 5. Risk-Recommendation Alignment
+
+**Statement:** The `overall_risk` classification and `recommendation` in a change-risk assessment must be logically consistent. High or critical risk cannot produce a "proceed" recommendation. Low risk with a "reject" recommendation must be explicitly justified. The valid default mappings are: low→proceed, medium→proceed_with_caution, high→human_review_required, critical→reject. Deviations from these defaults require justification in the risk summary.
+
+**Rationale:** Disconnects between risk assessment and recommendation undermine trust in the entire assessment. If an agent rates a change as "high risk" but recommends "proceed," the human reviewer must decide which signal to trust — the quantitative assessment or the qualitative recommendation. This ambiguity defeats the purpose of structured risk assessment. Risk-recommendation alignment ensures that the assessment's conclusion follows from its evidence, and deviations are conscious choices, not oversights.
+
+**Enforcement:** Change-risk assessment validation (@schema:change-risk) checks that `recommendation` matches the default mapping for `overall_risk`. If the recommendation deviates from the default (e.g., medium risk with `proceed` instead of `proceed_with_caution`), the `risk_summary` must contain an explicit justification for the deviation. Assessments with misaligned risk and recommendation and no justification are validation errors.
+
+## DO
+
+- Change-risk assessment for a configuration change: "Blast radius 2/5 — change modifies `config/database.py` (3 lines). Downstream consumer: `config/__init__.py` imports `DB_USER`, `DB_PASS`, `DB_HOST`. Variable names unchanged, so `app.py`, `workers/sync.py`, `scripts/migrate.py` which import from `config` are unaffected at the interface level."
+
+- Regression probability assessment with coverage data: "Regression probability 2/5 — `tests/test_config.py` covers 78% of `config/database.py`. 4 existing test cases will need environment variable fixtures after the change. No test-free code paths are being modified."
+
+- Unsafe context downgrade applied: "Change-risk dimension blast_radius scores 4/5 (change modifies the base `HttpClient` class used by 47 modules). UNSAFE CONTEXT — downgrading to Suggesting intervention level. Blast radius evidence: `grep -r 'import.*HttpClient' src/` returns 47 unique files. This change requires human architectural review before any structured remediation plan."
+
+- New dependency justified: "Coupling risk 2/5 — introduces `python-dotenv` (no transitive dependencies, 15M weekly downloads, MIT license). Alternative considered: manual `os.environ` without `.env` support. Rejected because local development requires `.env` file loading. If `python-dotenv` is unavailable, application still works — `load_dotenv()` is called but failure is non-fatal when environment variables are set directly."
+
+- Low-coverage warning: "UNTESTED CODE PATH — `config/database.py` has 0% test coverage per coverage.py. No existing tests validate database configuration loading. Regression probability elevated to 4/5. Recommend writing tests before applying this remediation."
+
+## DON'T
+
+- Change-risk assessment with blast radius 1/5 and evidence: "This is a small change."
+  **Why this is wrong:** "Small change" is a judgment, not evidence. Blast radius evidence must cite specific files and trace at least one level of downstream consumers. A one-line change to a utility function can have a blast radius of 5/5 if 50 modules import it.
+
+- Regression probability 1/5 with no mention of test coverage.
+  **Why this is wrong:** Regression probability without test coverage data is speculation. Score of 1 implies high confidence that no regressions will occur — this requires evidence (high test coverage, additive-only change, no behavior modification). Without coverage data, the minimum defensible score is 3 for any change that modifies existing behavior.
+
+- Change-risk assessment with overall_risk: high and recommendation: proceed.
+  **Why this is wrong:** High risk and "proceed" are contradictory. If the risk is high, the recommendation must be at least `human_review_required`. A "proceed" recommendation for a high-risk change tells the reviewer "go ahead" while the assessment says "this is dangerous" — the disconnect erodes trust in the entire assessment system.
+
+- Playbook at Authorizing level with blast_radius score 4/5 in the change-risk assessment.
+  **Why this is wrong:** Any risk dimension scoring 4+ triggers the unsafe context downgrade. The playbook must be constrained to Suggesting level. There is no mechanism to keep it at Authorizing — the circuit breaker is automatic and non-overridable.
+
+- Coupling risk assessment: "No new dependencies" when the change adds `import redis` to a module that previously had no Redis dependency.
+  **Why this is wrong:** Adding an import to a new package is a new dependency. The `new_dependencies` list must include `redis`. Coupling risk evidence must address the runtime dependency on a Redis server — what happens if Redis is unavailable, is there a fallback, does this change the deployment requirements?

package/modules/radar/src/transform/rules/safety-governance.md

@@ -0,0 +1,87 @@
+---
+id: safety-governance
+name: Safety Governance
+scope: transform_agents
+priority: critical
+---
+
+## Purpose
+
+Without safety governance rules, Transform agents produce overconfident remediation plans, escalate intervention levels without evidence, bypass confidence requirements when findings feel important, and — most dangerously — blur the boundary between producing plans and executing changes. These are the hard boundaries of the Transform system.
+
+Safety governance prevents the failure mode that makes AI-assisted remediation dangerous: well-structured, authoritative-sounding change plans built on insufficient evidence. A playbook that reaches Authorizing level with medium-confidence findings is not "slightly optimistic" — it is a change specification that a human reviewer may trust because the system presented it at a high governance tier. The tier itself becomes a false signal of evidence strength.
+
+These rules are non-negotiable. Unlike Core epistemic rules where a quality violation degrades output, a Transform safety violation can cause damage to the target codebase. A playbook that bypasses confidence gating and reaches Drive for execution planning has passed through every safety gate and acquired a veneer of legitimacy. If the underlying evidence was insufficient, the damage is amplified by the system's own authority.
+
+Every rule in this file has `priority: critical`. Violations invalidate the output.
+
+## Rules
+
+### 1. No Auto-Execution
+
+**Statement:** Radar Transform NEVER applies changes to the target codebase. Transform produces plans, assessments, and verification procedures. It does not modify source files, configuration files, database schemas, infrastructure definitions, or any artifact in the target project's working tree. Drive mediates all codebase modifications with human oversight.
+
+**Rationale:** The separation between diagnosis/planning and execution is a hard architectural boundary, not a configurable preference. If Transform could execute changes, a single miscalibrated confidence score or an incorrect risk assessment would result in codebase damage with no human checkpoint. The execution boundary exists because the cost of a false positive in planning (a bad plan that gets rejected) is negligible, while the cost of a false positive in execution (a bad change that gets applied) can be severe.
+
+**Enforcement:** No Transform workflow includes file-modification steps outside `.radar/` operational directory. If a Transform agent produces output that includes write operations to the target codebase (file creation, file modification, file deletion), the output is a critical violation and must be rejected at workflow validation. There is no trusted mode, no bypass flag, no override mechanism. This is enforced at the workflow definition level — Transform workflows simply do not have write access to the target tree.
+
+### 2. Conservative Bias
+
+**Statement:** Transform agents must default to the lowest intervention level that serves the user's needs. When uncertain about the appropriate intervention level, agents must downgrade — Authorizing becomes Planning, Planning becomes Suggesting. Escalation beyond the default requires explicit evidence justification citing specific sources.
+
+**Rationale:** The default behavior of language models is to present recommendations with high confidence and strong language. In the context of remediation planning, this natural tendency maps to intervention level inflation — a suggestion becomes a plan, a plan becomes an authorization. Conservative bias corrects for this by requiring agents to actively justify escalation rather than passively assuming it. The asymmetry is deliberate: under-escalation wastes a developer's time reading a suggestion when they could have had a plan. Over-escalation risks codebase damage from an insufficiently-evidenced change.
+
+**Enforcement:** Every playbook's intervention level must include an escalation justification when the level is Planning or above. The justification must cite: (1) the finding confidence that gates this level, (2) the number and type of evidence sources, and (3) for Authorizing/Executing, the change-risk assessment score. Playbooks without escalation justification are capped at Suggesting. Workflow validation checks that the justification references exist and are consistent with the claimed level.
+
+### 3. Confidence Gating
+
+**Statement:** The intervention level of a playbook is hard-gated by the source finding's confidence (@schema:confidence overall derivation). The minimum thresholds are: Suggesting requires any confidence (low, medium, or high); Planning requires medium or high confidence with at least 2 independent evidence sources; Authorizing requires high confidence with at least 3 cross-validated evidence sources; Executing requires high confidence with at least 3 cross-validated evidence sources. No mechanism exists to override these thresholds.
+
+**Rationale:** Confidence gating prevents the most dangerous scenario: a high-intervention remediation plan built on weak evidence. Without gating, a Transform agent could observe a single Semgrep signal, assess it as critical severity, and produce an Authorizing-level playbook — creating a change specification that carries the system's authority but rests on a single tool output. Confidence gating ensures that the evidence bar rises with the intervention level. Severity does not override confidence: a critical-severity finding with low confidence is still capped at Suggesting.
+
+**Enforcement:** Schema validation at @schema:playbook rejects any playbook where the declared intervention level exceeds the confidence gate. Validation checks: (1) finding's confidence overall meets or exceeds the level's minimum, (2) the number of distinct evidence sources in the finding meets or exceeds the level's minimum, (3) for Authorizing/Executing, at least one evidence source must corroborate another (cross-validation). Evidence source counting uses @schema:finding Layer 2 (evidence sourcing) — each distinct source type (tool signal, manual observation, documentation reference, test result) counts as one source regardless of how many instances of that type exist.
+
+### 4. Liability Escalation
+
+**Statement:** At Suggesting and Planning levels, Radar operates as an Advisor — it provides information and recommendations with no expectation that its output will be applied without independent verification. At Authorizing and Executing levels, Radar operates as an Architectural Actor — its output is intended to be applied to the codebase, and it must include explicit confidence statements and liability disclaimers. Higher liability postures require higher confidence and lower change risk.
+
+**Rationale:** The liability distinction is not cosmetic. When a system produces a suggestion, the human reviewer treats it as input to their own decision-making process. When a system produces an authorization-level change specification, the human reviewer is more likely to trust the system's assessment and approve without deep review — the tier itself signals "this has been thoroughly vetted." If the vetting was insufficient, the tier becomes a vector for false authority. Liability escalation ensures that the output explicitly states its evidential basis and limitations at the levels where humans are most likely to defer to the system.
+
+**Enforcement:** Authorizing and Executing-level playbooks must include a disclaimer section with: (1) confidence statement citing the finding's confidence and evidence source count, (2) risk statement citing the change-risk assessment's overall risk, (3) limitation acknowledgment identifying any evidence gaps or assumptions. Missing disclaimers are validation errors. The disclaimer must be a substantive assessment, not boilerplate — "This plan has been reviewed" is not a valid disclaimer.
+
+### 5. Intervention Level Immutability After Approval
+
+**Statement:** Once a playbook is assigned an intervention level and approved at that level by a human reviewer, the level cannot be upgraded without a full re-assessment including updated evidence review, confidence re-evaluation, and risk re-assessment. Downgrading is always permitted without re-assessment. This prevents post-approval escalation where a Planning-level playbook is silently upgraded to Authorizing after human review.
+
+**Rationale:** Post-approval escalation is a subtle but dangerous failure mode. A human reviews a Planning-level playbook with the understanding that it is a recommendation. If the system later upgrades it to Authorizing without re-review, the human's approval — given at a lower tier — is retroactively applied to a higher tier. The human did not consent to Authorizing-level output. Immutability after approval ensures that escalation always triggers re-review.
+
+**Enforcement:** Playbook metadata includes an `approved_at_level` field that records the level at which human approval was granted. Workflow validation rejects any execution at a level higher than `approved_at_level`. Downgrade workflows do not require re-approval. Upgrade workflows must reset `approved_at_level` to null and re-enter the approval pipeline.
+
+## DO
+
+- Playbook assigned Suggesting level with note: "Single Semgrep signal (S-SEM-047). No corroborating evidence from other tools or manual review. Confidence low. Capped at Suggesting per confidence gating rule."
+
+- Playbook downgraded from Planning to Suggesting after re-assessment: "Initial assessment cited 2 evidence sources, but both are from the same Semgrep rule set — counting as 1 independent source. Downgrading to Suggesting. Planning requires 2 independent sources."
+
+- Authorizing-level playbook includes disclaimer: "Based on 3 independent evidence sources (Semgrep signal S-SEM-047, manual code review observation, Gitleaks detection GL-012) with overall confidence high. Change risk assessment CR-001 rates overall risk as low. Limitation: test coverage for the affected module is 78% — regression probability score of 2/5 reflects this gap. This remediation plan should be reviewed by a qualified engineer before application."
+
+- Agent produces Planning-level playbook for a critical-severity finding with medium confidence: "Finding F-04-001 is severity critical but confidence medium (2 evidence sources). Confidence gates intervention at Planning. Cannot escalate to Authorizing without a third independent evidence source achieving high confidence. Severity does not override confidence."
+
+- Transform workflow produces playbooks and risk assessments as `.radar/` artifacts without modifying target codebase files. All output written to `.radar/transform/output/`.
+
+## DON'T
+
+- Playbook assigned Authorizing level for a finding with confidence medium.
+  **Why this is wrong:** Authorizing requires high confidence with 3+ cross-validated evidence sources. Medium confidence is hard-capped at Planning. The severity of the finding is irrelevant to the confidence gate — a critical-severity finding with medium confidence is still capped at Planning.
+
+- Transform agent modifies `src/config/database.py` directly to implement the remediation.
+  **Why this is wrong:** Transform never modifies target codebase files. It produces plans; Drive executes plans with human oversight. There is no "just this once" exception, no "it's a trivial change" bypass. The execution boundary is absolute.
+
+- Playbook at Planning level with escalation justification: "This seems like it should be at least Planning level given the severity."
+  **Why this is wrong:** "Seems like" is not evidence. Escalation justification must cite specific confidence levels and evidence source counts. Severity does not justify escalation — confidence does.
+
+- Planning-level playbook approved by human, then silently upgraded to Authorizing by the system for inclusion in a Drive execution plan.
+  **Why this is wrong:** The human approved at Planning level — they consented to a recommendation, not an execution specification. Upgrading without re-review retroactively elevates the human's consent. Escalation requires re-assessment and re-approval.
+
+- Authorizing-level playbook with disclaimer: "This plan has been thoroughly reviewed and is ready for implementation."
+  **Why this is wrong:** This is boilerplate, not a substantive disclaimer. A valid disclaimer cites the specific confidence, evidence count, risk assessment, and limitations. "Thoroughly reviewed" is a conclusion, not an assessment.

package/modules/radar/src/transform/schemas/change-risk.md

@@ -0,0 +1,139 @@
+---
+id: change-risk
+name: Change Risk Assessment
+version: 1.0.0
+used_by:
+  - change-risk-modeler
+  - execution-validator
+---
+
+## Purpose
+
+A Change Risk Assessment is a multi-dimensional risk evaluation for a proposed change to the target codebase. Every change that Transform considers — from a single-line configuration fix to a multi-file architectural refactor — must be assessed across four risk dimensions before a recommendation is issued.
+
+Risk assessment exists because fixes have costs. A remediation that addresses a medium-severity finding but introduces high coupling risk and touches untested code paths may cause more damage than the original issue. Without structured risk assessment, Transform optimizes for "fix count" rather than "net improvement" — producing technically correct remediations that are practically dangerous.
+
+Each risk dimension captures a different failure mode of change: blast radius measures how widely a change ripples, coupling risk measures whether the fix creates new dependencies, regression probability measures the likelihood of breaking existing functionality, and architectural tension measures whether the fix conflicts with the codebase's design direction. All four dimensions must be scored with evidence — a score without evidence is an unsupported assertion.
+
+The overall risk classification and recommendation are derived from the dimensional scores but are not mechanical averages. A change with three dimensions at 1/5 and one dimension at 5/5 is not "low risk" — the critical dimension dominates. This mirrors the conservative derivation principle from @schema:confidence: the weakest dimension determines the overall posture.
+
+Change Risk Assessments are consumed by the safety governance rules to gate intervention levels. High-risk changes are automatically constrained to lower intervention levels regardless of finding confidence.
+
+## Template
+
+```markdown
+### {change_id}
+
+**Findings Addressed:** {finding_refs}
+**Overall Risk:** {overall_risk}
+**Recommendation:** {recommendation}
+
+---
+
+#### Blast Radius
+
+**Score:** {blast_radius_score}/5
+**Evidence:** {blast_radius_evidence}
+**Affected Files:** {affected_files}
+
+#### Coupling Risk
+
+**Score:** {coupling_risk_score}/5
+**Evidence:** {coupling_risk_evidence}
+**New Dependencies:** {new_dependencies}
+
+#### Regression Probability
+
+**Score:** {regression_probability_score}/5
+**Evidence:** {regression_probability_evidence}
+**Test Coverage:** {test_coverage_pct}%
+
+#### Architectural Tension
+
+**Score:** {architectural_tension_score}/5
+**Evidence:** {architectural_tension_evidence}
+**Design Conflicts:** {design_conflicts}
+
+---
+
+#### Risk Summary
+
+{risk_summary}
+```
+
+## Field Reference
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `change_id` | string | yes | Unique change identifier. Format: `CR-{NNN}` where NNN is sequence. | Pattern: `CR-\d{3}` |
+| `finding_refs` | list of strings | yes | Finding IDs this change addresses. A single change may remediate multiple related findings. Each must match a valid finding ID from @schema:finding. | List of `F-\d{2}-\d{3}` patterns. Minimum 1 entry. |
+| `blast_radius_score` | integer | yes | How widely the change ripples through the codebase. | 1 (single file, no downstream consumers) to 5 (cross-service, multiple deployment units affected) |
+| `blast_radius_evidence` | string | yes | Justification referencing specific dependency chains, import trees, or API contracts affected. | Free-form. Must cite concrete files or modules. |
+| `affected_files` | list of strings | yes | Every file that will be directly modified or created by this change. | File paths relative to project root. Minimum 1 entry. |
+| `coupling_risk_score` | integer | yes | Whether the change introduces or tightens coupling between components. | 1 (no new coupling, change is internal to one module) to 5 (creates hard dependency on external system or service) |
+| `coupling_risk_evidence` | string | yes | Justification referencing specific interfaces, imports, or dependency relationships that are created or modified. | Free-form. Must cite concrete interfaces or dependencies. |
+| `new_dependencies` | list of strings | yes | New package dependencies, service dependencies, or interface contracts introduced by this change. Empty list if no new dependencies. | List of dependency identifiers (package names, service names, API contracts). |
+| `regression_probability_score` | integer | yes | Likelihood the change breaks existing functionality. | 1 (additive change, no existing behavior modified) to 5 (modifies core logic path with no test coverage) |
+| `regression_probability_evidence` | string | yes | Justification referencing test coverage data, affected code paths, and historical change failure rates. | Free-form. Must cite test files, coverage metrics, or historical data. |
+| `test_coverage_pct` | number | yes | Test coverage percentage for the files being modified. If unknown, state 0 with evidence explaining why coverage data is unavailable. | 0-100. |
+| `architectural_tension_score` | integer | yes | Whether the change conflicts with the codebase's architectural direction or established patterns. | 1 (aligns with existing patterns) to 5 (contradicts established architecture, requires pattern migration) |
+| `architectural_tension_evidence` | string | yes | Justification referencing architectural patterns, design documents, or established conventions in the codebase. | Free-form. Must cite concrete patterns or conventions. |
+| `design_conflicts` | list of strings | yes | Specific architectural patterns or design decisions that this change conflicts with. Empty list if no conflicts. | List of pattern descriptions or document references. |
+| `overall_risk` | enum | yes | Aggregate risk classification. Not a mechanical average — the highest-scoring dimension dominates. A single dimension at 5 with three at 1 is still high risk. | `low` (max dimension ≤2), `medium` (max dimension 3), `high` (max dimension 4), `critical` (any dimension 5) |
+| `recommendation` | enum | yes | Action recommendation derived from overall risk. Must be logically consistent with the risk classification. | `proceed` (low risk, no special precautions), `proceed_with_caution` (medium risk, additional verification recommended), `human_review_required` (high risk, human must approve before execution), `reject` (critical risk, change should not be applied as designed) |
+| `risk_summary` | string | yes | 2-4 sentence synthesis explaining the overall risk posture, the dominant risk dimension, and why the recommendation follows from the assessment. | Free-form. Must reference the specific dimensions that drive the recommendation. |
+
+## Validation Rules
+
+1. `change_id` must be unique across the entire audit. No two change risk assessments may share an ID. Format must match `CR-{NNN}`.
+2. `finding_refs` must contain at least one entry. Each entry must reference a valid finding ID from the current audit. A change that addresses no findings is purposeless.
+3. All four risk dimensions must have a score (integer 1-5), evidence (non-empty string), and dimension-specific sub-fields populated. A score without evidence is an unsupported assertion — it cannot be challenged or verified.
+4. `overall_risk` must reflect the dominant dimension: if any dimension scores 5, overall must be `critical`; if max dimension is 4, overall must be `high`; if max is 3, overall must be `medium`; if max is ≤2, overall must be `low`. Overriding this mapping requires explicit justification in `risk_summary`.
+5. `recommendation` must be logically consistent with `overall_risk`: `critical` risk cannot produce `proceed` or `proceed_with_caution`; `low` risk with `reject` must justify in `risk_summary`. The valid combinations are: low→proceed, medium→proceed_with_caution, high→human_review_required, critical→reject. Deviations require justification.
+6. `affected_files` must list every file that will be directly modified. An empty list is invalid — every change touches at least one file. Files listed here must be verifiable against the actual change.
+7. `test_coverage_pct` of 0 is valid only when accompanied by evidence explaining why coverage data is unavailable (no test suite, no coverage tooling, files are generated). A 0 without explanation is suspicious and should trigger reviewer attention.
+8. `risk_summary` must reference the specific dimension(s) that drive the recommendation. A generic summary like "this change is low risk" without citing which dimensions support that conclusion is invalid.
+
+## Examples
+
+### Example: Low-Risk Configuration Change
+
+```markdown
+### CR-001
+
+**Findings Addressed:** F-04-001
+**Overall Risk:** low
+**Recommendation:** proceed
+
+---
+
+#### Blast Radius
+
+**Score:** 2/5
+**Evidence:** Change is confined to `config/database.py` (3 lines modified) and `requirements.txt` (1 line added). The `config/__init__.py` module imports `DB_USER`, `DB_PASS`, `DB_HOST` from `database.py` — these variable names are unchanged, so downstream consumers are unaffected. No API contracts change. No deployment configuration changes beyond environment variable provisioning.
+**Affected Files:** config/database.py, requirements.txt, .env.example, .gitignore
+
+#### Coupling Risk
+
+**Score:** 2/5
+**Evidence:** Introduces runtime dependency on `python-dotenv` package (well-maintained, 15M weekly downloads, no transitive dependencies). Introduces implicit dependency on environment variable availability — application will fail to start without `DB_USER`, `DB_PASS`, `DB_HOST` set. This is intentional fail-closed behavior.
+**New Dependencies:** python-dotenv
+
+#### Regression Probability
+
+**Score:** 2/5
+**Evidence:** `tests/test_config.py` has 4 test cases covering database configuration import. Tests currently import the hardcoded values directly. After change, tests will need either a `.env` file in the test environment or environment variables set in the test runner. Test coverage for `config/` module is 78% per coverage.py output.
+**Test Coverage:** 78%
+
+#### Architectural Tension
+
+**Score:** 1/5
+**Evidence:** Environment-based configuration is already the established pattern in this codebase. `config/api.py` (line 8) uses `os.environ["API_KEY"]`. `config/redis.py` (line 5) uses `os.environ["REDIS_URL"]`. The database configuration is the only module still using hardcoded values — this change makes it consistent with the existing pattern.
+**Design Conflicts:** []
+
+---
+
+#### Risk Summary
+
+This is a low-risk configuration change. The highest-scoring dimensions (blast radius and regression probability, both 2/5) are driven by the test fixture update needed and the new `python-dotenv` dependency, neither of which introduces meaningful risk. The change aligns with established codebase patterns (architectural tension 1/5) and the fail-closed behavior of `os.environ["KEY"]` is a deliberate safety property. Recommendation: proceed without special precautions.
+```

package/modules/radar/src/transform/schemas/intervention-level.md

@@ -0,0 +1,207 @@
+---
+id: intervention-level
+name: Intervention Level
+version: 1.0.0
+used_by:
+  - remediation-architect
+  - change-risk-modeler
+  - execution-validator
+---
+
+## Purpose
+
+An Intervention Level defines a governance tier that controls what Transform is permitted to do for a given remediation. The four tiers — Suggesting, Planning, Authorizing, Executing — form an escalation ladder where each level requires stronger evidence, higher confidence, and lower risk than the one below it.
+
+Intervention levels exist because remediation carries liability. A suggestion ("consider externalizing secrets") carries minimal risk — if it is wrong, the developer ignores it. An execution plan handed to Drive for implementation carries substantial risk — if it is wrong, the codebase is damaged. The governance tiers ensure that the level of Transform's involvement is proportional to the strength of evidence supporting the remediation.
+
+The key design principle is conservative escalation: Transform defaults to the lowest level that serves the user, and escalation requires explicit evidence justification. A finding with medium confidence cannot produce an Authorizing-level playbook regardless of severity — confidence gates intervention, not severity. This prevents the most dangerous failure mode: high-confidence-sounding remediation built on weak evidence.
+
+Each level also carries a liability posture. At Suggesting and Planning levels, Radar is an Advisor — it provides information and recommendations. At Authorizing and Executing levels, Radar is an Architectural Actor — it produces artifacts intended to be applied to the codebase, which requires explicit disclaimers and higher evidence thresholds.
+
+This schema is the single source of truth for governance tiers. Safety rules (@rules in `src/transform/rules/`) enforce constraints against these tier definitions. Playbooks (@schema:playbook) declare which tier they operate at. The verification pipeline (@schema:verification-plan) is required for Authorizing and Executing tiers.
+
+## Template
+
+```markdown
+### Level: {level}
+
+**Liability Posture:** {liability_posture}
+**Requires Human Approval:** {requires_human_approval}
+**Requires Disclaimer:** {requires_disclaimer}
+
+---
+
+#### Confidence Requirements
+
+**Minimum Finding Confidence:** {minimum_finding_confidence}
+**Minimum Evidence Sources:** {minimum_evidence_sources}
+
+#### Risk Constraints
+
+**Allowed When Risk High:** {allowed_when_risk_high}
+
+#### Description
+
+{level_description}
+
+#### Permitted Outputs
+
+{permitted_outputs}
+```
+
+## Field Reference
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `level` | enum | yes | The intervention tier. Each tier represents an escalation in Transform's involvement and the evidence required to justify it. | `suggesting`, `planning`, `authorizing`, `executing` |
+| `liability_posture` | enum | yes | The legal/professional posture Radar assumes at this level. Determines disclaimer requirements and confidence thresholds. | `advisor` (suggesting, planning), `architectural_actor` (authorizing, executing) |
+| `requires_human_approval` | boolean | yes | Whether a human must explicitly approve before output at this level can be acted upon. | `false` (suggesting, planning), `true` (authorizing, executing) |
+| `requires_disclaimer` | boolean | yes | Whether output at this level must include an explicit confidence statement and liability disclaimer. | `false` (suggesting), `false` (planning), `true` (authorizing), `true` (executing) |
+| `minimum_finding_confidence` | enum | yes | Minimum confidence (@schema:confidence overall derivation) a finding must have for a playbook at this level. Findings below this threshold are rejected regardless of severity. | `low` (suggesting), `medium` (planning), `high` (authorizing), `high` (executing) |
+| `minimum_evidence_sources` | integer | yes | Minimum number of independent evidence sources required. Evidence sources are distinct tool signals, code analysis observations, or documentation references — not repetitions of the same source. | 1 (suggesting), 2 (planning), 3 (authorizing), 3 (executing) |
+| `allowed_when_risk_high` | boolean | yes | Whether this intervention level is permitted when any change-risk dimension (@schema:change-risk) exceeds a score of 4. High-risk changes are automatically constrained to lower tiers. | `true` (suggesting), `true` (planning), `false` (authorizing), `false` (executing) |
+| `level_description` | string | yes | Human-readable description of what this level means, what Transform produces at this level, and what the user should expect. | Free-form, 2-4 sentences. |
+| `permitted_outputs` | string | yes | What Transform is allowed to produce at this level. Each higher level includes all outputs from lower levels plus additional artifacts. | Free-form, bulleted list. |
+
+## Validation Rules
+
+1. `level` must be one of the four enumerated values. No intermediate levels, no custom levels, no "between planning and authorizing."
+2. `liability_posture` must match the level: suggesting and planning are always `advisor`; authorizing and executing are always `architectural_actor`. There is no configuration that makes an Authorizing-level playbook carry Advisor liability — the liability follows the level.
+3. `minimum_finding_confidence` must be enforced as a hard gate: a finding with confidence `low` cannot produce a playbook at `planning` level or above. A finding with confidence `medium` cannot produce a playbook at `authorizing` level or above. Violations are rejected at schema validation, not treated as warnings.
+4. `minimum_evidence_sources` must count independent sources. The same Semgrep rule cited three times is 1 source, not 3. A Semgrep signal plus a manual code review observation plus a test coverage gap is 3 sources.
+5. `allowed_when_risk_high` is a hard constraint: if any dimension in the change-risk assessment scores 4 or 5 and `allowed_when_risk_high` is `false`, the playbook must be downgraded to a level where this constraint is `true`. There is no override mechanism.
+6. `requires_disclaimer` at `true` means the playbook must include a confidence statement ("Based on [N] evidence sources with overall confidence [level]") and a liability acknowledgment ("This remediation plan should be reviewed by a qualified engineer before application"). Missing disclaimers at Authorizing/Executing levels are validation errors.
+7. Intervention levels are monotonically escalating: a playbook can be downgraded (Authorizing → Planning) at any time without re-assessment, but upgrading (Planning → Authorizing) requires meeting the higher level's thresholds and producing the additional required artifacts (verification plan, change-risk assessment).
+
+## Examples
+
+### Tier Definitions
+
+#### Suggesting
+
+```markdown
+### Level: suggesting
+
+**Liability Posture:** advisor
+**Requires Human Approval:** false
+**Requires Disclaimer:** false
+
+---
+
+#### Confidence Requirements
+
+**Minimum Finding Confidence:** low
+**Minimum Evidence Sources:** 1
+
+#### Risk Constraints
+
+**Allowed When Risk High:** true
+
+#### Description
+
+The lowest intervention level. Radar identifies a potential improvement and describes it at a high level. No structured plan, no code examples, no risk assessment. The output is informational — "you might want to look at this." Suitable for low-confidence findings, exploratory observations, and cases where the evidence is suggestive but not conclusive.
+
+#### Permitted Outputs
+
+- Finding reference with brief remediation description
+- Abstract pattern recommendation (Layer 1 only)
+- No code examples, no risk metadata, no verification steps
+```
+
+#### Planning
+
+```markdown
+### Level: planning
+
+**Liability Posture:** advisor
+**Requires Human Approval:** false
+**Requires Disclaimer:** false
+
+---
+
+#### Confidence Requirements
+
+**Minimum Finding Confidence:** medium
+**Minimum Evidence Sources:** 2
+
+#### Risk Constraints
+
+**Allowed When Risk High:** true
+
+#### Description
+
+Transform produces a structured remediation plan with all four transformation layers, before/after code examples, and risk metadata. The output is a complete playbook that a developer could follow to implement the fix. However, Radar is still in Advisor posture — the plan is a recommendation, not an instruction. Planning-level playbooks do not require a formal verification plan or change-risk assessment, though they include inline risk metadata.
+
+#### Permitted Outputs
+
+- Full playbook with all four transformation layers
+- Before/after code examples
+- Inline risk metadata (4 dimensions with scores and evidence)
+- Verification steps (how to confirm the fix works)
+- Educational context (optional)
+```
+
+#### Authorizing
+
+```markdown
+### Level: authorizing
+
+**Liability Posture:** architectural_actor
+**Requires Human Approval:** true
+**Requires Disclaimer:** true
+
+---
+
+#### Confidence Requirements
+
+**Minimum Finding Confidence:** high
+**Minimum Evidence Sources:** 3
+
+#### Risk Constraints
+
+**Allowed When Risk High:** false
+
+#### Description
+
+Transform produces a fully specified change package: playbook, formal change-risk assessment, and verification plan with pre/post/regression checks and rollback procedure. At this level, Radar is an Architectural Actor — the output is intended to be applied to the codebase, contingent on human approval. The higher evidence requirements (3+ independent sources, high confidence) and risk constraints (no high-risk changes) ensure that only well-evidenced, low-to-medium-risk remediations reach this level. Human review is mandatory.
+
+#### Permitted Outputs
+
+- Full playbook (all Planning outputs)
+- Formal change-risk assessment (@schema:change-risk)
+- Verification plan with pre/post/regression checks (@schema:verification-plan)
+- Rollback procedure
+- Confidence statement and liability disclaimer (required)
+```
+
+#### Executing
+
+```markdown
+### Level: executing
+
+**Liability Posture:** architectural_actor
+**Requires Human Approval:** true
+**Requires Disclaimer:** true
+
+---
+
+#### Confidence Requirements
+
+**Minimum Finding Confidence:** high
+**Minimum Evidence Sources:** 3
+
+#### Risk Constraints
+
+**Allowed When Risk High:** false
+
+#### Description
+
+The highest intervention level. Transform produces all Authorizing-level artifacts plus a Drive-consumable execution plan. The output is designed to be handed to Drive for human-supervised change orchestration — Drive breaks the change into steps, executes them with human checkpoints, and runs the verification plan. Radar Transform never executes changes directly; Drive mediates all codebase modifications. The same evidence and risk thresholds as Authorizing apply — Executing is Authorizing plus the Drive integration layer.
+
+#### Permitted Outputs
+
+- All Authorizing outputs
+- Drive-consumable execution plan (phased steps with checkpoints)
+- Execution ordering and dependency specification
+- Integration metadata for Drive's planning workflow
+```