diff --git a/.github/agents/code-review.agent.md b/.github/agents/code-review.agent.md
index cee797f..bb48e5c 100644
--- a/.github/agents/code-review.agent.md
+++ b/.github/agents/code-review.agent.md
@@ -15,7 +15,7 @@ Formal reviews are a quality enforcement mechanism, and as such MUST be performe
 1. Download the
    <https://github.com/demaconsulting/ContinuousCompliance/raw/refs/heads/main/docs/review-template/review-template.md>
    to get the checklist to fill in
-2. Use `dotnet reviewmark --elaborate [review-set]` to get the files to review
+2. Use `dotnet reviewmark --elaborate {review-set}` to get the files to review
 3. Review the files all together
 4. Populate the checklist with the findings to `.agent-logs/reviews/review-report-{review-set}.md` of the project.
 
@@ -41,33 +41,34 @@ of the project consisting of:
 
 ## Review Summary
 
-- **Review Set**: [Review set name/identifier]
-- **Review Report File**: [Name of detailed review report generated]
-- **Files Reviewed**: [Count and list of files reviewed]
-- **Review Template Used**: [Template source and version]
+- **Review Set**: {Review set name/identifier}
+- **Review Report File**: {Name of detailed review report generated}
+- **Files Reviewed**: {Count and list of files reviewed}
+- **Review Template Used**: {Template source and version}
 
 ## Review Results
 
-- **Overall Conclusion**: [Summary of review results]
-- **Critical Issues**: [Count of critical findings]
-- **High Issues**: [Count of high severity findings]
-- **Medium Issues**: [Count of medium severity findings]
-- **Low Issues**: [Count of low severity findings]
+- **Overall Conclusion**: {Summary of review results}
+- **Critical Issues**: {Count of critical findings}
+- **High Issues**: {Count of high severity findings}
+- **Medium Issues**: {Count of medium severity findings}
+- **Low Issues**: {Count of low severity findings}
 
 ## Issue Details
 
-[For each issue found, include:]
-- **File**: [File name and line number where applicable]
-- **Issue Type**: [Security, logic error, compliance violation, etc.]
-- **Severity**: [Critical/High/Medium/Low]
-- **Description**: [Issue description]
-- **Recommendation**: [Specific remediation recommendation]
+For each issue found, include:
+
+- **File**: {File name and line number where applicable}
+- **Issue Type**: {Security, logic error, compliance violation, etc.}
+- **Severity**: {Critical/High/Medium/Low}
+- **Description**: {Issue description}
+- **Recommendation**: {Specific remediation recommendation}
 
 ## Compliance Status
 
-- **Review Status**: [Complete/Incomplete with reasoning]
-- **Quality Gates**: [Status of review checklist items]
-- **Approval Status**: [Approved/Rejected with justification]
+- **Review Status**: {Complete/Incomplete with reasoning}
+- **Quality Gates**: {Status of review checklist items}
+- **Approval Status**: {Approved/Rejected with justification}
 ```
 
 Return summary to caller.
diff --git a/.github/agents/developer.agent.md b/.github/agents/developer.agent.md
index 2028f79..2671008 100644
--- a/.github/agents/developer.agent.md
+++ b/.github/agents/developer.agent.md
@@ -16,7 +16,8 @@ Perform software development tasks by determining and applying appropriate DEMA
 2. **Read relevant standards** from `.github/standards/` as defined in AGENTS.md based on work performed
 3. **Apply loaded standards** throughout development process
 4. **Execute work** following standards requirements and quality checks
-5. **Generate completion report** with results and compliance status
+5. **Lint fixes** follow the linting process before performing quality gates
+6. **Generate completion report** with results and compliance status
 
 # Reporting
 
@@ -30,20 +31,20 @@ of the project consisting of:
 
 ## Work Summary
 
-- **Files Modified**: [List of files created/modified/deleted]
-- **Languages Detected**: [Languages identified]
-- **Standards Applied**: [Standards files consulted]
+- **Files Modified**: {List of files created/modified/deleted}
+- **Languages Detected**: {Languages identified}
+- **Standards Applied**: {Standards files consulted}
 
 ## Tooling Executed
 
-- **Language Tools**: [Compilers, linters, formatters used]
-- **Compliance Tools**: [ReqStream, ReviewMark tools used]
-- **Validation Results**: [Tool execution results]
+- **Language Tools**: {Compilers, linters, formatters used}
+- **Compliance Tools**: {ReqStream, ReviewMark tools used}
+- **Validation Results**: {Tool execution results}
 
 ## Compliance Status
 
-- **Quality Checks**: [Standards quality checks status]
-- **Issues Resolved**: [Any problems encountered and resolved]
+- **Quality Checks**: {Standards quality checks status}
+- **Issues Resolved**: {Any problems encountered and resolved}
 ```
 
 Return this summary to the caller.
diff --git a/.github/agents/implementation.agent.md b/.github/agents/implementation.agent.md
index 91b44d7..03603a4 100644
--- a/.github/agents/implementation.agent.md
+++ b/.github/agents/implementation.agent.md
@@ -28,7 +28,7 @@ counting how many retries have occurred.
 
 Call the built-in explore sub-agent with:
 
-- **context**: the user's request and any current quality findings
+- **context**: the user's request + any previous quality findings + retry context
 - **goal**: analyze the implementation state and develop a plan to implement the request
 
 Once the explore sub-agent finishes, transition to the DEVELOPMENT state.
@@ -37,7 +37,7 @@ Once the explore sub-agent finishes, transition to the DEVELOPMENT state.
 
 Call the developer sub-agent with:
 
-- **context** the user's request and the current implementation plan
+- **context** the user's request + research plan + specific quality issues to address (if retry)
 - **goal** implement the user's request and any identified quality fixes
 
 Once the developer sub-agent finishes:
@@ -49,7 +49,7 @@ Once the developer sub-agent finishes:
 
 Call the quality sub-agent with:
 
-- **context** the user's request and the current implementation report
+- **context** the user's request + development summary + files changed + previous issues (if any)
 - **goal** check the quality of the work performed for any issues
 
 Once the quality sub-agent finishes:
@@ -72,22 +72,22 @@ of the project consisting of:
 
 ## State Machine Execution
 
-- **Research Results**: [Summary of explore agent findings]
-- **Development Results**: [Summary of developer agent results]  
-- **Quality Results**: [Summary of quality agent results]
-- **State Transitions**: [Log of state changes and decisions]
+- **Research Results**: {Summary of explore agent findings}
+- **Development Results**: {Summary of developer agent results}
+- **Quality Results**: {Summary of quality agent results}
+- **State Transitions**: {Log of state changes and decisions}
 
 ## Sub-Agent Coordination
 
-- **Explore Agent**: [Research findings and context]
-- **Developer Agent**: [Development status and files modified]
-- **Quality Agent**: [Validation results and compliance status]
+- **Explore Agent**: {Research findings and context}
+- **Developer Agent**: {Development status and files modified}
+- **Quality Agent**: {Validation results and compliance status}
 
 ## Final Status
 
-- **Implementation Success**: [Overall completion status]
-- **Quality Compliance**: [Final quality validation status]  
-- **Issues Resolved**: [Problems encountered and resolution attempts]
+- **Implementation Success**: {Overall completion status}
+- **Quality Compliance**: {Final quality validation status}
+- **Issues Resolved**: {Problems encountered and resolution attempts}
 ```
 
 Return this summary to the caller.
diff --git a/.github/agents/quality.agent.md b/.github/agents/quality.agent.md
index a7b57d4..18fc7c6 100644
--- a/.github/agents/quality.agent.md
+++ b/.github/agents/quality.agent.md
@@ -26,6 +26,13 @@ This assessment is a quality control system of the project and MUST be performed
 Upon completion create a summary in `.agent-logs/{agent-name}-{subject}-{unique-id}.md`
 of the project consisting of:
 
+The **Result** field MUST reflect the quality validation outcome for orchestrator decision-making:
+
+- **Result: SUCCEEDED** - Only when Overall Grade is PASS (all compliance requirements met)
+- **Result: FAILED** - When Overall Grade is FAIL or NEEDS_WORK (compliance failures present)
+
+This ensures orchestrators properly halt workflows when quality gates fail.
+
 ```markdown
 # Quality Assessment Report
 
@@ -34,88 +41,95 @@ of the project consisting of:
 
 ## Assessment Summary
 
-- **Work Reviewed**: [Description of work assessed]
-- **Standards Applied**: [Standards files used for assessment]
-- **Categories Evaluated**: [Quality check categories assessed]
+- **Work Reviewed**: {Description of work assessed}
+- **Standards Applied**: {Standards files used for assessment}
+- **Categories Evaluated**: {Quality check categories assessed}
 
 ## Requirements Compliance: (PASS|FAIL|N/A)
 
-- Were requirements updated to reflect functional changes? (PASS|FAIL|N/A) - [Evidence]
-- Were new requirements created for new features? (PASS|FAIL|N/A) - [Evidence]
-- Do requirement IDs follow semantic naming standards? (PASS|FAIL|N/A) - [Evidence]
-- Do requirement files follow kebab-case naming convention? (PASS|FAIL|N/A) - [Evidence]
-- Are requirement files organized under `docs/reqstream/` with proper folder structure? (PASS|FAIL|N/A) - [Evidence]
-- Are OTS requirements properly placed in `docs/reqstream/ots/` subfolder? (PASS|FAIL|N/A) - [Evidence]
-- Were source filters applied appropriately for platform-specific requirements? (PASS|FAIL|N/A) - [Evidence]
-- Does ReqStream enforcement pass without errors? (PASS|FAIL|N/A) - [Evidence]
-- Is requirements traceability maintained to tests? (PASS|FAIL|N/A) - [Evidence]
+- Were requirements updated to reflect functional changes? (PASS|FAIL|N/A) - {Evidence}
+- Were new requirements created for new features? (PASS|FAIL|N/A) - {Evidence}
+- Do requirement IDs follow semantic naming standards? (PASS|FAIL|N/A) - {Evidence}
+- Do requirement files follow kebab-case naming convention? (PASS|FAIL|N/A) - {Evidence}
+- Are requirement files organized under `docs/reqstream/` with proper folder structure? (PASS|FAIL|N/A) - {Evidence}
+- Are OTS requirements properly placed in `docs/reqstream/ots/` subfolder? (PASS|FAIL|N/A) - {Evidence}
+- Were source filters applied appropriately for platform-specific requirements? (PASS|FAIL|N/A) - {Evidence}
+- Does ReqStream enforcement pass without errors? (PASS|FAIL|N/A) - {Evidence}
+- Is requirements traceability maintained to tests? (PASS|FAIL|N/A) - {Evidence}
 
 ## Design Documentation Compliance: (PASS|FAIL|N/A)
 
-- Were design documents updated for architectural changes? (PASS|FAIL|N/A) - [Evidence]
-- Were new design artifacts created for new components? (PASS|FAIL|N/A) - [Evidence]
-- Do design folder names use kebab-case convention matching source structure? (PASS|FAIL|N/A) - [Evidence]
-- Are design files properly named ({subsystem-name}.md, {unit-name}.md patterns)? (PASS|FAIL|N/A) - [Evidence]
-- Is `docs/design/introduction.md` present with required Software Structure section? (PASS|FAIL|N/A) - [Evidence]
-- Are design decisions documented with rationale? (PASS|FAIL|N/A) - [Evidence]
-- Is system/subsystem/unit categorization maintained? (PASS|FAIL|N/A) - [Evidence]
-- Is design-to-implementation traceability preserved? (PASS|FAIL|N/A) - [Evidence]
+- Were design documents updated for architectural changes? (PASS|FAIL|N/A) - {Evidence}
+- Were new design artifacts created for new components? (PASS|FAIL|N/A) - {Evidence}
+- Do design folder names use kebab-case convention matching source structure? (PASS|FAIL|N/A) - {Evidence}
+- Are design files properly named ({subsystem-name}.md, {unit-name}.md patterns)? (PASS|FAIL|N/A) - {Evidence}
+- Is `docs/design/introduction.md` present with required Software Structure section? (PASS|FAIL|N/A) - {Evidence}
+- Are design decisions documented with rationale? (PASS|FAIL|N/A) - {Evidence}
+- Is system/subsystem/unit categorization maintained? (PASS|FAIL|N/A) - {Evidence}
+- Is design-to-implementation traceability preserved? (PASS|FAIL|N/A) - {Evidence}
 
 ## Code Quality Compliance: (PASS|FAIL|N/A)
 
-- Are language-specific standards followed (from applicable standards files)? (PASS|FAIL|N/A) - [Evidence]
-- Are quality checks from standards files satisfied? (PASS|FAIL|N/A) - [Evidence]
-- Is code properly categorized (system/subsystem/unit/OTS)? (PASS|FAIL|N/A) - [Evidence]
-- Is appropriate separation of concerns maintained? (PASS|FAIL|N/A) - [Evidence]
-- Was language-specific tooling executed and passing? (PASS|FAIL|N/A) - [Evidence]
+- Are language-specific standards followed (from applicable standards files)? (PASS|FAIL|N/A) - {Evidence}
+- Are quality checks from standards files satisfied? (PASS|FAIL|N/A) - {Evidence}
+- Is code properly categorized (system/subsystem/unit/OTS)? (PASS|FAIL|N/A) - {Evidence}
+- Is appropriate separation of concerns maintained? (PASS|FAIL|N/A) - {Evidence}
+- Was language-specific tooling executed and passing? (PASS|FAIL|N/A) - {Evidence}
 
 ## Testing Compliance: (PASS|FAIL|N/A)
 
-- Were tests created/updated for all functional changes? (PASS|FAIL|N/A) - [Evidence]
-- Is test coverage maintained for all requirements? (PASS|FAIL|N/A) - [Evidence]
-- Are testing standards followed (AAA pattern, etc.)? (PASS|FAIL|N/A) - [Evidence]
-- Does test categorization align with code structure? (PASS|FAIL|N/A) - [Evidence]
-- Do all tests pass without failures? (PASS|FAIL|N/A) - [Evidence]
+- Were tests created/updated for all functional changes? (PASS|FAIL|N/A) - {Evidence}
+- Is test coverage maintained for all requirements? (PASS|FAIL|N/A) - {Evidence}
+- Are testing standards followed (AAA pattern, etc.)? (PASS|FAIL|N/A) - {Evidence}
+- Does test categorization align with code structure? (PASS|FAIL|N/A) - {Evidence}
+- Do all tests pass without failures? (PASS|FAIL|N/A) - {Evidence}
 
 ## Review Management Compliance: (PASS|FAIL|N/A)
 
-- Were review-sets updated to include new/modified files? (PASS|FAIL|N/A) - [Evidence]
-- Do file patterns follow include-then-exclude approach? (PASS|FAIL|N/A) - [Evidence]
-- Is review scope appropriate for change magnitude? (PASS|FAIL|N/A) - [Evidence]
-- Was ReviewMark tooling executed and passing? (PASS|FAIL|N/A) - [Evidence]
-- Were review artifacts generated correctly? (PASS|FAIL|N/A) - [Evidence]
+- Were review-sets updated for structural changes (new/deleted systems, subsystems, or units)? (PASS|FAIL|N/A) - {Evidence}
+- Do file patterns follow include-then-exclude approach? (PASS|FAIL|N/A) - {Evidence}
+- Is review scope appropriate for change magnitude? (PASS|FAIL|N/A) - {Evidence}
+- Was ReviewMark tooling executed and passing? (PASS|FAIL|N/A) - {Evidence}
+- Were review artifacts generated correctly? (PASS|FAIL|N/A) - {Evidence}
 
 ## Documentation Compliance: (PASS|FAIL|N/A)
 
-- Was README.md updated for user-facing changes? (PASS|FAIL|N/A) - [Evidence]
-- Were user guides updated for feature changes? (PASS|FAIL|N/A) - [Evidence]
-- Does API documentation reflect code changes? (PASS|FAIL|N/A) - [Evidence]
-- Was compliance documentation generated? (PASS|FAIL|N/A) - [Evidence]
-- Does documentation follow standards formatting? (PASS|FAIL|N/A) - [Evidence]
-- Is documentation organized under `docs/` following standard folder structure? (PASS|FAIL|N/A) - [Evidence]
-- Do Pandoc collections include proper `introduction.md` with Purpose and Scope sections? (PASS|FAIL|N/A) - [Evidence]
-- Are auto-generated markdown files left unmodified? (PASS|FAIL|N/A) - [Evidence]
-- Do README.md files use absolute URLs and include concrete examples? (PASS|FAIL|N/A) - [Evidence]
-- Is documentation integrated into ReviewMark review-sets for formal review? (PASS|FAIL|N/A) - [Evidence]
+- Was README.md updated for user-facing changes? (PASS|FAIL|N/A) - {Evidence}
+- Were user guides updated for feature changes? (PASS|FAIL|N/A) - {Evidence}
+- Does API documentation reflect code changes? (PASS|FAIL|N/A) - {Evidence}
+- Was compliance documentation generated? (PASS|FAIL|N/A) - {Evidence}
+- Does documentation follow standards formatting? (PASS|FAIL|N/A) - {Evidence}
+- Is documentation organized under `docs/` following standard folder structure? (PASS|FAIL|N/A) - {Evidence}
+- Do Pandoc collections include proper `introduction.md` with Purpose and Scope sections? (PASS|FAIL|N/A) - {Evidence}
+- Are auto-generated markdown files left unmodified? (PASS|FAIL|N/A) - {Evidence}
+- Do README.md files use absolute URLs and include concrete examples? (PASS|FAIL|N/A) - {Evidence}
+- Is documentation integrated into ReviewMark review-sets for formal review? (PASS|FAIL|N/A) - {Evidence}
+
+## Software Item Completeness: (PASS|FAIL|N/A)
+
+- Does every identified software unit have its own requirements file? (PASS|FAIL|N/A) - {Evidence}
+- Does every identified software unit have its own design document? (PASS|FAIL|N/A) - {Evidence}
+- Does every identified subsystem have its own requirements file? (PASS|FAIL|N/A) - {Evidence}
+- Does every identified subsystem have its own design document? (PASS|FAIL|N/A) - {Evidence}
 
 ## Process Compliance: (PASS|FAIL|N/A)
 
-- Was Continuous Compliance workflow followed? (PASS|FAIL|N/A) - [Evidence]
-- Did all quality gates execute successfully? (PASS|FAIL|N/A) - [Evidence]
-- Were appropriate tools used for validation? (PASS|FAIL|N/A) - [Evidence]
-- Were standards consistently applied across work? (PASS|FAIL|N/A) - [Evidence]
-- Was compliance evidence generated and preserved? (PASS|FAIL|N/A) - [Evidence]
+- Was Continuous Compliance workflow followed? (PASS|FAIL|N/A) - {Evidence}
+- Did all quality gates execute successfully? (PASS|FAIL|N/A) - {Evidence}
+- Were appropriate tools used for validation? (PASS|FAIL|N/A) - {Evidence}
+- Were standards consistently applied across work? (PASS|FAIL|N/A) - {Evidence}
+- Was compliance evidence generated and preserved? (PASS|FAIL|N/A) - {Evidence}
 
 ## Overall Findings
 
-- **Critical Issues**: [Count and description of critical findings]
-- **Recommendations**: [Suggested improvements and next steps]
-- **Tools Executed**: [Quality tools used for validation]
+- **Critical Issues**: {Count and description of critical findings}
+- **Recommendations**: {Suggested improvements and next steps}
+- **Tools Executed**: {Quality tools used for validation}
 
 ## Compliance Status
 
-- **Standards Adherence**: [Overall compliance rating with specific standards]
-- **Quality Gates**: [Status of automated quality checks with tool outputs]
+- **Standards Adherence**: {Overall compliance rating with specific standards}
+- **Quality Gates**: {Status of automated quality checks with tool outputs}
 ```
 
 Return this summary to the caller.
diff --git a/.github/agents/repo-consistency.agent.md b/.github/agents/repo-consistency.agent.md
index b0f93d2..b623895 100644
--- a/.github/agents/repo-consistency.agent.md
+++ b/.github/agents/repo-consistency.agent.md
@@ -52,29 +52,29 @@ of the project consisting of:
 
 ## Consistency Analysis
 
-- **Template PRs Analyzed**: [Number and timeframe of PRs reviewed]
-- **Template Changes Identified**: [Count and types of template improvements]
-- **Applicable Updates**: [Changes determined suitable for this repository]
-- **Project Customizations Preserved**: [Valid differences maintained]
+- **Template PRs Analyzed**: {Number and timeframe of PRs reviewed}
+- **Template Changes Identified**: {Count and types of template improvements}
+- **Applicable Updates**: {Changes determined suitable for this repository}
+- **Project Customizations Preserved**: {Valid differences maintained}
 
 ## Template Evolution Applied
 
-- **Files Modified**: [List of files updated for template consistency]
-- **Improvements Adopted**: [Specific template enhancements implemented]
-- **Configuration Updates**: [Tool configurations, workflows, or standards updated]
+- **Files Modified**: {List of files updated for template consistency}
+- **Improvements Adopted**: {Specific template enhancements implemented}
+- **Configuration Updates**: {Tool configurations, workflows, or standards updated}
 
 ## Consistency Status
 
-- **Template Alignment**: [Overall consistency rating with template]
-- **Customization Respect**: [How project-specific needs were preserved]
-- **Functionality Validation**: [Verification that changes don't break existing features]
-- **Future Consistency**: [Recommendations for ongoing template alignment]
+- **Template Alignment**: {Overall consistency rating with template}
+- **Customization Respect**: {How project-specific needs were preserved}
+- **Functionality Validation**: {Verification that changes don't break existing features}
+- **Future Consistency**: {Recommendations for ongoing template alignment}
 
 ## Issues Resolved
 
-- **Drift Corrections**: [Template drift issues addressed]
-- **Enhancement Adoptions**: [Template improvements successfully integrated]
-- **Validation Results**: [Testing and validation outcomes]
+- **Drift Corrections**: {Template drift issues addressed}
+- **Enhancement Adoptions**: {Template improvements successfully integrated}
+- **Validation Results**: {Testing and validation outcomes}
 ```
 
 Return this summary to the caller.
diff --git a/.github/standards/csharp-testing.md b/.github/standards/csharp-testing.md
index 2f26520..f96a3c3 100644
--- a/.github/standards/csharp-testing.md
+++ b/.github/standards/csharp-testing.md
@@ -13,14 +13,11 @@ requirements.
 [TestMethod]
 public void ServiceName_MethodName_Scenario_ExpectedBehavior()
 {
-    // Arrange - (description)
-    // TODO: Set up test data, mocks, and system under test.
+    // Arrange: description of setup (omit if nothing to set up)
 
-    // Act - (description)
-    // TODO: Execute the action being tested
+    // Act: description of action (can combine with Assert when action occurs within assertion)
 
-    // Assert - (description)
-    // TODO: Verify expected outcomes and interactions
+    // Assert: description of verification
 }
 ```
 
@@ -28,7 +25,9 @@ public void ServiceName_MethodName_Scenario_ExpectedBehavior()
 
 Use descriptive test names because test names appear in requirements traceability matrices and compliance reports.
 
-- **Pattern**: `ClassName_MethodUnderTest_Scenario_ExpectedBehavior`
+- **System tests**: `{SystemName}_{Functionality}_{Scenario}_{ExpectedBehavior}`
+- **Subsystem tests**: `{SubsystemName}_{Functionality}_{Scenario}_{ExpectedBehavior}`  
+- **Unit tests**: `{ClassName}_{MethodUnderTest}_{Scenario}_{ExpectedBehavior}`
 - **Descriptive Scenarios**: Clearly describe the input condition being tested
 - **Expected Behavior**: State the expected outcome or exception
 
@@ -110,7 +109,7 @@ Use `Assert.StartsWith` instead, as it produces clearer failure messages:
 Before submitting C# tests, verify:
 
 - [ ] All tests follow AAA pattern with clear section comments
-- [ ] Test names follow `ClassName_MethodUnderTest_Scenario_ExpectedBehavior`
+- [ ] Test names follow hierarchical patterns defined in Test Naming Standards section
 - [ ] Each test verifies single, specific behavior (no shared state)
 - [ ] Both success and failure scenarios covered including edge cases
 - [ ] External dependencies mocked with NSubstitute or equivalent
diff --git a/.github/standards/design-documentation.md b/.github/standards/design-documentation.md
index 6312275..e14cd30 100644
--- a/.github/standards/design-documentation.md
+++ b/.github/standards/design-documentation.md
@@ -23,12 +23,13 @@ design to implementation:
 
 ```text
 docs/design/
-├── introduction.md             # Design overview with software structure
-├── system.md                   # System-level design documentation
-├── {subsystem-name}/           # Subsystem design documents (kebab-case folder names)
-│   ├── {subsystem-name}.md     # Subsystem overview and design
-│   └── {unit-name}.md          # Unit-level design documents
-└── {unit-name}.md              # Top-level unit design documents (if not in subsystem)
+├── introduction.md              # Design overview with software structure
+└── {system-name}/               # System-level design folder (one per system)
+    ├── {system-name}.md         # System-level design documentation
+    ├── {subsystem-name}/        # Subsystem design documents (kebab-case folder names)
+    │   ├── {subsystem-name}.md  # Subsystem overview and design
+    │   └── {unit-name}.md       # Unit-level design documents
+    └── {unit-name}.md           # Top-level unit design documents (if not in subsystem)
 ```
 
 ## introduction.md (MANDATORY)
@@ -56,13 +57,16 @@ to understand these classifications before creating this section.
 Example format:
 
 ```text
-ProjectName (System)
+Project1Name (System)
 ├── ComponentA (Subsystem)
 │   ├── ClassX (Unit)
 │   └── ClassY (Unit)
 ├── ComponentB (Subsystem)
 │   └── ClassZ (Unit)
 └── UtilityClass (Unit)
+
+Project2Name (System)
+└── HelperClass (Unit)
 ```
 
 ### Folder Layout Section (MANDATORY)
@@ -73,24 +77,29 @@ mirror the software structure, with file paths and brief descriptions.
 Example format:
 
 ```text
-src/ProjectName/
+src/Project1Name/
 ├── ComponentA/
-│   ├── ClassX.cs               — brief description
-│   └── ClassY.cs               — brief description
+│   ├── ClassX.cs               — Core business logic handler
+│   └── ClassY.cs               — Data validation service
 ├── ComponentB/
-│   └── ClassZ.cs               — brief description
-└── UtilityClass.cs             — brief description
+│   └── ClassZ.cs               — Integration interface
+└── UtilityClass.cs             — Common utility functions
+
+src/Project2Name/
+└── HelperClass.cs              — Helper functions
 ```
 
-## system.md (MANDATORY)
+## System Design Documentation (MANDATORY)
 
-The `system.md` file contains system-level design documentation including:
+For each system identified in the repository:
 
-- System architecture and major components
-- External interfaces and dependencies
-- Data flow and control flow
-- System-wide design constraints and decisions
-- Integration patterns and communication protocols
+- Create a kebab-case folder matching the system name
+- Include `{system-name}.md` with system-level design documentation such as:
+  - System architecture and major components
+  - External interfaces and dependencies
+  - Data flow and control flow
+  - System-wide design constraints and decisions
+  - Integration patterns and communication protocols
 
 ## Subsystem and Unit Design Documents
 
@@ -98,9 +107,9 @@ For each subsystem identified in the software structure:
 
 - Create a kebab-case folder matching the subsystem name (enables automated tooling)
 - Include `{subsystem-name}.md` with subsystem overview and design
-- Include unit design documents for complex units within the subsystem
+- Include unit design documents for ALL units within the subsystem
 
-For significant units requiring detailed design:
+For every unit identified in the software structure:
 
 - Document data models, algorithms, and key methods
 - Describe interactions with other units
@@ -124,8 +133,10 @@ implementation specification for formal code review:
 - **Implementation Detail**: Provide sufficient detail for code review and implementation
 - **Architectural Clarity**: Clearly define component boundaries and interfaces
 - **Traceability**: Link to requirements where applicable using ReqStream patterns
-- **Concrete Examples**: Use actual class names, method signatures, and data structures
-- **Current Information**: Keep synchronized with code changes and refactoring
+
+# Mermaid Diagram Integration
+
+Use Mermaid diagrams to supplement text descriptions (diagrams must not replace text content).
 
 # Quality Checks
 
@@ -133,10 +144,10 @@ Before submitting design documentation, verify:
 
 - [ ] `introduction.md` includes both Software Structure and Folder Layout sections
 - [ ] Software structure correctly categorizes items as System/Subsystem/Unit per `software-items.md`
-- [ ] Folder layout matches actual source code organization
-- [ ] `system.md` provides comprehensive system-level design
+- [ ] Folder layout mirrors software structure organization
+- [ ] Design documents provide sufficient detail for code review
+- [ ] System documentation provides comprehensive system-level design
 - [ ] Subsystem documentation folders use kebab-case names while mirroring source subsystem names and structure
-- [ ] Design documents contain sufficient implementation detail
 - [ ] All documents follow technical documentation formatting standards
 - [ ] Content is current with implementation and requirements
 - [ ] Documents are integrated into ReviewMark review-sets for formal review
diff --git a/.github/standards/reqstream-usage.md b/.github/standards/reqstream-usage.md
index aa75a1f..ff3bc95 100644
--- a/.github/standards/reqstream-usage.md
+++ b/.github/standards/reqstream-usage.md
@@ -30,15 +30,17 @@ the source code structure because reviewers need clear navigation from
 requirements to design to implementation:
 
 ```text
-requirements.yaml                  # Root file (includes only)
+requirements.yaml                   # Root file (includes only)
 docs/reqstream/
-├── system.yaml                    # System-level requirements
-├── platform-requirements.yaml     # Platform support requirements
-├── {subsystem-name}/              # Subsystem requirements (kebab-case folders)
-│   └── {subsystem-name}.yaml      # Requirements for this subsystem
-├── {unit-name}.yaml               # Unit requirements (for top-level units)
-└── ots/                           # OTS software item requirements
-    └── {ots-name}.yaml            # Requirements for OTS components
+├── {system-name}/                  # System-level requirements folder (one per system)
+│   ├── {system-name}.yaml          # System-level requirements
+│   ├── platform-requirements.yaml  # Platform support requirements
+│   ├── {subsystem-name}/           # Subsystem requirements (kebab-case folders)
+│   │   ├── {subsystem-name}.yaml   # Requirements for this subsystem
+│   │   └── {unit-name}.yaml        # Requirements for units within this subsystem
+│   └── {unit-name}.yaml            # Requirements for top-level units (outside subsystems)
+└── ots/                            # OTS software items folder
+    └── {ots-name}.yaml             # Requirements for OTS components
 ```
 
 The folder structure MUST mirror the source code organization to maintain
@@ -56,18 +58,31 @@ only flow downward in the hierarchy to maintain clear traceability:
 This prevents circular dependencies and ensures clear hierarchical relationships
 for compliance auditing.
 
+# Test Linkage Hierarchy
+
+Requirements MUST link to tests at their own level to maintain proper test scope:
+
+- **System requirements** → link ONLY to system-level integration tests
+- **Subsystem requirements** → link ONLY to subsystem-level tests
+- **Unit requirements** → link ONLY to unit-level tests
+
+Lower-level tests validate implementation details, while higher-level requirements
+are validated through integration behavior at their architectural level.
+
 # Requirements File Format
 
 ```yaml
 sections:
   - title: Functional Requirements
     requirements:
-      - id: Project-Subsystem-Feature
+      - id: System-Subsystem-Feature
         title: The system shall perform the required function.
         justification: |
           Business rationale explaining why this requirement exists.
           Include regulatory or standard references where applicable.
-        tests:
+        children:  # Links to child requirements (optional)
+          - ChildSystem-Feature-Behavior
+        tests:     # Links to test methods (required)
           - TestMethodName
           - windows@PlatformSpecificTest  # Source filter for platform evidence
 ```
@@ -88,7 +103,7 @@ sections:
     sections:
       - title: System.Text.Json
         requirements:
-          - id: Project-SystemTextJson-ReadJson
+          - id: TemplateTool-SystemTextJson-ReadJson
             title: System.Text.Json shall be able to read JSON files.
             tests:
               - JsonReaderTests.TestReadValidJson
@@ -96,7 +111,7 @@ sections:
 
 # Semantic IDs (MANDATORY)
 
-Use meaningful IDs following `Project-Section-ShortDesc` pattern because
+Use meaningful IDs following `System-Section-ShortDesc` pattern because
 auditors need to understand requirements without cross-referencing:
 
 - **Good**: `TemplateTool-Core-DisplayHelp`
@@ -127,12 +142,6 @@ dotnet reqstream \
   --requirements requirements.yaml \
   --lint
 
-# Enforce requirements traceability (use in CI/CD)
-dotnet reqstream \
-  --requirements requirements.yaml \
-  --tests "artifacts/**/*.trx" \
-  --enforce
-
 # Generate requirements report
 dotnet reqstream \
   --requirements requirements.yaml \
@@ -154,7 +163,7 @@ dotnet reqstream \
 
 Before submitting requirements, verify:
 
-- [ ] All requirements have semantic IDs (`Project-Section-Feature` pattern)
+- [ ] All requirements have semantic IDs (`System-Section-Feature` pattern)
 - [ ] Every requirement links to at least one passing test
 - [ ] Platform-specific requirements use source filters (`platform@TestName`)
 - [ ] Requirements specify observable behavior (WHAT), not implementation (HOW)
@@ -162,6 +171,7 @@ Before submitting requirements, verify:
 - [ ] Files organized under `docs/reqstream/` following folder structure patterns
 - [ ] Subsystem folders use kebab-case naming matching source code
 - [ ] OTS requirements placed in `ots/` subfolder
+- [ ] Every software unit has requirements file, design doc, and tests
 - [ ] Valid YAML syntax passes yamllint validation
 - [ ] ReqStream enforcement passes: `dotnet reqstream --enforce`
 - [ ] Test result formats compatible (TRX, JUnit XML)
diff --git a/.github/standards/reviewmark-usage.md b/.github/standards/reviewmark-usage.md
index a40179f..e2e380a 100644
--- a/.github/standards/reviewmark-usage.md
+++ b/.github/standards/reviewmark-usage.md
@@ -1,16 +1,24 @@
-# ReviewMark File Review Standards
+# ReviewMark Usage Standard
 
-This document defines DEMA Consulting standards for managing file reviews using
-ReviewMark within Continuous Compliance environments.
+## Purpose
 
-# Core Purpose
+ReviewMark manages file review status enforcement and formal review processes. It tracks which files need
+review, organizes them into review-sets, and generates review plans and reports.
 
-ReviewMark automates file review tracking using cryptographic fingerprints to
-ensure:
+## Key Commands
 
-- Every file requiring review is covered by a current, valid review
-- Reviews become stale when files change, triggering re-review
-- Complete audit trail of review coverage for regulatory compliance
+- **Lint Configuration**: `dotnet reviewmark --lint`
+- **Elaborate Review-Set**: `dotnet reviewmark --elaborate {review-set}`
+- **Generate Plan**: `dotnet reviewmark --plan docs/code_review_plan/plan.md`
+- **Generate Report**: `dotnet reviewmark --report docs/code_review_report/report.md`
+
+## Repository Structure
+
+Required repository items for ReviewMark operation:
+
+- `.reviewmark.yaml` - Configuration for review-sets, file-patterns, and review evidence-source.
+- `docs/code_review_plan/` - Review planning artifacts
+- `docs/code_review_report/` - Review status reports
 
 # Review Definition Structure
 
@@ -19,142 +27,142 @@ Configure reviews in `.reviewmark.yaml` at repository root:
 ```yaml
 # Patterns identifying all files that require review
 needs-review:
-  # Include core development artifacts
-  - "requirements.yaml"          # Root requirements file
-  - "docs/reqstream/**/*.yaml"   # Requirements files
-  - "docs/design/**/*.md"        # Design documentation
-  - "**/*.cs"                    # All C# source and test files
-
-  # Exclude build output and generated content
-  - "!**/obj/**"                 # Exclude build output
-  - "!**/bin/**"                 # Exclude binary output
-  - "!**/generated/**"           # Exclude auto-generated files
+  # Include source code (adjust file extensions for your repo)
+  - "**/*.cs"           # C# source files
+  - "**/*.cpp"          # C++ source files
+  - "**/*.hpp"          # C++ header files
+  - "!**/bin/**"        # Generated source in build outputs
+  - "!**/obj/**"        # Generated source in build intermediates
+
+  # Include requirement files
+  - "requirements.yaml"        # Root requirements file
+  - "docs/reqstream/**/*.yaml" # Requirements files
+
+  # Include critical documentation files
+  - "README.md"                                 # Root level README
+  - "docs/user_guide/**/*.md"                   # User guide
+  - "docs/design/**/*.md"                       # Design documentation
 
 # Source of review evidence
 evidence-source:
   type: none
-
-# Named review-sets grouping related files
-reviews:
-  - id: MyProduct-PasswordValidator
-    title: Password Validator Unit Review
-    paths:
-      - "docs/reqstream/authentication/password-validator.yaml"
-      - "docs/design/authentication/password-validator.md"
-      - "src/{ProjectName}/Authentication/PasswordValidator.cs"
-      - "test/{ProjectName}.Tests/Authentication/PasswordValidatorTests.cs"
-
-  - id: MyProduct-AllRequirements
-    title: All Requirements Review
-    paths:
-      - "requirements.yaml"
-      - "docs/reqstream/**/*.yaml"
 ```
 
-# Review-Set Organization
-
-Organize review-sets using standard patterns to ensure comprehensive coverage
-and consistent review processes:
-
-## [Project]-System Review
-
-Reviews system integration and operational validation:
-
-- **Files**: System requirements (`docs/reqstream/system.yaml`), design introduction
-  (`docs/design/introduction.md`), system design (`docs/design/system.md`),
-  integration tests
-- **Purpose**: Validates system operates as designed and meets overall requirements
-- **Example**: `TemplateTool-System`
+# Review-Set Design Principles
 
-## [Product]-Design Review
+When constructing review-sets, follow these principles to maintain manageable scope and effective compliance evidence:
 
-Reviews architectural and design consistency:
+- **Hierarchical Scope**: Higher-level reviews exclude lower-level implementation details, relying instead on design
+  documents to describe what components they use. System reviews exclude subsystem/unit details, subsystem reviews
+  exclude unit source code, only unit reviews include actual implementation.
+- **Single Focus**: Each review-set proves one specific compliance question (user promises, system architecture,
+  design consistency, etc.)
+- **Context Management**: Keep file counts manageable to prevent context overflow while maintaining complete coverage
+  through the hierarchy
 
-- **Files**: System requirements, platform requirements, all design documents under `docs/design/`
-- **Purpose**: Ensures design completeness and architectural coherence
-- **Example**: `MyProduct-Design`
+# Review-Set Organization
 
-## [Product]-AllRequirements Review
+Organize review-sets using these standard patterns to ensure comprehensive coverage
+while keeping each review manageable in scope:
 
-Reviews requirements quality and traceability:
+**Note**: File path patterns shown below use C# naming conventions (PascalCase, `.cs` extensions).
+Other languages should adapt these patterns to their conventions (e.g., C++ might use
+`snake_case` with `.cpp`/`.hpp` extensions).
 
-- **Files**: All requirement files including root `requirements.yaml` and all files under `docs/reqstream/`
-- **Purpose**: Validates requirements structure, IDs, justifications, and test linkage
-- **Example**: `MyProduct-AllRequirements`
+## `Purpose` Review (only one per repository)
 
-## [Product]-[Unit] Review
+Reviews user-facing capabilities and system promises:
 
-Reviews individual software unit implementation:
+- **Purpose**: Proves that the systems provide the capabilities the user is being told about
+- **Title**: "Review that Advertised Features Match System Design"
+- **Scope**: Excludes subsystem and unit files, relying on system-level design documents
+  to describe what subsystems and units they use
+- **File Path Patterns**:
+  - README: `README.md`
+  - User guide: `docs/user_guide/**/*.md`
+  - System requirements: `docs/reqstream/{system-name}/{system-name}.yaml`
+  - Design introduction: `docs/design/introduction.md`
+  - System design: `docs/design/{system-name}/{system-name}.md`
 
-- **Files**: Unit requirements, design documents, source code, unit tests
-- **Purpose**: Validates unit meets requirements and is properly implemented
-- **File Path Pattern**:
-  - Requirements: `docs/reqstream/{subsystem-name}/{unit-name}.yaml` or `docs/reqstream/{unit-name}.yaml`
-  - Design: `docs/design/{subsystem-name}/{unit-name}.md` or `docs/design/{unit-name}.md`
-  - Source: `src/{ProjectName}/{SubsystemName}/{UnitName}.cs`
-  - Tests: `test/{ProjectName}.Tests/{SubsystemName}/{UnitName}Tests.cs`
-- **Example**: `MyProduct-PasswordValidator`, `MyProduct-ConfigParser`
+## `{System}-Architecture` Review (one per system)
 
-## [Product]-[Subsystem] Review
+Reviews system architecture and operational validation:
 
-Reviews subsystem architecture and interfaces:
+- **Purpose**: Proves that the system is designed and tested to satisfy its requirements
+- **Title**: "Review that {System} Architecture Satisfies Requirements"
+- **Scope**: Excludes subsystem and unit files, relying on system-level design to describe
+  what subsystems and units it uses
+- **File Path Patterns**:
+  - System requirements: `docs/reqstream/{system-name}/{system-name}.yaml`
+  - Design introduction: `docs/design/introduction.md`
+  - System design: `docs/design/{system-name}/{system-name}.md`
+  - System integration tests: `test/{SystemName}.Tests/{SystemName}Tests.cs`
 
-- **Files**: Subsystem requirements, design documents, integration tests (usually no source code)
-- **Purpose**: Validates subsystem behavior and interface compliance
-- **File Path Pattern**:
-  - Requirements: `docs/reqstream/{subsystem-name}/{subsystem-name}.yaml`
-  - Design: `docs/design/{subsystem-name}/{subsystem-name}.md`
-  - Tests: `test/{ProjectName}.Tests/{SubsystemName}Integration/` or similar
-- **Example**: `MyProduct-Authentication`, `MyProduct-DataLayer`
+## `{System}-Design` Review (one per system)
 
-## [Product]-OTS Review
+Reviews architectural and design consistency:
 
-Reviews OTS (Off-The-Shelf) software integration:
+- **Purpose**: Proves the system design is consistent and complete
+- **Title**: "Review that {System} Design is Consistent and Complete"
+- **Scope**: Only brings in top-level requirements and relies on brevity of design documentation
+- **File Path Patterns**:
+  - System requirements: `docs/reqstream/{system-name}/{system-name}.yaml`
+  - Platform requirements: `docs/reqstream/{system-name}/platform-requirements.yaml`
+  - Design introduction: `docs/design/introduction.md`
+  - System design files: `docs/design/{system-name}/**/*.md`
 
-- **Files**: OTS requirements and integration test evidence
-- **Purpose**: Validates OTS components meet integration requirements
-- **File Path Pattern**:
-  - Requirements: `docs/reqstream/ots/{ots-name}.yaml`
-  - Tests: Integration tests proving OTS functionality
-- **Example**: `MyProduct-SystemTextJson`, `MyProduct-EntityFramework`
+## `{System}-AllRequirements` Review (one per system)
 
-# File Pattern Best Practices
+Reviews requirements quality and traceability:
 
-Use "include-then-exclude" approach for `needs-review` patterns because it
-ensures comprehensive coverage while removing unwanted files:
+- **Purpose**: Proves the requirements are consistent and complete
+- **Title**: "Review that All {System} Requirements are Complete"
+- **Scope**: Only brings in requirements files to keep review manageable
+- **File Path Patterns**:
+  - Root requirements: `requirements.yaml`
+  - System requirements: `docs/reqstream/{system-name}/**/*.yaml`
+  - OTS requirements: `docs/reqstream/ots/**/*.yaml` (if applicable)
 
-1. **Start broad**: Include all files of potential interest with generous patterns
-2. **Exclude overreach**: Use `!` patterns to remove build output, generated files, and temporary files
-3. **Test patterns**: Verify patterns match intended files using `dotnet reviewmark --elaborate`
+## `{System}-{Subsystem}` Review (one per subsystem)
 
-**Order matters**: Patterns are processed sequentially, excludes override earlier includes.
+Reviews subsystem architecture and interfaces:
 
-# ReviewMark Commands
+- **Purpose**: Proves that the subsystem is designed and tested to satisfy its requirements
+- **Title**: "Review that {System} {Subsystem} Satisfies Subsystem Requirements"
+- **Scope**: Excludes units under the subsystem, relying on subsystem design to describe
+  what units it uses
+- **File Path Patterns**:
+  - Requirements: `docs/reqstream/{system-name}/{subsystem-name}/{subsystem-name}.yaml`
+  - Design: `docs/design/{system-name}/{subsystem-name}/{subsystem-name}.md`
+  - Tests: `test/{SystemName}.Tests/{SubsystemName}/{SubsystemName}Tests.cs`
 
-Essential ReviewMark commands for Continuous Compliance:
+## `{System}-{Subsystem}-{Unit}` Review (one per unit)
 
-```bash
-# Lint review configuration for issues (run before use)
-dotnet reviewmark --lint
+Reviews individual software unit implementation:
 
-# Generate review plan and report (use in CI/CD)
-dotnet reviewmark \
-  --plan docs/code_review_plan/plan.md \
-  --report docs/code_review_report/report.md \
-  --enforce
-```
+- **Purpose**: Proves the unit is designed, implemented, and tested to satisfy its requirements
+- **Title**: "Review that {System} {Subsystem} {Unit} Implementation is Correct"
+- **Scope**: Complete unit review including all artifacts
+- **File Path Patterns**:
+  - Requirements: `docs/reqstream/{system-name}/{subsystem-name}/{unit-name}.yaml` or
+    `docs/reqstream/{system-name}/{unit-name}.yaml`
+  - Design: `docs/design/{system-name}/{subsystem-name}/{unit-name}.md` or
+    `docs/design/{system-name}/{unit-name}.md`
+  - Source: `src/{SystemName}/{SubsystemName}/{UnitName}.cs` or `src/{SystemName}/{UnitName}.cs`
+  - Tests: `test/{SystemName}.Tests/{SubsystemName}/{UnitName}Tests.cs` or
+    `test/{SystemName}.Tests/{UnitName}Tests.cs`
 
 # Quality Checks
 
 Before submitting ReviewMark configuration, verify:
 
 - [ ] `.reviewmark.yaml` exists at repository root with proper structure
-- [ ] `needs-review` patterns cover requirements, design, code, and tests with proper exclusions
-- [ ] Each review-set has unique `id` and groups architecturally related files
+- [ ] Review-set organization follows the standard hierarchy patterns
+- [ ] Purpose review-set includes README.md, user guide, system requirements, design introduction, and system design files
+- [ ] System-level reviews follow hierarchical scope principle (exclude subsystem/unit details)
+- [ ] Subsystem reviews follow hierarchical scope principle (exclude unit source code)
+- [ ] Only unit reviews include actual source code files
+- [ ] Each review-set focuses on a single compliance question (single focus principle)
 - [ ] File patterns use correct glob syntax and match intended files
-- [ ] File paths reflect current naming conventions (kebab-case design/requirements folders, PascalCase source folders)
+- [ ] Review-set file counts remain manageable (context management principle)
 - [ ] Evidence source properly configured (`none` for dev, `url` for production)
-- [ ] Environment variables used for credentials (never hardcoded)
-- [ ] ReviewMark enforcement configured: `dotnet reviewmark --enforce`
-- [ ] Generated documents accessible for compliance auditing
-- [ ] Review-set organization follows standard patterns ([Product]-[Unit], [Product]-Design, etc.)
diff --git a/.github/standards/software-items.md b/.github/standards/software-items.md
index 7991add..ce7e328 100644
--- a/.github/standards/software-items.md
+++ b/.github/standards/software-items.md
@@ -18,6 +18,11 @@ Categorize all software into four primary groups:
 - **OTS Software Item**: Third-party component (library, framework, tool)
   providing functionality not developed in-house
 
+**Naming**: When names collide in hierarchy, add descriptive suffix to higher-level entity:
+
+- System: Application/Library/System (e.g. TestResults → TestResultsLibrary)
+- Subsystem: Subsystem (e.g. Linter → LinterSubsystem)
+
 # Categorization Guidelines
 
 Choose the appropriate category based on scope and testability:
diff --git a/.github/standards/technical-documentation.md b/.github/standards/technical-documentation.md
index c117aa2..5bcc937 100644
--- a/.github/standards/technical-documentation.md
+++ b/.github/standards/technical-documentation.md
@@ -24,36 +24,39 @@ consistency and tool compatibility:
 
 ```text
 docs/
-  build_notes.md               # Generated by BuildMark
-  build_notes/                 # Auto-generated build notes
-    versions.md                # Generated by VersionMark
-  code_review_plan/            # Auto-generated review plans
-    plan.md                    # Generated by ReviewMark
-  code_review_report/          # Auto-generated review reports
-    report.md                  # Generated by ReviewMark
-  design/                      # Design documentation
-    introduction.md            # Design overview
-    system.md                  # System architecture
-    {subsystem-name}/          # Subsystem design folder
-      {subsystem-name}.md      # Subsystem-specific designs
-      {unit-name}.md           # Unit-specific designs
-    {unit-name}.md             # Top-level unit design
-  reqstream/                   # Requirements source files
-    system.yaml                # System requirements
-    platform-requirements.yaml # Platform requirements
-    {subsystem-name}/          # Subsystem requirements folder
-      {subsystem-name}.yaml    # Subsystem requirements
-      {unit-name}.yaml         # Unit requirements
-    ots/                       # OTS requirement files
-      {ots-name}.yaml          # OTS requirements
-  requirements_doc/            # Auto-generated requirements reports
-    requirements.md            # Generated by ReqStream
-    justifications.md          # Generated by ReqStream
-  requirements_report/         # Auto-generated trace matrices
-    trace_matrix.md            # Generated by ReqStream
-  user_guide/                  # User-facing documentation
-    introduction.md            # User guide overview
-    {section}.md               # User guide sections
+  build_notes.md                 # Generated by BuildMark
+  build_notes/                   # Auto-generated build notes
+    versions.md                  # Generated by VersionMark
+  code_review_plan/              # Auto-generated review plans
+    plan.md                      # Generated by ReviewMark
+  code_review_report/            # Auto-generated review reports
+    report.md                    # Generated by ReviewMark
+  design/                        # Design documentation
+    introduction.md              # Design overview
+    {system-name}/               # System architecture folder
+      {system-name}.md           # System architecture
+      {subsystem-name}/          # Subsystem design folder
+        {subsystem-name}.md      # Subsystem-specific designs
+        {unit-name}.md           # Unit-specific designs
+      {unit-name}.md             # Top-level unit design
+  reqstream/                     # Requirements source files
+    {system-name}/               # System requirements folder
+      {system-name}.yaml         # System requirements
+      platform-requirements.yaml # Platform requirements
+      {subsystem-name}/          # Subsystem requirements folder
+        {subsystem-name}.yaml    # Subsystem requirements
+        {unit-name}.yaml         # Unit-specific requirements
+      {unit-name}.yaml           # Top-level unit requirements
+    ots/                         # OTS requirement files
+      {ots-name}.yaml            # OTS requirements
+  requirements_doc/              # Auto-generated requirements reports
+    requirements.md              # Generated by ReqStream
+    justifications.md            # Generated by ReqStream
+  requirements_report/           # Auto-generated trace matrices
+    trace_matrix.md              # Generated by ReqStream
+  user_guide/                    # User-facing documentation
+    introduction.md              # User guide overview
+    {section}.md                 # User guide sections
 ```
 
 # Pandoc Document Structure (MANDATORY)
diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml
index 7af9960..4f1faba 100644
--- a/.github/workflows/build.yaml
+++ b/.github/workflows/build.yaml
@@ -667,11 +667,11 @@ jobs:
         shell: bash
         run: >
           dotnet pandoc
-          --defaults docs/guide/definition.yaml
+          --defaults docs/user_guide/definition.yaml
           --filter node_modules/.bin/mermaid-filter.cmd
           --metadata version="${{ inputs.version }}"
           --metadata date="$(date +'%Y-%m-%d')"
-          --output docs/guide/guide.html
+          --output docs/user_guide/guide.html
 
       - name: Generate Code Quality HTML with Pandoc
         shell: bash
@@ -736,7 +736,7 @@ jobs:
         run: >
           dotnet weasyprint
           --pdf-variant pdf/a-3u
-          docs/guide/guide.html
+          docs/user_guide/guide.html
           "docs/SpdxTool User Guide.pdf"
 
       - name: Generate Code Quality PDF with Weasyprint
diff --git a/.reviewmark.yaml b/.reviewmark.yaml
index a7b16ff..3c7fc01 100644
--- a/.reviewmark.yaml
+++ b/.reviewmark.yaml
@@ -9,6 +9,7 @@ needs-review:
   - "requirements.yaml"          # Root requirements file
   - "docs/reqstream/**/*.yaml"   # Requirements files
   - "docs/design/**/*.md"        # Design documentation
+  - "docs/user_guide/**/*.md"    # User guide documentation
   - "**/*.cs"                    # All C# source and test files
   - "!**/obj/**"                 # Exclude build output
   - "!**/bin/**"                 # Exclude build output
@@ -25,84 +26,369 @@ evidence-source:
 # Each review-set groups source and tests for a coherent software unit
 # so that an AI-assisted review can verify consistency across the full evidence chain.
 reviews:
-  # System-level review for DemaConsulting.SpdxTool
-  - id: SpdxTool-System
-    title: Review of DemaConsulting.SpdxTool System
+  # Purpose review - proves advertised features match system design
+  - id: Purpose
+    title: Review that Advertised Features Match System Design
     paths:
-      - "docs/reqstream/spdxtool-system.yaml"
+      - "README.md"
+      - "docs/user_guide/**/*.md"
+      - "docs/reqstream/spdx-tool/spdx-tool.yaml"
+      - "docs/reqstream/spdx-tool-targets/spdx-tool-targets.yaml"
       - "docs/design/introduction.md"
-      - "docs/design/spdxtool-system.md"
-      - "src/**/Program.cs"
-      - "src/**/Context.cs"
-      - "src/**/Runner.cs"
-      - "src/**/AssemblyInfo.cs"
-      - "test/**/IntegrationTests.cs"
-      - "test/**/ProgramTests.cs"
-      - "test/**/Runner.cs"
-      - "test/**/AssemblyInfo.cs"
-
-  # System-level review for DemaConsulting.SpdxTool.Targets
-  - id: SpdxTool-Targets-System
-    title: Review of DemaConsulting.SpdxTool.Targets System
-    paths:
-      - "docs/reqstream/spdxtool-targets-system.yaml"
-      - "docs/design/spdxtool-targets-system.md"
-      - "src/DemaConsulting.SpdxTool.Targets/**"
-      - "test/DemaConsulting.SpdxTool.Targets.Tests/**"
+      - "docs/design/spdx-tool/spdx-tool.md"
+      - "docs/design/spdx-tool-targets/spdx-tool-targets.md"
+
+  # System architecture review for DemaConsulting.SpdxTool
+  - id: SpdxTool-Architecture
+    title: Review that SpdxTool Architecture Satisfies Requirements
+    paths:
+      - "docs/reqstream/spdx-tool/spdx-tool.yaml"
+      - "docs/design/introduction.md"
+      - "docs/design/spdx-tool/spdx-tool.md"
+      - "src/DemaConsulting.SpdxTool/Program.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/IntegrationTests.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/ProgramTests.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/VersionTests.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/UsageTests.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SilentTests.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/LogTests.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Runner.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/AssemblyInfo.cs"
 
-  # Design review
+  # Design consistency review for DemaConsulting.SpdxTool
   - id: SpdxTool-Design
-    title: Review of SpdxTool Design Documentation
+    title: Review that SpdxTool Design is Consistent and Complete
     paths:
-      - "docs/reqstream/spdxtool-system.yaml"
-      - "docs/reqstream/platform-requirements.yaml"
-      - "docs/design/**/*.md"
+      - "docs/reqstream/spdx-tool/spdx-tool.yaml"
+      - "docs/reqstream/spdx-tool/platform-requirements.yaml"
+      - "docs/design/introduction.md"
+      - "docs/design/spdx-tool/**/*.md"
 
-  # All requirements review
+  # All requirements review for DemaConsulting.SpdxTool
   - id: SpdxTool-AllRequirements
-    title: Review of All SpdxTool Requirements
+    title: Review that All SpdxTool Requirements are Complete
     paths:
       - "requirements.yaml"
-      - "docs/reqstream/**/*.yaml"
+      - "docs/reqstream/spdx-tool/**/*.yaml"
+      - "docs/reqstream/spdx-tool-targets/**/*.yaml"
+      - "docs/reqstream/ots/**/*.yaml"
 
-  # Software unit reviews
-  - id: SpdxTool-Context
-    title: Review of SpdxTool Context Unit
+  # System architecture review for DemaConsulting.SpdxTool.Targets
+  - id: SpdxTargets-Architecture
+    title: Review that SpdxTool.Targets Architecture Satisfies Requirements
     paths:
-      - "src/**/Context.cs"
-      - "test/**/LogTests.cs"
+      - "docs/reqstream/spdx-tool-targets/spdx-tool-targets.yaml"
+      - "docs/design/introduction.md"
+      - "docs/design/spdx-tool-targets/spdx-tool-targets.md"
+      - "test/DemaConsulting.SpdxTool.Targets.Tests/**"
 
+  # Subsystem review for Commands
   - id: SpdxTool-Commands
-    title: Review of SpdxTool Commands Subsystem
+    title: Review that SpdxTool Commands Subsystem Satisfies Requirements
     paths:
-      - "docs/reqstream/commands/*.yaml"
-      - "docs/design/commands/*.md"
-      - "src/**/Commands/**"
-      - "test/**/Commands/**"
+      - "docs/reqstream/spdx-tool/commands/commands.yaml"
+      - "docs/design/spdx-tool/commands/commands.md"
+      - "src/DemaConsulting.SpdxTool/Commands/Command.cs"
+      - "src/DemaConsulting.SpdxTool/Commands/CommandEntry.cs"
+      - "src/DemaConsulting.SpdxTool/Commands/CommandErrorException.cs"
+      - "src/DemaConsulting.SpdxTool/Commands/CommandRegistry.cs"
+      - "src/DemaConsulting.SpdxTool/Commands/CommandUsageException.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/CommandTests.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/UnknownCommandTests.cs"
 
+  # Subsystem review for SelfTest
   - id: SpdxTool-SelfTest
-    title: Review of SpdxTool SelfTest Subsystem
+    title: Review that SpdxTool SelfTest Subsystem Satisfies Requirements
     paths:
-      - "docs/reqstream/self-test/self-test.yaml"
-      - "docs/design/self-test/self-test.md"
-      - "src/**/SelfTest/**"
-      - "test/**/SelfTest/**"
+      - "docs/reqstream/spdx-tool/self-test/self-test.yaml"
+      - "docs/design/spdx-tool/self-test/self-test.md"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/SelfTestTests.cs"
 
+  # Subsystem review for Utility
   - id: SpdxTool-Utility
-    title: Review of SpdxTool Utility Subsystem
+    title: Review that SpdxTool Utility Subsystem Satisfies Requirements
     paths:
-      - "docs/reqstream/utility.yaml"
-      - "docs/design/utility.md"
-      - "src/**/Spdx/**"
-      - "src/**/Utility/**"
-      - "test/**/Utility/**"
+      - "docs/reqstream/spdx-tool/utility/utility.yaml"
+      - "docs/design/spdx-tool/utility/utility.md"
+      - "src/DemaConsulting.SpdxTool/Utility/**"
+      - "src/DemaConsulting.SpdxTool/Spdx/**"
+      - "test/DemaConsulting.SpdxTool.Tests/Utility/**"
 
+  # OTS software review
   - id: SpdxTool-OTS
-    title: Review of SpdxTool OTS Software
-    paths:
-      - "docs/reqstream/ots/mstest.yaml"
-      - "docs/reqstream/ots/reqstream.yaml"
-      - "docs/reqstream/ots/buildmark.yaml"
-      - "docs/reqstream/ots/versionmark.yaml"
-      - "docs/reqstream/ots/sarifmark.yaml"
-      - "docs/reqstream/ots/sonarmark.yaml"
+    title: Review that SpdxTool OTS Software Requirements are Complete
+    paths:
+      - "docs/reqstream/ots/**/*.yaml"
+
+  # Context unit review
+  - id: SpdxTool-Context
+    title: Review that SpdxTool Context Unit Implementation is Correct
+    paths:
+      - "src/**/Context.cs"
+      - "test/**/LogTests.cs"
+
+  # Commands unit reviews
+  - id: SpdxTool-Commands-AddPackage
+    title: Review that SpdxTool Commands AddPackage Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/add-package.yaml"
+      - "docs/design/spdx-tool/commands/add-package.md"
+      - "src/DemaConsulting.SpdxTool/Commands/AddPackage.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/AddPackageTests.cs"
+
+  - id: SpdxTool-Commands-AddRelationship
+    title: Review that SpdxTool Commands AddRelationship Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/add-relationship.yaml"
+      - "docs/design/spdx-tool/commands/add-relationship.md"
+      - "src/DemaConsulting.SpdxTool/Commands/AddRelationship.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/AddRelationshipTests.cs"
+
+  - id: SpdxTool-Commands-CopyPackage
+    title: Review that SpdxTool Commands CopyPackage Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/copy-package.yaml"
+      - "docs/design/spdx-tool/commands/copy-package.md"
+      - "src/DemaConsulting.SpdxTool/Commands/CopyPackage.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/CopyPackageTests.cs"
+
+  - id: SpdxTool-Commands-Diagram
+    title: Review that SpdxTool Commands Diagram Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/diagram.yaml"
+      - "docs/design/spdx-tool/commands/diagram.md"
+      - "src/DemaConsulting.SpdxTool/Commands/Diagram.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/DiagramTests.cs"
+
+  - id: SpdxTool-Commands-FindPackage
+    title: Review that SpdxTool Commands FindPackage Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/find-package.yaml"
+      - "docs/design/spdx-tool/commands/find-package.md"
+      - "src/DemaConsulting.SpdxTool/Commands/FindPackage.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/FindPackageTests.cs"
+
+  - id: SpdxTool-Commands-GetVersion
+    title: Review that SpdxTool Commands GetVersion Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/get-version.yaml"
+      - "docs/design/spdx-tool/commands/get-version.md"
+      - "src/DemaConsulting.SpdxTool/Commands/GetVersion.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/GetVersionTests.cs"
+
+  - id: SpdxTool-Commands-Hash
+    title: Review that SpdxTool Commands Hash Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/hash.yaml"
+      - "docs/design/spdx-tool/commands/hash.md"
+      - "src/DemaConsulting.SpdxTool/Commands/Hash.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/HashTests.cs"
+
+  - id: SpdxTool-Commands-Help
+    title: Review that SpdxTool Commands Help Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/help.yaml"
+      - "docs/design/spdx-tool/commands/help.md"
+      - "src/DemaConsulting.SpdxTool/Commands/Help.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/HelpTests.cs"
+
+  - id: SpdxTool-Commands-Print
+    title: Review that SpdxTool Commands Print Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/print.yaml"
+      - "docs/design/spdx-tool/commands/print.md"
+      - "src/DemaConsulting.SpdxTool/Commands/Print.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/PrintTests.cs"
+
+  - id: SpdxTool-Commands-Query
+    title: Review that SpdxTool Commands Query Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/query.yaml"
+      - "docs/design/spdx-tool/commands/query.md"
+      - "src/DemaConsulting.SpdxTool/Commands/Query.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/QueryTests.cs"
+
+  - id: SpdxTool-Commands-RenameId
+    title: Review that SpdxTool Commands RenameId Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/rename-id.yaml"
+      - "docs/design/spdx-tool/commands/rename-id.md"
+      - "src/DemaConsulting.SpdxTool/Commands/RenameId.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/RenameIdTests.cs"
+
+  - id: SpdxTool-Commands-RunWorkflow
+    title: Review that SpdxTool Commands RunWorkflow Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/run-workflow.yaml"
+      - "docs/design/spdx-tool/commands/run-workflow.md"
+      - "src/DemaConsulting.SpdxTool/Commands/RunWorkflow.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/RunWorkflowTests.cs"
+
+  - id: SpdxTool-Commands-SetVariable
+    title: Review that SpdxTool Commands SetVariable Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/set-variable.yaml"
+      - "docs/design/spdx-tool/commands/set-variable.md"
+      - "src/DemaConsulting.SpdxTool/Commands/SetVariable.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/SetVariableTests.cs"
+
+  - id: SpdxTool-Commands-ToMarkdown
+    title: Review that SpdxTool Commands ToMarkdown Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/to-markdown.yaml"
+      - "docs/design/spdx-tool/commands/to-markdown.md"
+      - "src/DemaConsulting.SpdxTool/Commands/ToMarkdown.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/ToMarkdownTests.cs"
+
+  - id: SpdxTool-Commands-UpdatePackage
+    title: Review that SpdxTool Commands UpdatePackage Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/update-package.yaml"
+      - "docs/design/spdx-tool/commands/update-package.md"
+      - "src/DemaConsulting.SpdxTool/Commands/UpdatePackage.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/UpdatePackageTests.cs"
+
+  - id: SpdxTool-Commands-Validate
+    title: Review that SpdxTool Commands Validate Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/commands/validate.yaml"
+      - "docs/design/spdx-tool/commands/validate.md"
+      - "src/DemaConsulting.SpdxTool/Commands/Validate.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Commands/ValidateTests.cs"
+
+  # SelfTest unit reviews
+  - id: SpdxTool-SelfTest-Validate
+    title: Review that SpdxTool SelfTest Validate Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate.yaml"
+      - "docs/design/spdx-tool/self-test/validate.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/Validate.cs"
+
+  - id: SpdxTool-SelfTest-ValidateAddPackage
+    title: Review that SpdxTool SelfTest ValidateAddPackage Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-add-package.yaml"
+      - "docs/design/spdx-tool/self-test/validate-add-package.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateAddPackage.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateAddPackageTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateAddRelationship
+    title: Review that SpdxTool SelfTest ValidateAddRelationship Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-add-relationship.yaml"
+      - "docs/design/spdx-tool/self-test/validate-add-relationship.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateAddRelationship.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateAddRelationshipTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateBasic
+    title: Review that SpdxTool SelfTest ValidateBasic Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-basic.yaml"
+      - "docs/design/spdx-tool/self-test/validate-basic.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateBasic.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateBasicTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateCopyPackage
+    title: Review that SpdxTool SelfTest ValidateCopyPackage Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-copy-package.yaml"
+      - "docs/design/spdx-tool/self-test/validate-copy-package.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateCopyPackage.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateCopyPackageTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateDiagram
+    title: Review that SpdxTool SelfTest ValidateDiagram Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-diagram.yaml"
+      - "docs/design/spdx-tool/self-test/validate-diagram.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateDiagram.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateDiagramTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateFindPackage
+    title: Review that SpdxTool SelfTest ValidateFindPackage Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-find-package.yaml"
+      - "docs/design/spdx-tool/self-test/validate-find-package.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateFindPackage.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateFindPackageTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateGetVersion
+    title: Review that SpdxTool SelfTest ValidateGetVersion Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-get-version.yaml"
+      - "docs/design/spdx-tool/self-test/validate-get-version.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateGetVersion.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateGetVersionTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateHash
+    title: Review that SpdxTool SelfTest ValidateHash Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-hash.yaml"
+      - "docs/design/spdx-tool/self-test/validate-hash.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateHash.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateHashTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateNtia
+    title: Review that SpdxTool SelfTest ValidateNtia Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-ntia.yaml"
+      - "docs/design/spdx-tool/self-test/validate-ntia.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateNtia.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateNtiaTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateQuery
+    title: Review that SpdxTool SelfTest ValidateQuery Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-query.yaml"
+      - "docs/design/spdx-tool/self-test/validate-query.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateQuery.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateQueryTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateRenameId
+    title: Review that SpdxTool SelfTest ValidateRenameId Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-rename-id.yaml"
+      - "docs/design/spdx-tool/self-test/validate-rename-id.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateRenameId.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateRenameIdTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateRunNuGetWorkflow
+    title: Review that SpdxTool SelfTest ValidateRunNuGetWorkflow Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-run-nuget-workflow.yaml"
+      - "docs/design/spdx-tool/self-test/validate-run-nuget-workflow.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateRunNuGetWorkflow.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateRunNuGetWorkflowTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateToMarkdown
+    title: Review that SpdxTool SelfTest ValidateToMarkdown Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-to-markdown.yaml"
+      - "docs/design/spdx-tool/self-test/validate-to-markdown.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateToMarkdown.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateToMarkdownTests.cs"
+
+  - id: SpdxTool-SelfTest-ValidateUpdatePackage
+    title: Review that SpdxTool SelfTest ValidateUpdatePackage Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/self-test/validate-update-package.yaml"
+      - "docs/design/spdx-tool/self-test/validate-update-package.md"
+      - "src/DemaConsulting.SpdxTool/SelfTest/ValidateUpdatePackage.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/SelfTest/ValidateUpdatePackageTests.cs"
+
+  # Utility unit reviews
+  - id: SpdxTool-Utility-PathHelpers
+    title: Review that SpdxTool Utility PathHelpers Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/utility/utility.yaml"
+      - "docs/design/spdx-tool/utility/utility.md"
+      - "src/DemaConsulting.SpdxTool/Utility/PathHelpers.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Utility/PathHelpersTests.cs"
+
+  - id: SpdxTool-Utility-Wildcard
+    title: Review that SpdxTool Utility Wildcard Implementation is Correct
+    paths:
+      - "docs/reqstream/spdx-tool/utility/utility.yaml"
+      - "docs/design/spdx-tool/utility/utility.md"
+      - "src/DemaConsulting.SpdxTool/Utility/Wildcard.cs"
+      - "test/DemaConsulting.SpdxTool.Tests/Utility/WildcardTests.cs"
diff --git a/AGENTS.md b/AGENTS.md
index c884c2e..b6668ff 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -2,7 +2,43 @@
 
 Comprehensive guidance for AI agents working on repositories following Continuous Compliance practices.
 
-## Standards Application (ALL Agents Must Follow)
+# Project Structure
+
+The following is the basic folder structure of the project. Agents should use this information when searching for
+existing files and to know where to make new files.
+
+```text
+├── docs/
+│   ├── build_notes/
+│   ├── code_quality/
+│   ├── code_review_plan/
+│   ├── code_review_report/
+│   ├── design/
+│   ├── requirements_doc/
+│   ├── requirements_report/
+│   └── reqstream/
+├── src/
+│   └── <project>/
+└── test/
+    └── <test-project>/
+```
+
+# Key Configuration Files
+
+- **`.config/dotnet-tools.json`** - Local tool manifest for Continuous Compliance tools
+- **`.editorconfig`** - Code formatting rules
+- **`.clang-format`** - C/C++ formatting (if applicable)
+- **`.cspell.yaml`** - Spell-check configuration and technical term dictionary
+- **`.markdownlint-cli2.yaml`** - Markdown linting rules
+- **`.yamllint.yaml`** - YAML linting configuration
+- **`.reviewmark.yaml`** - File review definitions and tracking
+- **`nuget.config`** - NuGet package sources (if .NET)
+- **`package.json`** - Node.js dependencies for linting tools
+- **`requirements.yaml`** - Root requirements file with includes
+- **`pip-requirements.txt`** - Python dependencies for yamllint
+- **`lint.sh` / `lint.bat`** - Cross-platform comprehensive linting scripts
+
+# Standards Application (ALL Agents Must Follow)
 
 Before performing any work, agents must read and apply the relevant standards from `.github/standards/`:
 
@@ -17,24 +53,23 @@ Before performing any work, agents must read and apply the relevant standards fr
 Load only the standards relevant to your specific task scope and apply their
 quality checks and guidelines throughout your work.
 
-## Agent Delegation Guidelines
+# Agent Delegation Guidelines
 
 The default agent should handle simple, straightforward tasks directly.
 Delegate to specialized agents only for specific scenarios:
 
-- **Light development work** (small fixes, simple features) → Call developer agent
-- **Light quality checking** (linting, basic validation) → Call quality agent
-- **Formal feature implementation** (complex, multi-step) → Call the `implementation` agent
-- **Formal bug resolution** (complex debugging, systematic fixes) → Call the `implementation` agent
-- **Formal reviews** (compliance verification, detailed analysis) → Call code-review agent
-- **Template consistency** (downstream repository alignment) → Call repo-consistency agent
+- **Light development work** (small fixes, simple features) → Call the developer agent
+- **Light quality checking** (linting, basic validation) → Call the quality agent
+- **Formal feature implementation** (complex, multi-step) → Call the implementation agent
+- **Formal bug resolution** (complex debugging, systematic fixes) → Call the implementation agent
+- **Formal reviews** (compliance verification, detailed analysis) → Call the code-review agent
+- **Template consistency** (downstream repository alignment) → Call the repo-consistency agent
 
 ## Available Specialized Agents
 
-- **code-review** - Agent for performing formal reviews using standardized
-  review processes
-- **developer** - General-purpose software development agent that applies
-  appropriate standards based on the work being performed
+- **developer** - General-purpose software development agent that applies appropriate
+  standards based on the work being performed
+- **code-review** - Agent for performing formal reviews using standardized review processes
 - **implementation** - Orchestrator agent that manages quality implementations
   through a formal state machine workflow
 - **quality** - Quality assurance agent that grades developer work against DEMA
@@ -42,129 +77,49 @@ Delegate to specialized agents only for specific scenarios:
 - **repo-consistency** - Ensures downstream repositories remain consistent with
   the TemplateDotNetTool template patterns and best practices
 
-## Quality Gate Enforcement (ALL Agents Must Verify)
+# Linting (Required Before Quality Gates)
+
+1. **Markdown Auto-fix**: `npx markdownlint-cli2 --fix **/*.md` (fixes most markdown issues except line length)
+2. **Dotnet Auto-fix**: `dotnet format` (reformats .NET languages)
+3. **Run full check**: `lint.bat` (Windows) or `lint.sh` (Unix)
+4. **Fix remaining**: Address line length, spelling, YAML syntax manually
+5. **Verify clean**: Re-run until 0 errors before quality validation
+
+## Linting Tools (ALL Must Pass)
+
+- **markdownlint-cli2**: Markdown style and formatting enforcement
+- **cspell**: Spell-checking across all text files (use `.cspell.yaml` for technical terms)
+- **yamllint**: YAML structure and formatting validation
+- **Language-specific linters**: Based on repository technology stack
+
+# Quality Gate Enforcement (ALL Agents Must Verify)
 
 Configuration files and scripts are self-documenting with their design intent and
 modification policies in header comments.
 
-1. **Linting Standards**: `./lint.sh` (Unix) or `lint.bat` (Windows) - comprehensive linting suite
-2. **Build Quality**: Zero warnings (`TreatWarningsAsErrors=true`)
-3. **Static Analysis**: SonarQube/CodeQL passing with no blockers
-4. **Requirements Traceability**: `dotnet reqstream --enforce` passing
-5. **Test Coverage**: All requirements linked to passing tests
-6. **Documentation Currency**: All docs current and generated
-7. **File Review Status**: All reviewable files have current reviews
+1. **Build Quality**: Zero warnings (`TreatWarningsAsErrors=true`)
+2. **Static Analysis**: SonarQube/CodeQL passing with no blockers
+3. **Requirements Traceability**: `dotnet reqstream --enforce` passing
+4. **Test Coverage**: All requirements linked to passing tests
+5. **Documentation Currency**: All docs current and generated
+6. **File Review Status**: All reviewable files have current reviews
 
-## Continuous Compliance Overview
+# Continuous Compliance Overview
 
 This repository follows the DEMA Consulting Continuous Compliance
 <https://github.com/demaconsulting/ContinuousCompliance> approach, which enforces quality and
 compliance gates on every CI/CD run instead of as a last-mile activity.
 
-### Core Principles
+## Core Principles
 
 - **Requirements Traceability**: Every requirement MUST link to passing tests
 - **Quality Gates**: All quality checks must pass before merge
 - **Documentation Currency**: All docs auto-generated and kept current
 - **Automated Evidence**: Full audit trail generated with every build
 
-## Required Compliance Tools
-
-### Linting Tools (ALL Must Pass)
-
-- **markdownlint-cli2**: Markdown style and formatting enforcement
-- **cspell**: Spell-checking across all text files (use `.cspell.yaml` for technical terms)
-- **yamllint**: YAML structure and formatting validation
-- **Language-specific linters**: Based on repository technology stack
-
-### Quality Analysis
-
-- **SonarQube/SonarCloud**: Code quality and security analysis
-- **CodeQL**: Security vulnerability scanning (produces SARIF output)
-- **Static analyzers**: Microsoft.CodeAnalysis.NetAnalyzers, SonarAnalyzer.CSharp, etc.
-
-### Requirements & Compliance
+## Requirements & Compliance
 
 - **ReqStream**: Requirements traceability enforcement (`dotnet reqstream --enforce`)
 - **ReviewMark**: File review status enforcement
 - **BuildMark**: Tool version documentation
 - **VersionMark**: Version tracking across CI/CD jobs
-
-## Project Structure Template
-
-- `docs/` - Documentation and compliance artifacts
-  - `design/` - Detailed design documents
-    - `introduction.md` - System/Subsystem/Unit breakdown for this repository
-  - `reqstream/` - Subsystem requirements YAML files (included by root requirements.yaml)
-  - Auto-generated reports (requirements, justifications, trace matrix)
-- `src/{ProjectName}/` - Source code projects
-- `test/{ProjectName}.Tests/` - Test projects
-- `.github/workflows/` - CI/CD pipeline definitions (build.yaml, build_on_push.yaml, release.yaml)
-- Configuration files: `.editorconfig`, `.clang-format`, `nuget.config`, `.reviewmark.yaml`, etc.
-
-## Key Configuration Files
-
-### Essential Files (Repository-Specific)
-
-- **`lint.sh` / `lint.bat`** - Cross-platform comprehensive linting scripts
-- **`.editorconfig`** - Code formatting rules
-- **`.clang-format`** - C/C++ formatting (if applicable)
-- **`.cspell.yaml`** - Spell-check configuration and technical term dictionary
-- **`.markdownlint-cli2.yaml`** - Markdown linting rules
-- **`.yamllint.yaml`** - YAML linting configuration
-- **`nuget.config`** - NuGet package sources (if .NET)
-- **`package.json`** - Node.js dependencies for linting tools
-
-### Compliance Files
-
-- **`requirements.yaml`** - Root requirements file with includes
-- **`.reviewmark.yaml`** - File review definitions and tracking
-- CI/CD pipeline files with quality gate enforcement
-
-## Continuous Compliance Workflow
-
-### CI/CD Pipeline Stages (Standard)
-
-1. **Lint**: `./lint.sh` or `lint.bat` - comprehensive linting suite
-2. **Build**: Compile with warnings as errors
-3. **Analyze**: SonarQube/SonarCloud, CodeQL security scanning
-4. **Test**: Execute all tests, generate coverage reports
-5. **Validate**: Tool self-validation tests
-6. **Document**: Generate requirements reports, trace matrix, build notes
-7. **Enforce**: Requirements traceability, file review status
-8. **Publish**: Generate final documentation (Pandoc → PDF)
-
-### Quality Gate Enforcement
-
-All stages must pass before merge. Pipeline fails immediately on:
-
-- Any linting errors
-- Build warnings or errors
-- Security vulnerabilities (CodeQL)
-- Requirements without test coverage
-- Outdated file reviews
-- Missing documentation
-
-## Continuous Compliance Requirements
-
-This repository follows continuous compliance practices from DEMA Consulting
-Continuous Compliance <https://github.com/demaconsulting/ContinuousCompliance>.
-
-### Core Requirements Traceability Rules
-
-- **ALL requirements MUST be linked to tests** - Enforced in CI via `dotnet reqstream --enforce`
-- **NOT all tests need requirement links** - Tests may exist for corner cases, design validation, failure scenarios
-- **Source filters are critical** - Platform/framework requirements need specific test evidence
-
-For detailed requirements format, test linkage patterns, and ReqStream
-integration, call the developer agent with requirements management context.
-
-## Agent Report Files
-
-Upon completion, create a report file at `.agent-logs/{agent-name}-{subject}-{unique-id}.md` that includes:
-
-- A concise summary of the work performed
-- Any important decisions made and their rationale
-- Follow-up items, open questions, or TODOs
-
-Store agent logs in the `.agent-logs/` folder so they are ignored via `.gitignore` and excluded from linting and commits.
diff --git a/README.md b/README.md
index 799d25d..f17a8f9 100644
--- a/README.md
+++ b/README.md
@@ -187,7 +187,7 @@ Additional information can be found at:
 
 [command-line-docs]: https://github.com/demaconsulting/SpdxTool/blob/main/docs/spdx-tool-command-line.md
 [workflow-docs]: https://github.com/demaconsulting/SpdxTool/blob/main/docs/spdx-tool-workflow-files.md
-[user-guide]: https://github.com/demaconsulting/SpdxTool/blob/main/docs/guide/guide.md
+[user-guide]: https://github.com/demaconsulting/SpdxTool/blob/main/docs/user_guide/introduction.md
 [contributing]: https://github.com/demaconsulting/SpdxTool/blob/main/CONTRIBUTING.md
 [code-of-conduct]: https://github.com/demaconsulting/SpdxTool/blob/main/CODE_OF_CONDUCT.md
 [architecture]: https://github.com/demaconsulting/SpdxTool/blob/main/ARCHITECTURE.md
diff --git a/docs/design/introduction.md b/docs/design/introduction.md
index 21043ac..5391412 100644
--- a/docs/design/introduction.md
+++ b/docs/design/introduction.md
@@ -143,10 +143,10 @@ src/DemaConsulting.SpdxTool.Targets/
 
 Per-unit design documentation is maintained for Commands and SelfTest subsystem units:
 
-- `docs/design/commands/<command>.md` — design doc for each command unit
-- `docs/design/self-test/<unit>.md` — design doc for each SelfTest unit
+- `docs/design/spdx-tool/commands/<command>.md` — design doc for each command unit
+- `docs/design/spdx-tool/self-test/<unit>.md` — design doc for each SelfTest unit
 
 Per-unit requirements are maintained alongside the design docs:
 
-- `docs/reqstream/commands/<command>.yaml` — requirements for each command unit
-- `docs/reqstream/self-test/<unit>.yaml` — requirements for each SelfTest unit
+- `docs/reqstream/spdx-tool/commands/<command>.yaml` — requirements for each command unit
+- `docs/reqstream/spdx-tool/self-test/<unit>.yaml` — requirements for each SelfTest unit
diff --git a/docs/design/spdxtool-targets-system.md b/docs/design/spdx-tool-targets/spdx-tool-targets.md
similarity index 100%
rename from docs/design/spdxtool-targets-system.md
rename to docs/design/spdx-tool-targets/spdx-tool-targets.md
diff --git a/docs/design/commands/add-package.md b/docs/design/spdx-tool/commands/add-package.md
similarity index 100%
rename from docs/design/commands/add-package.md
rename to docs/design/spdx-tool/commands/add-package.md
diff --git a/docs/design/commands/add-relationship.md b/docs/design/spdx-tool/commands/add-relationship.md
similarity index 100%
rename from docs/design/commands/add-relationship.md
rename to docs/design/spdx-tool/commands/add-relationship.md
diff --git a/docs/design/commands/commands.md b/docs/design/spdx-tool/commands/commands.md
similarity index 100%
rename from docs/design/commands/commands.md
rename to docs/design/spdx-tool/commands/commands.md
diff --git a/docs/design/commands/copy-package.md b/docs/design/spdx-tool/commands/copy-package.md
similarity index 100%
rename from docs/design/commands/copy-package.md
rename to docs/design/spdx-tool/commands/copy-package.md
diff --git a/docs/design/commands/diagram.md b/docs/design/spdx-tool/commands/diagram.md
similarity index 100%
rename from docs/design/commands/diagram.md
rename to docs/design/spdx-tool/commands/diagram.md
diff --git a/docs/design/commands/find-package.md b/docs/design/spdx-tool/commands/find-package.md
similarity index 100%
rename from docs/design/commands/find-package.md
rename to docs/design/spdx-tool/commands/find-package.md
diff --git a/docs/design/commands/get-version.md b/docs/design/spdx-tool/commands/get-version.md
similarity index 100%
rename from docs/design/commands/get-version.md
rename to docs/design/spdx-tool/commands/get-version.md
diff --git a/docs/design/commands/hash.md b/docs/design/spdx-tool/commands/hash.md
similarity index 100%
rename from docs/design/commands/hash.md
rename to docs/design/spdx-tool/commands/hash.md
diff --git a/docs/design/commands/help.md b/docs/design/spdx-tool/commands/help.md
similarity index 100%
rename from docs/design/commands/help.md
rename to docs/design/spdx-tool/commands/help.md
diff --git a/docs/design/commands/print.md b/docs/design/spdx-tool/commands/print.md
similarity index 100%
rename from docs/design/commands/print.md
rename to docs/design/spdx-tool/commands/print.md
diff --git a/docs/design/commands/query.md b/docs/design/spdx-tool/commands/query.md
similarity index 100%
rename from docs/design/commands/query.md
rename to docs/design/spdx-tool/commands/query.md
diff --git a/docs/design/commands/rename-id.md b/docs/design/spdx-tool/commands/rename-id.md
similarity index 100%
rename from docs/design/commands/rename-id.md
rename to docs/design/spdx-tool/commands/rename-id.md
diff --git a/docs/design/commands/run-workflow.md b/docs/design/spdx-tool/commands/run-workflow.md
similarity index 100%
rename from docs/design/commands/run-workflow.md
rename to docs/design/spdx-tool/commands/run-workflow.md
diff --git a/docs/design/commands/set-variable.md b/docs/design/spdx-tool/commands/set-variable.md
similarity index 100%
rename from docs/design/commands/set-variable.md
rename to docs/design/spdx-tool/commands/set-variable.md
diff --git a/docs/design/commands/to-markdown.md b/docs/design/spdx-tool/commands/to-markdown.md
similarity index 100%
rename from docs/design/commands/to-markdown.md
rename to docs/design/spdx-tool/commands/to-markdown.md
diff --git a/docs/design/commands/update-package.md b/docs/design/spdx-tool/commands/update-package.md
similarity index 100%
rename from docs/design/commands/update-package.md
rename to docs/design/spdx-tool/commands/update-package.md
diff --git a/docs/design/commands/validate.md b/docs/design/spdx-tool/commands/validate.md
similarity index 100%
rename from docs/design/commands/validate.md
rename to docs/design/spdx-tool/commands/validate.md
diff --git a/docs/design/self-test/self-test.md b/docs/design/spdx-tool/self-test/self-test.md
similarity index 100%
rename from docs/design/self-test/self-test.md
rename to docs/design/spdx-tool/self-test/self-test.md
diff --git a/docs/design/self-test/validate-add-package.md b/docs/design/spdx-tool/self-test/validate-add-package.md
similarity index 100%
rename from docs/design/self-test/validate-add-package.md
rename to docs/design/spdx-tool/self-test/validate-add-package.md
diff --git a/docs/design/self-test/validate-add-relationship.md b/docs/design/spdx-tool/self-test/validate-add-relationship.md
similarity index 100%
rename from docs/design/self-test/validate-add-relationship.md
rename to docs/design/spdx-tool/self-test/validate-add-relationship.md
diff --git a/docs/design/self-test/validate-basic.md b/docs/design/spdx-tool/self-test/validate-basic.md
similarity index 100%
rename from docs/design/self-test/validate-basic.md
rename to docs/design/spdx-tool/self-test/validate-basic.md
diff --git a/docs/design/self-test/validate-copy-package.md b/docs/design/spdx-tool/self-test/validate-copy-package.md
similarity index 100%
rename from docs/design/self-test/validate-copy-package.md
rename to docs/design/spdx-tool/self-test/validate-copy-package.md
diff --git a/docs/design/self-test/validate-diagram.md b/docs/design/spdx-tool/self-test/validate-diagram.md
similarity index 100%
rename from docs/design/self-test/validate-diagram.md
rename to docs/design/spdx-tool/self-test/validate-diagram.md
diff --git a/docs/design/self-test/validate-find-package.md b/docs/design/spdx-tool/self-test/validate-find-package.md
similarity index 100%
rename from docs/design/self-test/validate-find-package.md
rename to docs/design/spdx-tool/self-test/validate-find-package.md
diff --git a/docs/design/self-test/validate-get-version.md b/docs/design/spdx-tool/self-test/validate-get-version.md
similarity index 100%
rename from docs/design/self-test/validate-get-version.md
rename to docs/design/spdx-tool/self-test/validate-get-version.md
diff --git a/docs/design/self-test/validate-hash.md b/docs/design/spdx-tool/self-test/validate-hash.md
similarity index 100%
rename from docs/design/self-test/validate-hash.md
rename to docs/design/spdx-tool/self-test/validate-hash.md
diff --git a/docs/design/self-test/validate-ntia.md b/docs/design/spdx-tool/self-test/validate-ntia.md
similarity index 100%
rename from docs/design/self-test/validate-ntia.md
rename to docs/design/spdx-tool/self-test/validate-ntia.md
diff --git a/docs/design/self-test/validate-query.md b/docs/design/spdx-tool/self-test/validate-query.md
similarity index 100%
rename from docs/design/self-test/validate-query.md
rename to docs/design/spdx-tool/self-test/validate-query.md
diff --git a/docs/design/self-test/validate-rename-id.md b/docs/design/spdx-tool/self-test/validate-rename-id.md
similarity index 100%
rename from docs/design/self-test/validate-rename-id.md
rename to docs/design/spdx-tool/self-test/validate-rename-id.md
diff --git a/docs/design/self-test/validate-run-nuget-workflow.md b/docs/design/spdx-tool/self-test/validate-run-nuget-workflow.md
similarity index 100%
rename from docs/design/self-test/validate-run-nuget-workflow.md
rename to docs/design/spdx-tool/self-test/validate-run-nuget-workflow.md
diff --git a/docs/design/self-test/validate-to-markdown.md b/docs/design/spdx-tool/self-test/validate-to-markdown.md
similarity index 100%
rename from docs/design/self-test/validate-to-markdown.md
rename to docs/design/spdx-tool/self-test/validate-to-markdown.md
diff --git a/docs/design/self-test/validate-update-package.md b/docs/design/spdx-tool/self-test/validate-update-package.md
similarity index 100%
rename from docs/design/self-test/validate-update-package.md
rename to docs/design/spdx-tool/self-test/validate-update-package.md
diff --git a/docs/design/self-test/validate.md b/docs/design/spdx-tool/self-test/validate.md
similarity index 100%
rename from docs/design/self-test/validate.md
rename to docs/design/spdx-tool/self-test/validate.md
diff --git a/docs/design/spdxtool-system.md b/docs/design/spdx-tool/spdx-tool.md
similarity index 100%
rename from docs/design/spdxtool-system.md
rename to docs/design/spdx-tool/spdx-tool.md
diff --git a/docs/design/utility.md b/docs/design/spdx-tool/utility/utility.md
similarity index 100%
rename from docs/design/utility.md
rename to docs/design/spdx-tool/utility/utility.md
diff --git a/docs/reqstream/self-test/self-test.yaml b/docs/reqstream/self-test/self-test.yaml
deleted file mode 100644
index e6b6b28..0000000
--- a/docs/reqstream/self-test/self-test.yaml
+++ /dev/null
@@ -1,52 +0,0 @@
-# DemaConsulting.SpdxTool Self-Test Requirements
-#
-# This file contains requirements for the SpdxTool self-test subsystem,
-# covering the --validate flag, depth control, and result output formats.
-# It is included by the root requirements.yaml file.
----
-sections:
-  - title: SpdxTool Requirements
-    sections:
-      - title: Self-Validation
-        requirements:
-          - id: SpdxTool-Cmd-Validate
-            title: The tool shall perform self-validation when invoked with the --validate flag.
-            tags:
-              - cli
-            justification: |
-              Self-validation ensures that the tool functions correctly after installation
-              or deployment. This is critical for CI/CD pipelines and quality assurance.
-            tests:
-              - SelfTest_ValidateFlag_Succeeds
-
-          - id: SpdxTool-Cmd-Depth
-            title: The tool shall support depth control for self-validation output.
-            tags:
-              - cli
-            justification: |
-              Users may want to see detailed hierarchical results during self-validation
-              to understand which specific tests passed or failed at different depths.
-            tests:
-              - SelfTest_ValidateFlagWithDepth_ShowsDepth
-
-          - id: SpdxTool-Cmd-ResultsTrx
-            title: The tool shall write self-validation results as TRX when the --result flag uses a .trx extension.
-            tags:
-              - cli
-            justification: |
-              CI/CD systems and test reporting tools often require test results in
-              standardized formats like TRX. This enables integration with existing
-              test infrastructure.
-            tests:
-              - SelfTest_ValidateFlagWithResults_GeneratesTrxFile
-
-          - id: SpdxTool-Cmd-ResultsJUnit
-            title: The tool shall write self-validation results as JUnit XML when the --result flag uses .xml extension.
-            tags:
-              - cli
-            justification: |
-              Many CI/CD systems and test reporting tools support JUnit XML format.
-              Auto-detecting the format from the file extension allows users to generate
-              JUnit output without requiring a separate flag.
-            tests:
-              - SelfTest_ValidateFlagWithResults_GeneratesJUnitFile
diff --git a/docs/reqstream/spdxtool-targets-system.yaml b/docs/reqstream/spdx-tool-targets/spdx-tool-targets.yaml
similarity index 100%
rename from docs/reqstream/spdxtool-targets-system.yaml
rename to docs/reqstream/spdx-tool-targets/spdx-tool-targets.yaml
diff --git a/docs/reqstream/commands/add-package.yaml b/docs/reqstream/spdx-tool/commands/add-package.yaml
similarity index 69%
rename from docs/reqstream/commands/add-package.yaml
rename to docs/reqstream/spdx-tool/commands/add-package.yaml
index 8cb4450..71860ac 100644
--- a/docs/reqstream/commands/add-package.yaml
+++ b/docs/reqstream/spdx-tool/commands/add-package.yaml
@@ -14,4 +14,7 @@ sections:
           Users need to incrementally build SPDX documents by adding new packages
           that represent software components, libraries, or dependencies.
         tests:
-          - SpdxTool_AddPackage
+          - AddPackage_OnCommandLine_ReportsWorkflowOnlyError
+          - AddPackage_InWorkflowWithRelationship_AddsPackageAndRelationship
+          - AddPackage_InWorkflowNoRelationship_AddsPackageOnly
+          - AddPackage_InWorkflowWithQueryVersion_AddsPackage
diff --git a/docs/reqstream/commands/add-relationship.yaml b/docs/reqstream/spdx-tool/commands/add-relationship.yaml
similarity index 78%
rename from docs/reqstream/commands/add-relationship.yaml
rename to docs/reqstream/spdx-tool/commands/add-relationship.yaml
index eb172cf..c3de787 100644
--- a/docs/reqstream/commands/add-relationship.yaml
+++ b/docs/reqstream/spdx-tool/commands/add-relationship.yaml
@@ -15,4 +15,6 @@ sections:
           elements. Users need to define these relationships to accurately represent
           dependency graphs and component hierarchies.
         tests:
-          - SpdxTool_AddRelationship
+          - AddRelationship_OnCommandLine_ReportsWorkflowOnlyError
+          - AddRelationship_InWorkflow_AddsRelationship
+          - AddRelationship_ReplaceMode_ReplacesExistingRelationship
diff --git a/docs/reqstream/spdx-tool/commands/commands.yaml b/docs/reqstream/spdx-tool/commands/commands.yaml
new file mode 100644
index 0000000..b6e323f
--- /dev/null
+++ b/docs/reqstream/spdx-tool/commands/commands.yaml
@@ -0,0 +1,72 @@
+# DemaConsulting.SpdxTool Commands Subsystem Requirements
+#
+# This file contains subsystem-level requirements for the Commands subsystem,
+# covering command registry, dispatch, and variable expansion.
+# It is included by the root requirements.yaml file.
+---
+sections:
+  - title: Commands Subsystem Requirements
+    requirements:
+      - id: SpdxTool-Commands-Registry
+        title: The Commands subsystem shall maintain a registry of all available commands.
+        justification: |
+          The command registry provides a central lookup mechanism for all commands
+          supported by the SpdxTool. This enables dynamic dispatch and allows the
+          help system to enumerate available commands. The registry must correctly
+          map command names to their implementations.
+        children:
+          - SpdxTool-Pkg-AddPackage
+          - SpdxTool-Rel-AddRelationship
+          - SpdxTool-Pkg-CopyPackage
+          - SpdxTool-Xfm-Diagram
+          - SpdxTool-Pkg-FindPackage
+          - SpdxTool-Pkg-GetVersion
+          - SpdxTool-Hsh-Hash
+          - SpdxTool-Cmd-HelpCommand
+          - SpdxTool-Wkf-Print
+          - SpdxTool-Wkf-Query
+          - SpdxTool-Man-RenameId
+          - SpdxTool-Wkf-RunWorkflow
+          - SpdxTool-Wkf-NuGetWorkflow
+          - SpdxTool-Wkf-SetVariable
+          - SpdxTool-Xfm-ToMarkdown
+          - SpdxTool-Pkg-UpdatePackage
+          - SpdxTool-Val-Validate
+          - SpdxTool-Val-NtiaMinimum
+        tests:
+          - Command_Expand_NoVariables_ReturnsOriginal
+          - UnknownCommand_UnrecognizedCommand_ReportsError
+
+      - id: SpdxTool-Commands-Dispatch
+        title: The Commands subsystem shall dispatch commands by name to their implementations.
+        justification: |
+          Command dispatch is the core responsibility of the Commands subsystem.
+          When a command name is provided, the subsystem must locate and execute
+          the correct implementation, or report an appropriate error when the
+          command is not found.
+        tests:
+          - UnknownCommand_UnrecognizedCommand_ReportsError
+
+      - id: SpdxTool-Commands-VariableExpansion
+        title: The Commands subsystem shall expand variables in command arguments using ${{ variable }} syntax.
+        justification: |
+          Variable expansion allows workflow authors to parameterize command
+          arguments. The expansion must handle missing variables, simple variable
+          substitution, and nested variable references where a variable name
+          itself contains a variable reference.
+        tests:
+          - Command_Expand_MissingVariable_ReturnsMissingToken
+          - Command_Expand_NoVariables_ReturnsOriginal
+          - Command_Expand_BasicVariable_ReturnsExpanded
+          - Command_Expand_NestedVariable_ReturnsFullyExpanded
+
+      - id: SpdxTool-Commands-MapString
+        title: The Commands subsystem shall extract string values from YAML mapping nodes with variable expansion.
+        justification: |
+          Command implementations read their arguments from YAML mapping nodes.
+          The GetMapString helper must return null for missing entries and apply
+          variable expansion to present entries, enabling consistent argument
+          handling across all commands.
+        tests:
+          - Command_GetMapString_MissingEntry_ReturnsNull
+          - Command_GetMapString_WithVariableExpansion_ReturnsExpanded
diff --git a/docs/reqstream/commands/copy-package.yaml b/docs/reqstream/spdx-tool/commands/copy-package.yaml
similarity index 71%
rename from docs/reqstream/commands/copy-package.yaml
rename to docs/reqstream/spdx-tool/commands/copy-package.yaml
index fdceb76..92c0019 100644
--- a/docs/reqstream/commands/copy-package.yaml
+++ b/docs/reqstream/spdx-tool/commands/copy-package.yaml
@@ -14,4 +14,7 @@ sections:
           Users need to reuse package information across multiple SPDX documents
           to avoid duplication and ensure consistency of package metadata.
         tests:
-          - SpdxTool_CopyPackage
+          - CopyPackage_OnCommandLine_ReportsWorkflowOnlyError
+          - CopyPackage_InWorkflow_CopiesPackage
+          - CopyPackage_InWorkflowRecursive_CopiesPackageRecursively
+          - CopyPackage_InWorkflowWithFiles_CopiesPackageAndFiles
diff --git a/docs/reqstream/commands/diagram.yaml b/docs/reqstream/spdx-tool/commands/diagram.yaml
similarity index 84%
rename from docs/reqstream/commands/diagram.yaml
rename to docs/reqstream/spdx-tool/commands/diagram.yaml
index 16ba664..891e181 100644
--- a/docs/reqstream/commands/diagram.yaml
+++ b/docs/reqstream/spdx-tool/commands/diagram.yaml
@@ -15,4 +15,5 @@ sections:
           help users understand complex dependency graphs. Mermaid is a popular
           text-based diagramming language.
         tests:
-          - SpdxTool_Diagram
+          - Diagram_ValidSpdxFile_GeneratesDiagram
+          - Diagram_WithToolsOption_GeneratesDiagramWithTools
diff --git a/docs/reqstream/commands/find-package.yaml b/docs/reqstream/spdx-tool/commands/find-package.yaml
similarity index 70%
rename from docs/reqstream/commands/find-package.yaml
rename to docs/reqstream/spdx-tool/commands/find-package.yaml
index be00e7e..0a4ba52 100644
--- a/docs/reqstream/commands/find-package.yaml
+++ b/docs/reqstream/spdx-tool/commands/find-package.yaml
@@ -14,4 +14,8 @@ sections:
           Users need to locate specific packages within SPDX documents based on
           criteria such as name, version, or other attributes to query or modify them.
         tests:
-          - SpdxTool_FindPackage
+          - FindPackage_OnCommandLine_ReportsWorkflowOnlyError
+          - FindPackage_ByName_FindsPackage
+          - FindPackage_ByVersion_FindsPackage
+          - FindPackage_ByFileName_FindsPackage
+          - FindPackage_ByDownloadUrl_FindsPackage
diff --git a/docs/reqstream/commands/get-version.yaml b/docs/reqstream/spdx-tool/commands/get-version.yaml
similarity index 83%
rename from docs/reqstream/commands/get-version.yaml
rename to docs/reqstream/spdx-tool/commands/get-version.yaml
index d39fe73..5c4deec 100644
--- a/docs/reqstream/commands/get-version.yaml
+++ b/docs/reqstream/spdx-tool/commands/get-version.yaml
@@ -14,4 +14,5 @@ sections:
           Users need to extract version information from packages for reporting,
           dependency management, and compatibility checking.
         tests:
-          - SpdxTool_GetVersion
+          - GetVersion_OnCommandLine_ReportsWorkflowOnlyError
+          - GetVersion_InWorkflow_ReturnsPackageVersion
diff --git a/docs/reqstream/commands/hash.yaml b/docs/reqstream/spdx-tool/commands/hash.yaml
similarity index 79%
rename from docs/reqstream/commands/hash.yaml
rename to docs/reqstream/spdx-tool/commands/hash.yaml
index 2f4a375..07cb2bf 100644
--- a/docs/reqstream/commands/hash.yaml
+++ b/docs/reqstream/spdx-tool/commands/hash.yaml
@@ -15,4 +15,6 @@ sections:
           Users need to compute hashes using various algorithms and verify that
           files match expected hash values.
         tests:
-          - SpdxTool_Hash
+          - Hash_GenerateOperation_UpdatesPackageHash
+          - Hash_VerifyOperation_SucceedsForValidHash
+          - Hash_VerifyOperation_FailsForInvalidHash
diff --git a/docs/reqstream/commands/help.yaml b/docs/reqstream/spdx-tool/commands/help.yaml
similarity index 100%
rename from docs/reqstream/commands/help.yaml
rename to docs/reqstream/spdx-tool/commands/help.yaml
diff --git a/docs/reqstream/commands/print.yaml b/docs/reqstream/spdx-tool/commands/print.yaml
similarity index 100%
rename from docs/reqstream/commands/print.yaml
rename to docs/reqstream/spdx-tool/commands/print.yaml
diff --git a/docs/reqstream/commands/query.yaml b/docs/reqstream/spdx-tool/commands/query.yaml
similarity index 82%
rename from docs/reqstream/commands/query.yaml
rename to docs/reqstream/spdx-tool/commands/query.yaml
index fb1b22c..0bd0e85 100644
--- a/docs/reqstream/commands/query.yaml
+++ b/docs/reqstream/spdx-tool/commands/query.yaml
@@ -14,4 +14,5 @@ sections:
           Workflows often need to extract information from external tools or
           commands to incorporate into SPDX documents or workflow logic.
         tests:
-          - SpdxTool_Query
+          - Query_DotNetVersion_OnCommandLine_ReturnsVersion
+          - Query_DotNetVersion_InWorkflow_StoresVersion
diff --git a/docs/reqstream/commands/rename-id.yaml b/docs/reqstream/spdx-tool/commands/rename-id.yaml
similarity index 93%
rename from docs/reqstream/commands/rename-id.yaml
rename to docs/reqstream/spdx-tool/commands/rename-id.yaml
index 90a5afc..2041c92 100644
--- a/docs/reqstream/commands/rename-id.yaml
+++ b/docs/reqstream/spdx-tool/commands/rename-id.yaml
@@ -15,4 +15,4 @@ sections:
           conventions, or reorganize SPDX documents while maintaining referential
           integrity.
         tests:
-          - SpdxTool_RenameId
+          - RenameId_ValidSpdxFile_RenamesId
diff --git a/docs/reqstream/commands/run-workflow.yaml b/docs/reqstream/spdx-tool/commands/run-workflow.yaml
similarity index 76%
rename from docs/reqstream/commands/run-workflow.yaml
rename to docs/reqstream/spdx-tool/commands/run-workflow.yaml
index 28231d6..eff6f0a 100644
--- a/docs/reqstream/commands/run-workflow.yaml
+++ b/docs/reqstream/spdx-tool/commands/run-workflow.yaml
@@ -16,10 +16,11 @@ sections:
           enable users to define and automate multi-step processes in a declarative
           YAML format.
         tests:
-          - SpdxTool_AddPackage
-          - SpdxTool_AddRelationship
-          - SpdxTool_CopyPackage
-          - SpdxTool_UpdatePackage
+          - RunWorkflow_ValidWorkflowFile_ExecutesWorkflow
+          - RunWorkflow_WithDefaultParameters_UsesDefaults
+          - RunWorkflow_WithSpecifiedParameters_UsesSpecified
+          - RunWorkflow_WithOutputs_PopulatesOutputs
+          - RunWorkflow_UrlWorkflow_ExecutesWorkflow
 
       - id: SpdxTool-Wkf-NuGetWorkflow
         title: The tool shall support running workflow files from NuGet packages using the run-workflow command.
@@ -30,4 +31,4 @@ sections:
           workflows can be versioned, distributed, and cached locally rather than
           downloaded on every run.
         tests:
-          - SpdxTool_RunNuGetWorkflow
+          - RunWorkflow_NuGetWorkflow_ExecutesWorkflow
diff --git a/docs/reqstream/commands/set-variable.yaml b/docs/reqstream/spdx-tool/commands/set-variable.yaml
similarity index 100%
rename from docs/reqstream/commands/set-variable.yaml
rename to docs/reqstream/spdx-tool/commands/set-variable.yaml
diff --git a/docs/reqstream/commands/to-markdown.yaml b/docs/reqstream/spdx-tool/commands/to-markdown.yaml
similarity index 92%
rename from docs/reqstream/commands/to-markdown.yaml
rename to docs/reqstream/spdx-tool/commands/to-markdown.yaml
index 2b9ba7e..4a8b679 100644
--- a/docs/reqstream/commands/to-markdown.yaml
+++ b/docs/reqstream/spdx-tool/commands/to-markdown.yaml
@@ -15,4 +15,4 @@ sections:
           documentation, reporting, and review purposes. Markdown is a widely
           supported format for documentation.
         tests:
-          - SpdxTool_ToMarkdown
+          - ToMarkdown_ValidSpdxFile_GeneratesMarkdown
diff --git a/docs/reqstream/commands/update-package.yaml b/docs/reqstream/spdx-tool/commands/update-package.yaml
similarity index 83%
rename from docs/reqstream/commands/update-package.yaml
rename to docs/reqstream/spdx-tool/commands/update-package.yaml
index bdb2bec..42dd239 100644
--- a/docs/reqstream/commands/update-package.yaml
+++ b/docs/reqstream/spdx-tool/commands/update-package.yaml
@@ -14,4 +14,5 @@ sections:
           Users need to modify package metadata as software components evolve,
           such as updating versions, licenses, or other attributes.
         tests:
-          - SpdxTool_UpdatePackage
+          - UpdatePackage_OnCommandLine_ReportsWorkflowOnlyError
+          - UpdatePackage_InWorkflow_UpdatesPackage
diff --git a/docs/reqstream/commands/validate.yaml b/docs/reqstream/spdx-tool/commands/validate.yaml
similarity index 83%
rename from docs/reqstream/commands/validate.yaml
rename to docs/reqstream/spdx-tool/commands/validate.yaml
index 7fb6844..68a9d37 100644
--- a/docs/reqstream/commands/validate.yaml
+++ b/docs/reqstream/spdx-tool/commands/validate.yaml
@@ -15,7 +15,8 @@ sections:
           Users need to verify that SPDX documents conform to the SPDX specification
           before using them in downstream processes or sharing them with others.
         tests:
-          - SpdxTool_Validate
+          - Validate_ValidSpdxDocument_Succeeds
+          - Validate_ValidDocumentNoFilesAnalyzed_Succeeds
 
       - id: SpdxTool-Val-NtiaMinimum
         title: The tool shall validate SPDX documents against NTIA minimum elements requirements.
@@ -26,4 +27,5 @@ sections:
           defined minimum elements for SBOM. Users need to verify compliance with
           these requirements for regulatory and industry standards.
         tests:
-          - SpdxTool_Ntia
+          - Validate_NtiaValidDocument_Succeeds
+          - Validate_NtiaInvalidDocument_ReportsNtiaErrors
diff --git a/docs/reqstream/platform-requirements.yaml b/docs/reqstream/spdx-tool/platform-requirements.yaml
similarity index 100%
rename from docs/reqstream/platform-requirements.yaml
rename to docs/reqstream/spdx-tool/platform-requirements.yaml
diff --git a/docs/reqstream/spdx-tool/self-test/self-test.yaml b/docs/reqstream/spdx-tool/self-test/self-test.yaml
new file mode 100644
index 0000000..3aa81cf
--- /dev/null
+++ b/docs/reqstream/spdx-tool/self-test/self-test.yaml
@@ -0,0 +1,51 @@
+# DemaConsulting.SpdxTool Self-Test Subsystem Requirements
+#
+# This file contains subsystem-level requirements for the SelfTest subsystem,
+# covering self-validation orchestration and result output formats.
+# It is included by the root requirements.yaml file.
+---
+sections:
+  - title: SelfTest Subsystem Requirements
+    requirements:
+      - id: SpdxTool-SelfTest-Validate
+        title: The SelfTest subsystem shall perform self-validation of all commands and report results.
+        justification: |
+          Self-validation ensures that the tool functions correctly after installation
+          or deployment. The subsystem must orchestrate all validation steps and
+          collect pass/fail results into a structured outcome.
+        children:
+          - SpdxTool-ST-Orchestrate
+        tests:
+          - SelfTest_Validate_Succeeds
+
+      - id: SpdxTool-SelfTest-Depth
+        title: The SelfTest subsystem shall support depth-controlled output for validation results.
+        justification: |
+          Users may want to see detailed hierarchical results during self-validation
+          to understand which specific steps passed or failed at different depths.
+        children:
+          - SpdxTool-ST-Orchestrate
+        tests:
+          - SelfTest_ValidateWithDepth_Succeeds
+
+      - id: SpdxTool-SelfTest-ResultsTrx
+        title: The SelfTest subsystem shall write validation results in TRX format.
+        justification: |
+          CI/CD systems and test reporting tools often require test results in
+          standardized formats like TRX. This enables integration with existing
+          test infrastructure.
+        children:
+          - SpdxTool-ST-Orchestrate
+        tests:
+          - SelfTest_ValidateWithTrxResult_GeneratesTrxFile
+
+      - id: SpdxTool-SelfTest-ResultsJUnit
+        title: The SelfTest subsystem shall write validation results in JUnit XML format.
+        justification: |
+          Many CI/CD systems and test reporting tools support JUnit XML format.
+          Auto-detecting the format from the file extension allows users to generate
+          JUnit output without requiring a separate flag.
+        children:
+          - SpdxTool-ST-Orchestrate
+        tests:
+          - SelfTest_ValidateWithJUnitResult_GeneratesJUnitFile
diff --git a/docs/reqstream/self-test/validate-add-package.yaml b/docs/reqstream/spdx-tool/self-test/validate-add-package.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-add-package.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-add-package.yaml
diff --git a/docs/reqstream/self-test/validate-add-relationship.yaml b/docs/reqstream/spdx-tool/self-test/validate-add-relationship.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-add-relationship.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-add-relationship.yaml
diff --git a/docs/reqstream/self-test/validate-basic.yaml b/docs/reqstream/spdx-tool/self-test/validate-basic.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-basic.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-basic.yaml
diff --git a/docs/reqstream/self-test/validate-copy-package.yaml b/docs/reqstream/spdx-tool/self-test/validate-copy-package.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-copy-package.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-copy-package.yaml
diff --git a/docs/reqstream/self-test/validate-diagram.yaml b/docs/reqstream/spdx-tool/self-test/validate-diagram.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-diagram.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-diagram.yaml
diff --git a/docs/reqstream/self-test/validate-find-package.yaml b/docs/reqstream/spdx-tool/self-test/validate-find-package.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-find-package.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-find-package.yaml
diff --git a/docs/reqstream/self-test/validate-get-version.yaml b/docs/reqstream/spdx-tool/self-test/validate-get-version.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-get-version.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-get-version.yaml
diff --git a/docs/reqstream/self-test/validate-hash.yaml b/docs/reqstream/spdx-tool/self-test/validate-hash.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-hash.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-hash.yaml
diff --git a/docs/reqstream/self-test/validate-ntia.yaml b/docs/reqstream/spdx-tool/self-test/validate-ntia.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-ntia.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-ntia.yaml
diff --git a/docs/reqstream/self-test/validate-query.yaml b/docs/reqstream/spdx-tool/self-test/validate-query.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-query.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-query.yaml
diff --git a/docs/reqstream/self-test/validate-rename-id.yaml b/docs/reqstream/spdx-tool/self-test/validate-rename-id.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-rename-id.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-rename-id.yaml
diff --git a/docs/reqstream/self-test/validate-run-nuget-workflow.yaml b/docs/reqstream/spdx-tool/self-test/validate-run-nuget-workflow.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-run-nuget-workflow.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-run-nuget-workflow.yaml
diff --git a/docs/reqstream/self-test/validate-to-markdown.yaml b/docs/reqstream/spdx-tool/self-test/validate-to-markdown.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-to-markdown.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-to-markdown.yaml
diff --git a/docs/reqstream/self-test/validate-update-package.yaml b/docs/reqstream/spdx-tool/self-test/validate-update-package.yaml
similarity index 100%
rename from docs/reqstream/self-test/validate-update-package.yaml
rename to docs/reqstream/spdx-tool/self-test/validate-update-package.yaml
diff --git a/docs/reqstream/self-test/validate.yaml b/docs/reqstream/spdx-tool/self-test/validate.yaml
similarity index 77%
rename from docs/reqstream/self-test/validate.yaml
rename to docs/reqstream/spdx-tool/self-test/validate.yaml
index 06dd46a..45fce53 100644
--- a/docs/reqstream/self-test/validate.yaml
+++ b/docs/reqstream/spdx-tool/self-test/validate.yaml
@@ -15,4 +15,7 @@ sections:
           in sequence, collecting pass/fail results, and reporting a summary. This
           ensures complete coverage of all commands during self-validation.
         tests:
-          - SelfTest_ValidateFlag_Succeeds
+          - SelfTest_Validate_Succeeds
+          - SelfTest_ValidateWithDepth_Succeeds
+          - SelfTest_ValidateWithTrxResult_GeneratesTrxFile
+          - SelfTest_ValidateWithJUnitResult_GeneratesJUnitFile
diff --git a/docs/reqstream/spdxtool-system.yaml b/docs/reqstream/spdx-tool/spdx-tool.yaml
similarity index 54%
rename from docs/reqstream/spdxtool-system.yaml
rename to docs/reqstream/spdx-tool/spdx-tool.yaml
index 883c4a1..f56cf2f 100644
--- a/docs/reqstream/spdxtool-system.yaml
+++ b/docs/reqstream/spdx-tool/spdx-tool.yaml
@@ -61,3 +61,53 @@ sections:
             tests:
               - Log_ShortFlag_WritesOutputToFile
               - Log_LongFlag_WritesOutputToFile
+
+          - id: SpdxTool-Cmd-Validate
+            title: The tool shall perform self-validation when invoked with the --validate flag.
+            tags:
+              - cli
+            justification: |
+              Self-validation ensures that the tool functions correctly after installation
+              or deployment. This is critical for CI/CD pipelines and quality assurance.
+            children:
+              - SpdxTool-SelfTest-Validate
+            tests:
+              - SelfTest_ValidateFlag_Succeeds
+
+          - id: SpdxTool-Cmd-Depth
+            title: The tool shall support depth control for self-validation output.
+            tags:
+              - cli
+            justification: |
+              Users may want to see detailed hierarchical results during self-validation
+              to understand which specific tests passed or failed at different depths.
+            children:
+              - SpdxTool-SelfTest-Depth
+            tests:
+              - SelfTest_ValidateFlagWithDepth_ShowsDepth
+
+          - id: SpdxTool-Cmd-ResultsTrx
+            title: The tool shall write self-validation results as TRX when the --result flag uses a .trx extension.
+            tags:
+              - cli
+            justification: |
+              CI/CD systems and test reporting tools often require test results in
+              standardized formats like TRX. This enables integration with existing
+              test infrastructure.
+            children:
+              - SpdxTool-SelfTest-ResultsTrx
+            tests:
+              - SelfTest_ValidateFlagWithResults_GeneratesTrxFile
+
+          - id: SpdxTool-Cmd-ResultsJUnit
+            title: The tool shall write self-validation results as JUnit XML when the --result flag uses .xml extension.
+            tags:
+              - cli
+            justification: |
+              Many CI/CD systems and test reporting tools support JUnit XML format.
+              Auto-detecting the format from the file extension allows users to generate
+              JUnit output without requiring a separate flag.
+            children:
+              - SpdxTool-SelfTest-ResultsJUnit
+            tests:
+              - SelfTest_ValidateFlagWithResults_GeneratesJUnitFile
diff --git a/docs/reqstream/utility.yaml b/docs/reqstream/spdx-tool/utility/utility.yaml
similarity index 100%
rename from docs/reqstream/utility.yaml
rename to docs/reqstream/spdx-tool/utility/utility.yaml
diff --git a/docs/guide/definition.yaml b/docs/user_guide/definition.yaml
similarity index 82%
rename from docs/guide/definition.yaml
rename to docs/user_guide/definition.yaml
index a4a7deb..301daf6 100644
--- a/docs/guide/definition.yaml
+++ b/docs/user_guide/definition.yaml
@@ -3,13 +3,13 @@
 
 # Resource paths for finding files and templates
 resource-path:
-  - docs/guide
+  - docs/user_guide
   - docs/template
 
 # Input files in order (relative to resource-path)
 input-files:
-  - docs/guide/title.txt
-  - docs/guide/guide.md
+  - docs/user_guide/title.txt
+  - docs/user_guide/introduction.md
 
 # Template configuration
 template: template.html
diff --git a/docs/guide/guide.md b/docs/user_guide/introduction.md
similarity index 100%
rename from docs/guide/guide.md
rename to docs/user_guide/introduction.md
diff --git a/docs/guide/title.txt b/docs/user_guide/title.txt
similarity index 100%
rename from docs/guide/title.txt
rename to docs/user_guide/title.txt
diff --git a/lint.bat b/lint.bat
index c7440d4..433421b 100644
--- a/lint.bat
+++ b/lint.bat
@@ -2,7 +2,7 @@
 setlocal
 
 REM Comprehensive Linting Script
-REM 
+REM
 REM PURPOSE:
 REM - Run ALL lint checks when executed (no options or modes)
 REM - Output lint failures directly for agent parsing
@@ -11,30 +11,55 @@ REM - Agents execute this script to identify files needing fixes
 
 set "LINT_ERROR=0"
 
-REM Install npm dependencies
-call npm install --silent
+REM === PYTHON SECTION ===
+
+REM Create python venv if necessary
+if not exist ".venv\Scripts\activate.bat" python -m venv .venv
+if errorlevel 1 goto skip_python
 
-REM Create Python virtual environment (for yamllint) if missing
-if not exist ".venv\Scripts\activate.bat" (
-    python -m venv .venv
-)
+REM Activate python venv
 call .venv\Scripts\activate.bat
+if errorlevel 1 goto skip_python
+
+REM Install python tools
 pip install -r pip-requirements.txt --quiet --disable-pip-version-check
+if errorlevel 1 goto skip_python
+
+REM Run yamllint
+yamllint .
+if errorlevel 1 set "LINT_ERROR=1"
+goto npm_section
+
+:skip_python
+set "LINT_ERROR=1"
+
+REM === NPM SECTION ===
 
-REM Run spell check
+:npm_section
+
+REM Install npm dependencies
+call npm install --silent
+if errorlevel 1 goto skip_npm
+
+REM Run cspell
 call npx cspell --no-progress --no-color --quiet "**/*.{md,yaml,yml,json,cs,cpp,hpp,h,txt}"
 if errorlevel 1 set "LINT_ERROR=1"
 
-REM Run markdownlint check
+REM Run markdownlint-cli2
 call npx markdownlint-cli2 "**/*.md"
 if errorlevel 1 set "LINT_ERROR=1"
+goto dotnet_section
 
-REM Run yamllint check
-yamllint .
-if errorlevel 1 set "LINT_ERROR=1"
+:skip_npm
+set "LINT_ERROR=1"
+
+REM === DOTNET SECTION ===
+
+:dotnet_section
 
-REM Run .NET formatting check (verifies no changes are needed)
+REM Run dotnet format
 dotnet format --verify-no-changes
 if errorlevel 1 set "LINT_ERROR=1"
 
+REM Report result
 exit /b %LINT_ERROR%
diff --git a/lint.sh b/lint.sh
index c567e09..13ac584 100755
--- a/lint.sh
+++ b/lint.sh
@@ -1,7 +1,7 @@
 #!/bin/bash
 
 # Comprehensive Linting Script
-# 
+#
 # PURPOSE:
 # - Run ALL lint checks when executed (no options or modes)
 # - Output lint failures directly for agent parsing
@@ -10,26 +10,47 @@
 
 lint_error=0
 
-# Install npm dependencies
-npm install --silent
+# === PYTHON SECTION ===
 
-# Create Python virtual environment (for yamllint)
+# Create python venv if necessary
 if [ ! -d ".venv" ]; then
-  python -m venv .venv
+    python -m venv .venv || { lint_error=1; skip_python=1; }
+fi
+
+# Activate python venv
+if [ "$skip_python" != "1" ]; then
+    source .venv/bin/activate || { lint_error=1; skip_python=1; }
+fi
+
+# Install python tools
+if [ "$skip_python" != "1" ]; then
+    pip install -r pip-requirements.txt --quiet --disable-pip-version-check || { lint_error=1; skip_python=1; }
+fi
+
+# Run yamllint
+if [ "$skip_python" != "1" ]; then
+    yamllint . || lint_error=1
 fi
-source .venv/bin/activate
-pip install -r pip-requirements.txt --quiet --disable-pip-version-check
 
-# Run spell check
-npx cspell --no-progress --no-color --quiet "**/*.{md,yaml,yml,json,cs,cpp,hpp,h,txt}" || lint_error=1
+# === NPM SECTION ===
+
+# Install npm dependencies
+npm install --silent || { lint_error=1; skip_npm=1; }
+
+# Run cspell
+if [ "$skip_npm" != "1" ]; then
+    npx cspell --no-progress --no-color --quiet "**/*.{md,yaml,yml,json,cs,cpp,hpp,h,txt}" || lint_error=1
+fi
 
-# Run markdownlint check
-npx markdownlint-cli2 "**/*.md" || lint_error=1
+# Run markdownlint-cli2
+if [ "$skip_npm" != "1" ]; then
+    npx markdownlint-cli2 "**/*.md" || lint_error=1
+fi
 
-# Run yamllint check
-yamllint . || lint_error=1
+# === DOTNET SECTION ===
 
-# Run .NET formatting check (verifies no changes are needed)
+# Run dotnet format
 dotnet format --verify-no-changes || lint_error=1
 
+# Report result
 exit $lint_error
diff --git a/requirements.yaml b/requirements.yaml
index 1237829..c3f48d8 100644
--- a/requirements.yaml
+++ b/requirements.yaml
@@ -29,42 +29,43 @@
 #
 ---
 includes:
-  - docs/reqstream/spdxtool-system.yaml
-  - docs/reqstream/self-test/self-test.yaml
-  - docs/reqstream/self-test/validate.yaml
-  - docs/reqstream/self-test/validate-basic.yaml
-  - docs/reqstream/self-test/validate-add-package.yaml
-  - docs/reqstream/self-test/validate-add-relationship.yaml
-  - docs/reqstream/self-test/validate-copy-package.yaml
-  - docs/reqstream/self-test/validate-diagram.yaml
-  - docs/reqstream/self-test/validate-find-package.yaml
-  - docs/reqstream/self-test/validate-get-version.yaml
-  - docs/reqstream/self-test/validate-hash.yaml
-  - docs/reqstream/self-test/validate-ntia.yaml
-  - docs/reqstream/self-test/validate-query.yaml
-  - docs/reqstream/self-test/validate-rename-id.yaml
-  - docs/reqstream/self-test/validate-run-nuget-workflow.yaml
-  - docs/reqstream/self-test/validate-to-markdown.yaml
-  - docs/reqstream/self-test/validate-update-package.yaml
-  - docs/reqstream/commands/add-package.yaml
-  - docs/reqstream/commands/add-relationship.yaml
-  - docs/reqstream/commands/copy-package.yaml
-  - docs/reqstream/commands/diagram.yaml
-  - docs/reqstream/commands/find-package.yaml
-  - docs/reqstream/commands/get-version.yaml
-  - docs/reqstream/commands/hash.yaml
-  - docs/reqstream/commands/help.yaml
-  - docs/reqstream/commands/print.yaml
-  - docs/reqstream/commands/query.yaml
-  - docs/reqstream/commands/rename-id.yaml
-  - docs/reqstream/commands/run-workflow.yaml
-  - docs/reqstream/commands/set-variable.yaml
-  - docs/reqstream/commands/to-markdown.yaml
-  - docs/reqstream/commands/update-package.yaml
-  - docs/reqstream/commands/validate.yaml
-  - docs/reqstream/utility.yaml
-  - docs/reqstream/platform-requirements.yaml
-  - docs/reqstream/spdxtool-targets-system.yaml
+  - docs/reqstream/spdx-tool/spdx-tool.yaml
+  - docs/reqstream/spdx-tool/self-test/self-test.yaml
+  - docs/reqstream/spdx-tool/self-test/validate.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-basic.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-add-package.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-add-relationship.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-copy-package.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-diagram.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-find-package.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-get-version.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-hash.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-ntia.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-query.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-rename-id.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-run-nuget-workflow.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-to-markdown.yaml
+  - docs/reqstream/spdx-tool/self-test/validate-update-package.yaml
+  - docs/reqstream/spdx-tool/commands/commands.yaml
+  - docs/reqstream/spdx-tool/commands/add-package.yaml
+  - docs/reqstream/spdx-tool/commands/add-relationship.yaml
+  - docs/reqstream/spdx-tool/commands/copy-package.yaml
+  - docs/reqstream/spdx-tool/commands/diagram.yaml
+  - docs/reqstream/spdx-tool/commands/find-package.yaml
+  - docs/reqstream/spdx-tool/commands/get-version.yaml
+  - docs/reqstream/spdx-tool/commands/hash.yaml
+  - docs/reqstream/spdx-tool/commands/help.yaml
+  - docs/reqstream/spdx-tool/commands/print.yaml
+  - docs/reqstream/spdx-tool/commands/query.yaml
+  - docs/reqstream/spdx-tool/commands/rename-id.yaml
+  - docs/reqstream/spdx-tool/commands/run-workflow.yaml
+  - docs/reqstream/spdx-tool/commands/set-variable.yaml
+  - docs/reqstream/spdx-tool/commands/to-markdown.yaml
+  - docs/reqstream/spdx-tool/commands/update-package.yaml
+  - docs/reqstream/spdx-tool/commands/validate.yaml
+  - docs/reqstream/spdx-tool/utility/utility.yaml
+  - docs/reqstream/spdx-tool/platform-requirements.yaml
+  - docs/reqstream/spdx-tool-targets/spdx-tool-targets.yaml
   - docs/reqstream/ots/mstest.yaml
   - docs/reqstream/ots/reqstream.yaml
   - docs/reqstream/ots/buildmark.yaml
diff --git a/test/DemaConsulting.SpdxTool.Tests/Commands/CommandTests.cs b/test/DemaConsulting.SpdxTool.Tests/Commands/CommandTests.cs
index 618d1be..0b98040 100644
--- a/test/DemaConsulting.SpdxTool.Tests/Commands/CommandTests.cs
+++ b/test/DemaConsulting.SpdxTool.Tests/Commands/CommandTests.cs
@@ -81,10 +81,10 @@ public void Command_Expand_NestedVariable_ReturnsFullyExpanded()
     }
 
     /// <summary>
-    ///     Test that Command.GetMapString with missing entry throws exception
+    ///     Test that Command.GetMapString with missing entry returns null
     /// </summary>
     [TestMethod]
-    public void Command_GetMapString_MissingEntry_ThrowsException()
+    public void Command_GetMapString_MissingEntry_ReturnsNull()
     {
         // Test getting a missing parameter
         var map = new YamlMappingNode();