icdev 0.0.3__py3-none-any.whl

docs/research/ai-architecture-patterns-2024-2026.md

@@ -0,0 +1,1236 @@
+# AI System Architecture Patterns Research Report (2024-2026)
+## Applicable to ICDEV: Multi-Agent Compliance Automation Platform for DoD/Federal Programs
+
+**Date:** 2026-03-08
+**Classification:** CUI // SP-CTI
+
+---
+
+## Table of Contents
+
+1. [Multi-Agent System (MAS) Architecture Patterns](#1-multi-agent-system-mas-architecture-patterns)
+2. [RAG (Retrieval-Augmented Generation) Architecture](#2-rag-retrieval-augmented-generation-architecture)
+3. [LLM Orchestration Patterns](#3-llm-orchestration-patterns)
+4. [AI Safety & Governance Architecture](#4-ai-safety--governance-architecture)
+5. [Edge-Cloud AI Architecture](#5-edge-cloud-ai-architecture)
+6. [Compliance-as-Code Architecture](#6-compliance-as-code-architecture)
+7. [Summary: Top 10 Architecture Recommendations](#summary-top-10-architecture-recommendations-for-icdev)
+8. [Sources](#sources)
+
+---
+
+## 1. Multi-Agent System (MAS) Architecture Patterns
+
+### 1.1 Google A2A (Agent-to-Agent) Protocol
+
+The A2A protocol, launched by Google in April 2025 and now governed by the Linux Foundation, has become the emerging standard for inter-agent communication. It has support from 50+ technology partners including Atlassian, Salesforce, SAP, ServiceNow, and Langchain. The protocol is built on HTTP, SSE, and JSON-RPC 2.0.
+
+**Core Capabilities:**
+
+- **Agent Cards**: JSON descriptors published at `/.well-known/agent.json` advertising capabilities, endpoints, authentication requirements, and access policies. These are exchanged during agent handshake processes, allowing autonomous entities to negotiate collaboration terms before executing tasks.
+- **Task Lifecycle**: Defined states (submitted, working, input-required, completed, failed) with streaming updates via Server-Sent Events.
+- **Capability Discovery**: Agents query one another to identify which tools, actions, or processes are best suited for a request.
+- **User Experience Negotiation**: Adapts to different UI capabilities across agents.
+
+**V0.2 Specification Updates (Late 2025):**
+
+- Stateless interaction mode for simpler development scenarios where session management is not needed.
+- Standardized authentication based on an OpenAPI-like schema ensuring clear communication of authentication requirements across agents.
+- gRPC transport support alongside HTTP for lower-latency scenarios.
+- Security card signing for verifiable agent identity.
+- Extended client-side support in the Python SDK.
+
+**Governance:** In 2025, A2A was donated to the Linux Foundation as the open-source Agent2Agent project. Under Linux Foundation governance, A2A remains vendor-neutral with inclusive contributions and a focus on extensibility, security, and real-world usability across industries.
+
+**ICDEV Applicability:** ICDEV already uses Agent Cards and JSON-RPC 2.0 over mTLS for its 12-agent architecture. The current implementation predates the formal spec. Recommended actions:
+
+- Migrate Agent Cards from the current custom format to the standardized v0.2 JSON schema with `authentication`, `capabilities`, and `skills` fields.
+- Add gRPC support alongside existing HTTP+mTLS for lower-latency intra-cluster communication between the Orchestrator, Builder, and Compliance agents.
+- Implement the formal task lifecycle state machine to replace ad-hoc task status tracking in agent_tasks table.
+- Register ICDEV agents with the Linux Foundation A2A registry for ecosystem discoverability.
+
+---
+
+### 1.2 Anthropic MCP (Model Context Protocol)
+
+MCP has reached massive adoption: 97+ million monthly SDK downloads across all languages and 10,000+ production MCP servers by December 2025. The architecture draws from the Language Server Protocol (LSP), using JSON-RPC 2.0 messages over various transports (STDIO, HTTP) for stateful client-server conversations.
+
+**November 2025 Spec Revision (Major Update):**
+
+- **Asynchronous operations** for long-running tools.
+- **Stateless mode** alongside the original stateful sessions.
+- **Server identity and authentication** -- critical for enterprise and federal use cases.
+- **Official community-driven registry** for discovering MCP servers.
+
+**December 2025:** Anthropic donated MCP to the newly formed Agentic AI Foundation (AAIF) under the Linux Foundation.
+
+**Critical Production Pattern -- Code Execution with MCP:** Most MCP clients load all tool definitions upfront directly into context, but agents scale significantly better by writing code to call tools instead. Code execution with MCP enables agents to use context more efficiently by:
+
+- Loading tools on demand rather than injecting all definitions.
+- Filtering data before it reaches the model.
+- Executing complex logic in a single step.
+
+**ICDEV Applicability:** ICDEV runs 12 MCP servers exposing 80+ tools. Current architecture injects all tool definitions into context. Recommended actions:
+
+- Implement lazy tool loading in the Orchestrator -- load tool definitions on-demand based on the declared session purpose rather than injecting all 80+ tools.
+- Add MCP server identity verification using the new spec's authentication primitives, aligning with ICDEV's IL4 security posture.
+- Evaluate publishing ICDEV's compliance MCP servers to the AAIF registry as discoverable compliance tooling for the federal ecosystem.
+- Adopt the async operations spec for long-running tools like Monte Carlo simulations and SBOM generation.
+
+---
+
+### 1.3 A2A + MCP Complementary Architecture
+
+The industry consensus is that MCP and A2A are complementary, not competing. MCP is for capability/context injection into a single agent. A2A is for coordination between autonomous agents. The mental model: A2A handles coordination between autonomous actors, while MCP handles capability/context injection into a single actor.
+
+**Architecture Diagram (C4 Context Level):**
+
+```
+System Context: ICDEV Multi-Agent Platform
+
+[External User / Operator]
+    |
+    v
+[ICDEV Orchestrator Agent (Port 9443)]
+    |
+    |-- A2A Protocol (JSON-RPC 2.0, mTLS, Agent Cards) -->
+    |       |
+    |       |-- [Compliance Agent (9446)]
+    |       |       |-- MCP (stdio) --> ssp_generate, stig_check, sbom_generate,
+    |       |       |                   control_map, nist_lookup, cui_mark, crosswalk
+    |       |
+    |       |-- [Security Agent (9447)]
+    |       |       |-- MCP (stdio) --> sast_scan, dep_audit, secret_detect,
+    |       |       |                   container_scan, prompt_injection_detect
+    |       |
+    |       |-- [Builder Agent (9445)]
+    |       |       |-- MCP (stdio) --> scaffold, generate_code, write_tests,
+    |       |       |                   run_tests, lint, format
+    |       |
+    |       |-- [Requirements Agent (9453)]
+    |       |       |-- MCP (stdio) --> create_intake, process_turn, detect_gaps,
+    |       |       |                   score_readiness, decompose_requirements
+    |       |
+    |       |-- [Architect Agent (9444)]
+    |       |       |-- MCP (stdio) --> design_system, decompose, interface_contract
+    |       |
+    |       |-- [Devsecops_ZTA Agent (9457)]
+    |       |       |-- MCP (stdio) --> zta_maturity_score, pipeline_security_generate,
+    |       |       |                   policy_generate, service_mesh_generate
+    |       |
+    |       |-- [Simulation Agent (9455)]
+    |       |       |-- MCP (stdio) --> create_scenario, run_simulation,
+    |       |       |                   run_monte_carlo, generate_coas
+    |       |
+    |       |-- [Supply Chain Agent (9454)]
+    |       |       |-- MCP (stdio) --> build_dependency_graph, assess_scrm,
+    |       |       |                   triage_cve, manage_isa
+    |       |
+    |       |-- [Connector Forge Agent (9458)]
+    |       |       |-- MCP (stdio) --> forge_from_spec, forge_validate,
+    |       |       |                   forge_promote, forge_publish
+    |       |
+    |       |-- [Knowledge Agent (9449)]
+    |       |       |-- MCP (stdio) --> search_knowledge, add_pattern,
+    |       |       |                   get_recommendations, self_heal
+    |       |
+    |       |-- [Monitor Agent (9450)]
+    |               |-- MCP (stdio) --> log_analyze, health_check,
+    |                                   metrics_query, alert_manage
+    |
+    |-- A2A Protocol --> [Ops MCP Server (18 tools)]
+            |-- runbook_list, runbook_execute, metastore_list_apps,
+            |   metastore_dependencies, ops_query_zones, ops_query_siem, ...
+
+External Systems:
+    [AWS GovCloud (us-gov-west-1)] <-- Bedrock, SageMaker, S3
+    [PostgreSQL (Supabase)] <-- Primary DB backend
+    [Ollama (Local)] <-- qwen3.5, phi4-reasoning, llava:13b
+```
+
+---
+
+### 1.4 Agent Topology Patterns
+
+Research from 2025 identifies three dominant patterns with a strong trend toward hybridization.
+
+**Supervisor/Orchestrator Pattern (ICDEV's current architecture):**
+
+- A central "boss" agent delegates to "worker" agents with private workspaces. Only final outputs are shared upward.
+- The Supervisor owns orchestration logic, decides agent order, allocates information budgets, and synthesizes partial results.
+- Strengths: Clear control flow, deterministic routing, complete audit trail, straightforward debugging.
+- Weaknesses: Single point of failure, bottleneck at high fan-out, every sub-agent reports through the same chain.
+
+**Swarm/Decentralized Pattern:**
+
+- Each agent runs its own sense-decide-act loop. Communication is local. Global behavior emerges from repeated local updates across the swarm.
+- Decentralized control allows large populations. Failure of some agents degrades performance gradually instead of collapsing the system.
+- Agents influence each other by sharing partial results, proposing next steps, or negotiating responsibilities.
+- Requires strong convergence mechanisms and clear rules about shared state and termination.
+- Strengths: Fault tolerance, scalability, resilience.
+- Weaknesses: Harder to audit, convergence not guaranteed, difficult to reason about emergent behavior.
+
+**Hierarchical/Layered Pattern:**
+
+- Three canonical layers: Strategy (leader/orchestrator), Planning (subtask decomposition), Execution (specialized workers).
+- Static hierarchies simplify mental models but struggle as task complexity and agent quantity grow.
+- The Puppeteer framework (Dang et al., 2025) uses reinforcement-learned orchestration to dynamically decide which agent to invoke next and can skip branches that add little value -- departing from static tree structures.
+
+**Hybrid Trend (2025-2026):**
+
+Sun et al. (2025) identify "hybridization of hierarchical and decentralized mechanisms" as the crucial strategy for scalability while maintaining adaptability. Production systems increasingly combine patterns: hierarchical control within each agent group, coordinated through a swarm layer across groups.
+
+**ICDEV Applicability:** The current supervisor pattern is correct for compliance workloads where audit trail and determinism are required (NIST AU controls). Recommended hybrid extension:
+
+- Keep the Orchestrator as supervisor for compliance/security workflows (audit trail mandatory).
+- Add a swarm coordination layer for simulation and analytics agents (Monte Carlo, DORA metrics, scorecard computation) where parallel independent execution is natural and graceful degradation is acceptable.
+- Implement Puppeteer-style dynamic branch skipping in the ATLAS workflow -- avoid running all 5 phases when only specific phases are needed (e.g., skip Architect phase for minor code changes that only need Assemble + Stress_test).
+
+---
+
+### 1.5 LangGraph State Machine Patterns
+
+LangGraph models agent workflows as state machine graphs where nodes are processing steps and edges define control flow. It is battle-tested by companies including Uber, LinkedIn, and Klarna.
+
+**Core Architectural Concepts:**
+
+- **Directed graph**: Nodes are processing functions, edges define transitions. Supports cycles (iterative loops), conditional routing, and parallel branches.
+- **Centralized state**: A shared state object accessible to all nodes for reading and updating. State is first-class, not an afterthought.
+- **Conditional branching**: Edges evaluate current state to determine next node. Enables dynamic workflow routing based on intermediate results.
+- **Persistent checkpointing**: State is serialized at each node, enabling time-travel debugging, workflow resumption after interruption, and rollback to prior states with adjusted parameters.
+- **Parallel execution**: Independent nodes run simultaneously. LangGraph ensures synchronization so downstream nodes wait until all parallel branches complete.
+
+**Workflow Patterns:**
+
+- Sequential: Linear A -> B -> C pipelines.
+- Fan-out/Fan-in: Parallel execution with synchronization barrier.
+- Cyclic: Iterative refinement loops (agent retries until quality threshold met).
+- Conditional: Route to different subgraphs based on classification or state evaluation.
+- Human-in-the-loop: Pause execution at designated nodes, wait for human input, resume.
+
+**ICDEV Applicability:** ICDEV's ATLAS workflow and TDD cycle are natural state machine candidates:
+
+- Model ATLAS phases (M-Model -> Architect -> Trace -> Link -> Assemble -> Stress_test) as explicit state graph nodes with conditional edges (skip M-Model if no SysML/ReqIF files detected).
+- Add persistent checkpointing at each ATLAS phase boundary for workflow resumability -- currently sessions break if interrupted mid-workflow.
+- Model TDD as a cyclic graph: RED (write failing test) -> GREEN (make test pass) -> REFACTOR (clean up) -> evaluate (more tests needed?) -> RED or DONE.
+- Enable parallel branches within Assemble phase: unit tests, BDD tests, SAST scans, and dependency audits can run concurrently with a synchronization barrier before Stress_test.
+
+---
+
+### 1.6 Microsoft AutoGen and CrewAI Patterns
+
+**AutoGen (now Microsoft Agent Framework):**
+
+- Treats complex workflows as dialogues among multiple agents. Each agent can send and receive messages to drive tasks forward.
+- Supports sequential (linear), concurrent (parallel), and conversational (open-ended dialogue) patterns.
+- In October 2025, Microsoft merged AutoGen with Semantic Kernel into a unified Microsoft Agent Framework, with general availability targeting Q1 2026 with production SLAs, multi-language support (C#, Python, Java), and deep Azure integration.
+
+**CrewAI:**
+
+- Role-based model inspired by organizational structures. Each agent has a clearly defined responsibility.
+- Excels at linear or parallel task execution with role-based agents.
+- Best for production workflows with clear role specialization.
+
+**Selection Guidance for ICDEV:**
+
+- ICDEV's architecture most closely resembles the supervisor/orchestrator model. LangGraph's state machine approach would add formal workflow modeling.
+- CrewAI's role-based model maps well to ICDEV's domain-specific agents (Compliance, Security, Builder each have clear roles).
+- AutoGen's conversational pattern is relevant for RICOAS requirements intake sessions where multi-turn dialogue drives requirements elicitation.
+
+---
+
+## 2. RAG (Retrieval-Augmented Generation) Architecture
+
+### 2.1 Advanced RAG Patterns
+
+Three patterns have matured beyond research into production readiness in 2025-2026:
+
+**Corrective RAG (CRAG):**
+
+- Adds a lightweight retrieval evaluator that assesses the quality of retrieved documents before generation.
+- Three corrective paths: (1) use documents as-is if high confidence, (2) refine query and re-retrieve if ambiguous, (3) fall back to web/broader search if documents are irrelevant.
+- The evaluator enables the system to adaptively respond to incorrect, ambiguous, or irrelevant information, ensuring generated content is more accurate and reliable.
+- Reduces hallucination by 30-40% in benchmarks.
+
+**Self-RAG:**
+
+- The model generates "reflection tokens" that dynamically determine: (a) whether external retrieval is needed, (b) whether retrieved content is relevant, (c) whether the generated response is faithful to the sources.
+- Evaluation is baked into the model through special tokens, not applied as a separate post-processing step.
+- RAG-EVO (EPIA 2025) extended Self-RAG with evolutionary learning and persistent vector memory, achieving 92.6% composite accuracy against Self-RAG, HyDE, and ReAct baselines.
+
+**Adaptive RAG:**
+
+- A trained classifier (originally T5-large in Jeong et al., 2024) routes queries into three complexity tiers:
+  - Simple: Direct retrieval from knowledge base.
+  - Moderate: Query decomposition into sub-queries, each retrieved independently.
+  - Complex: Multi-hop reasoning with parametric knowledge augmentation.
+- By 2026, this router pattern is considered "table stakes" -- every production RAG system should have query routing.
+
+**A-RAG Framework (February 2026, arXiv:2602.03442):**
+
+- Exposes keyword, semantic, and chunk-level retrieval as agent tools directly accessible to the LLM.
+- The agent selects which retrieval strategy to use per query.
+- Improves QA accuracy by 5-13% over flat retrieval approaches.
+
+**Agentic RAG (2025 trend):**
+
+- The LLM acts as an agent that can plan retrieval strategies, evaluate results, and iterate.
+- Combines tool use (retrieval as a tool) with self-reflection (evaluate retrieval quality) and planning (multi-step retrieval strategies).
+- Self-correcting: if initial retrieval fails, the agent reformulates queries, tries different sources, or synthesizes from partial results.
+
+**ICDEV Applicability:** ICDEV already implements hybrid search (0.7 * BM25 + 0.3 * semantic) via `tools/memory/hybrid_search.py`. The next evolution:
+
+- Implement Corrective RAG for compliance document retrieval -- add an evaluator that checks if retrieved NIST controls actually match query intent before generating SSP narratives. This is critical because control numbering (e.g., AC-2 vs AC-2(1)) can lead to subtly wrong retrievals.
+- Add Adaptive RAG routing in the RAG pipeline: simple control lookups go direct, cross-framework queries use decomposition (break "What does implementing AC-2 require across FedRAMP and CMMC?" into sub-queries per framework), novel compliance questions use multi-hop with crosswalk engine.
+- Expose retrieval strategies as tools (A-RAG pattern) so the LLM router can select the optimal strategy per query rather than always running the same hybrid search.
+
+---
+
+### 2.2 GraphRAG for Compliance Knowledge
+
+GraphRAG combines knowledge graph traversal with vector retrieval, providing both semantic understanding via vector similarity and symbolic reasoning via graph structure.
+
+**Architecture:**
+
+- A vector index and a graph database work in tandem. The vector index retrieves relevant text passages. The graph database retrieves structured facts and relationships. Both feed into the LLM's context window.
+- The knowledge graph can act as a direct context source and/or annotate and filter text fragments for retrieval.
+
+**Construction Approaches:**
+
+- **Top-Down**: Define ontology first (entities, relationship types, constraints), then extract from documents into the ontology. Best for structured domains like compliance frameworks where the schema is well-known.
+- **Bottom-Up**: Extract entities and relations from documents using NER and RE, then cluster into topic communities. Best for unstructured content.
+- **Hybrid**: Combine both. Use top-down for the compliance framework structure, bottom-up for evidence documents.
+
+**Key Implementations (2025):**
+
+- **Microsoft GraphRAG**: Open-source, uses community detection to create hierarchical summaries of document corpora.
+- **Graphiti (Zep AI)**: Framework for AI agents needing real-time, evolving memory. Updates knowledge graphs incrementally as new information arrives. Uses Neo4j for storage. Suited for long-running agents.
+- **AWS Bedrock Knowledge Bases**: Supports GraphRAG with managed ingestion into Neptune.
+- **Azure Cognitive Search**: Integrates with graph databases.
+
+**ICDEV Applicability:** ICDEV's crosswalk engine (mapping NIST 800-53 -> FedRAMP -> CMMC -> 800-171 -> CISA SbD) is conceptually a knowledge graph stored as SQL adjacency lists (D27). The digital thread (requirements -> design -> code -> tests -> evidence) is another natural graph.
+
+Recommended actions:
+
+- Model the control crosswalk as a formal knowledge graph with typed relationships: `implements`, `inherits`, `partially_satisfies`, `supersedes`, `maps_to`. This enables transitive queries that SQL joins handle poorly (e.g., "What CMMC practices are transitively satisfied by implementing AC-2 through the FedRAMP inheritance chain?").
+- Use GraphRAG for compliance queries where relationship traversal matters more than text similarity.
+- Adopt the Graphiti pattern for the cATO Live Engine -- incrementally update the compliance knowledge graph as new evidence arrives rather than rebuilding from scratch.
+- The digital thread heatmap (`thread_heatmap.py`) would benefit from graph-based orphan detection instead of the current N x M matrix approach.
+
+---
+
+### 2.3 Chunking Strategies for Compliance Documents
+
+Research shows dramatic variation in chunking effectiveness depending on strategy:
+
+**Benchmarks (2025-2026):**
+
+- **Adaptive chunking** aligned to logical topic boundaries: 87% accuracy vs 13% for fixed-size baselines (clinical decision support study, November 2025).
+- **Recursive 512-token splitting**: 69% accuracy in academic benchmarks (Vecta, February 2026, across 50 papers and 7 strategies).
+- **Semantic chunking**: Only 54% accuracy due to producing fragments averaging 43 tokens -- too small to carry sufficient context.
+
+**Emerging Best Practices:**
+
+- **Section-aware chunking**: Split on document headings, sections, and subsections rather than token counts. Compliance documents (SSPs, STIGs, NIST SPs) have well-defined section structures.
+- **Parent-child chunk relationships**: Maintain hierarchy so a retrieved chunk can pull its parent section for additional context when needed.
+- **Proposition-based chunking**: Decompose text into atomic propositions (single facts), then group related propositions. Good for dense regulatory text.
+- **Domain-specific strategies**: Legal documents split by headings and subsections. Medical literature by sentence boundaries or key concepts. Compliance documents should split by control family, individual control, and implementation statement.
+
+**ICDEV Applicability:** For compliance documents (SSPs, STIGs, NIST 800-53, FedRAMP baselines):
+
+- Implement section-aware chunking that splits on control boundaries. Each NIST 800-53 control has a well-defined structure (title, description, supplemental guidance, control enhancements) that should be preserved as a single chunk.
+- Maintain parent-child relationships: control family -> control -> enhancement. When AC-2(1) is retrieved, the parent AC-2 context should be available.
+- For OSCAL documents, chunk at the control/assessment-result level since these are natural semantic units with defined XML/JSON structure.
+- Avoid semantic chunking for compliance content -- the short fragment problem (43-token average) destroys compliance context.
+
+---
+
+### 2.4 RAG Evaluation with RAGAS
+
+RAGAS (Retrieval Augmented Generation Assessment) provides reference-free evaluation of RAG pipelines.
+
+**Core Metrics:**
+
+- **Context Relevancy**: Are the retrieved documents relevant to the query?
+- **Context Recall**: Did retrieval capture all necessary information?
+- **Faithfulness**: Is the generated response supported by the retrieved context (no hallucination)?
+- **Answer Relevancy**: Does the response actually answer the question asked?
+
+These four metrics compose into a single RAGAs score.
+
+**Architecture:** The RAGAS framework follows a modular design: Document Processing -> Knowledge Graph Engine -> Transformation Pipeline -> Query Synthesis Engine -> Evaluation Metrics Engine.
+
+**ICDEV Applicability:**
+
+- Implement RAGAS evaluation as a quality gate in the compliance narrative workflow (`tools/compliance/narrative_workflow.py`). After generating an AI narrative for a control, score faithfulness against the source NIST control text before entering the approval queue. This adds quantitative quality assurance to the existing draft -> pending_review -> approved/rejected workflow.
+- Use context_relevancy scoring to validate that the hybrid search (BM25 + semantic) is retrieving the correct controls before narrative generation.
+- Track RAGAs scores over time per control family to identify which compliance areas have the weakest retrieval quality and need chunking or embedding improvements.
+
+---
+
+### 2.5 Embedding Model Selection
+
+Key considerations for embedding model selection in compliance/federal contexts:
+
+- **Accuracy**: The embedding model must accurately represent compliance domain concepts. General-purpose embeddings may conflate similar but legally distinct terms (e.g., "authorization" vs "authentication" have very different compliance implications).
+- **Dimensionality vs. performance**: Higher dimensions capture more nuance but increase storage and search cost. ICDEV uses text-embedding-3-small (1536 dims) which is a reasonable balance.
+- **Fine-tuning**: Domain-specific fine-tuning on compliance corpora can significantly improve retrieval quality for specialized vocabularies.
+- **Air-gap considerations**: For IL4+ environments, embedding models must be deployable locally. ICDEV's Ollama-based architecture supports this.
+
+**ICDEV Applicability:**
+
+- Evaluate fine-tuning text-embedding-3-small on a corpus of NIST 800-53 controls, FedRAMP SSP language, and STIG content to improve retrieval precision for compliance-specific queries.
+- Consider adding a second embedding model optimized for code (for digital thread code-to-requirement tracing) alongside the compliance-optimized model.
+
+---
+
+## 3. LLM Orchestration Patterns
+
+### 3.1 Router Patterns
+
+ICDEV's 4-tier routing architecture (Planner -> Worker -> Scanner -> Default) is well-validated by industry patterns:
+
+**Industry Router Patterns:**
+
+- **Complexity-based routing**: Route simple queries to small/fast models, complex queries to capable models. ICDEV already does this with its tier system.
+- **Budget-aware routing**: Track token spend per request type. Dynamically downgrade model tier when approaching budget limits. One implementation achieved 47% cost reduction while maintaining quality.
+- **Health-aware routing**: Probe model availability before routing, fall back to alternatives on failure. ICDEV's router already implements this with the fallback chain (qwen3.5 -> phi4-reasoning -> claude-sonnet).
+- **Quality-aware routing**: Route based on required output quality. Compliance narratives need high quality (Claude). Log summaries need speed (qwen3.5).
+- **Latency-aware routing**: For real-time interactions, route to fastest available model regardless of capability.
+
+**ICDEV Applicability:** Add budget-aware routing as a fifth routing dimension:
+
+- Track cumulative token spend per project and per session in the audit trail (aligns with NIST AU-3).
+- Define per-project token budgets in `args/llm_config.yaml`.
+- When a project approaches its budget ceiling, automatically shift Worker-tier tasks to Scanner-tier (qwen3.5-only) and reduce Planner-tier usage.
+- Emit budget utilization metrics to the Monitor agent for alerting.
+
+---
+
+### 3.2 Semantic Caching
+
+Multi-tier caching has become the 2025 standard for LLM cost optimization:
+
+**Tier 1 -- Exact Match Cache:**
+
+- Sub-millisecond latency.
+- Handles identical queries (same prompt, same parameters).
+- Simple hash-based lookup.
+- Effective for repetitive operations like control lookups.
+
+**Tier 2 -- Semantic Cache:**
+
+- Converts queries to vector embeddings.
+- Searches for semantically similar cached queries using vector search.
+- Returns cached responses if similarity exceeds a configurable threshold.
+- Redis LangCache achieves up to 73% cost reduction in high-repetition workloads.
+- Cache hits return in milliseconds versus seconds for fresh LLM inference.
+
+**Tier 3 -- Session Context Cache:**
+
+- Maintains conversation state efficiently.
+- Avoids re-sending full conversation history on each turn.
+- Reduces token consumption for multi-turn interactions.
+
+**Production Results:**
+
+- Organizations report 40-60% cost reductions with systematic caching.
+- One implementation achieved 47% LLM spend reduction using semantic cache + budget-aware routing while keeping quality flat.
+- 15-30% cost reductions are typical even with conservative caching strategies.
+
+**ICDEV Applicability:** Implement semantic caching in `tools/llm/router.py`:
+
+- Cache compliance lookups (NIST control queries, crosswalk results) -- these are the most repetitive queries in the system. The same AC-2 control description is retrieved dozens of times across projects.
+- Use ICDEV's existing embedding infrastructure (text-embedding-3-small, already generating embeddings for memory entries) to embed cache keys.
+- Store cache entries in a dedicated database table with TTL: 30 days for compliance data (controls rarely change), 7 days for code analysis results, 1 day for dynamic content.
+- Expected impact: 40-60% token reduction for compliance workloads.
+- Implementation note: Cache invalidation on NIST SP updates or framework version changes must clear affected entries.
+
+---
+
+### 3.3 Prompt Versioning and A/B Testing
+
+Production prompt management in 2025 requires infrastructure that treats prompts as first-class artifacts:
+
+**Core Requirements:**
+
+- **Version storage with atomic updates**: Every prompt change is versioned. Rollback is instant.
+- **Environment separation**: dev, staging, prod environments with promotion gates.
+- **A/B testing infrastructure**: Compare prompt versions on real traffic with quality scoring. Route percentages of traffic to candidate prompts.
+- **Performance tracking**: Latency, cost, token usage, and evaluation metrics per prompt version.
+- **Collaborative editing**: Product managers and engineers iterate together on prompts.
+
+**Key Insight:** The non-deterministic nature of LLMs makes prompt versioning fundamentally different from code versioning. You cannot run unit tests and be confident of identical output. You need statistical evaluation across many samples.
+
+**A/B Testing Variables:**
+
+- System instruction content.
+- Context window composition (RAG retrieval strategy).
+- Model parameters (temperature, top-p).
+- Model selection (different models for same prompt).
+
+**Leading Platforms (2025):**
+
+- **PromptLayer**: Visual prompt management with registry-based approach. Edit, A/B test, and deploy prompts through dashboard without code changes.
+- **Langfuse**: Observability-first. Labels prompt versions (prod-a, prod-b) with automatic performance metric tracking.
+- **Braintrust**: Development infrastructure connecting versioning to evaluation with staged deployment.
+
+**ICDEV Applicability:** ICDEV's `hardprompts/` directory contains reusable LLM instruction templates but lacks versioning:
+
+- Add SHA-256 content hashing to hard prompts (mirrors D-INV-5 template provenance pattern).
+- Store prompt versions in the database with performance metrics (faithfulness score, cost, latency, user acceptance rate).
+- Implement A/B testing for compliance narrative prompts: route 10% of narrative generation to a candidate prompt, compare RAGAS faithfulness scores against the production prompt, promote if statistically significant improvement.
+- Track prompt lineage in the audit trail for NIST AU compliance.
+
+---
+
+### 3.4 Fallback Chains with Health Checking
+
+ICDEV's existing fallback chain (qwen3.5 -> phi4-reasoning -> claude-sonnet) follows industry best practices:
+
+**Pattern Elements:**
+
+- **Availability probing**: Check model health before routing. ICDEV's router already probes Ollama availability.
+- **Graceful degradation**: If preferred model is unavailable, fall back to next-best rather than failing.
+- **Circuit breaker**: After N consecutive failures, temporarily remove a model from the chain and retry periodically.
+- **Latency budgets**: If a model exceeds its latency SLA, treat as unavailable and fall back.
+
+**ICDEV Enhancement:** Add circuit breaker logic to the router. Currently, if Ollama is down, every request attempts Ollama before falling back, adding unnecessary latency. A circuit breaker would skip Ollama for 60 seconds after 3 consecutive failures, then probe again.
+
+---
+
+### 3.5 GovCloud Cost Optimization
+
+**AWS Bedrock in GovCloud (2025-2026):**
+
+- Anthropic Claude and Meta Llama models now have **FedRAMP High and DoD IL-4/5 authorization** in AWS GovCloud (us-gov-west-1) -- the first cloud provider to achieve this.
+- Amazon invested $50B in government-only AI cloud infrastructure.
+- New data centers breaking ground in 2026 will add 1.3 GW of AI compute capacity across Top Secret, Secret, and GovCloud regions.
+
+**Pricing Tiers:**
+
+- Standard: Pay-per-use, highest per-token cost.
+- Flex: Lower cost for flexible scheduling.
+- Priority: Guaranteed throughput.
+- Reserved: Committed usage with significant discount.
+
+**Cost Optimization Strategies for Federal:**
+
+- **Reserved pricing** for predictable Bedrock Claude usage (ICDEV's tier2 model).
+- **Maximize local Ollama** for Scanner-tier work -- zero cloud cost for qwen3.5, phi4-reasoning, llava:13b workloads.
+- **Token budget management** per project aligned to DoD budget cycles.
+- **Cost allocation tags** (AWS Flexible Cost Allocation, announced January 2026 for GovCloud) to track AI spend per program/contract.
+
+**ICDEV Applicability:**
+
+- Validate that Scanner-tier routing is being fully utilized -- every query that can run on qwen3.5 locally should never reach Bedrock.
+- Use Reserved pricing for Bedrock Claude if monthly usage exceeds the break-even threshold.
+- Implement per-agent token consumption monitoring to identify which agents drive the most cloud LLM cost (likely Compliance and Requirements agents due to narrative generation and intake sessions).
+- Leverage AWS Flexible Cost Allocation tags to attribute AI costs to specific DoD programs/contracts.
+
+---
+
+## 4. AI Safety & Governance Architecture
+
+### 4.1 NIST AI RMF Implementation Patterns
+
+The NIST AI Risk Management Framework (AI RMF 1.0) defines four interconnected functions designed to be implemented iteratively throughout an AI system's lifecycle:
+
+**GOVERN:**
+
+- Establish governance structures, policies, roles, and responsibilities for AI risk management.
+- Define organizational risk tolerance and acceptable AI use policies.
+- Ensure accountability mechanisms and oversight processes.
+
+**MAP:**
+
+- Identify system context: purpose, stakeholders, deployment environment.
+- Catalog data sources, dependencies, and third-party components.
+- Assess potential impacts and affected populations.
+- Map AI system capabilities and limitations.
+
+**MEASURE:**
+
+- Monitor performance, trustworthiness, risks, and outcomes continuously.
+- Implement metrics for fairness, accuracy, robustness, and transparency.
+- Track model drift and degradation over time.
+- Conduct adversarial testing and red teaming.
+
+**MANAGE:**
+
+- Prioritize, mitigate, and continuously monitor AI risks.
+- Manage third-party and supply chain risks.
+- Implement incident response procedures.
+- Maintain documentation and audit trails.
+
+**2025-2026 Developments:**
+
+- NIST expected to release RMF 1.1 guidance addenda with expanded profiles and more granular evaluation methodologies through 2026.
+- Sector regulators (FTC, FDA, SEC, DoD, CFPB, EEOC) increasingly reference AI RMF in their expectations.
+- Agentic AI systems require adapted frameworks for planning, tool use, and multi-step actions -- the original RMF was designed for traditional ML systems.
+- Cross-border regulatory alignment is driving convergence between NIST AI RMF and EU AI Act requirements.
+
+**ICDEV AI RMF Mapping:**
+
+```
+GOVERN Layer (ICDEV Implementation):
+  - Policy Engine: args/sbd_gates.yaml, policy_generator.py
+  - Role-based Access: agent_trust_scorer.py, tool_chain_validator.py
+  - Audit Trail: append-only tables (NIST AU compliance)
+  - Session Purpose: session_purpose.py (declared intent per session)
+  - Dispatcher Mode: dispatcher_mode.py (Orchestrator restricted to delegation)
+
+MAP Layer (ICDEV Implementation):
+  - AI BOM: ai_bom_generator.py (component inventory)
+  - System/Model Cards: ai_transparency goal workflow
+  - Dependency Graph: supply_chain/dependency_graph.py
+  - Stakeholder Impact: boundary_analyzer.py (4-tier ATO impact)
+
+MEASURE Layer (ICDEV Implementation):
+  - ATLAS Assessment: atlas_assessor.py, atlas_red_team.py
+  - OWASP Assessment: owasp_llm_assessor.py, owasp_agentic_assessor.py
+  - Agent Attribution: agent_shap.py (Monte Carlo Shapley values)
+  - XAI Assessment: xai_assessor.py (10 compliance checks)
+  - Code Quality: code_analyzer.py (cyclomatic/cognitive complexity)
+
+MANAGE Layer (ICDEV Implementation):
+  - Prompt Injection Defense: prompt_injection_detector.py (5 categories)
+  - AI Telemetry: ai_telemetry_logger.py (SHA-256 hashed, privacy-preserving)
+  - Tool Chain Validation: tool_chain_validator.py
+  - Continuous Monitoring: cato_live_engine.py
+  - Incident Response: crash_analyzer.py, self_heal pattern
+```
+
+**ICDEV Applicability:** ICDEV already implements most AI RMF functions. Formalize the mapping:
+
+- Add `ai_rmf` as a framework key in the crosswalk engine (alongside `cisa_sbd`, `nist_800_53`, etc.) so running ICDEV's existing AI security tools auto-populates AI RMF compliance status.
+- Create an explicit AI RMF subcategory-to-tool mapping table. This allows ICDEV to generate AI RMF compliance reports automatically.
+- Address the agentic AI gap: current AI RMF guidance does not fully address multi-agent systems. Document ICDEV's agentic controls (dispatcher mode, tool chain validation, trust scoring) as supplementary measures.
+
+---
+
+### 4.2 AI Bill of Materials (AI BOM)
+
+**Converging Standards:**
+
+- **SPDX 3.0.1**: The technical backbone for AI-BOMs. AI and Dataset Profiles capture architecture, data sources, licensing, and provenance in a machine-readable, interoperable format.
+- **CycloneDX 1.6 ML-BOM**: Introduces AI entities and component types for model and dataset metadata exchange.
+- Both standards enable organizations to catalog model parameters, dataset sources, environment details, training methodologies, and dependency chains.
+
+**AI BOM Components:**
+
+- Model architecture and version.
+- Training data sources and provenance.
+- Software dependencies and library versions.
+- Hardware requirements and deployment environment.
+- Configuration files and hyperparameters.
+- Licensing and IP obligations.
+- Ethical considerations and bias assessments.
+- Performance benchmarks and limitations.
+
+**Automation Patterns:**
+
+- Integrate AI BOM generation into CI/CD and MLOps pipelines.
+- Use pipeline scripts to extract metadata from AI components during runtime.
+- Every new model version or retraining cycle automatically updates the AI BOM without human intervention.
+- Automated AI BOM generation catalogs every AI asset (models, datasets, dependencies) deployed across the organization.
+
+**ICDEV Applicability:** ICDEV's `ai_bom_generator.py` exists. Enhancements:
+
+- Output in CycloneDX 1.6 ML-BOM format (aligns with D-INV-45 firmware SBOM using CycloneDX 1.5 and D-INV-46 VEX using CSAF 2.0).
+- Auto-trigger AI BOM regeneration on: Ollama model updates, Bedrock model version changes, OTA model deployments to fleet devices.
+- Include the full Ollama model inventory (qwen3.5:latest, phi4-reasoning:latest, llava:13b, gemma3:latest, etc.) with version hashes and sizes.
+- Track training data provenance for any fine-tuned models (ft_pair_generator.py output).
+- Generate separate AI BOMs per deployment tier (Tier 0 browser, Tier 1 MCU, Tier 2 edge, Tier 3 cloud) since each tier has different model inventories.
+
+---
+
+### 4.3 Model Cards and System Cards Automation
+
+**Model Cards:**
+
+- Standardized documentation of a model's purpose, performance metrics, limitations, ethical considerations, and intended use cases.
+- Should be auto-generated from training metadata and evaluation results.
+- Must include: model details, intended use, factors (demographic, environmental), metrics, evaluation data, ethical considerations, caveats.
+
+**System Cards:**
+
+- Broader than model cards -- document the entire AI system including multiple models, data pipelines, human oversight mechanisms, and deployment context.
+- Critical for multi-agent systems like ICDEV where the system behavior emerges from agent interactions, not any single model.
+
+**ICDEV Applicability:** ICDEV has `goals/ai_transparency.md` covering model/system cards. Enhance with:
+
+- Auto-generate model cards from the LLM router configuration (each model in `args/llm_config.yaml` gets a card).
+- Auto-generate a system card for the ICDEV platform that documents: agent topology, MCP tool inventory, routing decisions, compliance framework coverage, and human oversight mechanisms (narrative approval workflow, dispatcher mode).
+- Include system card in OSCAL SSP output for FedRAMP 20x machine-readable packages.
+
+---
+
+### 4.4 Prompt Injection Defense Architecture
+
+Research from late 2025 demonstrates that a combined defense framework reduces successful attack rates from **73.2% to 8.7%** while maintaining 94.3% of baseline task performance.
+
+**Three-Layer Defense Architecture:**
+
+**Layer 1 -- Input Validation (Content Filtering):**
+
+- Embedding-based analysis to detect injection patterns.
+- Content filtering catches obvious injection attempts.
+- Alone, reduces attack success to 41.0% -- necessary but insufficient.
+- Must cover all data sources: user input, RAG retrieved content, tool outputs, external API responses.
+
+**Layer 2 -- Context Isolation (Guardrails):**
+
+- Clear delimiters marking retrieved content with explicit directives to treat delimited text as reference data only.
+- System instructions with explicit precedence markers (system > user).
+- Structured prompts that separate instructions from data.
+- Goal-lock mechanisms: once a task purpose is declared, reject instructions that deviate.
+
+**Layer 3 -- Output Verification (Response Validation):**
+
+- Multi-stage output validation before responses reach users.
+- Check for leaked system prompts, tool credentials, or internal state.
+- Verify response alignment with declared task purpose.
+- Detect data exfiltration attempts (responses containing sensitive data patterns).
+
+**Agentic AI Considerations (Critical for ICDEV):**
+
+- Agentic systems amplify prompt injection risks because compromised agents can use tools, access data, and influence other agents.
+- Required controls: input validation on ALL data sources (not just user input), goal-lock mechanisms, tool sandboxing with minimal privileges, strategic human-in-the-loop approval for high-impact actions.
+- Prevention -- not detection -- is the only viable defense for AI systems.
+
+**ICDEV Applicability:** ICDEV's `prompt_injection_detector.py` (5 detection categories) covers Layer 1. Strengthen the architecture:
+
+- **Layer 2 -- Context Isolation**: Add explicit delimiter markers in MCP tool responses so the LLM can distinguish tool output from user input. Implement goal-lock in the Orchestrator -- once session purpose is declared via `session_purpose.py`, reject tool invocations that deviate from the declared intent.
+- **Layer 3 -- Output Verification**: Add post-generation validation in the LLM router that checks responses for leaked system prompts, tool credentials, database connection strings, or internal state. Flag responses containing classification markings above the session's declared impact level.
+- **Agentic Controls**: The dispatcher mode (`dispatcher_mode.py`) already restricts the Orchestrator to delegation-only. Extend this pattern to all agents: each agent should have a declared capability boundary and reject tool invocations outside that boundary.
+
+---
+
+### 4.5 Explainability Pipelines
+
+**SHAP (SHapley Additive exPlanations):**
+
+- Provides both global (which features matter overall) and local (why this specific prediction) explanations.
+- Based on Shapley values from cooperative game theory -- mathematically guaranteed unique solution.
+- Reproducible: running SHAP twice on the same data yields identical results.
+- Generates multiple visualization types: summary plots, dependence plots, force plots, waterfall plots.
+- Drawback: Computationally expensive for large models. Can be prohibitive at production scale.
+
+**LIME (Local Interpretable Model-agnostic Explanations):**
+
+- Creates local linear approximations around individual predictions.
+- Universally applicable to any model (model-agnostic).
+- Faster than SHAP for individual explanations.
+- Drawback: Non-deterministic. Random sampling means running LIME twice may yield different explanations. Only local explanations (no global view).
+
+**Attention Visualization:**
+
+- Transformer self-attention weights show token-to-token "attention" relationships.
+- Useful for quick sanity checks and catching obvious failures.
+- Not ground truth for model reasoning -- attention captures one mechanism in a complex system, not the full reasoning process.
+
+**Production Scaling Concerns:**
+
+- Some XAI methods that work on small examples become computationally prohibitive at scale.
+- Production systems need to explain thousands or millions of decisions.
+- Caching and batching of explanations is essential.
+- Regulatory pressure increasing: EU AI Act requires high-risk AI system deployers to explain decision logic.
+
+**ICDEV Applicability:** ICDEV's `agent_shap.py` uses Monte Carlo Shapley values for tool attribution -- the right approach. Enhancements:
+
+- Add batch SHAP computation for compliance narratives. Run attribution analysis on all AI-generated narratives in a batch to identify which tools/controls most influenced each narrative.
+- Cache SHAP results per control family. Compliance queries within the same family will have similar attribution patterns, reducing recomputation.
+- Integrate SHAP results into the XAI assessment report for NIST AI RMF MEASURE function compliance.
+- For the Orchestrator's routing decisions, generate SHAP explanations for why specific agents were selected for a task -- this supports the GOVERN function (accountability).
+
+---
+
+## 5. Edge-Cloud AI Architecture
+
+### 5.1 TinyML Deployment Patterns
+
+The convergence of TinyML and federated learning is the dominant 2025 trend for edge AI:
+
+**Federated TinyML Architecture:**
+
+- Devices collaboratively improve models while keeping data local -- critical for DoD data sensitivity.
+- A novel FL-IoT framework combines: OTA model updates, LoRa-based distributed communication, lossless data compression to reduce transmission cost.
+- Architecture: Raspberry Pi-based aggregation nodes (Tier 2 edge gateways) coordinate microcontroller-based IoT clients (Tier 1 devices).
+- Privacy-preserving by design: only model gradients/updates are transmitted, never raw data.
+
+**Compression Pipeline (2025 Standard):**
+
+Three-stage pipeline has become standard practice:
+
+1. **Pruning**: Remove redundant weights/neurons. Structured pruning removes entire channels; unstructured pruning removes individual weights.
+2. **Quantization**: Reduce numeric precision. 4-bit quantization reduces memory 75-90% with minimal accuracy loss. 2-bit k-means quantization emerging for extreme compression.
+3. **Knowledge Distillation**: Train a smaller "student" model to mimic a larger "teacher" model's behavior.
+
+**Production Results:**
+
+- Hybrid pruning-quantization pipeline: 75% model size reduction, 50% power consumption reduction, 97% accuracy retention.
+- 4-bit quantization: Up to 90% memory footprint reduction.
+- Mid-term trend: Hybrid pipelines become standard. Long-term: Models trained natively for compression from initialization.
+
+**ICDEV Applicability:** SparkPilot already supports TFLite Micro on Tier 1 devices. Enhancements:
+
+- Add a standard compression pipeline to the model deployment workflow in `edge_ai/model_manager.py`: quantize -> validate accuracy -> package -> deploy.
+- Include compression metadata in firmware SBOM (original size, compressed size, quantization level, accuracy delta).
+- Support multiple quantization levels per device class: 8-bit for ESP32-S3 (512KB RAM), 4-bit for RPi Pico (264KB RAM).
+
+---
+
+### 5.2 Federated Learning for Fleet Devices
+
+**Architecture Pattern:**
+
+```
+C4 Container Diagram -- Federated Learning Architecture:
+
+[Fleet Devices (Tier 1: ESP32/STM32)]
+  |-- Local training on device-specific data
+  |-- Compute model gradient updates locally
+  |-- Send only gradient updates (NOT raw data) to aggregator
+  |
+  v (LoRa / MQTT / WiFi)
+
+[Edge Gateway / Aggregation Node (Tier 2: RPi/Jetson)]
+  |-- Receive gradient updates from N fleet devices
+  |-- Run federated averaging (FedAvg) or FedProx
+  |-- Produce updated global model
+  |-- Validate updated model against holdout test set
+  |-- If accuracy meets threshold:
+  |     Push updated model to fleet via OTA (canary -> full)
+  |-- If accuracy degrades:
+  |     Rollback to previous global model
+  |-- Report aggregation metrics to cloud
+  |
+  v (HTTPS / mTLS)
+
+[Cloud (Tier 3: AWS GovCloud)]
+  |-- Cross-cluster federated aggregation (if multiple edge gateways)
+  |-- Global model versioning and storage
+  |-- Compliance monitoring and audit trail
+  |-- Model performance dashboards
+```
+
+**Key Challenges:**
+
+- Heterogeneous data across fleet devices (non-IID data distribution).
+- Communication efficiency on bandwidth-constrained links (LoRa: ~50 kbps).
+- Security of gradient updates (gradient inversion attacks can reconstruct training data).
+- Convergence guarantees with unreliable device connectivity.
+
+**ICDEV Applicability:**
+
+- Add a federated learning coordinator at the Edge Gateway tier. Use FedAvg for homogeneous fleet segments, FedProx for heterogeneous segments.
+- Integrate with existing OTA manager for model distribution after federated training rounds.
+- Add differential privacy to gradient updates before transmission to prevent gradient inversion attacks (critical for DoD data sensitivity).
+- Log federated training rounds in the audit trail with participant counts, convergence metrics, and accuracy deltas.
+
+---
+
+### 5.3 Split Inference Architecture
+
+**Pattern:** Partition a neural network across edge and cloud tiers based on computational requirements and latency constraints.
+
+```
+C4 Component Diagram -- Split Inference:
+
+[IoT Device (Tier 1)]
+  Components:
+  - TFLite Micro Runtime
+  - Early Network Layers (feature extraction, convolutions)
+  - Confidence Evaluator
+
+  Flow:
+  1. Run sensor input through early layers
+  2. Evaluate confidence of intermediate representation
+  3. If confidence > threshold (e.g., 0.85):
+       -> Complete inference locally
+       -> Report result + confidence to gateway
+  4. If confidence < threshold:
+       -> Send intermediate features to edge gateway
+       -> Receive refined result from gateway
+
+[Edge Gateway (Tier 2)]
+  Components:
+  - Later Network Layers (classification, refinement)
+  - Local LLM (llama.cpp, ~7B params)
+  - Multi-agent Coordinator
+  - Inference Cache
+
+  Flow:
+  1. Receive intermediate features from device
+  2. Complete inference through later layers
+  3. If still uncertain: forward to cloud
+  4. Cache results for similar future queries
+
+[Cloud (Tier 3)]
+  Components:
+  - Full Model (no size constraints)
+  - Training Pipeline
+  - Model Versioning
+  - Compliance Monitoring
+```
+
+**Benefits:**
+
+- Reduces latency for high-confidence predictions (local inference in milliseconds).
+- Reduces bandwidth (intermediate features are smaller than raw sensor data).
+- Enables privacy (raw data stays on device).
+- Graceful degradation (device can still operate if gateway/cloud is unreachable).
+
+**ICDEV Applicability:**
+
+- Add inference confidence threshold configuration to TinyML model deployment in `edge_ai/model_manager.py`.
+- Route low-confidence inferences to edge gateway for refinement.
+- Track split inference ratios (local vs. offloaded) in inference telemetry for fleet health monitoring.
+- Use split ratios as a fleet health metric: if a device suddenly offloads most inferences, it may indicate sensor degradation or model drift.
+
+---
+
+### 5.4 OTA Model Updates with Rollback
+
+**Production Patterns:**
+
+**Signed Model Packages:**
+
+- Cryptographic signature verification before deployment.
+- Model hash included in device attestation.
+- Reject unsigned or tampered packages at the device level.
+
+**Staged Rollouts (ICDEV already has this via ota_manager.py):**
+
+- Canary deployment: Deploy to 10% of fleet, monitor for 72 hours.
+- Broader rollout: If canary passes accuracy and stability thresholds, deploy to remaining fleet.
+- Automatic rollback: If accuracy degrades beyond threshold during canary, revert to previous model.
+
+**A/B Model Testing:**
+
+- Run old and new models simultaneously on a subset of devices.
+- Compare inference accuracy, latency, power consumption, and crash rates.
+- Promote winning model to full fleet.
+
+**MCUboot Integration:**
+
+- Hardware-level rollback to previous firmware/model partition on crash.
+- ICDEV's crash_analyzer.py already detects crash patterns with a 72-hour stability window.
+
+**ICDEV Enhancements:**
+
+- Add model version pinning per device group -- allow different fleet segments to run different model versions for A/B testing.
+- Include model hashes in firmware SBOM (`firmware_sbom.py`) for supply chain traceability.
+- Add differential OTA: transmit only model weight deltas rather than full models to reduce bandwidth on constrained links.
+- Track model provenance: which training data version, which federated round, which compression pipeline produced each deployed model.
+
+---
+
+## 6. Compliance-as-Code Architecture
+
+### 6.1 OSCAL Ecosystem (2025-2026)
+
+The Open Security Controls Assessment Language (OSCAL) is the NIST-led standard for machine-readable security compliance data. Available in XML, JSON, and YAML.
+
+**OSCAL Models:**
+
+- **Catalog**: Defines security controls (e.g., NIST 800-53 Rev 5 catalog).
+- **Profile**: Selects and tailors controls for a specific baseline (e.g., FedRAMP Moderate).
+- **System Security Plan (SSP)**: Documents how a system implements selected controls.
+- **Security Assessment Plan (SAP)**: Defines assessment procedures.
+- **Security Assessment Results (SAR)**: Records assessment findings.
+- **Plan of Action & Milestones (POA&M)**: Tracks remediation of findings.
+- **Component Definition**: Describes reusable security components and their control implementations.
+
+**2025-2026 Developments:**
+
+- OSCAL adoption is expanding rapidly in both government and private sector.
+- Tool ecosystem growing: OSCAL validators, generators, converters, and CI/CD integrations.
+- NIST is seeking tool developers and vendors to implement OSCAL in commercial and open-source offerings.
+- **January 2026 (RFC-0024): Machine-readable OSCAL packages mandated for ALL FedRAMP providers** -- not just 20x participants.
+
+**ICDEV Applicability:** ICDEV's `oscal_generator.py` already produces SSP, SAR, and POA&M in OSCAL format. Enhancements:
+
+- Add Component Definition generation for ICDEV platform controls (reusable across child applications).
+- Generate OSCAL Profiles that document ICDEV's tailored baselines per impact level (IL2, IL4, IL5).
+- Validate generated OSCAL against NIST schemas before output (automated quality gate).
+- Ensure all OSCAL outputs include FedRAMP 20x metadata extensions for machine-readable package compatibility.
+
+---
+
+### 6.2 FedRAMP 20x: The Compliance Revolution
+
+FedRAMP 20x, announced March 24, 2025, represents the biggest shift in federal cloud compliance since FedRAMP's inception. It replaces manual documentation with automated validation and continuous monitoring.
+
+**Core Principles:**
+
+- Shift from documentation-based compliance to engineering-based assurance.
+- Automate validation of at least 80% of security requirements.
+- Replace screenshots and lengthy narratives with machine-readable evidence.
+- Continuous posture reporting instead of point-in-time assessments.
+
+**Key Security Indicators (KSIs):**
+
+- Machine-readable security signals that CSPs continuously emit.
+- Examples: vulnerability scan results, configuration compliance checks, access control events, encryption status, patch currency.
+- KSIs are validated automatically, not by human reviewers.
+
+**Timeline and Results:**
+
+- Phase 1 (Completed Sept 2025): 20x Low Pilot. 26 submissions, 12 pilot authorizations.
+- Phase 2 (Active through March 31, 2026): 20x Moderate Pilot. Limited to 13 participants.
+- Phase 3 (FY26 Q3-Q4): Formalize all 20x Low and Moderate requirements. Open for wide-scale adoption.
+- Phase 4 (FY27 Q1-Q2): Pilot for 20x High authorizations.
+- January 13, 2026: RFC-0024 mandates machine-readable packages for ALL FedRAMP providers.
+
+**Authorization Speed:** Participants in the first pilot achieved full authorization in as little as **3 months**, compared to 18+ months for the traditional process. Organizations using automation achieve authorization in approximately 6 months on average.
+
+**ICDEV Applicability -- High Priority:**
+
+```
+C4 Container Diagram -- ICDEV FedRAMP 20x Architecture:
+
+[ICDEV Compliance Engine]
+  |
+  |-- [Evidence Collectors] (automated, continuous)
+  |     |-- SAST results --> security/sast_runner.py
+  |     |-- Dependency audit --> security/dependency_auditor.py
+  |     |-- Container scan --> security/container_scanner.py
+  |     |-- STIG checks --> compliance/stig_checker.py
+  |     |-- AI telemetry --> security/ai_telemetry_logger.py
+  |     |-- ZTA maturity --> devsecops/zta_maturity_scorer.py
+  |     |-- Agent trust scores --> security/agent_trust_scorer.py
+  |     |-- Code quality metrics --> analysis/code_analyzer.py
+  |
+  |-- [OSCAL Generator] (compliance/oscal_generator.py)
+  |     |-- SSP (System Security Plan) -- OSCAL JSON
+  |     |-- SAR (Security Assessment Results) -- OSCAL JSON
+  |     |-- POA&M -- OSCAL JSON
+  |     |-- Component Definitions -- OSCAL JSON
+  |
+  |-- [cATO Live Engine] (compliance/cato_live_engine.py)
+  |     |-- Incremental per-control assessment-results (D-INV-1)
+  |     |-- Evidence freshness tracking: current<=30d, stale<=90d, expired>90d
+  |     |-- Real-time compliance posture dashboard
+  |     |-- Timeline of control status changes
+  |
+  |-- [FedRAMP 20x KSI Emitter] (NEW -- recommended)
+  |     |-- Transform cATO evidence streams into KSI format
+  |     |-- Machine-readable JSON output per KSI category
+  |     |-- Automated validation endpoint for 3PAO
+  |     |-- Continuous posture reporting to FedRAMP
+  |
+  |-- [Control Inheritance Engine]
+  |     |-- Crosswalk: NIST 800-53 -> FedRAMP -> CMMC -> 800-171 -> CISA SbD
+  |     |-- AWS shared responsibility model (46+ inherited controls)
+  |     |-- ICDEV platform controls (implemented by tools)
+  |     |-- Child app controls (inherited via Golden Path scaffolder)
+  |
+  |-- [Narrative Workflow] (compliance/narrative_workflow.py)
+        |-- AI-generated control narratives
+        |-- Two-tier LLM: qwen3.5 drafts, Claude reviews
+        |-- Approval workflow: draft -> pending_review -> approved/rejected
+        |-- RAGAS faithfulness scoring (NEW -- recommended)
+```
+
+**Specific Recommendations:**
+
+1. Build a **KSI emitter** that translates cATO evidence streams into FedRAMP 20x Key Security Indicator format. This positions ICDEV-built applications for 3-month authorization cycles.
+2. Ensure all evidence collectors output **timestamped, machine-readable OSCAL assessment-results** (not human-readable reports).
+3. Add **automated OSCAL schema validation** as a quality gate before any compliance output is published.
+4. Formalize the **control inheritance chain** in OSCAL Component Definitions: AWS GovCloud baseline (46+ controls) -> ICDEV platform controls -> child application controls.
+
+---
+
+### 6.3 Continuous Monitoring Architecture
+
+FedRAMP 20x shifts compliance from periodic assessment to continuous assurance:
+
+**Evidence Collection Automation Patterns:**
+
+- **Pipeline-integrated evidence**: Security scans, dependency audits, and STIG checks run as CI/CD pipeline stages. Results are automatically formatted as OSCAL assessment-results and stored.
+- **Configuration drift detection**: Continuous comparison of actual system configuration against declared security baselines. ICDEV's `sync_engine.py` (drift detection for MBSE) is a conceptual model that can be extended.
+- **Event-driven evidence**: Security events (access control changes, vulnerability discoveries, patch deployments) trigger immediate evidence generation rather than waiting for scheduled scans.
+- **Evidence freshness**: Track the age of each piece of evidence. FedRAMP 20x expects continuous evidence streams, not stale documents. ICDEV's cATO engine already tracks freshness (current <= 30d, stale <= 90d, expired > 90d).
+
+**Continuous Monitoring Architecture Pattern:**
+
+```
+Event Sources:
+  Git commits --> PR Intelligence (pr_intelligence.py)
+  Container builds --> Container Scanner (container_scanner.py)
+  Dependency updates --> Dependency Auditor (dependency_auditor.py)
+  Config changes --> STIG Checker (stig_checker.py)
+  Access events --> Audit Trail (append-only)
+  Model updates --> AI BOM Generator (ai_bom_generator.py)
+
+  All events flow to:
+  --> cATO Live Engine (incremental OSCAL assessment-results)
+  --> Evidence Store (timestamped, immutable)
+  --> KSI Emitter (machine-readable FedRAMP 20x format)
+  --> Dashboard (real-time posture visualization)
+  --> Alerting (stale evidence, failed controls, expired exceptions)
+```
+
+---
+
+### 6.4 Control Inheritance Models
+
+**AWS Shared Responsibility Model:**
+
+- AWS provides 46+ pre-implemented security controls for GovCloud customers.
+- **IaaS controls** (physical security, network infrastructure): Fully inherited from AWS.
+- **PaaS controls** (OS hardening, runtime patching): Shared responsibility.
+- **Application controls** (access management, audit logging, encryption at rest/transit): Customer responsibility.
+
+**Platform-to-Application Inheritance:**
+
+- ICDEV platform implements security controls that child applications inherit.
+- Golden Path scaffolder (`golden_path.py`) already generates SECURITY.md, .well-known/security.txt, and args/sbd_gates.yaml for child apps (D-SBD-5).
+- Control inheritance should be documented in OSCAL Component Definitions so inheriting applications can reference ICDEV's implementations.
+
+**Three-Tier Inheritance Chain:**
+
+```
+Tier 1: AWS GovCloud (CSP Controls)
+  - Physical security (PE-*)
+  - Network infrastructure (SC-7 partial)
+  - Hypervisor isolation (SC-39)
+  - 46+ controls fully inherited
+  |
+  v (documented in OSCAL Component Definition)
+
+Tier 2: ICDEV Platform (Platform Controls)
+  - Access control (AC-2, AC-3, AC-6)
+  - Audit logging (AU-2, AU-3, AU-6, AU-12)
+  - Configuration management (CM-2, CM-6)
+  - Identification/authentication (IA-2, IA-5)
+  - System integrity (SI-2, SI-3, SI-4)
+  - Implemented by ICDEV tools, tested by STIG checker
+  |
+  v (inherited via Golden Path scaffolder)
+
+Tier 3: Child Applications (Application Controls)
+  - Application-specific access rules
+  - Custom audit events
+  - Data-specific encryption
+  - Application SBOM
+  - Inherit platform controls, implement application-specific controls
+```
+
+**ICDEV Applicability:**
+
+- Document the full inheritance chain in OSCAL Component Definitions.
+- Each tier should declare which controls are "fully inherited," "shared," or "application-specific."
+- The crosswalk engine should auto-populate inheritance status when generating SSPs for child applications.
+- Track inherited control verification: even inherited controls need periodic evidence that the inheriting system is correctly configured to receive the inheritance (e.g., child app is actually deployed in GovCloud, not commercial AWS).
+
+---
+
+## Summary: Top 10 Architecture Recommendations for ICDEV
+
+| Priority | Recommendation | Effort | Impact | ICDEV Architecture Decision |
+|----------|---------------|--------|--------|-----------------------------|
+| 1 | **FedRAMP 20x KSI emitter** -- transform cATO evidence streams into KSI format for 3-month authorizations | Medium | Critical | Extends D-INV-1, D-INV-2 |
+| 2 | **Semantic caching in LLM router** -- cache compliance lookups for 40-60% token cost reduction | Medium | High | Extends router.py, new cache table |
+| 3 | **Corrective RAG for compliance retrieval** -- evaluate retrieval quality before narrative generation to reduce hallucination | Medium | High | Extends hybrid_search.py, narrative_workflow.py |
+| 4 | **A2A v0.2 Agent Card migration** -- adopt Linux Foundation standard for ecosystem interoperability | Low | Medium | Updates existing Agent Cards |
+| 5 | **Lazy MCP tool loading** -- load tools on-demand per session purpose instead of all 80+ tools | Low | Medium | Optimizes context window usage |
+| 6 | **Budget-aware routing** -- per-project token spending limits with automatic tier downgrade | Low | Medium | Extends llm_config.yaml, router.py |
+| 7 | **GraphRAG for crosswalk engine** -- enable transitive control relationship queries across frameworks | High | High | Extends crosswalk_engine.py |
+| 8 | **Output verification gate** -- post-generation validation for prompt injection defense (Layer 3) | Medium | High | New gate in router.py |
+| 9 | **Federated learning coordinator** -- privacy-preserving fleet model improvement without centralizing data | High | Medium | New component in fleet/ |
+| 10 | **AI RMF crosswalk** -- map existing ICDEV tools to NIST AI RMF subcategories automatically | Low | Medium | Extends crosswalk_engine.py |
+
+---
+
+## Sources
+
+**Multi-Agent Systems:**
+- [Google A2A Protocol Announcement](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/)
+- [A2A Protocol Upgrades](https://cloud.google.com/blog/products/ai-machine-learning/agent2agent-protocol-is-getting-an-upgrade)
+- [A2A at Google I/O](https://developers.googleblog.com/agents-adk-agent-engine-a2a-enhancements-google-io/)
+- [Linux Foundation A2A Project](https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents)
+- [A2A GitHub Repository](https://github.com/a2aproject/A2A)
+- [IBM: What Is A2A Protocol](https://www.ibm.com/think/topics/agent2agent-protocol)
+- [MCP Specification (2025-11-25)](https://modelcontextprotocol.io/specification/2025-11-25)
+- [Anthropic MCP Announcement](https://www.anthropic.com/news/model-context-protocol)
+- [A Year of MCP Review](https://www.pento.ai/blog/a-year-of-mcp-2025-review)
+- [MCP Enterprise Adoption Guide](https://guptadeepak.com/the-complete-guide-to-model-context-protocol-mcp-enterprise-adoption-market-trends-and-implementation-strategies/)
+- [Anthropic: Code Execution with MCP](https://www.anthropic.com/engineering/code-execution-with-mcp)
+- [MCP Architecture 2026](https://onereach.ai/blog/what-to-know-about-model-context-protocol/)
+- [CrewAI vs LangGraph vs AutoGen](https://www.datacamp.com/tutorial/crewai-vs-langgraph-vs-autogen)
+- [AutoGen Multi-Agent Patterns](https://sparkco.ai/blog/deep-dive-into-autogen-multi-agent-patterns-2025)
+- [AI Agent Frameworks 2025](https://www.getmaxim.ai/articles/top-5-ai-agent-frameworks-in-2025-a-practical-guide-for-ai-builders/)
+- [Agent Framework Landscape 2025](https://medium.com/@hieutrantrung.it/the-ai-agent-framework-landscape-in-2025-what-changed-and-what-matters-3cd9b07ef2c3)
+- [Agent Swarm vs Workflows vs LangGraph](https://blog.softmaxdata.com/agent-architectures-compared/)
+- [Taxonomy of Hierarchical MAS](https://arxiv.org/html/2508.12683)
+- [Top 5 Agent Architectures Compared](https://www.marktechpost.com/2025/11/15/comparing-the-top-5-ai-agent-architectures-in-2025-hierarchical-swarm-meta-learning-modular-evolutionary/)
+- [Supervisor-Style MAS](https://towardsai.net/p/machine-learning/supervisor-style-the-king-of-multi-agent-systems)
+- [AWS Multi-Agent Patterns](https://aws.amazon.com/blogs/machine-learning/multi-agent-collaboration-patterns-with-strands-agents-and-amazon-nova/)
+- [Survey of Agent Interoperability Protocols](https://arxiv.org/html/2505.02279v1)
+- [MCP vs A2A](https://www.clarifai.com/blog/mcp-vs-a2a-clearly-explained)
+- [Agent Card Protocol](https://www.agentcard.net/)
+- [AWS Open Protocols for Interoperability](https://aws.amazon.com/blogs/opensource/open-protocols-for-agent-interoperability-part-1-inter-agent-communication-on-mcp/)
+- [LangGraph State Graphs](https://vanducng.dev/2025/05/29/LangGraph-State-Graphs-for-Agentic-Workflows/)
+- [LangGraph Architecture Guide 2025](https://latenode.com/blog/ai-frameworks-technical-infrastructure/langgraph-multi-agent-orchestration/langgraph-ai-framework-2025-complete-architecture-guide-multi-agent-orchestration-analysis)
+- [LangGraph State Management](https://medium.com/@bharatraj1918/langgraph-state-management-part-1-how-langgraph-manages-state-for-multi-agent-workflows-da64d352c43b)
+
+**RAG Architecture:**
+- [Advanced RAG Techniques - Pinecone](https://www.pinecone.io/learn/advanced-rag-techniques/)
+- [14 Types of RAG](https://www.meilisearch.com/blog/rag-types)
+- [RAG Techniques Repository](https://github.com/NirDiamant/RAG_Techniques)
+- [Agentic RAG Survey](https://github.com/asinghcsu/AgenticRAG-Survey)
+- [Agentic RAG: Self-Correcting Retrieval](https://www.letsdatascience.com/blog/agentic-rag-self-correcting-retrieval)
+- [GraphRAG Concepts](https://graphrag.com/concepts/intro-to-graphrag/)
+- [Microsoft GraphRAG](https://microsoft.github.io/graphrag/)
+- [Neo4j Advanced RAG](https://neo4j.com/blog/genai/advanced-rag-techniques/)
+- [Knowledge Graph RAG on Databricks](https://www.databricks.com/blog/building-improving-and-deploying-knowledge-graph-rag-systems-databricks)
+- [Chunking Strategies 2025](https://www.firecrawl.dev/blog/best-chunking-strategies-rag)
+- [RAGAS Documentation](https://docs.ragas.io/)
+- [RAG Evaluation Guide - Qdrant](https://qdrant.tech/blog/rag-evaluation-guide/)
+
+**LLM Orchestration:**
+- [LLM Token Optimization - Redis](https://redis.io/blog/llm-token-optimization-speed-up-apps/)
+- [LLM Cost Optimization Guide](https://ai.koombea.com/blog/llm-cost-optimization)
+- [47% Cost Reduction with Caching](https://medium.com/@duckweave/how-i-cut-llm-spend-47-with-smarter-caching-35451224d089)
+- [AWS: Optimize LLM Costs](https://aws.amazon.com/blogs/database/optimize-llm-response-costs-and-latency-with-effective-caching/)
+- [GPTCache](https://github.com/zilliztech/GPTCache)
+- [Prompt Versioning Tools 2025](https://www.braintrust.dev/articles/best-prompt-versioning-tools-2025)
+- [A/B Testing LLM Prompts - Langfuse](https://langfuse.com/docs/prompt-management/features/a-b-testing)
+- [Prompt Versioning Best Practices](https://www.getmaxim.ai/articles/prompt-versioning-and-its-best-practices-2025/)
+- [Bedrock FedRAMP High / DoD IL-4/5](https://aws.amazon.com/blogs/publicsector/accelerating-government-innovation-amazon-bedrock-models-get-fedramp-high-and-dod-il-4-5-approval-in-aws-govcloud-us/)
+- [Azure vs AWS GovCloud 2026](https://vso-inc.com/azure-government-cloud-vs-aws-govcloud-a-2026-cost-and-capability-comparison-for-defense-contractors-2/)
+- [Amazon $50B Government AI Cloud](https://fedscoop.com/amazon-50-billion-ai-supercomputing-infrastructure-agencies/)
+
+**AI Safety & Governance:**
+- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
+- [NIST AI RMF 2025 Updates](https://www.ispartnersllc.com/blog/nist-ai-rmf-2025-updates-what-you-need-to-know-about-the-latest-framework-changes/)
+- [AI BOM - Wiz](https://www.wiz.io/academy/ai-security/ai-bom-ai-bill-of-materials)
+- [AI BOM Systematizing - arXiv](https://www.arxiv.org/pdf/2511.12668)
+- [AI BOM Transparency](https://noma.security/blog/securing-ai-systems-through-transparency-the-critical-role-of-ai-bills-of-materials/)
+- [Securing LLM Agents - arXiv](https://arxiv.org/pdf/2506.08837)
+- [CSA: AI Prompt Guardrails](https://cloudsecurityalliance.org/blog/2025/12/10/how-to-build-ai-prompt-guardrails-an-in-depth-guide-for-securing-enterprise-genai)
+- [OWASP Prompt Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)
+- [AI Agent Security Benchmark](https://arxiv.org/html/2511.15759v1)
+- [XAI: SHAP and LIME](https://arxiv.org/html/2305.02012v3)
+- [XAI 2025 Guide](https://tensorblue.com/blog/explainable-ai-xai-shap-lime-model-interpretability-2025)
+
+**Edge-Cloud AI:**
+- [Federated Learning and TinyML](https://www.sciencedirect.com/science/article/pii/S2405959525000839)
+- [Advancing TinyML in IoT](https://www.mdpi.com/1999-5903/17/6/257)
+- [TinyML and Edge AI 2025](https://www.nexentron.com/blog/tinyml-edge-ai-microcontrollers-2025)
+- [AI Model Compression 2025](https://tensorblue.com/blog/ai-model-compression-pruning-quantization-knowledge-distillation-2025)
+- [Edge LLM Deployment 2025](https://medium.com/@kodekx-solutions/edge-llm-deployment-on-small-devices-the-2025-guide-2eafb7c59d07)
+
+**Compliance-as-Code:**
+- [OSCAL - NIST](https://pages.nist.gov/OSCAL/)
+- [FedRAMP Automation](https://automate.fedramp.gov/about/)
+- [OSCAL and FedRAMP 2026](https://www.ignyteplatform.com/blog/fedramp/oscal-and-fedramp-automation/)
+- [FedRAMP 20x Requirements Guide 2026](https://www.workstreet.com/blog/fedramp-20x-requirements)
+- [FedRAMP 20x Phases and Timeline](https://pretorin.com/blog/fedramp-20x-phases-timeline/)
+- [AWS: Prepare for FedRAMP 20x](https://aws.amazon.com/blogs/publicsector/prepare-for-fedramp-20x-with-aws-automation-and-validation/)
+- [FedRAMP 20x GRC Automation](https://www.telos.com/blog/2026/01/13/fedramp-20x-how-automation-is-transforming-federal-cloud-authorization/)
+- [FedRAMP 20x Predictions 2026](https://360advanced.com/the-future-of-federal-cloud-security-5-predictions-for-fedramp-20x-in-2026/)
+- [FedRAMP 20x in 2026](https://lazarusalliance.com/fedramp-20x-in-2026/)