icdev 1.0.0__py3-none-any.whl

icdev/data/docs/features/phase-49-ai-accountability.md

@@ -0,0 +1,243 @@
+# Phase 49 — AI Accountability
+
+**CUI // SP-CTI**
+
+| Field | Value |
+|-------|-------|
+| Phase | 49 |
+| Title | AI Accountability |
+| Status | Implemented |
+| Priority | P1 |
+| Dependencies | Phase 48 (AI Transparency), Phase 46 (Observability, Traceability & XAI), Phase 37 (MITRE ATLAS Integration) |
+| Author | ICDEV Architect Agent |
+| Date | 2026-02-23 |
+
+---
+
+## 1. Problem Statement
+
+Phase 48 delivers transparency artifacts -- model cards, system cards, AI inventories, and framework assessors -- but transparency alone is insufficient. Federal AI mandates require accountability: designated responsible officials, human oversight plans, appeal mechanisms for AI-affected decisions, ethics review processes, incident response procedures, and scheduled reassessments.
+
+OMB M-25-21 mandates that agencies designate a Chief AI Officer (CAIO) responsible for AI governance. OMB M-26-04 requires ongoing monitoring with scheduled reassessments and documented incident response. GAO-21-519SP demands accountability structures including appeal mechanisms for AI decisions that affect individual rights. NIST AI RMF Govern 1.3 requires defined roles and responsibilities, while Govern 4.1 mandates organizational processes for AI incident response.
+
+Without accountability tooling, ICDEV cannot enforce oversight plans for its agentic workflows, track CAIO designations per project, provide appeal channels for AI-affected decisions, conduct structured ethics reviews, log and respond to AI incidents, or schedule periodic reassessments. The four Phase 48 assessors also require hardening -- their initial checks used placeholder evidence; Phase 49 replaces these with real database queries across 14 checks spanning all four assessors.
+
+Phase 49 delivers six accountability capabilities: oversight plan management with role assignments, CAIO designation registry, appeal tracking for rights-impacting AI decisions, structured ethics reviews, AI incident response logging and management, and reassessment scheduling with automated due-date tracking. It also hardens all four Phase 48 assessors to perform real DB-backed checks, and exposes everything through dashboard, portal, REST API, MCP tools, and a dedicated security gate.
+
+---
+
+## 2. Goals
+
+1. Manage AI oversight plans with role assignments, escalation paths, and human-in-the-loop requirements per project and use case
+2. Maintain a CAIO designation registry tracking responsible officials, their authority scope, and delegation chains
+3. Track appeals for AI-affected decisions with status lifecycle (submitted, under_review, resolved, escalated) and resolution documentation
+4. Conduct structured ethics reviews with multi-reviewer workflows, scoring rubrics, and version-tracked review artifacts
+5. Log and manage AI incidents with severity classification, root cause analysis, remediation tracking, and lessons learned
+6. Schedule and enforce periodic reassessments with automated due-date tracking and overdue alerting
+7. Harden 14 assessor checks across OMB M-25-21, OMB M-26-04, NIST AI 600-1, and GAO-21-519SP with real DB queries replacing placeholder evidence
+8. Assess cross-framework accountability posture through a unified audit that identifies gaps across all mandates
+9. Expose accountability data through dashboard (/ai-accountability), portal (/portal/ai-accountability), REST API (/api/v1/ai-accountability/*), and MCP tools
+
+---
+
+## 3. Architecture
+
+```
+                     AI Accountability Stack
+            ┌────────────────────────────────────┐
+            │    Cross-Framework Accountability   │
+            │         Audit (unified)             │
+            │  (ai_accountability_audit.py)       │
+            └────────────────┬───────────────────┘
+                             │
+       ┌──────────┬──────────┼──────────┬──────────┐
+       ↓          ↓          ↓          ↓          ↓
+  OMB M-25-21  OMB M-26-04  NIST AI  GAO-21-519SP │
+  (hardened    (hardened     600-1    (hardened     │
+   DB checks)  DB checks)  (hardened  DB checks)   │
+       │          │        DB checks)     │        │
+       └──────────┴──────────┼──────────┴──────────┘
+                             │
+       ┌──────────┬──────────┼──────────┬──────────┐
+       ↓          ↓          ↓          ↓          ↓
+  Oversight   CAIO        Appeal     Ethics     Incident
+  Plans       Registry    Tracking   Reviews    Response
+  (ai_over-   (ai_caio_  (ai_ac-    (ai_eth-   (ai_inci-
+  sight_       registry)  countab-   ics_       dent_log)
+  plans)                  ility_     reviews)
+                          appeals)
+       │          │          │          │          │
+       └──────────┴──────────┼──────────┴──────────┘
+                             │
+                    Reassessment Scheduler
+                  (ai_reassessment_schedule)
+                    automated due-date
+                    tracking + alerting
+                             │
+       ┌─────────────────────┼─────────────────────┐
+       ↓                     ↓                      ↓
+  /ai-accountability    REST API              MCP Tools
+  (dashboard + portal)  /api/v1/ai-           (unified gateway)
+                        accountability/*
+```
+
+Oversight plans define human-in-the-loop checkpoints within agentic workflows. Each plan specifies which decisions require human approval, the escalation path when approval is denied, and the roles authorized to approve. The CAIO registry tracks designated officials per project with authority scope (project-level, program-level, or agency-level) and delegation chains. Appeals follow a four-state lifecycle and are linked to specific AI decisions via trace IDs from Phase 46 provenance tracking.
+
+The reassessment scheduler maintains a calendar of required periodic reviews. When a reassessment comes due, it triggers notifications through the heartbeat daemon (Phase 29) and blocks the accountability security gate until the reassessment is completed.
+
+---
+
+## 4. Database Schema
+
+| Table | Purpose |
+|-------|---------|
+| `ai_oversight_plans` | Oversight plan storage — plan_id, project_id, use_case_id, plan_name, roles (JSON), escalation_path (JSON), hitl_checkpoints (JSON), approval_required, status (active/draft/archived), created_at, created_by, version |
+| `ai_caio_registry` | CAIO designation tracking — designation_id, project_id, official_name, official_email, authority_scope (project/program/agency), delegation_chain (JSON), effective_date, expiry_date, status (active/expired/revoked) |
+| `ai_accountability_appeals` | Appeal tracking — appeal_id, project_id, decision_trace_id, appellant, reason, status (submitted/under_review/resolved/escalated), reviewer, resolution, resolution_date, created_at |
+| `ai_ethics_reviews` | Ethics review records — review_id, project_id, use_case_id, reviewer_id, review_type (initial/periodic/incident_triggered), score (JSON rubric), findings, recommendations, status (pending/in_progress/completed/requires_changes), version, created_at |
+| `ai_incident_log` | AI incident tracking — incident_id, project_id, severity (critical/high/medium/low), title, description, root_cause, affected_systems (JSON), remediation_status (open/investigating/mitigated/resolved/closed), lessons_learned, reported_by, reported_at, resolved_at |
+| `ai_reassessment_schedule` | Reassessment scheduling — schedule_id, project_id, assessment_type, frequency_days, last_completed, next_due, status (on_track/due/overdue), assigned_to, created_at |
+
+---
+
+## 5. Tools
+
+| Tool | Purpose |
+|------|---------|
+| `tools/compliance/accountability_manager.py` | Oversight plan CRUD — create, update, list, archive plans; CAIO designation management; role assignment with escalation paths |
+| `tools/compliance/ai_incident_response.py` | AI incident lifecycle management — log, investigate, remediate, resolve, close; severity classification; lessons learned extraction |
+| `tools/compliance/ai_reassessment_scheduler.py` | Reassessment scheduling — create schedules, check due dates, trigger notifications, mark completions, overdue alerting |
+| `tools/compliance/ai_impact_assessor.py` | AI impact assessment — evaluate rights-impact and safety-impact dimensions for use cases; generate impact classification for OMB reporting |
+| `tools/compliance/ai_accountability_audit.py` | Cross-framework accountability audit — runs hardened assessor checks, gap analysis across all mandates, unified report generation |
+| `tools/compliance/omb_m25_21_assessor.py` | (Hardened) OMB M-25-21 assessor — real DB checks for CAIO designation, inventory completeness, oversight plans, risk classification |
+| `tools/compliance/omb_m26_04_assessor.py` | (Hardened) OMB M-26-04 assessor — real DB checks for public reporting readiness, monitoring active, reassessment schedule, incident response |
+| `tools/compliance/nist_ai_600_assessor.py` | (Hardened) NIST AI 600-1 assessor — real DB checks for confabulation detection active, fairness assessment current, provenance tracking, content tracing policy |
+| `tools/compliance/gao_ai_assessor.py` | (Hardened) GAO-21-519SP assessor — real DB checks for governance structures, performance monitoring, transparency reporting, accountability mechanisms |
+| `tools/dashboard/api/ai_accountability.py` | Flask API blueprint for /ai-accountability dashboard and REST endpoints |
+| `tools/dashboard/templates/ai_accountability.html` | Dashboard template — oversight plans, CAIO registry, appeal tracker, incident timeline, reassessment calendar |
+
+---
+
+## 6. Assessor Hardening Detail
+
+Phase 49 replaces placeholder evidence in 14 assessor checks with real database queries:
+
+| Assessor | Check ID | Before (Phase 48) | After (Phase 49) |
+|----------|----------|-------------------|-------------------|
+| OMB M-25-21 | M25-001 | Placeholder evidence | Query `ai_use_case_inventory` for completeness |
+| OMB M-25-21 | M25-002 | Placeholder evidence | Query `ai_caio_registry` for active designation |
+| OMB M-25-21 | M25-003 | Placeholder evidence | Query `ai_oversight_plans` for rights-impacting use cases |
+| OMB M-25-21 | M25-004 | Placeholder evidence | Query `ai_use_case_inventory` for risk_classification coverage |
+| OMB M-26-04 | M26-001 | Placeholder evidence | Query `ai_model_cards` for public reporting completeness |
+| OMB M-26-04 | M26-002 | Placeholder evidence | Query `ai_reassessment_schedule` for active schedules |
+| OMB M-26-04 | M26-003 | Placeholder evidence | Query `ai_incident_log` for response procedures documented |
+| NIST AI 600-1 | AI600-001 | Placeholder evidence | Query `ai_confabulation_log` for detection activity |
+| NIST AI 600-1 | AI600-002 | Placeholder evidence | Query `ai_fairness_assessments` for current results |
+| NIST AI 600-1 | AI600-003 | Placeholder evidence | Query `prov_entities`/`prov_relations` for provenance chain |
+| NIST AI 600-1 | AI600-004 | Placeholder evidence | Check `ICDEV_CONTENT_TRACING_ENABLED` env + xai_assessments |
+| GAO | GAO-001 | Placeholder evidence | Query `ai_caio_registry` + `ai_oversight_plans` for governance |
+| GAO | GAO-002 | Placeholder evidence | Query `ai_telemetry` + `ai_fairness_assessments` for monitoring |
+| GAO | GAO-003 | Placeholder evidence | Query `ai_accountability_appeals` for appeal mechanisms |
+
+---
+
+## 7. Architecture Decisions
+
+| ID | Decision | Rationale |
+|----|----------|-----------|
+| D316 | Oversight plans versioned via insert-new-row pattern (no UPDATE) | Consistent with D6 append-only audit; preserves oversight plan history for compliance audits and ATO evidence |
+| D317 | CAIO registry supports delegation chains as JSON array | Federal agencies delegate CAIO authority to program/project levels; JSON captures chain without additional join tables |
+| D318 | Appeals linked to decisions via trace_id from Phase 46 provenance | Provides full traceability from appeal to the specific AI decision, tool calls, and agent that produced it |
+| D319 | Ethics reviews use multi-reviewer scoring rubric stored as JSON | Different organizations use different rubrics; JSON schema allows customization without code changes (D26 pattern) |
+| D320 | Incident response reuses self-healing severity model (critical/high/medium/low) | Consistent with existing self-healing thresholds (Phase 8); operators already understand the severity taxonomy |
+| D321 | Reassessment scheduler integrates with heartbeat daemon (Phase 29) for notifications | Reuses existing notification infrastructure (audit trail + SSE + gateway channels per D163) instead of building separate alerting |
+
+---
+
+## 8. Security Gate
+
+**AI Accountability Gate:**
+- **Blocking:** No active CAIO designation for federal agency projects, oversight plans missing for rights-impacting AI use cases, unresolved critical AI incidents older than SLA (72 hours for critical), appeals in submitted state without reviewer assignment for more than 5 business days
+- **Warning:** Reassessments overdue by more than 30 days, ethics reviews not completed for new use cases, incident response plan not documented, fewer than 80% of assessor checks passing
+- **Thresholds:** caio_required=true (federal projects), oversight_plan_required=true (rights-impacting), critical_incident_sla_hours=72, appeal_assignment_sla_days=5, reassessment_overdue_warning_days=30, min_assessor_coverage_pct=80
+
+---
+
+## 9. Commands
+
+```bash
+# Oversight plans
+python tools/compliance/accountability_manager.py --project-id "proj-123" --create-plan --json
+python tools/compliance/accountability_manager.py --project-id "proj-123" --list-plans --json
+python tools/compliance/accountability_manager.py --project-id "proj-123" --plan-id "<id>" --json
+
+# CAIO designation
+python tools/compliance/accountability_manager.py --project-id "proj-123" --designate-caio \
+  --official-name "Jane Smith" --official-email "jane@agency.gov" --scope agency --json
+python tools/compliance/accountability_manager.py --project-id "proj-123" --caio-status --json
+
+# Appeal tracking
+python tools/compliance/accountability_manager.py --project-id "proj-123" --submit-appeal \
+  --decision-trace-id "<trace-id>" --reason "Incorrect classification" --json
+python tools/compliance/accountability_manager.py --project-id "proj-123" --list-appeals --json
+python tools/compliance/accountability_manager.py --appeal-id "<id>" --resolve \
+  --resolution "Decision reversed" --json
+
+# Ethics reviews
+python tools/compliance/accountability_manager.py --project-id "proj-123" --create-review \
+  --use-case-id "<id>" --reviewer-id "reviewer@mil" --json
+python tools/compliance/accountability_manager.py --project-id "proj-123" --list-reviews --json
+
+# AI incident response
+python tools/compliance/ai_incident_response.py --project-id "proj-123" --log \
+  --severity critical --title "Model hallucination in compliance report" --json
+python tools/compliance/ai_incident_response.py --project-id "proj-123" --list --json
+python tools/compliance/ai_incident_response.py --incident-id "<id>" --investigate --json
+python tools/compliance/ai_incident_response.py --incident-id "<id>" --resolve \
+  --root-cause "Training data gap" --lessons-learned "Add validation step" --json
+
+# Reassessment scheduling
+python tools/compliance/ai_reassessment_scheduler.py --project-id "proj-123" --create \
+  --assessment-type transparency_audit --frequency-days 90 --json
+python tools/compliance/ai_reassessment_scheduler.py --project-id "proj-123" --check-due --json
+python tools/compliance/ai_reassessment_scheduler.py --project-id "proj-123" --mark-complete \
+  --schedule-id "<id>" --json
+python tools/compliance/ai_reassessment_scheduler.py --project-id "proj-123" --overdue --json
+
+# Impact assessment
+python tools/compliance/ai_impact_assessor.py --project-id "proj-123" --use-case-id "<id>" --json
+python tools/compliance/ai_impact_assessor.py --project-id "proj-123" --all --json
+
+# Cross-framework accountability audit
+python tools/compliance/ai_accountability_audit.py --project-id "proj-123" --json
+python tools/compliance/ai_accountability_audit.py --project-id "proj-123" --human --stream
+python tools/compliance/ai_accountability_audit.py --project-id "proj-123" --gate
+
+# Dashboard page: /ai-accountability
+# Portal page: /portal/ai-accountability
+# REST API: GET/POST /api/v1/ai-accountability/oversight-plans
+#            GET/POST /api/v1/ai-accountability/caio
+#            GET/POST /api/v1/ai-accountability/appeals
+#            GET/POST /api/v1/ai-accountability/ethics-reviews
+#            GET/POST /api/v1/ai-accountability/incidents
+#            GET/POST /api/v1/ai-accountability/reassessments
+#            POST /api/v1/ai-accountability/audit
+# MCP tools: accountability_manage, ai_incident_log, ai_reassessment_schedule,
+#            ai_impact_assess, ai_accountability_audit
+# Slash command: /icdev-accountability
+
+# Configuration
+# args/ai_accountability_config.yaml — oversight plan templates, CAIO scope rules,
+#   appeal SLAs, ethics rubrics, incident severity mapping, reassessment frequencies
+# args/security_gates.yaml — ai_accountability gate conditions
+```
+
+---
+
+## 10. Related
+
+- [Phase 48: AI Transparency](phase-48-ai-transparency.md) -- Model cards, AI inventory, framework assessors (hardened by this phase)
+- [Phase 46: Observability, Traceability & XAI](phase-46-observability-traceability-xai.md) -- Trace IDs for appeal linkage, provenance for assessor checks
+- [Phase 29: Proactive Monitoring](phase-29-proactive-monitoring.md) -- Heartbeat daemon for reassessment notifications
+- [Phase 8: Self-Healing](phase-08-self-healing.md) -- Severity model reused for incident classification
+- [Phase 50: AI Governance Integration](phase-50-ai-governance-intake-chat.md) -- Intake and chat integration for governance pillars

icdev/data/docs/features/phase-50-ai-governance-intake-chat.md

@@ -0,0 +1,195 @@
+# Phase 50 — AI Governance Integration (Intake & Chat)
+
+**CUI // SP-CTI**
+
+| Field | Value |
+|-------|-------|
+| Phase | 50 |
+| Title | AI Governance Integration (Intake & Chat) |
+| Status | Implemented |
+| Priority | P1 |
+| Dependencies | Phase 48 (AI Transparency), Phase 49 (AI Accountability), Phase 44 (Innovation Adaptation — chat and extension hooks) |
+| Author | ICDEV Architect Agent |
+| Date | 2026-02-23 |
+
+---
+
+## 1. Problem Statement
+
+Phase 48 and Phase 49 deliver comprehensive AI transparency and accountability tooling -- model cards, AI inventories, framework assessors, oversight plans, incident response, and reassessment scheduling. However, these capabilities exist as standalone tools. They are not woven into the workflows operators actually use: requirements intake sessions and agent chat streams. An operator running a RICOAS intake session for a federal agency project will not discover that OMB M-25-21 applies until they manually run the transparency assessor after intake completes. An operator chatting with the builder agent will not learn that their project lacks a CAIO designation until they separately navigate to the accountability dashboard.
+
+This gap means governance requirements are discovered late, after design decisions have already been made. Late discovery increases rework, delays ATO submissions, and risks non-compliance for projects that should have had governance structures from the start.
+
+Phase 50 closes this gap by integrating AI governance into the two primary operator workflows: requirements intake and agent chat. During intake, keyword detection identifies which of the six governance pillars (transparency, accountability, fairness, safety, explainability, privacy) are relevant and auto-triggers governance probes. Readiness scoring gains a seventh dimension (ai_governance_readiness) alongside the existing five dimensions plus a newly implemented devsecops_readiness dimension. Extension hooks activate built-in handlers to inject governance context. Chat streams display governance advisories and a sidebar showing governance posture. All configuration lives in a single YAML file, no new database tables are required, and a dedicated security gate blocks projects with unaddressed governance gaps.
+
+---
+
+## 2. Goals
+
+1. Detect AI governance-relevant keywords during RICOAS intake sessions and identify applicable governance pillars
+2. Auto-trigger OMB M-25-21 governance requirements for federal agency projects based on intake metadata
+3. Generate governance probe questions for missing pillars to capture requirements early in the intake flow
+4. Add ai_governance_readiness as a seventh dimension to readiness scoring, and implement the previously stubbed devsecops_readiness dimension
+5. Activate built-in extension hook handlers for governance context injection at the pre-LLM and post-tool hook points
+6. Display governance advisory messages in the unified agent chat when AI governance gaps are detected
+7. Render a governance sidebar in the unified chat showing real-time governance posture per project
+8. Consolidate all governance integration configuration into a single `args/ai_governance_config.yaml` file
+9. Reuse existing database tables from Phase 48 and Phase 49 without creating new tables
+
+---
+
+## 3. Architecture
+
+```
+                    AI Governance Integration
+          ┌──────────────────────────────────────┐
+          │        ai_governance_config.yaml      │
+          │   (single config for all integration) │
+          │                                       │
+          │  pillars:                              │
+          │    transparency, accountability,       │
+          │    fairness, safety, explainability,   │
+          │    privacy                             │
+          │  keywords: per-pillar detection terms  │
+          │  probes: per-pillar question templates │
+          │  triggers: agency_type → auto-enable   │
+          └──────────────┬───────────────────────┘
+                         │
+          ┌──────────────┼───────────────────┐
+          ↓              ↓                    ↓
+   Intake Integration  Chat Integration   Extension Hooks
+          │              │                    │
+   keyword detection   governance           built-in handlers
+   pillar mapping      advisory messages    pre-LLM injection
+   probe questions     sidebar posture      post-tool context
+   auto-trigger        gap highlighting
+   (federal agency)
+          │              │                    │
+          ↓              ↓                    ↓
+   Readiness Scorer   Chat Manager         Extension Manager
+   (7 dimensions)     (Phase 44)           (Phase 44)
+   +ai_governance     advisory as           handler activation
+   +devsecops         system message        via hook points
+          │              │                    │
+          └──────────────┼───────────────────┘
+                         │
+                    Existing DB Tables
+              (Phase 48 + Phase 49 — no new tables)
+          ai_use_case_inventory, ai_model_cards,
+          ai_oversight_plans, ai_caio_registry,
+          ai_reassessment_schedule, ai_fairness_assessments,
+          ai_transparency_assessments, intake_sessions
+```
+
+The integration layer reads `ai_governance_config.yaml` at startup and registers keyword patterns for each of the six governance pillars. During intake, every customer message is scanned against these patterns. When a pillar is detected, the system records it and generates follow-up probe questions for any pillars that remain unaddressed. Federal agency projects (detected via customer organization metadata or explicit `--agency` flag) automatically trigger OMB M-25-21 requirements without keyword matching.
+
+Chat integration works through the Phase 44 extension hook system. A built-in governance handler activates at the pre-LLM hook point, querying existing governance tables to determine the project's governance posture. If gaps are found, advisory messages are injected as system-role messages in the chat context. The chat sidebar renders governance posture using the same data, with color-coded status per pillar.
+
+---
+
+## 4. Readiness Scoring (7 Dimensions)
+
+Phase 50 extends the readiness scorer with two new dimensions:
+
+| Dimension | Weight | Source | Status |
+|-----------|--------|--------|--------|
+| completeness | 0.25 | Intake requirements coverage | Existing |
+| clarity | 0.20 | Ambiguity and gap detection | Existing |
+| feasibility | 0.20 | Technical feasibility signals | Existing |
+| compliance | 0.15 | NIST control coverage | Existing |
+| testability | 0.10 | BDD criteria coverage | Existing |
+| devsecops_readiness | 0.05 | DevSecOps profile maturity, pipeline security stages | New (D323) |
+| ai_governance_readiness | 0.05 | Governance pillar coverage, oversight plans, CAIO designation | New (D323) |
+
+The ai_governance_readiness score is computed as a weighted average of: pillar coverage (how many of the 6 applicable pillars are addressed), oversight plan presence (for rights-impacting use cases), CAIO designation (for federal projects), and model card completeness (for projects using AI models). The devsecops_readiness score queries the `devsecops_profiles` table for maturity level and the `devsecops_pipeline_audit` table for pipeline security stage coverage.
+
+---
+
+## 5. Extension Hook Handlers
+
+Phase 50 activates built-in governance handlers through the Phase 44 extension hook system:
+
+| Hook Point | Handler | Behavior |
+|------------|---------|----------|
+| `pre_llm_call` | `governance_context_injector` | Queries governance tables; injects system message with governance posture summary and any blocking gaps |
+| `post_tool_call` | `governance_posture_updater` | After compliance/transparency tools run, refreshes cached governance posture for the chat sidebar |
+
+Handlers are registered as built-in extensions (not external plugin files) and are activated when `ai_governance_config.yaml` sets `integration.enabled: true`. They follow the Phase 44 behavioral tier (they modify chat context), have a maximum execution time of 5 seconds per the Phase 44 safety limits, and are isolated by the existing exception handling so that handler failures do not interrupt the chat flow.
+
+---
+
+## 6. Chat Governance Advisory
+
+When an agent chat stream is active for a project with AI components, the governance advisory system:
+
+1. Queries existing tables (`ai_use_case_inventory`, `ai_oversight_plans`, `ai_caio_registry`, `ai_transparency_assessments`) at chat context initialization
+2. Computes a per-pillar status: **covered** (requirements captured + assessor passing), **partial** (requirements captured, assessor not yet run or failing), **missing** (no requirements captured)
+3. Injects an advisory system message when any pillar is missing or partial, formatted as: "AI Governance Advisory: [pillar] requirements not yet addressed. Consider running /icdev-transparency or /icdev-accountability."
+4. Renders a sidebar panel (visible in `/chat` dashboard page) showing all six pillars with color-coded status indicators
+
+Advisory messages are non-blocking -- they inform the operator but do not prevent chat continuation. The security gate (section 7) is the enforcement mechanism.
+
+---
+
+## 7. Security Gate
+
+**AI Governance Gate:**
+- **Blocking:** Federal agency project without OMB M-25-21 assessment initiated, rights-impacting use cases without oversight plan, ai_governance_readiness score below 0.3 for projects with AI components, all six governance pillars unaddressed for projects flagged as AI-dependent
+- **Warning:** ai_governance_readiness below 0.5, fewer than 4 of 6 pillars addressed, devsecops_readiness below 0.3, governance advisory dismissed without action more than 3 times
+- **Thresholds:** min_ai_governance_readiness=0.30, min_pillar_coverage=1 (at least 1 pillar addressed to unblock), federal_omb_assessment_required=true, oversight_plan_required=true (rights-impacting)
+
+---
+
+## 8. Architecture Decisions
+
+| ID | Decision | Rationale |
+|----|----------|-----------|
+| D322 | Six governance pillars (transparency, accountability, fairness, safety, explainability, privacy) defined in ai_governance_config.yaml with per-pillar keywords | Declarative keyword patterns enable intake detection without LLM; add/remove pillars without code changes (D26 pattern) |
+| D323 | Readiness scoring extended to 7 dimensions; devsecops_readiness now implemented (was stubbed) | Both dimensions share the weighted-average pattern from D21; weights kept low (0.05 each) to avoid disrupting existing readiness thresholds |
+| D324 | Extension hooks use built-in handlers (not external plugin files) for governance | Governance is a core ICDEV capability, not a tenant extension; built-in handlers avoid file I/O overhead and cannot be accidentally deleted |
+| D325 | Handlers activated via config flag (integration.enabled) not code change | Consistent with D44 flag-based backward compatibility; omitting the flag produces identical behavior to pre-Phase 50 |
+| D326 | Governance sidebar in chat renders from cached posture (refreshed by post_tool_call hook) | Avoids per-message DB queries; posture changes infrequently (only after compliance tool runs), so cache invalidation on tool completion is sufficient |
+| D327 | Advisory messages injected as system-role messages (not user-role) | System messages are non-interruptive in the chat flow; they inform the LLM context without appearing as user commands |
+| D328 | Single config file (ai_governance_config.yaml) for all integration settings | Operators configure pillar keywords, probe templates, auto-triggers, readiness weights, and hook activation in one place; consistent with single-file config pattern used by other phases |
+| D329 | No new database tables -- reuses Phase 48 and Phase 49 tables | All governance data already exists in ai_use_case_inventory, ai_oversight_plans, ai_caio_registry, ai_transparency_assessments, ai_fairness_assessments, ai_reassessment_schedule; integration layer is read-only against these tables |
+| D330 | Security gate (ai_governance) is separate from ai_transparency and ai_accountability gates | Integration-level gate checks cross-cutting posture (pillar coverage, readiness score) that cannot be captured by individual framework gates |
+
+---
+
+## 9. Commands
+
+```bash
+# Governance integration is automatic during intake and chat when enabled.
+# Manual commands for testing and inspection:
+
+# Check governance pillar detection for text
+python tools/requirements/intake_engine.py --session-id "<id>" --message "We need fairness testing for our AI classifier" --json
+# (governance pillars detected in response metadata)
+
+# Check readiness with governance dimension
+python tools/requirements/readiness_scorer.py --session-id "<id>" --json
+# (response includes ai_governance_readiness and devsecops_readiness dimensions)
+
+# Run governance gate check
+python tools/compliance/ai_transparency_audit.py --project-id "proj-123" --gate
+python tools/compliance/ai_accountability_audit.py --project-id "proj-123" --gate
+# (ai_governance gate is evaluated as part of multi-regime assessment)
+
+# Chat with governance advisory (start dashboard, navigate to /chat)
+python tools/dashboard/app.py
+# Governance sidebar and advisory messages appear automatically for AI projects
+
+# Configuration
+# args/ai_governance_config.yaml — pillar definitions, keywords, probe templates,
+#   auto-triggers, readiness weights, hook activation, sidebar settings
+# args/security_gates.yaml — ai_governance gate conditions
+```
+
+---
+
+## 10. Related
+
+- [Phase 48: AI Transparency](phase-48-ai-transparency.md) -- Model cards, AI inventory, framework assessors queried by governance integration
+- [Phase 49: AI Accountability](phase-49-ai-accountability.md) -- Oversight plans, CAIO registry, incident response queried by governance integration
+- [Phase 44: Innovation Adaptation](phase-44-innovation-adaptation.md) -- Chat manager and extension hook system used for governance injection
+- [Phase 29: Proactive Monitoring](phase-29-proactive-monitoring.md) -- Heartbeat daemon for reassessment due-date notifications