update

ASG_Framework.md

@@ -9,12 +9,12 @@ This document defines the documentation framework for a software project. It est
 | Document | Purpose | Primary Audience | Format / Content | Example (SaaS Context) | Measurement (KPI) |
 |----------|---------|-----------------|------------------|------------------------|-------------------|
 | **Requirements** | Capture the **business intent** — why we're building this and what success looks like. Defines boundaries and user-visible outcomes. | Stakeholders, Product Owners, Lead Developers | User stories, PRDs, acceptance criteria, non-functional constraints. | "System must process tabular data from Julia to SvelteKit UI with <200ms latency for 5-member teams." | 95% of requests complete <200ms (synthetic monitoring). |
-| **Specification** | The **technical contract** — precise rules for inputs, outputs, and data shape. Ensures consistency across dev and test. | Developers, QA Engineers, CI/CD pipelines | OpenAPI, Protobuf, AsyncAPI. Endpoint definitions, schemas, error codes. | `contract.yaml` defining a NATS subject that accepts Arrow streams with snake_case headers. | 100% of messages validated against spec (CI block rate). |
+| **Solution Design** | Translate requirements into an **viable solution** — how the system solves the user problem. Defines approach, components, and trade-offs before technical details. | Product Owners, Architects, Developers | Problem decomposition, solution approach, alternatives considered, high-level component diagram, decision rationale. | "Problem: Users need to compare wines. Solution: Build a comparison table with filtering, sorting, and visual comparison. Components: Data layer (Wine API), UI layer (Table component), Logic layer (Filter/Sort engine)." | 100% of user problems mapped to solution components before spec writing. |
+| **Walkthrough** | The **end-to-end trace** — maps the entire system flow from startup to cycle completion. Provides a "big picture" view that validates solution design before technical specification is locked. | Product Owners, Architects, Developers | End-to-end user journey, sequence diagrams, state machine diagrams. Explicitly links to solution-design.md and requirements.md. | "User logs in → selects wine → edits details → saves → backend validates against spec → UI updates with error states." | 100% of user journeys traced across all layers before implementation starts. |
+| **Specification** | The **technical contract** — precise rules for inputs, outputs, and data shape. Ensures consistency across dev and test. Maps technical implementation to both *what* (requirements) and *how* (solution design). | Developers, QA Engineers, CI/CD pipelines | OpenAPI, Protobuf, AsyncAPI. Endpoint definitions, schemas, error codes. | `contract.yaml` defining a NATS subject (solution-design SD-3.1) that accepts Arrow streams with snake_case headers (requirements FR-001). | 100% of messages validated against spec (CI block rate). |
 | **UI Specification** | The **design contract** — precise rules for UI components, interactions, and visual patterns. Ensures consistency across design and implementation. | Product Designers, Frontend Developers, QA Engineers | Component libraries, style guides, interaction specs, design tokens. | Atomic design system with Figma tokens synced to CSS variables. | 100% of UI components match design spec (visual regression tests). |
-| **Walkthrough** | The **end-to-end trace** — maps the entire system flow from startup to cycle completion. Provides a "big picture" view that aligns users and developers, exposing architectural gaps before coding begins. | Product Owners, Architects, Developers | End-to-end user journey, sequence diagrams, state machine diagrams. Explicitly links to specification.md and ui-specification.md. | "User logs in → selects wine → edits details → saves → backend validates against spec → UI updates with error states." | 100% of user journeys traced across all layers before implementation starts. |
+| **Validation** | The **enforcer** — defines tests before implementation begins to ensure spec compliance. Blocks drift and human error. | QA Engineers, Developers, Automation servers | Unit tests, integration tests, performance tests, penetration tests, contract tests, CI jobs, linting rules, schema validation. | CI job rejects PR with camelCase field not allowed by YAML spec. | <1% of PRs bypass validation gates. |
-| **Architecture** | The **blueprint** — how components fit together, interact, and scale. Guides system structure and trade-offs. | Architects, Senior Developers, DevOps | C4 diagrams, Mermaid.js, component/network/storage models. | Diagram showing 6-node cluster routing traffic via Caddy → Node.js API → Julia pods. | 100% of major decisions logged with trade-off analysis. |
+| **Implementation Plan** | The **execution roadmap** — how implementation is organized, prioritized, and delivered. Maps code to validation tests and specification. | Developers, Project Managers, Lead Developers | Implementation plan, module breakdown, task list, delivery timeline, test strategy. | Phase 1: Core API + data layer; Phase 2: UI components; Phase 3: Integration tests + E2E validation. | 100% of validation tests covered by implementation tasks, <10% timeline drift. |
-| **Implementation** | The **real code** — business logic, helpers, tests, configs. Where design becomes executable. | Developers, Code Reviewers | Source code, README.md, unit tests, setup scripts. | Julia function for matrix calculation + SvelteKit component rendering table. | >80% unit test coverage, <5% drift from spec. |
-| **Validation** | The **enforcer** — ensures implementation matches the spec. Blocks drift and human error. | Automation servers, QA, Lead Developers | CI jobs, contract tests, linting, integration checks. | CI job rejects PR with camelCase field not allowed by YAML spec. | <1% of PRs bypass validation gates. |
 | **Runbook** | The **operational manual** — how the system lives in production, scales, and recovers. Guides on-call engineers. | DevOps, SREs, On-call Developers | K8s manifests, Helm charts, Markdown guides. Deployment, scaling, backup/restore, troubleshooting. | GitOps manifest ensuring 6 Julia replicas restart if memory >80%. | MTTR <15 minutes for P1 incidents. |
 
 ---
@@ -30,26 +30,117 @@ This document defines the documentation framework for a software project. It est
 - Aligns engineering efforts with business goals
 - Provides a north star for feature development
 - Establishes acceptance criteria before implementation begins
-- Creates a contract between product and engineering
+- Creates a contract between product, engineering, security, and operations.
 
 **Content Guidelines**:
 - User stories with clear acceptance criteria (As a X, I want Y so that Z)
-- Product Requirements Documents (PRDs) with success metrics
+- **Functional Requirements (FR)**: Testable features with clear IDs (e.g., `FR-001`, `FR-101`). Each functional requirement must be linked to a measurable KPI in the success metrics section.
-- Non-functional requirements (performance, security, scalability)
+- **Non-Functional Requirements (NFR)**: Qualities or constraints the system must have (performance, scalability, availability, reliability, security, privacy, observability). NFRs define *what kind of system* you need, not *what it does*.
-- Boundary definitions (what's in scope vs. out of scope)
+  - Example NFR: "System shall support 10K TPS" (requirement)
-- Do not cite any other documents as requirements.md is the first document to be created in the ASG Framework
+  - Example KPI: "95th percentile latency <200ms" (measurable success metric)
+- **Success Metrics & KPIs**: Specific, measurable targets that validate whether requirements were met. KPIs are *measured after deployment*; NFRs are *defined before implementation*.
+- Boundary definitions that state what is in scope and out of scope.
+- Security requirements including threat model outcomes, authentication and authorization expectations, data classification, encryption requirements, and compliance controls.
+- Observability requirements specifying required telemetry, metrics, traces, logs, alerting thresholds, and retention policies.
+- Traceability Rule: Requirements must be self-contained (no cross-references to other docs as justification), but must include IDs (e.g., FR-001) so downstream artifacts (spec, UI spec, architecture) can trace back. All downstream documents MUST cite requirement IDs, but requirements themselves stand alone.
 
 **Best Practices**:
-- Link each requirement to a measurable KPI
+- **Link each requirement to a measurable KPI** — functional requirements should have explicit KPIs; non-functional requirements should have measurable thresholds
 - Keep requirements testable and verifiable
 - Maintain backward compatibility with existing requirements
 - Review and update requirements as business context changes
 
 ---
 
-### 2. Specification
+### 2. Solution Design
+`solution-design.md`
+
+**Purpose**: Translate requirements into an *viable solution* — how the system solves the user problem. Defines approach, components, and trade-offs before technical details.
+
+**Why It Matters**:
+- Prevents technical-first thinking that skips design decisions
+- Ensures the solution addresses the actual user problem, not just requirements
+- Enables architects to evaluate alternatives before committing to technical details
+- Creates alignment between product, design, and engineering on the approach
+- Provides a reference for evaluating specification choices against intended solution
+
+**Content Guidelines**:
+- Problem decomposition: Break down the user problem into smaller, solvable pieces
+- Solution approach: Describe the high-level approach (e.g., "Use event sourcing for audit trail", "Implement caching layer for performance")
+- Alternatives considered: Document at least 2-3 alternative approaches with rationale for why they were rejected
+- High-level component diagram: Show major components and their relationships (not technical details, just the big picture)
+- Decision rationale: Explain why each major decision was made (e.g., "Chose NATS over Kafka for simpler ops", "Used server-side rendering for SEO")
+- Risk assessment: Identify potential risks and how they will be mitigated
+- Traceability: Link each solution component to specific requirement ID(s) (e.g., FR-001, NFR-201) that it addresses
+- Decision IDs: Assign unique IDs to major decisions using the format `SD-XXX` (e.g., `SD-001` for "Use NATS for async messaging") to enable specification traceability
+
+**Best Practices**:
+- Write solution design from the user's perspective first, then justify technical choices
+- Keep it high-level—avoid technical specifics (API endpoints, data schemas, etc.)
+- Use diagrams that are easy to update (Mermaid.js)
+- Document trade-off decisions explicitly
+- Review solution design against requirements to verify completeness
+- Get sign-off from product, architecture, and engineering before creating walkthroughs
+
+**Gap-Check Question**: Does the Solution Design clearly explain how the system solves the user problem, not just what it does?
+
+**Example Gap**: Requirements say "users can compare wines", but solution design only mentions "wine comparison API" without explaining how users will actually use the comparison feature.
+
+---
+
+### 3. Walkthrough
+`walkthrough.md`
+
+**Purpose**: The *end-to-end trace* — maps the entire system flow from startup to cycle completion, incorporating both internal logic and external interactions. Provides a "big picture" view that aligns users and developers, validating the solution design before technical specification is locked.
+
+**Unified Lifecycle Review**
+The walkthrough functions as a collaborative audit, mapping the proposed solution directly onto your workflow to ensure a shared "single source of truth." It synchronizes the user's operational needs with the developer's technical implementation.
+
+**For the User: Validating Operational Utility**
+- **Visual Fidelity**: Concrete demonstration of the UI and user-facing components
+- **Workflow Integration**: Clear mapping of how the tool fits into existing day-to-day operations
+- **Operational Control**: Practical exposure to system controls and interaction patterns
+- **Outcome Verification**: Direct observation of the system's outputs and deliverables
+- **Impact Assessment**: Data-driven evaluation of the solution's ROI and efficiency gains
+- **Expectation Alignment**: Early discovery of discrepancies between intended functionality and actual experience
+
+**For the Developer: Aligning Architecture with Reality**
+- **Requirement Validation**: Confirming the solution satisfies core business objectives
+- **Impact Analysis**: Assessing the solution's real-world behavioral performance
+- **Knowledge Synthesis**: Identifying disconnects between domain intent and technical interpretation
+- **Specification Refinement**: Spotting missing technical dependencies or edge cases
+- **System Harmony**: Observing how the technical workflow and the user process interleave
+- **Code-to-Process Mapping**: Refining abstraction layers to better reflect the user's actual sequence of events
+
+**Why It Matters**:
+- Serves as a single source of truth for system behavior, bridging user experience and technical implementation
+- Validates that all components (UI, API, backend logic) work together cohesively before implementation begins
+- Exposes solution design gaps and integration risks early in the design phase
+- Aligns stakeholders (product, design, development) on the complete user journey
+- Provides a reference for verifying implementation against intended behavior and for tracing requirements through to architecture
+
+**Content Guidelines**:
+- End-to-end user journey from system startup to task completion
+- External interactions (user actions, API calls, third-party integrations)
+- Internal flow (state transitions, business logic, data transformations)
+- Error paths and edge cases with their handling
+- Sequence diagrams showing request/response patterns across all layers
+- State machine diagrams for complex workflows
+- Each major walkthrough step must cite the exact **Solution Design decision ID(s)** (e.g., SD-001, SD-002) from `solution-design.md` and/or **Requirement ID(s)** from `requirements.md` that it implements or depends on.
+
+**Best Practices**:
+- Write walkthroughs from the user's perspective first, then trace the technical implementation
+- Include concrete examples with realistic data values
+- Link each step to its corresponding Solution Design decision (SD-XXX IDs) and requirement IDs
+- Document failure modes and recovery paths
+- Keep walkthroughs updated as requirements evolve
+- Review walkthroughs against the solution design to verify completeness
+
+---
+
+### 4. Specification
 `specification.md`
-**Purpose**: The *technical contract* — precise rules for inputs, outputs, and data shape. Ensures consistency across dev and test.
+**Purpose**: The *technical contract* — precise rules for inputs, outputs, and data shape. Ensures consistency across dev and test. Maps technical implementation to both *what* (requirements) and *how* (solution design).
 
 **Why It Matters**:
 - Prevents implementation drift between components
@@ -64,7 +155,10 @@ This document defines the documentation framework for a software project. It est
 - Error codes and their meanings
 - Data validation rules and constraints
 - Rate limiting and quota definitions
-- Each specification item must cite the specific requirement ID(s) from requirements.md (for example, FR-001, NFR-201). Link each endpoint, schema, validation rule, error case, etc to the exact requirement(s) it implements or satisfies.
+- Each specification item must cite:
+  - **Requirement ID(s)** from requirements.md (e.g., FR-001, NFR-201) — defines *what* the system must do
+  - **Solution Design reference(s)** from solution-design.md (e.g., SD-2.1, SD-3.3) — defines *how* and *why* this technical approach was chosen
+  - Link each endpoint, schema, validation rule, error case, etc to the exact requirement(s) and solution design decision(s) it implements or satisfies.
 
 **Best Practices**:
 - Use formal specification languages (OpenAPI 3.0+, AsyncAPI)
@@ -75,7 +169,7 @@ This document defines the documentation framework for a software project. It est
 
 ---
 
-### 3. UI Specification
+### 5. UI Specification
 `ui-specification.md`
 
 **Purpose**: The *design contract* — precise rules for UI components, interactions, and visual patterns. Ensures consistency across design and implementation.
@@ -106,115 +200,40 @@ This document defines the documentation framework for a software project. It est
 
 ---
 
-### 4. Walkthrough
+### 6. Validation
-`walkthrough.md`
-
-**Purpose**: The *end-to-end trace* — maps the entire system flow from startup to cycle completion, incorporating both internal logic and external interactions. Provides a "big picture" view that aligns users and developers, exposing architectural gaps before coding begins.
-
-**Why It Matters**:
-- Serves as a single source of truth for system behavior, bridging user experience and technical implementation
-- Validates that all components (UI, API, backend logic) work together cohesively before implementation begins
-- Exposes architectural gaps and integration risks early in the design phase
-- Aligns stakeholders (product, design, development) on the complete user journey
-- Provides a reference for verifying implementation against intended behavior
-
-**Content Guidelines**:
-- End-to-end user journey from system startup to task completion
-- External interactions (user actions, API calls, third-party integrations)
-- Internal flow (state transitions, business logic, data transformations)
-- Error paths and edge cases with their handling
-- Sequence diagrams showing request/response patterns across all layers
-- State machine diagrams for complex workflows
-- Each major walkthrough step must cite the exact specification ID(s) or spec path(s) in specification.md and/or the UI‑spec artifact ID(s) or path(s) in ui-specification.md that it implements or depends on.
-
-**Best Practices**:
-- Write walkthroughs from the user's perspective first, then trace the technical implementation
-- Include concrete examples with realistic data values
-- Link each step to its corresponding specification and UI spec sections
-- Document failure modes and recovery paths
-- Keep walkthroughs updated as requirements evolve
-- Review walkthroughs against architecture to verify feasibility
-
----
-
-### 5. Architecture
-`architecture.md`
-
-**Purpose**: The *blueprint* — how components fit together, interact, and scale. Guides system structure and trade-offs.
-
-**Why It Matters**:
-- Provides a mental model for system design
-- Guides technical decision-making and trade-off analysis
-- Facilitates onboarding of new architects and senior developers
-- Documents scaling and performance considerations
-- Enables traceability from technical specifications and UI specifications to architectural decisions
-
-**Content Guidelines**:
-- C4 diagrams (Context, Container, Component levels)
-- Mermaid.js flowcharts for sequence diagrams
-- Component interaction diagrams
-- Network topology and data flow
-- Storage and caching strategies
-- Scaling and resilience patterns
-- Each architecture component must cite the exact specification ID(s) or spec path(s) in specification.md and/or the UI‑spec artifact ID(s) or path(s) in ui-specification.md that it implements or depends on.
-
-**Best Practices**:
-- Use diagrams that are easy to update (Mermaid.js over static images)
-- Document trade-off decisions with Rationale Documents
-- Include scaling considerations for each component
-- Document failure modes and recovery strategies
-- Keep architecture diagrams versioned with code
-
----
-
-### 6. Implementation
-
-**Purpose**: The *real code* — business logic, helpers, tests, configs. Where design becomes executable.
-
-**Why It Matters**:
-- This is the actual artifact that runs in production
-- Code is the ultimate source of truth (when it matches spec)
-- Tests validate correctness and prevent regressions
-- Configuration files define runtime behavior
-
-**Content Guidelines**:
-- Business logic implementation
-- Helper functions and utilities
-- Unit and integration tests
-- Configuration files (YAML, JSON, environment)
-- Setup and development scripts
-- Code organization and module structure
-
-**Best Practices**:
-- Follow consistent code style and conventions
-- Write tests before or alongside implementation (TDD/BDD)
-- Document complex logic with inline comments
-- Keep configuration externalized and versioned
-- Use type annotations where applicable
-
----
-
-### 7. Validation
 `validation.md`
 
-**Purpose**: The *enforcer* — ensures implementation matches the spec. Blocks drift and human error.
+**Purpose**: The *enforcer* — defines tests **before implementation begins** to ensure spec compliance. Blocks drift and human error.
 
 **Why It Matters**:
+- Ensures tests are written before implementation, so code can be tested as it's built
 - Prevents breaking changes from reaching production
 - Catches specification violations early in the CI pipeline
 - Maintains data integrity and API consistency
 - Reduces manual QA effort through automation
+- Provides immediate feedback to developers during implementation
+- Validates performance NFRs (latency, throughput) against measurable KPIs before deployment
+- Validates security requirements through adversarial testing before production
 
 **Content Guidelines**:
-- CI/CD pipeline configurations
+- **Unit tests** — atomic tests for each specification rule, data schema field, and UI component state (cites specification.md sections, ui-specification.md component specs)
-- Contract testing scripts
+- **Integration tests** — end-to-end flow validation covering workflows defined in walkthrough.md (cites specification.md endpoint chains, walkthrough.md journeys)
-- Linting rules and configurations
+- **Performance tests** — load tests, stress tests, and benchmarking against NFR thresholds (cites requirements.md NFRs, solution-design.md performance decisions)
-- Integration test suites
+- **Penetration tests** — adversarial testing of security requirements and auth flows (cites requirements.md security NFRs, specification.md auth endpoints)
-- Schema validation jobs
+- Contract testing scripts (mapped to specification.md sections)
-- Security scanning and audit jobs
+- Linting rules and configurations (enforcing style guides from ui-specification.md)
-- Each validation must include explicit references to requirements.md (e.g., FR-001, NFR-201), specification.md (exact spec IDs or paths — API contracts, data schemas, e.g., sections 3.1, 4.2), and ui-specification.md (components, interactions, visual states, e.g., sections 15.1, 15.3) as applicable.
+- Schema validation jobs (validating data shapes from specification.md)
+- Visual regression tests (verifying UI matches ui-specification.md)
+- Security scanning and audit jobs (SAST, dependency vulnerability checks)
+- CI/CD pipeline configurations for automated test execution
+- Each validation test must include explicit references to:
+  - **specification.md** (exact spec IDs or paths — API contracts, data schemas, e.g., sections 3.1, 4.2) — technical rules being tested
+  - **ui-specification.md** (components, interactions, visual states, e.g., sections 15.1, 15.3) — UI contract being verified
+  - **requirements.md** (e.g., FR-001, NFR-101, NFR-201) — business intent and NFR thresholds being validated
+  - **solution-design.md** (e.g., SD-2.1, SD-3.3) — architectural decisions being tested
 
 **Best Practices**:
+- Define tests **before** writing implementation code
 - Fail CI on specification violations
 - Run validation jobs on every commit and PR
 - Use automated code review tools
@@ -223,6 +242,73 @@ This document defines the documentation framework for a software project. It est
 
 ---
 
+#### Specification-to-Test Execution Trace
+
+Every specification rule must have a runnable, verifiable test. This trace maps each spec item to its corresponding test file, test function, and CI gate — proving that every requirement was tested, not just claimed.
+
+**Trace Format**:
+
+| Requirement ID | Source Path | Unit Test File | Unit Test Function | Additional Test File(s) | CI Gate | Status |
+|----------------|-------------|----------------|-------------------|------------------------|---------|--------|
+| FR-001 | `specification.md:3.2.1` | `tests/unit/schema-validation.test.ts` | `test_rejects_camelCase_headers` | — | `ci/contract-validation.yaml` | Pass |
+| FR-002 | `specification.md:4.1` | `tests/unit/api-routes.test.ts` | `test_post_wine_returns_201` | `tests/integration/wine-flow.test.ts` | `ci/contract-validation.yaml` | Pass |
+| FR-003 | `specification.md:3.2.3` | — | — | `tests/integration/error-handling.test.ts` | `ci/contract-validation.yaml` | Pass |
+| NFR-101 | `requirements.md:4.1` | — | — | `tests/performance/load.test.ts` | `ci/performance.yaml` | Pass |
+| SD-001 | `solution-design.md:5.1` | — | — | `tests/integration/nats-async.test.ts` | `ci/integration.yaml` | Pass |
+| UI-15.3.2 | `ui-specification.md:15.3.2` | `tests/unit/wine-table.test.tsx` | `test_sort_by_name` | `tests/visual/wine-table.spec.js` | `ci/visual-regression.yaml` | Pass |
+
+**Additional Test File(s)** column covers: integration tests (walkthrough flows), performance tests (NFR benchmarks), penetration tests (security NFRs), and visual regression tests (UI component states).
+
+**Trace Rules**:
+- **Every** specification section with a concrete rule (endpoint, schema field, validation constraint, error code) must have at least one unit test
+- **Every** walkthrough journey must have at least one integration test
+- **Every** performance NFR must have at least one performance test (load/stress/benchmark)
+- **Every** security NFR must have at least one penetration test scenario
+- **Every** UI component state must have at least one unit test (behavior) and one visual regression test (appearance)
+- A test may cover multiple spec items, but each spec item must be covered by **at least one** test
+- Status is tracked via CI gate results (Pass/Fail/Skipped) — not manual checks
+
+**How to Maintain**:
+1. When writing a new spec rule, add a trace row **before** implementation
+2. When writing the test, fill in the test file and function
+3. CI gate auto-updates Status from pipeline results
+4. Gap-Check step 6 (Validation Review) verifies 100% row coverage — no spec rule without a test
+
+**Tooling** (optional):
+- Use YAML or JSON files (e.g., `validation/test-trace.yaml`) as machine-readable trace data
+- Generate CI reports that auto-populate the Status column from pipeline results
+- Use tools like `cypress open` for E2E traces, `k6` for performance traces, `owasp-zap` for pen test traces
+- Integrate trace data into PR descriptions so reviewers can verify coverage before merge
+
+---
+
+### 7. Implementation Plan
+`implementation-plan.md`
+
+**Why It Matters**:
+- Converts specification into executable code with clear ownership and timeline
+- Enables parallel development across teams by defining module boundaries
+- Provides visibility into progress and blockers for stakeholders
+- Ensures all validation tests are covered by implementation tasks
+
+**Content Guidelines**:
+- Implementation phases and timeline (e.g., Phase 1: Core API + data layer; Phase 2: UI components; Phase 3: Integration tests + E2E validation)
+- Module/component breakdown with responsibilities and dependencies
+- Task list with assignees, priorities, and estimated effort
+- Test coverage: which validation tests each implementation task satisfies
+- Build and deployment preparation (CI/CD setup, environment configuration)
+- Risk mitigation: known blockers and mitigation steps
+
+**Best Practices**:
+- Break implementation into small, testable increments (1-3 day sprints)
+- Map each implementation task to specific validation tests (not just specification sections)
+- Define clear ownership for each module or component
+- Include test coverage targets for each phase
+- Document dependencies between modules to avoid blocking work
+- Review implementation plan against validation tests to ensure complete coverage
+
+---
+
 ### 8. Runbook
 `runbook.md`
 
@@ -241,8 +327,8 @@ This document defines the documentation framework for a software project. It est
 - Troubleshooting guides for common issues
 - Runbook entries for specific error codes
 - Contact information and escalation paths
-- Explicit references to [`specification.md`](specification.md) (API contracts, data schemas, specification.md sections 3.1, 4.2)
+- Explicit references to [`specification.md`](specification.md) (API contracts, data schemas, specific endpoint sections)
-- Explicit references to [`ui-specification.md`](ui-specification.md) (components, interactions, visual states, ui-specification.md sections 15.1, 15.3)
+- Explicit references to [`ui-specification.md`](ui-specification.md) (components, interactions, visual states, specific component sections)
 
 **Best Practices**:
 - Write runbooks for every P1/P2 incident
@@ -264,41 +350,43 @@ Before writing any code or documentation, establish clear requirements. Ask:
 
 **Action**: Create a `docs/requirements/` directory and start with `PRD.md` and `KPIs.md`.
 
-### 2. Define the Specification First
+### 2. Define Solution Design
 
-Once requirements are stable, define the technical specification. This becomes the contract for implementation.
+Once requirements are stable, translate them into an viable solution. This ensures the technical approach solves the user problem, not just requirements.
 
-**Action**: Create `docs/specification/` with `contract.yaml` (or appropriate format) and `error-codes.md`.
+**Action**: Create `docs/solution-design/` with `solution-design.md`, problem decomposition, alternatives considered, high-level component diagram, and decision rationale.
 
-### 3. Define UI Specification Early
+### 3. Create Walkthroughs Early
+
+As soon as the solution design is defined, create walkthroughs. This helps identify gaps in the flow and provides onboarding material. The walkthrough should be a single source of truth that explicitly links to solution-design.md (SD-XXX IDs) and requirements.md.
+
+**Action**: Create `docs/walkthrough/` with `TOUR.md`, sequence diagrams, and cross-references to solution design decisions and requirements.
+
+### 4. Define the Specification
+
+With walkthrough in place, define the technical specification. This becomes the contract for implementation. Each specification item must trace to **both**:
+- **Requirements** (WHAT - business intent)
+- **Solution Design** (HOW/WHY - architectural decisions)
+
+**Action**: Create `docs/specification/` with `contract.yaml` (or appropriate format), `error-codes.md`, and traceability mappings to requirements.md, solution-design.md, and walkthrough.md.
+
+### 5. Define UI Specification Early
 
 Create UI specifications before implementing frontend components. This ensures design consistency and provides a contract for implementation.
 
 **Action**: Create `docs/ui-specification/` with `component-library.md`, `style-guide.md`, and `design-tokens.json`.
 
-### 4. Create Walkthroughs Early
+### 6. Define Validation Tests Before Implementation
 
-As soon as the UI specification is defined, create walkthroughs. This helps identify gaps in the flow and provides onboarding material. The walkthrough should be a single source of truth that explicitly links to specification.md and ui-specification.md.
+Write validation tests **before** implementation begins. This ensures every specification rule and UI state has a corresponding test that defines success. Tests should reference specification.md, ui-specification.md, requirements.md (NFR thresholds), and solution-design.md (performance decisions). Create a specification-to-test execution trace that maps every spec item to its test file, test function, and CI gate.
 
-**Action**: Create `docs/walkthrough/` with `TOUR.md`, sequence diagrams, and cross-references to specification and UI spec sections.
+**Action**: Create `docs/validation/` with `unit-tests/` (spec rules, schema fields, component states), `integration-tests/` (end-to-end flows from walkthrough.md), `performance-tests/` (NFR benchmarks: latency, TPS), `penetration-tests/` (security NFRs, auth flows), `contract-tests/`, `ci-pipeline.yaml`, `lint-rules/`, and `test-trace.yaml` (specification-to-test execution trace mapping every spec path to its test file, test function, and CI gate).
 
-### 5. Design the Architecture
+### 7. Create Implementation Plan
 
-With requirements, specification, UI spec, and walkthrough in place, design the architecture. Document trade-off decisions explicitly.
+With validation tests defined, create the implementation plan. Map each implementation task to specific validation tests that it must satisfy.
 
-**Action**: Create `docs/architecture/` with Mermaid diagrams and `trade-offs.md`.
+**Action**: Create `docs/implementation-plan/` with phases, module breakdown, task list with assignees, and test coverage targets.
-
-### 6. Implement with Validation in Mind
-
-Write implementation code that adheres to the specification. Build validation into the CI pipeline from day one.
-
-**Action**: Ensure test files are co-located with implementation and run on every commit.
-
-### 7. Automate Validation
-
-Build automated validation that runs in CI/CD. This ensures spec compliance and prevents drift.
-
-**Action**: Configure CI jobs to validate against specification and block PRs on violations.
 
 ### 8. Document Operations from Day One
 
@@ -314,25 +402,32 @@ Since all docs defined in the ASG Framework are **living documents** that evolve
 
 | Stage Transition | Goal | Gap-Check Question | Example Gap | Result |
 |------------------|------|-------------------|-------------|--------|
-| **Requirements → Specification** | Turn a "Wish" into a "Rule" | Does the Specification define all edge cases and conflict scenarios from the Requirements? | Requirement says "invite a teammate" but Specification doesn't define what happens if the teammate already has an account | Add a `UserConflict` rule to the Specification |
+| **Requirements → Solution Design** | Turn a "Wish" into a "Solution" | Does the Solution Design clearly explain how the system solves the user problem, not just what it does? | Requirements say "users can compare wines", but solution design only mentions "wine comparison API" without explaining how users will actually use the comparison feature | Add UI flow and user interaction patterns to the solution design |
+| **Solution Design → Walkthrough** | Turn a "Solution" into a "Story" | Does the Walkthrough trace the complete flow the Solution Design describes, including all SD-XXX decisions? | Solution design says "use NATS for async messaging", but Walkthrough doesn't trace the async flow or reference SD-001 | Add the async messaging flow with SD-001 reference to Walkthrough |
+| **Walkthrough → Specification** | Turn the "Story" into "Rules" | Does the Specification cover all the behaviors defined in the Walkthrough? | Walkthrough shows 10 IoT sensors sending real-time updates, but Specification only defines REST API | Add NATS/MQTT protocol definitions to Specification |
 | **Specification → UI Specification** | Turn a "Rule" into a "Button" | Does the UI Specification expose all the data and states defined in the Specification? | Specification says device must "Handshake" within 5 seconds, but UI Specification has no connection status indicator | Add a `Connection Status` component to UI Specification |
-| **UI Specification → Walkthrough** | Turn "Screens" into a "Story" | Does the Walkthrough reflect the complete flow including error states and timing? | Walkthrough shows "Success" screen, but Specification says backend process takes 2 minutes | Add a `Processing` state to UI Specification and `JobStatus` field to Specification |
+| **UI Specification → Validation** | Turn "Design" into "Tests" | Do the Validation tests cover all specification rules, UI states, performance NFRs, and security requirements? | UI Spec defines 15 component states but Validation only has 5 unit tests; NFR-101 latency threshold has no performance test | Add unit tests for all component states, performance benchmarks for NFR thresholds, and pen test scenarios for security NFRs |
-| **Walkthrough → Architecture** | Turn the "Story" into "Steel" | Does the Architecture support the performance and integration requirements defined in the Walkthrough? | Walkthrough shows 10 IoT sensors sending real-time updates, but Architecture uses REST API | Switch to NATS/MQTT for high-frequency data flow |
+| **Validation → Implementation Plan** | Turn "Tests" into "Tasks" | Does the Implementation Plan satisfy all validation tests with clear ownership? | Validation defines 30 test cases but Implementation Plan only has tasks for 20 | Add implementation tasks for remaining test cases with assignees and timelines |
 
 ### Why Gap-Checks Matter
 
 - **Prevent rework**: Catch missing requirements before coding begins
 - **Ensure completeness**: Verify all scenarios are covered across all layers
-- **Validate feasibility**: Confirm architectural decisions support the intended user flow
+- **Validate feasibility**: Confirm technical approach supports the intended user flow
 - **Maintain alignment**: Keep all stakeholders (product, design, dev) on the same page
 
 ### How to Run Gap-Checks
 
 1. **Requirements Review**: After writing requirements, ask "What happens if X?" for each user story
-2. **Specification Review**: After writing the spec, verify every requirement has at least one rule with a corresponding requirement ID reference
+2. **Solution Design Review**: After writing solution design, verify every requirement is addressed by at least one solution component with a corresponding requirement ID reference
-3. **UI Specification Review**: After writing UI Specification, verify every spec rule has at least one UI representation with a corresponding requirement ID reference
+3. **Walkthrough Review**: After writing walkthrough, verify every SD-XXX decision and requirement is traced in the end-to-end flow with error paths included
-4. **Walkthrough Review**: After writing walkthrough, verify every UI step has a corresponding backend flow
+4. **Specification Review**: After writing the spec, verify every spec item has:
-5. **Architecture Review**: After designing architecture, verify every walkthrough flow is technically feasible and every architecture decision references specification and UI specification sections
+   - At least one requirement ID reference (WHAT)
+   - At least one solution design reference (HOW/WHY)
+   - Coverage for all behaviors defined in the Walkthrough
+5. **UI Specification Review**: After writing UI Specification, verify every spec rule has at least one UI representation with a corresponding requirement ID reference
+6. **Validation Review**: After writing Validation, verify every specification section and UI state has at least one corresponding unit/integration test case; every performance NFR has a benchmark test; every security NFR has a penetration test scenario — each with explicit references to specification.md, ui-specification.md, and/or requirements.md
+7. **Implementation Plan Review**: After writing the plan, verify every validation test is covered by at least one implementation task with an assignee and timeline
 
 ---
 
@@ -343,10 +438,11 @@ This habit ensures that each documentation stage is complete and validated befor
 | Stage | Debug Checklist | Why It Matters |
 |-------|-----------------|----------------|
 | **Requirements** | If I can't state the Value, I'm building a feature nobody needs. | Clarifies the business impact before technical discussion begins |
-| **Specification** | If I can't write a Rule with a requirement ID reference, I haven't thought the logic through. | Ensures traceability from technical rules to business requirements |
+| **Solution Design** | If I can't Imagine the solution, I'm building without a compass. | Ensures the technical approach solves the user problem before spec writing |
+| **Walkthrough** | If I can't Trace the full flow, the system has a 'broken bridge'. | Identifies gaps between components and validates the solution design end-to-end |
+| **Specification** | If I can't write a Rule with a requirement ID reference AND/OR solution design reference, I haven't thought the logic through. | Ensures traceability from technical rules to both business requirements (*what*) and architectural decisions (*how/why*) |
 | **UI Specification** | If I can't See it with a requirement ID reference, the user has no way to trigger the logic. | Ensures traceability from UI elements to business requirements |
-| **Walkthrough** | If I can't Trace the full flow, the system has a 'broken bridge'. | Identifies gaps between components before implementation begins |
+| **Validation** | If I can't Write a Test for every spec rule, UI state, NFR threshold, and security requirement, implementation is untestable. | Ensures code can be tested from day one — unit, integration, performance, and pen tests define success before implementation begins |
-| **Architecture** | If the Walkthrough doesn't Require it, or if I can't trace spec/UI-spec references, I'm over-engineering or missing requirements. | Ensures traceability from architecture to spec/UI-spec and requirements |
 
 **How to Use This Habit:**
 
@@ -379,9 +475,9 @@ Each documentation artifact has associated KPIs. Track these to ensure quality:
 | Document | KPI | Target |
 |----------|-----|--------|
 | Requirements | Requirement coverage | 100% of features have associated requirements |
+| Solution Design | Solution completeness | 100% of user problems mapped to solution components before spec writing |
 | Specification | Specification compliance rate | 100% of messages validate against spec |
 | UI Specification | UI spec compliance | 100% of components match design spec (visual regression tests) |
-| Architecture | Decision documentation | 100% of major decisions logged with trade-offs |
 | Walkthrough | New dev time-to-first-PR | <2 days from onboarding to first contribution |
 | Implementation | Test coverage | >80% unit test coverage |
 | Validation | Bypass rate | <1% of PRs bypass validation gates |
@@ -394,6 +490,23 @@ Each documentation artifact has associated KPIs. Track these to ensure quality:
 
 ---
 
+## Deployment Decision Rules
+
+These rules define the critical gates that must be passed before and after deployment:
+
+- **Acceptance Condition NOT met → Don't deploy** (buggy/broken)
+- **KPI NOT met after deployment → Deployed feature is failing business goals (need fix/optimization)**
+
+**Acceptance Conditions** are verified *before deployment* through testing and validation. They determine whether the implementation matches the specification and is ready for production.
+
+**KPIs** are measured *after deployment* to validate whether the feature is achieving its business goals. If KPIs are not met, the feature may be deployed but is failing its intended purpose and requires immediate attention (fixes or optimization).
+
+These rules serve as a binary decision framework:
+- Acceptance Conditions = **Quality Gate** (deploy or block)
+- KPIs = **Business Health Monitor** (deploy but fix if failing)
+
+---
+
 ## Template Examples
 
 ### Requirements Template
@@ -401,26 +514,183 @@ Each documentation artifact has associated KPIs. Track these to ensure quality:
 ```markdown
 # PRD: Feature Name
 
-## Business Goal
+## 1. Business Context & Success Metrics
-[What problem are we solving?]
 
-## Success Metrics
+### Business Goal
-- [Metric 1]: Target [value]
+[Clear statement of the business problem being solved and why]
-- [Metric 2]: Target [value]
 
-## User Stories
+### User Stories
-- As a [role], I want [feature] so that [benefit]
+- **US-XXX**: [User story with clear action and value]
-  - Acceptance Criteria: [details]
+- *Example: US-001 - As a wine retailer customer, I want to access the sommpanion chat so that I can get wine-related help quickly*
 
-## Non-Functional Requirements
+### KPIs & Targets
-- Performance: [details]
+- **KPI-XXX**: [Measurable target with validation reference]
-- Security: [details]
+- *Example: KPI-001 - 95% of chat messages receive responses within 3 seconds (validates FR-001)*
-- Scalability: [details]
 
-## Out of Scope
+## 2. Technical Boundaries
-- [What's explicitly excluded]
+
+### In Scope
+[List features and capabilities included in this release]
+
+### Out of Scope
+[List features explicitly excluded from this release]
+
+### Dependencies
+[List external services, APIs, or systems this feature depends on]
+
+### Deployment Constraints
+- **NFR-XXX**: [Deployment-specific requirement]
+- *Example: NFR-501 - System shall be deployed to MicroK8s cluster with relative URL support*
+
+## 3. Functional Requirements (FR)
+
+### FR-XXX: [Requirement Title]
+[Detailed description of what the system shall do]
+- [Specific behavior 1]
+- [Specific behavior 2]
+- [Specific behavior 3]
+
+**Traceability**: US-XXX, US-XXX
+
+### FR-XXX: [Requirement Title]
+[Detailed description of what the system shall do]
+- [Specific behavior 1]
+
+**Traceability**: US-XXX
+
+## 4. Non-Functional Requirements (NFRs)
+
+### 4.1 Performance & Scalability
+- **NFR-XXX**: [Performance requirement with measurable threshold]
+- *Example: NFR-101 - Support page shall load in <1 second on 3G networks*
+
+### 4.2 Availability & Reliability
+- **NFR-XXX**: [Reliability requirement]
+- *Example: NFR-201 - Chat functionality shall have 99.9% monthly uptime*
+
+### 4.3 Privacy & Security
+- **Data Classification**: [e.g., PII, PHI, commercial data]
+- **Encryption**: [e.g., TLS 1.3+, AES-256 at rest]
+- **Authentication**: [e.g., Session-based, OAuth2, API keys]
+- **Compliance**: [e.g., GDPR Art. 32, SOC2 Type II, HIPAA]
+
+### 4.4 Observability & Telemetry
+- **Required Logs**: [e.g., `session_id`, `user_id`, `message_id`, `event_type`, `timestamp`, `latency_ms`]
+- **Critical Metrics**:
+  - `metric_name_1`
+  - `metric_name_2`
+- **Tracing**: [e.g., Zipkin/B3 propagation, 10% sampling]
+- **Alerting**: [e.g., `chat_delivery_rate < 95%` triggers PagerDuty]
+- **Retention**: [e.g., Logs: 30 days, Metrics: 1 year]
+
+## 5. Acceptance Conditions
+
+- [ ] **FR-XXX**: [Verifiable acceptance condition]
+- [ ] **FR-XXX**: [Verifiable acceptance condition]
+- [ ] **NFR-XXX**: [Verifiable acceptance condition]
+- *Example: [ ] FR-001: Sommpanion landing page renders with all required elements*
+
+## 6. Requirements Traceability Matrix
+
+| Requirement ID | Description | Implementation File | Test File |
+|----------------|-------------|---------------------|-----------|
+| FR-XXX | [Brief description] | `path/to/file.ext` | `tests/file.spec.js` |
+| NFR-XXX | [Brief description] | `path/to/file.ext` | `tests/file.spec.js` |
+
+**Notes**:
+- Functional Requirements (FR) define what the system shall do
+- Non-Functional Requirements (NFR) define system qualities (performance, availability, security, etc.)
+- KPIs are measurable targets that validate whether requirements were met post-deployment
+- Each requirement must include a clear requirement ID for traceability
+- All acceptance conditions must be verifiable through testing or manual inspection
 ```
 
+### Solution Design Template
+
+```markdown
+# Solution Design: Feature Name
+
+## 1. Problem Decomposition
+
+Break down the user problem into smaller, solvable pieces.
+
+| Problem | Description | User Impact |
+|---------|-------------|-------------|
+| [Problem ID] | Brief description of the problem | How this affects the user |
+
+**Example**: 
+- **P-001**: Users cannot compare multiple wines side-by-side → They must navigate between wine pages, losing context and making comparisons difficult
+
+## 2. Solution Approach
+
+Describe the high-level approach to solving the problem.
+
+**Approach**: [e.g., "Implement a comparison table with filtering, sorting, and visual comparison features"]
+
+**Key Principles**:
+- [e.g., "Keep comparison data in memory for instant updates"]
+- [e.g., "Use server-side rendering for SEO"]
+- [e.g., "Support unlimited wine comparisons for power users"]
+
+## 3. Alternatives Considered
+
+Document at least 2-3 alternative approaches with rationale.
+
+| Alternative | Pros | Cons | Decision |
+|-------------|------|------|----------|
+| Client-side comparison | Fast updates, no server load | Memory-intensive, no sharing | Rejected - memory constraints on mobile |
+| Server-side comparison | Centralized, scalable | Latency, complex state sync | Accepted - matches performance requirements |
+| Hybrid approach | Best of both worlds | Complex, hard to maintain | Rejected - over-engineering |
+
+## 4. High-Level Component Diagram
+
+```mermaid
+%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#3b82f6'}}}%%
+flowchart TD
+    A[User] --> B[Comparison UI]
+    B --> C[Comparison State]
+    B --> D[Wine API]
+    C --> D
+```
+
+**Component Descriptions**:
+- **[Component Name]**: [Brief description of responsibilities and how it solves part of the problem]
+  - Links to requirements: FR-001, NFR-201
+
+## 5. Decision Rationale
+
+Explain why each major decision was made.
+
+| Decision ID | Decision | Rationale | Alternatives Rejected |
+|-------------|----------|-----------|----------------------|
+| SD-001 | Use NATS for async messaging | Required for real-time messaging with low overhead | Kafka - too complex for current scale |
+| SD-002 | Use WebSockets for real-time updates | Required for <100ms feedback | REST polling - too slow, too many requests |
+| SD-003 | Store comparison list in localStorage | Allows offline comparison editing | Redux - overkill for this feature |
+| SD-004 | Server-side rendering for comparison export | SEO for shared comparisons | Client-side rendering - no SEO benefit |
+
+## 6. Risk Assessment
+
+Identify potential risks and mitigation strategies.
+
+| Risk | Impact | Probability | Mitigation |
+|------|--------|-------------|------------|
+| Performance degradation with >5 wines | High | Medium | Implement performance profiling, limit to 10 wines max |
+| Race conditions in real-time updates | Medium | Low | Use optimistic updates with rollback |
+| Memory leaks from comparison state | Medium | Medium | Implement cleanup on unmount, use weak references |
+
+## 7. Requirements Traceability
+
+Link each solution component to specific requirements and assign Solution Design IDs for specification traceability.
+
+| Solution Component | Requirement ID | Decision ID | Description |
+|-------------------|----------------|-------------|-------------|
+| Comparison table UI | FR-101 | SD-001 | Display wines in table format (uses NATS messaging) |
+| Filtering | FR-102 | SD-002 | Filter wines by criteria (uses WebSocket updates) |
+| Sorting | FR-103 | SD-003 | Sort wines by any column (stored in localStorage) |
+| Real-time updates | NFR-201 | SD-002 | Updates appear within 100ms (uses WebSocket) |
+| Export comparison | FR-201 | SD-004 | Export comparison to PDF/CSV (uses server-side rendering) |
+
+
 ### Specification Template
 
 ```yaml
@@ -429,7 +699,7 @@ openapi: 3.0.0
 info:
   title: NATSBridge API
   version: 1.0.0
-  description: Technical specification with requirements traceability
+  description: Technical specification with requirements and solution design traceability
 paths:
   /api/v1/endpoint:
     post:
@@ -445,7 +715,8 @@ paths:
             application/json:
               schema:
                 $ref: '#/components/schemas/Response'
-      x-requirement-id: FR-001  # Reference to Requirements document
+      x-requirement-id: FR-001    # Reference to Requirements document (WHAT)
+      x-solution-design-ref: SD-3.1  # Reference to Solution Design decision (HOW/WHY)
 components:
   schemas:
     Request:
@@ -453,13 +724,15 @@ components:
       properties:
         data:
           type: string
-          x-requirement-id: FR-002  # Reference to Requirements document
+          x-requirement-id: FR-002    # Reference to Requirements document (WHAT)
+          x-solution-design-ref: SD-3.2  # Reference to Solution Design decision (HOW/WHY)
     Response:
       type: object
       properties:
         status:
           type: string
-          x-requirement-id: FR-003  # Reference to Requirements document
+          x-requirement-id: FR-003    # Reference to Requirements document (WHAT)
+          x-solution-design-ref: SD-3.1  # Reference to Solution Design decision (HOW/WHY)
 ```
 
 ### UI Specification Template
@@ -473,9 +746,9 @@ components:
 **Version**: 1.0.0
 
 ## Requirements Traceability
-| UI Element | Requirement ID | Description |
+| UI Element | Requirement ID | Solution Design Ref | Description |
-|------------|----------------|-------------|
+|------------|----------------|---------------------|-------------|
-| Login form | FR-001 | Username/password authentication |
+| Login form | FR-001 | SD-2.1 | Username/password authentication |
 | Sidebar menu | NFR-202 | Collapsible sidebar for usability |
 | Wine table | FR-101 | Sortable, searchable inventory table |
 
@@ -524,19 +797,19 @@ flowchart TD
 ```
 
 **Specification Traceability:**
-| Architecture Component | Specification Section | UI Specification Section | Requirement ID |
+| Architecture Component | Solution Design Ref | Specification Section | UI Specification Section | Requirement ID |
-|------------------------|----------------------|--------------------------|----------------|
+|------------------------|---------------------|----------------------|--------------------------|----------------|
-| NATS Bridge (smartsend) | specification.md:3.1 | - | FR-301, NFR-201 |
+| NATS Bridge (smartsend) | SD-3.1 | specification.md:3.1 | - | FR-301, NFR-201 |
-| Login Form | specification.md:10.1 | ui-specification.md:15.2.1 | FR-001, NFR-201 |
+| Login Form | SD-2.1 | specification.md:10.1 | ui-specification.md:15.2.1 | FR-001, NFR-201 |
-| Wine Inventory Table | specification.md:4.2 | ui-specification.md:15.3.3 | FR-101, NFR-205 |
+| Wine Inventory Table | SD-2.2 | specification.md:4.2 | ui-specification.md:15.3.3 | FR-101, NFR-205 |
-| Sidebar Menu | specification.md:11.1 | ui-specification.md:15.3.2 | NFR-202 |
+| Sidebar Menu | SD-2.3 | specification.md:11.1 | ui-specification.md:15.3.2 | NFR-202 |
 
 **Component Details:**
-- **Caddy**: Static file serving (specification.md:2.2, ui-specification.md:15.1)
+- **Caddy**: Static file serving (specification.md:2.2, ui-specification.md:15.1, solution-design.md:SD-1.1)
-- **Node.js API**: NATS bridge client (specification.md:3.1)
+- **Node.js API**: NATS bridge client (specification.md:3.1, solution-design.md:SD-3.1)
-- **Julia Worker**: Backend processing (specification.md:4.1)
+- **Julia Worker**: Backend processing (specification.md:4.1, solution-design.md:SD-4.1)
-- **NATS Cluster**: Message bus (specification.md:3.3)
+- **NATS Cluster**: Message bus (specification.md:3.3, solution-design.md:SD-3.3)
-- **Storage**: Data persistence (specification.md:5.1)
+- **Storage**: Data persistence (specification.md:5.1, solution-design.md:SD-5.1)
 
 ### Runbook Template
 
@@ -567,7 +840,7 @@ flowchart TD
 
 ## Conclusion
 
-This ASG + GitOps Documentation Framework ensures that documentation is:
+This ASG Documentation Framework ensures that documentation is:
 - **Structured**: Eight distinct artifacts with clear purposes
 - **Automated**: Validation and CI/CD integration
 - **Versioned**: All documentation in git with history