icdev 1.0.0__py3-none-any.whl

icdev/data/goals/parallel_cicd.md

@@ -0,0 +1,61 @@
+# [TEMPLATE: CUI // SP-CTI]
+# Parallel CI/CD Goal — Git Worktree Isolation + GitLab Task Board
+
+## Purpose
+Enable parallel, conflict-free CI/CD execution through git worktree isolation
+and automated GitLab task board monitoring with tag-based workflow routing.
+
+## Trigger
+- GitLab issue created with `{{icdev: workflow}}` tag
+- Manual worktree creation via `/init_worktree`
+- Webhook/poll trigger with worktree isolation enabled
+
+## Workflow
+
+### 1. Task Detection
+GitLab Task Monitor (`tools/ci/triggers/gitlab_task_monitor.py`) polls
+open issues with the `icdev` label every 20 seconds.
+
+### 2. Tag Extraction
+Parse issue body for `{{icdev: workflow}}` tags:
+| Tag | Workflow |
+|-----|---------|
+| `{{icdev: intake}}` | RICOAS intake session |
+| `{{icdev: build}}` | TDD build (RED->GREEN->REFACTOR) |
+| `{{icdev: sdlc}}` | Full SDLC pipeline |
+| `{{icdev: comply}}` | Compliance artifact generation |
+| `{{icdev: secure}}` | Security scanning |
+| `{{icdev: modernize}}` | Legacy app modernization |
+
+### 3. Worktree Isolation
+For each claimed task:
+- Create isolated worktree: `trees/<task-id>/`
+- Sparse checkout: only target directory
+- CUI classification marker
+- Separate git branch: `icdev-<task-id>`
+
+### 4. Workflow Execution
+- Spawn workflow as detached subprocess
+- Track in `gitlab_task_claims` table
+- Update GitLab issue with progress comments
+
+### 5. Cleanup
+- After workflow completes, cleanup worktree
+- Update claim status to completed/failed
+- Remove `icdev-processing` label
+
+## Tools Used
+| Tool | Purpose |
+|------|---------|
+| `worktree.py` | Git worktree lifecycle (create, list, cleanup, status) |
+| `gitlab_task_monitor.py` | GitLab issue polling + tag routing |
+
+## Database Tables
+- `ci_worktrees` -- Worktree state tracking
+- `gitlab_task_claims` -- Issue claim dedup
+
+## Success Criteria
+- Multiple workflows run in parallel without git conflicts
+- Each worktree has classification marker
+- GitLab issues auto-claimed and routed to correct workflow
+- Worktrees cleaned up after task completion

icdev/data/goals/requirements_intake.md

@@ -0,0 +1,213 @@
+# Goal: Requirements Intake & Decomposition (RICOAS Phase 1)
+
+## Purpose
+
+Transform vague customer requirements into structured, decomposed, MBSE-traced, compliance-validated work items through AI-driven conversational intake.
+
+## When to Use
+
+- Customer provides new requirements (SOW, CDD, CONOPS, verbal)
+- Existing requirements need refinement or gap analysis
+- Requirements need SAFe decomposition (Epic > Feature > Story)
+- BDD acceptance criteria generation needed
+- Readiness assessment before proceeding to architecture/build
+
+## Workflow
+
+### Stage 1: Session Setup
+
+1. Create intake session: `create_intake_session` (MCP) or `python tools/requirements/intake_engine.py --project-id <id> --customer-name <name> --json`
+2. Session stores: customer info, impact level (IL2-IL6), classification, ATO context
+
+### Stage 2: Conversational Intake
+
+1. Process customer messages via `process_intake_turn` (MCP) or CLI `--message`
+2. Engine extracts requirements from each turn automatically
+3. Detects ambiguities in real-time (patterns from context/requirements/ambiguity_patterns.json)
+4. Detects gap signals (security, performance, data, compliance)
+5. Detects ATO boundary impact signals
+6. Every 5 turns (configurable), auto-runs gap detection and readiness scoring
+
+### Stage 3: Document Upload (Optional)
+
+1. Customer uploads SOW/CDD/CONOPS via `upload_document`
+2. Extract requirements via `extract_document`
+3. Extracted requirements merge into session's requirement set
+4. Supports: PDF (pypdf), DOCX (python-docx), TXT, MD
+
+### Stage 4: Gap Detection & Readiness Scoring
+
+1. Run gap detection: `detect_gaps` — checks security, compliance, testability, interfaces, data
+2. Gaps reference NIST 800-53 controls and provide remediation recommendations
+3. Run readiness scoring: `score_readiness` — 5 dimensions (completeness, clarity, feasibility, compliance, testability)
+4. Thresholds: 0.7 = proceed to decomposition, 0.8 = proceed to COA, 0.9 = proceed to implementation
+5. Score trend tracked across turns to show progress
+
+### Stage 5: SAFe Decomposition
+
+1. Decompose requirements: `decompose_requirements` with target level (epic/feature/story)
+2. Generates SAFe hierarchy: Epic > Capability > Feature > Story > Enabler
+3. T-shirt size estimation per item (XS through XXL)
+4. WSJF scoring for prioritization
+5. Optional BDD acceptance criteria (Gherkin Given/When/Then)
+
+### Stage 6: Export & Handoff
+
+1. Export requirements: `python tools/requirements/intake_engine.py --session-id <id> --export --json`
+2. Decomposed items ready for Architect agent (ATLAS workflow)
+3. Requirements link to digital thread for MBSE traceability
+4. Audit trail records all intake events
+
+---
+
+## Visual Workflow
+
+### Intake Pipeline Flowchart
+
+```mermaid
+flowchart TD
+    A["Stage 1: Session Setup"] --> B["Stage 2: Conversational Intake"]
+    B --> C["Stage 3: Document Upload"]
+    C --> D["Stage 4: Gap Detection & Readiness"]
+    D --> E{Readiness Score?}
+    E -->|"score < 0.7"| B
+    E -->|"score >= 0.7"| F["Stage 5: SAFe Decomposition"]
+    F --> G["Stage 6: Export & Handoff"]
+
+    style A fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style B fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style C fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style D fill:#3a3a1a,stroke:#ffc107,color:#e0e0e0
+    style E fill:#3a2a1a,stroke:#e8590c,color:#e0e0e0
+    style F fill:#1a3a5c,stroke:#4a90d9,color:#e0e0e0
+    style G fill:#1a3a2d,stroke:#28a745,color:#e0e0e0
+```
+
+### SAFe Hierarchy
+
+```mermaid
+classDiagram
+    Epic "1" --> "*" Capability : decomposes into
+    Capability "1" --> "*" Feature : decomposes into
+    Feature "1" --> "*" Story : decomposes into
+    Feature "1" --> "*" Enabler : decomposes into
+
+    class Epic {
+        +String id
+        +String title
+        +String description
+        +String wsjf_score
+        +String t_shirt_size
+    }
+
+    class Capability {
+        +String id
+        +String title
+        +String epic_id
+        +String priority
+    }
+
+    class Feature {
+        +String id
+        +String title
+        +String capability_id
+        +String acceptance_criteria
+        +String t_shirt_size
+    }
+
+    class Story {
+        +String id
+        +String title
+        +String feature_id
+        +String bdd_scenarios
+        +String story_points
+    }
+
+    class Enabler {
+        +String id
+        +String title
+        +String feature_id
+        +String enabler_type
+        +String t_shirt_size
+    }
+```
+
+---
+
+## Tools Used
+
+| Tool | Purpose |
+|------|---------|
+| tools/requirements/intake_engine.py | Conversational intake, session management |
+| tools/requirements/gap_detector.py | Gap and ambiguity detection |
+| tools/requirements/readiness_scorer.py | 5-dimension readiness scoring |
+| tools/requirements/decomposition_engine.py | SAFe hierarchy decomposition |
+| tools/requirements/document_extractor.py | Document upload and extraction |
+| tools/mcp/requirements_server.py | MCP server (10 tools) |
+
+## Args
+
+- `args/ricoas_config.yaml` — Readiness weights, thresholds, gap detection settings, cost models
+
+## Context
+
+- `context/requirements/gap_patterns.json` — 10 gap detection patterns with NIST mappings
+- `context/requirements/ambiguity_patterns.json` — 15 ambiguity patterns with clarification suggestions
+- `context/requirements/safe_templates.json` — SAFe hierarchy templates and WSJF formula
+- `context/requirements/document_extraction_rules.json` — Extraction rules per document type
+- `context/requirements/readiness_rubric.json` — 5-dimension scoring rubric
+
+## Hard Prompts
+
+- `hardprompts/requirements/intake_conversation.md` — Intake agent system prompt
+- `hardprompts/requirements/gap_detection.md` — Gap analysis prompt
+- `hardprompts/requirements/decomposition.md` — SAFe decomposition prompt
+- `hardprompts/requirements/document_extraction.md` — Document extraction prompt
+- `hardprompts/requirements/bdd_generation.md` — BDD criteria generation prompt
+- `hardprompts/requirements/readiness_assessment.md` — Readiness scoring prompt
+
+---
+
+## Edge Cases
+
+- Customer provides contradictory requirements → flag as gap with both references
+- Document extraction finds 0 requirements → suggest different document type or manual entry
+- Readiness score stuck below threshold → show trend, suggest specific areas to address
+- Session resumed after long gap → summarize previous context to customer
+- Impact level change mid-session → re-run boundary analysis on all requirements
+
+---
+
+## Success Criteria
+
+- All requirements captured with type, priority, and source
+- Readiness score >= 0.7 before decomposition
+- Zero unresolved critical gaps
+- SAFe items have acceptance criteria and estimates
+- Full audit trail of intake process
+
+---
+
+## GOTCHA Layer Mapping
+
+| Intake Stage | GOTCHA Layer |
+|--------------|--------------|
+| Session Setup | Goals (define what to capture) |
+| Conversational Intake | Orchestration (AI guides conversation) |
+| Document Upload | Tools (extraction scripts) |
+| Gap Detection | Context (gap patterns, ambiguity patterns) |
+| Readiness Scoring | Args (thresholds, weights) |
+| SAFe Decomposition | Hard Prompts (decomposition templates) |
+
+---
+
+## Related Files
+
+- **Goal:** `goals/build_app.md` — ATLAS workflow (receives decomposed requirements)
+- **Goal:** `goals/mbse_integration.md` — MBSE digital thread (links to requirements)
+- **Goal:** `goals/compliance_workflow.md` — Compliance artifacts (informed by gap analysis)
+- **Skill:** `.claude/skills/icdev-intake/SKILL.md` — Claude Code slash command
+
+---
+
+## Changelog

icdev/data/goals/sbd_ivv_workflow.md

@@ -0,0 +1,195 @@
+# Goal: Secure by Design (SbD) + IV&V Certification Workflow
+
+## Description
+
+Assess applications against **CISA Secure by Design** commitments and **IEEE 1012 IV&V** process requirements. This workflow ensures that security is designed in from the start (not bolted on) and that an independent verification process confirms correctness.
+
+**Standards:**
+- CISA Secure by Design Pledge (7 commitments)
+- DoDI 5000.87 (Software Acquisition Pathway)
+- NIST SP 800-218 SSDF (Secure Software Development Framework)
+- IEEE 1012-2016 (V&V Standard)
+- NIST 800-53 Rev 5 SA-24 (Cyber Resiliency by Design)
+
+**Why this matters:** SbD ensures security is an architectural decision, not an afterthought. IV&V provides independent assurance that systems work correctly and securely. Together they are the 7th and 8th components of the ICDEV compliance scoring system.
+
+---
+
+## Prerequisites
+
+- [ ] Project initialized (`goals/init_project.md` completed)
+- [ ] Project has code to assess
+- [ ] Security scans completed (`goals/security_scan.md`)
+- [ ] STIG checks completed (STIG findings feed SbD assessment)
+- [ ] SBOM generated (freshness feeds SbD assessment)
+- [ ] Tests written (test coverage feeds IV&V assessment)
+
+---
+
+## Process
+
+### Step 1: Run SbD Assessment
+
+**Tool:** `python tools/compliance/sbd_assessor.py --project-id <project_id> --domain all`
+
+Assesses 14 domains with 20 automated checks:
+- **Authentication:** MFA patterns, default password elimination
+- **Memory Safety:** Language choice, safety tooling
+- **Vulnerability Management:** Patch cadence, dependency scanning
+- **Intrusion Evidence:** Audit logging completeness
+- **Cryptography:** TLS config, encryption at rest
+- **Access Control:** RBAC, least privilege
+- **Input Handling:** Validation, output encoding
+- **Error Handling:** Secure error handling, no stack traces
+- **Supply Chain:** SBOM freshness, dependency scanning
+- **Threat Modeling:** STRIDE/PASTA documentation
+- **Defense in Depth:** Security headers, secure configs
+- **Secure Defaults:** No default credentials, hardened baselines
+- **CUI Compliance:** CUI markings present
+- **DoD Software Assurance:** DoDI 5000.87 requirements
+
+**CRITICAL GATE:** 0 critical "not_satisfied" = PASS
+
+**Scoring:** 100 × (satisfied + partial×0.5 + risk_accepted×0.75) / assessable_count
+
+---
+
+### Step 2: Generate SbD Report
+
+**Tool:** `python tools/compliance/sbd_report_generator.py --project-id <project_id>`
+
+Generates CUI-marked report including:
+- Executive Summary with overall SbD score
+- CISA 7 Commitment status table
+- Domain-by-domain assessment details
+- Auto-check results and manual review items
+- Remediation recommendations
+- NIST 800-53 control mapping
+
+---
+
+### Step 3: Generate Requirements Traceability Matrix (RTM)
+
+**Tool:** `python tools/compliance/traceability_matrix.py --project-id <project_id> --project-dir <path>`
+
+Discovers and traces:
+- **Requirements:** .feature files, requirements.md, user stories
+- **Design:** architecture.md, system_design.md, ADR directory
+- **Code:** src/ modules and their functionality
+- **Tests:** tests/ directory mapped to requirements
+
+Produces:
+- Forward trace: requirement → design → code → tests
+- Backward trace: test → code → design → requirement
+- Gap analysis: untested requirements, orphan tests
+- Coverage percentage
+
+---
+
+### Step 4: Run IV&V Assessment
+
+**Tool:** `python tools/compliance/ivv_assessor.py --project-id <project_id> --process-area all`
+
+Assesses 9 process areas with 18 automated checks:
+1. **Requirements Verification:** Completeness, consistency, testability
+2. **Design Verification:** Architecture docs, design patterns
+3. **Code Verification:** SAST results, coding standards, complexity
+4. **Test Verification:** Coverage, test plans, security tests
+5. **Integration Verification:** BDD coverage, E2E tests
+6. **Traceability Analysis:** RTM exists, requirements linked
+7. **Security Verification:** Pipeline security, artifact integrity
+8. **Build/Deploy Verification:** Config hardening, rollback capability
+9. **Process Compliance:** All of the above in aggregate
+
+**Scoring:**
+- Verification (60%): Average of process areas 1-6
+- Validation (40%): Average of process areas 4-5 (test-focused)
+- Overall: weighted combination
+
+**CRITICAL GATE:** 0 critical findings = PASS
+
+**Certification recommendation:**
+- **CERTIFY:** ≥80% overall, 0 critical findings
+- **CONDITIONAL:** ≥60% overall, 0 critical findings
+- **DENY:** <60% or any critical findings
+
+---
+
+### Step 5: Generate IV&V Report
+
+**Tool:** `python tools/compliance/ivv_report_generator.py --project-id <project_id>`
+
+Generates CUI-marked certification report including:
+- Executive Summary with certification recommendation
+- Verification results by process area
+- Validation results (testing focus)
+- RTM summary and coverage
+- Findings list with severity and status
+- Independence declaration
+- NIST 800-53 control mapping
+
+---
+
+### Step 6: Log to Audit Trail
+
+**Tool:** `python tools/audit/audit_logger.py --event "sbd_ivv_assessed" --actor "orchestrator" --action "SbD + IV&V assessment complete" --project <name>`
+
+**Tool:** `python tools/memory/memory_write.py --content "SbD + IV&V assessed for <name>. SbD score: <pct>%, IV&V cert: <CERTIFY|CONDITIONAL|DENY>" --type event --importance 7`
+
+---
+
+## Success Criteria
+
+- [ ] SbD assessment completed across all 14 domains
+- [ ] SbD report generated with CISA commitment status and CUI markings
+- [ ] RTM generated with forward and backward trace, gap analysis
+- [ ] IV&V assessment completed across all 9 process areas
+- [ ] IV&V certification recommendation generated (CERTIFY/CONDITIONAL/DENY)
+- [ ] IV&V report generated with independence declaration and CUI markings
+- [ ] Audit trail entries logged for all assessments
+- [ ] No critical SbD requirements "not_satisfied"
+- [ ] No critical IV&V findings open
+
+---
+
+## Edge Cases & Notes
+
+1. **SbD is design-level:** SbD checks patterns and architecture, not individual vulnerabilities. A project can pass STIG checks but fail SbD if security wasn't designed in.
+2. **IV&V independence:** Automated IV&V provides process verification. For formal certification, human-independent assessment may also be required per IEEE 1012.
+3. **RTM gaps:** Untested requirements should be flagged as risks, not failures. Some requirements may be non-testable (policy, process).
+4. **Memory safety:** Projects in memory-unsafe languages (C/C++) should have safety tooling (AddressSanitizer, Valgrind). This doesn't block the assessment but generates warnings.
+5. **CISA commitments:** The 7 CISA commitments are aspirational targets. Partial satisfaction is expected for new projects. Track progress over time.
+6. **Certification validity:** IV&V certifications expire after 12 months per `args/project_defaults.yaml`. Re-assessment required after significant changes.
+
+---
+
+## GOTCHA Layer Mapping
+
+| Step | GOTCHA Layer | Component |
+|------|-------------|-----------|
+| SbD assessment | Tools | sbd_assessor.py |
+| SbD report | Tools | sbd_report_generator.py |
+| RTM generation | Tools | traceability_matrix.py |
+| IV&V assessment | Tools | ivv_assessor.py |
+| IV&V report | Tools | ivv_report_generator.py |
+| Sequence decisions | Orchestration | AI (you) |
+| SbD requirements | Context | cisa_sbd_requirements.json |
+| IV&V requirements | Context | ivv_requirements.json |
+| Gate thresholds | Args | security_gates.yaml |
+
+---
+
+## Related Files
+
+- **Tools:** `tools/compliance/sbd_assessor.py`, `tools/compliance/sbd_report_generator.py`, `tools/compliance/traceability_matrix.py`, `tools/compliance/ivv_assessor.py`, `tools/compliance/ivv_report_generator.py`
+- **Context:** `context/compliance/cisa_sbd_requirements.json`, `context/compliance/ivv_requirements.json`, `context/compliance/sbd_report_template.md`, `context/compliance/ivv_report_template.md`, `context/compliance/ivv_checklist_template.md`
+- **Args:** `args/project_defaults.yaml` (sbd + ivv sections), `args/security_gates.yaml` (sbd + ivv thresholds)
+- **Hard Prompts:** `hardprompts/compliance/sbd_assessment.md`, `hardprompts/compliance/ivv_assessment.md`
+- **Feeds from:** `goals/security_scan.md` (SAST findings), `goals/tdd_workflow.md` (test coverage)
+- **Feeds into:** `goals/compliance_workflow.md` (compliance scoring), `goals/deploy_workflow.md` (deployment gate)
+
+---
+
+## Changelog
+
+- 2026-02-15: Initial creation (Phase 15)

icdev/data/goals/security_categorization.md

@@ -0,0 +1,133 @@
+# Goal: Security Categorization (FIPS 199 / FIPS 200)
+
+**CUI // SP-CTI**
+
+## Description
+
+Perform system security categorization per FIPS 199 using NIST SP 800-60 information types, validate minimum security requirements per FIPS 200, and dynamically select the appropriate NIST 800-53 baseline. For IL6/SECRET national security systems, apply CNSSI 1253 overlays.
+
+**Why this matters:** FIPS 199 categorization is Step 1 of the NIST Risk Management Framework (RMF). Everything downstream — SSP, control selection, baselines, FedRAMP, CMMC — depends on correct categorization. An incorrect categorization means wrong controls = failed ATO.
+
+## Prerequisites
+
+- Project initialized (`goals/init_project.md` completed)
+- ICDEV database initialized (`python tools/db/init_icdev_db.py`)
+- NIST SP 800-60 catalog exists (`context/compliance/nist_sp_800_60_types.json`)
+
+## Process
+
+### Step 1: Browse Information Type Catalog
+
+**Tool:** `python tools/compliance/fips199_categorizer.py --list-catalog`
+
+Review the NIST SP 800-60 Vol 2 information type catalog. Filter by category:
+- `--category D.1` — Services Delivery (defense, health, education, law enforcement, etc.)
+- `--category D.2` — Government Resource Management (admin, finance, HR, IT)
+- `--category D.3` — Internal Risk Management (regulatory, public affairs, budget)
+
+Identify which information types the system processes, stores, or transmits.
+
+### Step 2: Assign Information Types to Project
+
+**Tool:** `python tools/compliance/fips199_categorizer.py --project-id <id> --add-type D.x.x.x`
+
+Add each relevant information type. Each type has provisional CIA impact levels from SP 800-60.
+
+**Optional adjustments:** If organizational factors require deviation from provisional levels:
+```bash
+python tools/compliance/fips199_categorizer.py --project-id <id> --add-type D.2.3.4 \
+    --adjust-c High --adjustment-justification "PII payroll data requires elevated confidentiality"
+```
+
+**Key rules:**
+- Adjustments must have written justification
+- Adjustments can only raise impact levels, not lower below provisional (organizational policy)
+- Multiple types can be assigned — the watermark takes the highest across all types
+
+### Step 3: Run FIPS 199 Categorization
+
+**Tool:** `python tools/compliance/fips199_categorizer.py --project-id <id> --categorize --json`
+
+This computes:
+1. **High watermark** across all assigned information types for each CIA objective
+2. **Overall categorization** = max(Confidentiality, Integrity, Availability)
+3. **CNSSI 1253 overlay** automatically applied for IL6/SECRET systems
+4. **Baseline selection** = overall categorization maps to NIST 800-53 baseline
+
+**Output:** SC {system_name} = {(confidentiality, impact), (integrity, impact), (availability, impact)}
+
+**Alternative methods:**
+- `--method manual --manual-c High --manual-i High --manual-a Moderate` — Manual categorization with justification
+- `--method cnssi_1253` — Force CNSSI 1253 overlay for national security systems
+
+### Step 4: Validate FIPS 200 Minimum Security Requirements
+
+**Tool:** `python tools/compliance/fips200_validator.py --project-id <id> --json`
+
+Checks all 17 minimum security requirement areas against the baseline from Step 3:
+- AC, AT, AU, CA, CM, CP, IA, IR, MA, MP, PE, PL, PS, RA, SA, SC, SI
+
+For each area, verifies that required NIST 800-53 controls are mapped in `project_controls`.
+
+**Gate evaluation:** `--gate` flag checks for 0 not_satisfied areas.
+
+### Step 5: Generate SSP with Dynamic Baseline
+
+**Tool:** `python tools/compliance/ssp_generator.py --project <id>`
+
+The SSP now auto-reads the categorization from the database:
+- Section 2: Actual C/I/A impact levels (not hardcoded "Moderate")
+- Section 12: Correct NIST 800-53 applicability statement with baseline
+- Section 13: Dynamic control baseline matching categorization
+- Section 15: All 17 FIPS 200 families included
+
+### Step 6: Review and Approve
+
+Categorization starts as "draft". The Authorizing Official (AO) reviews and approves:
+1. Verify information types are correct and complete
+2. Verify impact adjustments have justification
+3. Verify CNSSI 1253 overlay applied if applicable (IL6/SECRET)
+4. Verify baseline is appropriate for system risk profile
+
+## Error Handling
+
+| Error | Resolution |
+|-------|-----------|
+| No information types assigned | Review SP 800-60 catalog; assign at least one type |
+| All impacts are "N/A" | Invalid — at least one type must have Low/Moderate/High |
+| IL6 project without CNSSI 1253 | Gate fails — must apply overlay or change method to cnssi_1253 |
+| Manual categorization without justification | Warning — require `--justification` flag |
+| Stale categorization (>30 days draft) | Warning — categorization should be approved |
+
+## Verify
+
+```bash
+# Categorization stored in DB
+python tools/compliance/fips199_categorizer.py --project-id <id> --json
+
+# Projects table updated
+sqlite3 data/icdev.db "SELECT fips199_overall, fips199_confidentiality, fips199_integrity, fips199_availability FROM projects WHERE id='<id>'"
+
+# SSP reflects actual categorization
+python tools/compliance/ssp_generator.py --project <id>
+grep "Overall.*Categorization" projects/<id>/docs/compliance/ssp_*.md
+
+# FIPS 200 coverage
+python tools/compliance/fips200_validator.py --project-id <id> --json
+
+# Audit trail
+python tools/audit/audit_query.py --project <id> --type fips199_categorized
+```
+
+## Related Goals
+
+- `goals/compliance_workflow.md` — SSP generation (now uses dynamic baseline)
+- `goals/ato_acceleration.md` — Multi-framework ATO (categorization drives baselines)
+- `goals/init_project.md` — Project initialization
+
+## Architecture Decisions
+
+- **D30:** FIPS 199 uses high watermark across information types; SP 800-60 provisionals are defaults, adjustable per organization
+- **D31:** FIPS 200 validates all 17 minimum security areas against baseline from FIPS 199, not impact level alone
+- **D32:** SSP baseline selection is dynamic: query DB for categorization first, fall back to IL mapping
+- **D33:** CNSSI 1253 auto-applies for IL6/SECRET systems; elevates minimum C/I/A floor per overlay rules