@accelerationguy/accel 1.0.0

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

@@ -0,0 +1,287 @@
+---
+id: finding
+name: Epistemic Finding
+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
+
+A Finding is the atomic unit of agent output in Radar — a single identified issue, risk, or observation produced by an agent during domain audit phases. Every concern an agent raises must be expressed as a Finding. Findings feed into disagreement resolution, severity calibration, and final report generation.
+
+The 7-layer epistemic structure enforces decomposition of reasoning. Agents cannot jump from observation to judgment — they must pass through evidence sourcing, interpretation, assumption surfacing, risk modeling, and impact assessment first. This prevents the most common failure mode in AI-generated analysis: confident conclusions built on unexamined assumptions.
+
+Findings are Layer A (diagnostic) output. They are the primary input to disagreement resolution, the Transform remediation pipeline, and the final report.
+
+## Template
+
+```markdown
+### {finding_id}
+
+**Domain:** {domain_number} — {domain_name}
+**Agent:** {agent_id}
+**Severity:** {severity}
+
+#### Confidence Vector
+@schema:confidence — {confidence_vector}
+
+---
+
+#### Layer 1 — Observation (Raw Signal)
+
+{observation}
+
+**Source signals:**
+- {signal_reference_1}
+- {signal_reference_2}
+
+#### Layer 2 — Evidence Source
+
+| Attribute | Value |
+|-----------|-------|
+| Source type | {source_type} |
+| Tool or artifact | {tool_or_artifact} |
+| Location | {location} |
+| Freshness | {freshness} |
+| Additional sources | {additional_sources} |
+
+#### Layer 3 — Interpretation (Mechanism)
+
+{interpretation}
+
+**Causal mechanism:** {causal_mechanism}
+
+**Alternative interpretations:**
+- {alternative_1}
+
+#### Layer 4 — Assumptions
+
+What must be true for the interpretation to hold:
+
+1. {assumption_1}
+2. {assumption_2}
+
+**Falsifiability:** {how_assumptions_could_be_disproved}
+
+#### Layer 5 — Risk Statement
+
+If {interpretation_summary}, then {failure_mode}, impacting {asset}.
+
+#### Layer 6 — Impact & Likelihood
+
+| Dimension | Assessment |
+|-----------|------------|
+| Impact domain | {impact_domain} |
+| Impact magnitude | {impact_magnitude} |
+| Likelihood | {likelihood} |
+| Time horizon | {time_horizon} |
+| Blast radius | {blast_radius} |
+
+**Reasoning:** {impact_reasoning}
+
+#### Layer 7 — Judgment (Decision-Oriented)
+
+**Action:** {action}
+**Owning agent:** {judgment_owner}
+**Rationale:** {judgment_rationale}
+
+---
+
+**References:**
+- {reference_1}
+- {reference_2}
+```
+
+## Field Reference
+
+### Metadata Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `finding_id` | string | yes | Unique identifier across the entire audit. | Pattern: `F-{DD}-{NNN}` where DD is two-digit domain number (00-13), NNN is three-digit sequence (001-999). Example: `F-04-001` |
+| `domain_number` | string | yes | Two-digit domain number this finding belongs to. | `00` through `13` |
+| `domain_name` | string | yes | Human-readable domain name. | Must match the domain file's `name` field |
+| `agent_id` | string | yes | ID of the agent that produced this finding. | Must match an agent assembly manifest's `id` field. Agent must have the specified domain in its `domains` list. |
+| `severity` | enum | yes | Assessed severity of the finding. | `critical`, `high`, `medium`, `low`, `informational` |
+| `confidence_vector` | object | yes | Multi-dimensional confidence assessment. | Must conform to @schema:confidence. Contains: evidence_diversity (1-5), signal_freshness (1-5), assumption_fragility (1-5), historical_precedent (1-5), overall (low/medium/high), justification (string). |
+
+### Layer 1 — Observation Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `observation` | string | yes | What exists independently of interpretation. Factual description of what was observed. | No adjectives. No risk language. No value judgments. Tool outputs live here. 1-4 sentences. |
+| `signal_references` | list of strings | yes | IDs or descriptions of signals that produced this observation. | At least one signal reference. Can be tool signal IDs, file paths, or configuration excerpts. |
+
+### Layer 2 — Evidence Source Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `source_type` | enum | yes | Category of evidence. | `static_analysis`, `config_file`, `runtime_metric`, `log`, `commit_history`, `manual_review`, `dependency_scan`, `iac_scan`, `secrets_scan` |
+| `tool_or_artifact` | string | yes | Which tool or artifact produced the evidence. | Tool name (e.g., "Semgrep", "SonarQube") or artifact name (e.g., "Dockerfile", "terraform/main.tf") |
+| `location` | string | yes | Where the evidence was found. | File path + line number, environment name, config key, or API endpoint. Must be specific enough to locate. |
+| `freshness` | enum | yes | Temporal relevance of the evidence. | `static` (code as-written), `historical` (git history, past data), `recent` (recent config/deploy), `live` (current runtime data) |
+| `additional_sources` | list of objects | no | Additional corroborating sources beyond the primary. | Each object: {source_type, tool_or_artifact, location, freshness}. Strengthens evidence_diversity in confidence vector. |
+
+### Layer 3 — Interpretation Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `interpretation` | string | yes | What this observation means in context. | Must explain a causal mechanism. No value judgment. 2-4 sentences. |
+| `causal_mechanism` | string | yes | The specific mechanism by which this observation could lead to a problem. | One sentence describing cause-and-effect. |
+| `alternative_interpretations` | list of strings | no | Other valid interpretations of the same observation. | Each entry is a plausible alternative. Presence indicates epistemic honesty; absence is acceptable only when interpretation is unambiguous. |
+
+### Layer 4 — Assumptions Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `assumptions` | list of strings | yes | What must be true for the interpretation to hold. | At least one falsifiable assumption. Each must be a concrete, testable statement. |
+| `falsifiability` | string | yes | How the assumptions could be disproved. | Description of what evidence would invalidate the interpretation. |
+
+### Layer 5 — Risk Statement Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `risk_statement` | string | yes | Structured risk assertion. | Must follow format: "If [interpretation], then [failure mode], impacting [asset]." All three components required. |
+
+### Layer 6 — Impact & Likelihood Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `impact_domain` | enum | yes | Which domain of impact this finding affects. | `security`, `data_integrity`, `availability`, `compliance`, `velocity` |
+| `impact_magnitude` | enum | yes | How severe the impact would be if the risk materializes. | `low`, `moderate`, `high`, `critical`, `existential` |
+| `likelihood` | enum | yes | How likely the risk is to materialize. | `rare`, `unlikely`, `possible`, `likely`, `frequent` |
+| `time_horizon` | enum | yes | When the risk is expected to manifest. | `immediate`, `near_term`, `long_term`, `hypothetical` |
+| `blast_radius` | enum | yes | How widely the impact would spread. | `localized`, `service_level`, `systemic`, `org_wide` |
+| `impact_reasoning` | string | yes | Explicit reasoning for the impact and likelihood assessments. | 2-4 sentences connecting evidence to impact dimensions. No "vibes" — must reference specific evidence. |
+
+### Layer 7 — Judgment Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `action` | enum | yes | Recommended action. | `must_fix`, `should_fix`, `accept_risk`, `monitor`, `out_of_scope` |
+| `judgment_owner` | string | yes | Agent responsible for the final judgment. | Typically `principal-engineer` for final judgments. Originating agent for initial recommendations. |
+| `judgment_rationale` | string | yes | Why this action is recommended. | 1-3 sentences. Must reference Layer 6 assessments. Judgment is explicitly separated from facts. |
+
+### Reference Fields
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `references` | list of strings | no | External standards, related findings, or documentation. | CWE IDs, CVE IDs, standard references, or related finding IDs (F-{DD}-{NNN} format). |
+
+## Validation Rules
+
+1. **Unique ID:** `finding_id` must be unique across the entire audit. No two findings may share an ID.
+2. **Valid domain:** `domain_number` must reference an existing domain (00-13).
+3. **Agent-domain alignment:** `agent_id` must reference an agent that has the specified domain in its `domains` list.
+4. **Observation purity:** Layer 1 (`observation`) must contain no adjectives, risk language, or value judgments. It describes what exists, not what it means. Phrases like "dangerous", "poor", "inadequate" in Layer 1 are validation failures.
+5. **Evidence grounding:** Layer 2 must contain at least one concrete source reference (file path, tool signal ID, or configuration excerpt). Assertions without evidence are invalid.
+6. **Mechanistic interpretation:** Layer 3 (`interpretation`) must explain a causal mechanism. Restating the observation is not interpretation. "Function retries on 500" (observation) vs "Unbounded retries can amplify load during partial outages" (interpretation).
+7. **Falsifiable assumptions:** Layer 4 must list at least one falsifiable assumption. Tautologies ("the code does what it does") are not assumptions.
+8. **Risk statement structure:** Layer 5 must follow "If [interpretation], then [failure mode], impacting [asset]" structure. All three components are required.
+9. **Enumerated values:** All Layer 6 fields must use their enumerated values. No other values are valid.
+10. **Valid judgment:** Layer 7 `action` must be one of the five enumerated values.
+11. **Confidence vector conformance:** `confidence_vector` must be a valid instance of @schema:confidence. All four dimensions required, all scoring within 1-5 range.
+12. **Severity-confidence consistency:** A finding with `severity: critical` and `confidence_vector.overall: low` must include explicit justification in Layer 7 explaining why a critical severity is warranted despite low confidence. The combination triggers mandatory review by the Principal Engineer.
+13. **Cross-reference validity:** Any finding ID referenced in `references` must exist in the audit's finding set.
+
+## Examples
+
+### Example: Critical Security Finding — Hardcoded Credentials
+
+```markdown
+### F-04-001
+
+**Domain:** 04 — Security
+**Agent:** security-engineer
+**Severity:** critical
+
+#### Confidence Vector
+@schema:confidence
+- Evidence diversity: 4 (static analysis + secrets scan + config review + commit history)
+- Signal freshness: 2 (static analysis only, no runtime confirmation)
+- Assumption fragility: 5 (credentials are plaintext in source — self-evident)
+- Historical precedent: 5 (CWE-798 is among the most documented credential failures)
+- Overall: high
+- Justification: Four independent evidence sources confirm plaintext credentials in source code. This is a well-documented failure mode (CWE-798) with extensive incident history. Signal freshness is limited to static analysis, but the finding does not require runtime validation — the credentials are visible in the code.
+
+---
+
+#### Layer 1 — Observation (Raw Signal)
+
+File `config/database.py` lines 12-14 contain three string literals assigned to variables named `DB_USER`, `DB_PASS`, and `DB_HOST`. The values are `"admin"`, `"pr0d_s3cret_2024"`, and `"prod-db.internal.company.com"` respectively.
+
+**Source signals:**
+- Gitleaks signal GL-047: high-entropy secret detected in config/database.py
+- Semgrep rule python.security.hardcoded-credentials: match at config/database.py:12-14
+- SonarQube hotspot S2068: credentials should not be hard-coded
+
+#### Layer 2 — Evidence Source
+
+| Attribute | Value |
+|-----------|-------|
+| Source type | static_analysis |
+| Tool or artifact | Gitleaks v8.x |
+| Location | config/database.py, lines 12-14 |
+| Freshness | static |
+| Additional sources | Semgrep (static_analysis, config/database.py:12), SonarQube (static_analysis, S2068 hotspot), git log (commit_history, credentials present since initial commit a1b2c3d, 2024-03-15) |
+
+#### Layer 3 — Interpretation (Mechanism)
+
+Production database credentials stored as plaintext strings in source code are accessible to anyone with repository read access. The credentials are not injected at runtime via environment variables or a secrets manager — they are embedded directly in the application configuration module.
+
+**Causal mechanism:** Repository access grants database access because credentials are not externalized from the codebase.
+
+**Alternative interpretations:**
+- The values could be development-only defaults overridden by environment variables at runtime. However, no environment variable lookup or override mechanism exists in the file.
+
+#### Layer 4 — Assumptions
+
+What must be true for the interpretation to hold:
+
+1. The `config/database.py` file is used in production deployments (not just local development).
+2. No runtime override mechanism (environment variable, secrets manager injection) supersedes these values before the database connection is established.
+3. The repository is accessible to individuals who should not have production database credentials.
+
+**Falsifiability:** If a deployment script or container entrypoint injects environment variables that override these values before `config/database.py` is loaded, the plaintext values would never be used in production. Review of deployment configuration (Dockerfile, docker-compose.yml, CI/CD pipeline) would confirm or refute this.
+
+#### Layer 5 — Risk Statement
+
+If production database credentials are embedded in source code without runtime override, then anyone with repository access can connect directly to the production database, impacting data confidentiality, integrity, and availability.
+
+#### Layer 6 — Impact & Likelihood
+
+| Dimension | Assessment |
+|-----------|------------|
+| Impact domain | security |
+| Impact magnitude | critical |
+| Likelihood | likely |
+| Time horizon | immediate |
+| Blast radius | systemic |
+
+**Reasoning:** The credentials are plaintext and have been in the repository since the initial commit (11 months). Any developer, CI system, or third-party integration with repository access has had production database credentials for nearly a year. The blast radius is systemic because database compromise affects all application data and all services that depend on this database. Credential rotation requires a code change and redeployment.
+
+#### Layer 7 — Judgment (Decision-Oriented)
+
+**Action:** must_fix
+**Owning agent:** security-engineer
+**Rationale:** Plaintext production credentials in source code are an immediate, systemic risk with critical impact magnitude. The finding has high confidence across all dimensions. Remediation is well-understood (externalize to environment variables or secrets manager) and low-risk. There is no defensible reason to accept this risk.
+
+---
+
+**References:**
+- CWE-798: Use of Hard-coded Credentials
+- F-04-003 (related: missing secrets scanning in CI pipeline)
+- OWASP Top 10 A07:2021 — Identification and Authentication Failures
+```

package/modules/radar/src/schemas/report-section.md

@@ -0,0 +1,150 @@
+---
+id: report-section
+name: Report Section
+version: 1.0.0
+used_by:
+  - principal-engineer
+  - phase-5-synthesis-workflow
+---
+
+## Purpose
+
+The report section schema defines the structure of the Radar Layer A diagnostic report — the primary deliverable of every audit. The report consists of 7 sections in fixed order, each with a defined purpose, required content, data sources, and target audience.
+
+This schema governs structure, not generation. How the report is assembled is workflow logic (Phase 6). What the report must contain is defined here. The distinction prevents structural drift across audits — every Radar report has the same sections in the same order with the same content requirements, regardless of the target codebase.
+
+## Template
+
+```markdown
+# Radar Audit Report: {project_name}
+
+**Audit ID:** {audit_id}
+**Date:** {audit_date}
+**Version:** {audit_version}
+**Target:** {target_description}
+
+---
+
+## Section 1: Executive Risk Summary
+
+{executive_risk_summary}
+
+## Section 2: Architecture Narrative
+
+{architecture_narrative}
+
+## Section 3: Findings by Domain (Severity-Ranked)
+
+### Domain {DD} — {domain_name}
+
+{domain_findings_block}
+
+[Repeated for all 14 domains]
+
+## Section 4: Cross-Validation Notes
+
+{cross_validation_notes}
+
+## Section 5: Remediation Roadmap
+
+{remediation_roadmap}
+
+## Section 6: Long-Term Structural Risks
+
+{long_term_risks}
+
+## Section 7: What Would Break First at 10x Scale
+
+{scale_failure_analysis}
+
+---
+
+**Audit metadata:**
+- Agents deployed: {agent_list}
+- Tools executed: {tool_list}
+- Total findings: {finding_count}
+- Total disagreements: {disagreement_count}
+- Unresolved disagreements: {unresolved_count}
+```
+
+## Field Reference
+
+### Report Metadata
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `audit_id` | string | yes | Unique identifier for this audit run. | Format: `Radar-{YYYYMMDD}-{NNN}` |
+| `audit_date` | string | yes | Date the audit was completed. | ISO 8601 date. |
+| `audit_version` | string | yes | Version of the Radar system used. | Semantic version matching Radar release. |
+| `target_description` | string | yes | What was audited. | Repository name, path, and scope constraints. |
+
+### Section Specifications
+
+| Section | Name | Required Content | Data Sources | Audience |
+|---------|------|-----------------|--------------|----------|
+| 1 | Executive Risk Summary | Top 5 risks by severity, overall risk posture (critical/high/medium/low), count of findings per severity, count of unresolved disagreements, single-paragraph assessment | Aggregated @schema:finding by severity, @schema:disagreement with status: open | Leadership, non-technical stakeholders |
+| 2 | Architecture Narrative | System description, architectural pattern identified, component map, dependency direction analysis, key strengths, key concerns | Domain 00 (Context) Phase 0 output, Domain 01 (Architecture) findings | Technical leadership, architects |
+| 3 | Findings by Domain | All findings grouped by domain (00-13), severity-ranked within each domain, each finding in full @schema:finding format | All @schema:finding instances | Engineering teams, domain owners |
+| 4 | Cross-Validation Notes | All disagreements with positions, root causes, resolution models, and Principal responses. Disagreement heatmap data (severity x disagreement intensity). | All @schema:disagreement instances | Principal Engineer, technical leadership |
+| 5 | Remediation Roadmap | Prioritized action plan, findings with action: must_fix or should_fix, ordered by severity then dependency, estimated effort categories, quick wins highlighted | @schema:finding where action is must_fix or should_fix | Engineering teams, project managers |
+| 6 | Long-Term Structural Risks | Risks that worsen over time — architectural erosion, tech debt accumulation, knowledge concentration, test coverage decay | @schema:finding where time_horizon is long_term or hypothetical | Technical leadership, architects |
+| 7 | What Would Break First at 10x Scale | Predictive failure analysis — which components fail first under 10x load/users/data, bottleneck identification, cascade failure paths | Domain 07 (Reliability) + Domain 08 (Performance) findings, findings with blast_radius: systemic | CTO, architects, SRE team |
+
+### Section Content Rules
+
+| Rule | Applies To | Description |
+|------|-----------|-------------|
+| Severity ranking | Section 3 | Findings within each domain are ordered: critical → high → medium → low → informational |
+| Completeness | Section 3 | All 14 domains must be present. Domains with no findings state "No findings in this domain." |
+| Resolution status | Section 4 | Each disagreement shows current status. Unresolved disagreements are flagged. |
+| Dependency ordering | Section 5 | Remediations are ordered by dependency (foundation fixes before dependent fixes), not just severity. |
+| Evidence grounding | Section 7 | Predictions must reference specific findings and evidence, not speculation. |
+
+## Validation Rules
+
+1. **All sections required:** All 7 sections must be present. Omitting a section is a validation error, even if the section would be sparse.
+2. **Fixed order:** Sections must appear in order 1-7. Reordering is a validation error.
+3. **Section 3 completeness:** All 14 domains (00-13) must be represented in Section 3, even if a domain has zero findings.
+4. **Data source traceability:** Every finding in Section 3 must have a valid finding_id matching @schema:finding. Every disagreement in Section 4 must have a valid disagreement_id matching @schema:disagreement.
+5. **Executive summary constraints:** Section 1 must not exceed one page equivalent (~500 words). It is a summary, not a detailed analysis.
+6. **No orphaned references:** Any finding_id or disagreement_id referenced in the report must exist in the audit's dataset. Forward references to findings not yet produced are invalid.
+7. **Unresolved disagreement count:** Report metadata must accurately count disagreements with status: open. A report claiming zero unresolved disagreements when open disagreements exist is a validation error.
+
+## Examples
+
+### Example: Executive Risk Summary (Section 1)
+
+```markdown
+## Section 1: Executive Risk Summary
+
+**Overall Risk Posture: HIGH**
+
+| Severity | Count |
+|----------|-------|
+| Critical | 2 |
+| High | 7 |
+| Medium | 14 |
+| Low | 8 |
+| Informational | 3 |
+
+**Top 5 Risks:**
+
+1. **F-04-001 — Hardcoded production database credentials** (Critical, Security)
+   Plaintext credentials in source code accessible to all repository users. Immediate remediation required.
+
+2. **F-04-012 — Missing authentication on admin API endpoints** (Critical, Security)
+   Three admin endpoints accept unauthenticated requests. Exploitation is trivial.
+
+3. **F-01-003 — Circular dependency between core modules** (High, Architecture)
+   Service layer and data layer have bidirectional dependencies, preventing independent deployment and testing.
+
+4. **F-07-002 — No circuit breaker on external API calls** (High, Reliability)
+   Downstream service failures cascade into full application unavailability.
+
+5. **F-02-005 — Race condition in user balance updates** (High, Data Integrity)
+   Concurrent requests can produce incorrect balances. Confirmed by code structure; unverified at runtime.
+
+**Disagreements:** 4 total, 1 unresolved (D-003: severity of F-02-005 disputed between data-engineer and senior-app-engineer).
+
+**Assessment:** The codebase has two critical security vulnerabilities requiring immediate attention. Architectural issues (circular dependencies, missing circuit breakers) create systemic fragility that will worsen under growth. The unresolved disagreement on F-02-005 needs runtime validation to determine true severity.
+```

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

@@ -0,0 +1,108 @@
+---
+id: signal
+name: Signal
+version: 1.0.0
+used_by:
+  - tool-adapters
+  - 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
+
+A Signal is a normalized tool output — the bridge between heterogeneous analysis tools and structured agent reasoning. Tools speak different severity languages: SonarQube uses "blocker/critical/major/minor/info", Semgrep uses "ERROR/WARNING/INFO", Trivy uses "CRITICAL/HIGH/MEDIUM/LOW/UNKNOWN", Gitleaks uses "match/no-match". Without normalization, agents cannot compare or correlate signals across tools.
+
+The signal schema converts all tool output into four normalized dimensions (severity, confidence estimate, blast radius, domain relevance) while preserving the original tool output for audit trail integrity. Signals are Phase 1 output — raw evidence gathered before any agent reasoning begins. Agents consume signals as input to their domain audits, producing @schema:finding instances as output.
+
+Signals are NOT findings. A signal is evidence. A finding is a reasoned conclusion built on evidence. The separation is fundamental to Radar's epistemic architecture.
+
+## Template
+
+```markdown
+### {signal_id}
+
+**Source tool:** {source_tool}
+**Source rule:** {source_rule}
+**Location:** {location}
+**Category:** {signal_category}
+
+#### Normalized Dimensions
+
+| Dimension | Value |
+|-----------|-------|
+| Severity | {severity} |
+| Confidence estimate | {confidence_estimate} |
+| Blast radius | {blast_radius} |
+| Domain relevance | {domain_relevance} |
+
+#### Raw Output
+
+**Raw severity:** {raw_severity}
+**Raw output ref:** {raw_output_ref}
+**Normalization notes:** {normalization_notes}
+```
+
+## Field Reference
+
+| Field | Type | Required | Description | Valid Values |
+|-------|------|----------|-------------|--------------|
+| `signal_id` | string | yes | Unique identifier across the audit. | Pattern: `S-{TTT}-{NNN}` where TTT is 2-4 character tool abbreviation, NNN is three-digit sequence. Examples: `S-SMG-001` (Semgrep), `S-SQ-001` (SonarQube), `S-TRV-001` (Trivy), `S-GL-001` (Gitleaks), `S-CHK-001` (Checkov), `S-GRP-001` (Grype), `S-GIT-001` (git mining) |
+| `source_tool` | enum | yes | Tool that produced this signal. | `sonarqube`, `semgrep`, `trivy`, `gitleaks`, `checkov`, `syft`, `grype`, `git-mining`, `manual-review` |
+| `source_rule` | string | yes | The specific rule, check, or policy that fired. | Tool-specific rule identifier. Examples: `python.security.sql-injection` (Semgrep), `S2068` (SonarQube), `CVE-2024-1234` (Trivy/Grype). |
+| `location` | string | yes | Where the signal was detected. | File path + line range, container image + layer, dependency name + version, or config path. Must be specific enough to locate. |
+| `signal_category` | enum | yes | Which of the 6 evidence dimensions this signal belongs to. | `structure`, `behavior`, `history`, `dependencies`, `policy_posture`, `runtime_contracts` |
+| `severity` | enum | yes | Normalized Radar severity. | `critical`, `high`, `medium`, `low`, `informational` |
+| `confidence_estimate` | enum | yes | Tool-level confidence in the signal's accuracy. This is a rough estimate, not the full @schema:confidence vector (agents compute that during analysis). | `high`, `medium`, `low` |
+| `blast_radius` | enum | yes | Estimated scope of impact if this signal represents a real issue. | `localized`, `service_level`, `systemic`, `org_wide` |
+| `domain_relevance` | list of strings | yes | Domain numbers this signal is relevant to. | At least one value. Each must be a two-digit domain number `00` through `13`. |
+| `raw_severity` | string | yes | The original severity string from the tool, preserved verbatim. | Free text — exact value the tool reported. |
+| `raw_output_ref` | string | yes | Path to the raw tool output file. | File path within the `.radar/signals/` directory. |
+| `normalization_notes` | string | no | Context about how raw values were mapped to Radar values. | Useful when mapping is ambiguous (e.g., SonarQube "blocker" maps to Radar "critical" but with context-dependent confidence). |
+
+## Validation Rules
+
+1. **Unique ID:** `signal_id` must be unique across the entire audit.
+2. **Valid tool:** `source_tool` must match a configured tool adapter in the Radar installation.
+3. **Radar severity values:** `severity` must use the 5-value Radar enum. Raw tool severities are preserved in `raw_severity` but never used directly by agents.
+4. **Domain relevance required:** `domain_relevance` must contain at least one valid domain number (00-13).
+5. **Raw preservation:** `raw_severity` must be preserved exactly as the tool reported it. Discarding raw values breaks audit trail integrity.
+6. **Signal is not finding:** Signals must not contain interpretation, risk statements, or judgment. These are Layer 1 (observation) + Layer 2 (evidence source) content only. If a signal contains reasoning, it has been contaminated by agent logic.
+7. **Category alignment:** `signal_category` must match the tool's evidence type. Static analysis tools produce `structure` or `policy_posture` signals, not `behavior` signals.
+
+## Examples
+
+### Example: Semgrep SQL Injection Signal
+
+```markdown
+### S-SMG-001
+
+**Source tool:** semgrep
+**Source rule:** python.security.sql-injection.string-concat-query
+**Location:** src/api/users.py:45
+**Category:** policy_posture
+
+#### Normalized Dimensions
+
+| Dimension | Value |
+|-----------|-------|
+| Severity | high |
+| Confidence estimate | medium |
+| Blast radius | service_level |
+| Domain relevance | 04, 03 |
+
+#### Raw Output
+
+**Raw severity:** ERROR
+**Raw output ref:** .radar/signals/semgrep/run-001.json
+**Normalization notes:** Semgrep ERROR maps to Radar high (not critical) because Semgrep does not distinguish between exploitable and theoretical vulnerabilities. Confidence is medium because Semgrep is pattern-based without data flow analysis — the match may be a false positive if input is sanitized upstream. Domain 04 (Security) is primary; Domain 03 (Correctness) is secondary because string concatenation in SQL is also a correctness issue.
+```