# Future UAT Scenarios Scenarios tested and deferred, with actual results from 2026-02-05 testing. --- ## Scenario: Multi-Pack Conflict Resolution **Status:** TESTED - Current behavior documented **Priority:** Medium **Trigger:** When enterprises need to combine policies from multiple sources ### User Story > As a compliance officer, when Pack A (Security Team) says TLS 1.2 and Pack B (Vendor Compliance) says TLS 1.3, I need to see both conflicting policies and understand how to resolve them. ### Test Results (2026-02-05) **Script:** `uat/scripts/test-multi-pack-conflict.sh` **Findings:** - Both packs import successfully - **Second import OVERWRITES the first** (same subject key in PackSourceStore) - Both assertions exist in storage (content-addressed = different hashes for different values) - But policy_source only shows the LAST imported pack **Example Output:** ```json { "sources": [ { "path": "code://standard/tls/min_version", "policy_source": { "pack_name": "Compliance-Team", // <- Only last pack shows "pack_version": "0.1.0" }, "value": 1.2 }, { "path": "code://standard/tls/min_version", "policy_source": { "pack_name": "Compliance-Team", // <- Same, even though first was Security-Team "pack_version": "0.1.0" }, "value": 1.3 } ] } ``` **Current Behavior:** Last imported pack wins for policy_source attribution. ### Future Enhancement (if needed) - [ ] Store multiple pack sources per subject (append, not overwrite) - [ ] Show all contributing packs in conflict report - [ ] Add `pack_priority` field to control precedence - [ ] Support pack composition (extend other packs) --- ## Scenario: Pack Version Update **Status:** PASS - Working correctly **Priority:** Medium ### User Story > As a security lead, when I update our standards pack from v1.0 to v2.0, I need the attribution to update so teams know they're running against current policy. ### Test Results (2026-02-05) **Script:** `uat/scripts/test-pack-version-update.sh` **Results:** 6/6 tests passed | Test | Status | |------|--------| | Create v1.0 pack | PASS | | Import v1.0 | PASS | | v1.0 attribution shown | PASS | | Create v2.0 pack | PASS | | Import v2.0 | PASS | | v2.0 attribution shown | PASS | | v1.0 no longer appears | PASS | **Conclusion:** Pack version updates work correctly. Importing v2.0 supersedes v1.0. --- ## Scenario: Predicate Aliases **Status:** NOT IMPLEMENTED - Deferred **Priority:** Low **Trigger:** Based on enterprise feedback showing predicate naming conflicts ### User Story > As a security architect, when my policy uses `required=true` but the extractor emits `enabled=true`, I need them to match semantically. ### Implementation Plan (when needed) 1. Add `predicate_aliases` field to Trust Pack schema 2. Update ConceptIndex to check aliases during lookup 3. Consider default aliases: `enabled` ↔ `required` ↔ `mandatory` ↔ `enforced` --- ## Scenario: Pack Signing Key Rotation **Status:** NOT IMPLEMENTED - Deferred **Priority:** Low **Trigger:** Security key management requirements ### User Story > As a security admin, when our signing key is rotated, I need to re-sign all packs without losing policy content. ### Implementation Plan (when needed) 1. Add `aphoria policy resign` command 2. Preserve pack content hash 3. Update signature with new key 4. Audit log for key rotation --- ## Test Scripts | Script | Scenario | Status | |--------|----------|--------| | `test-enterprise-workflow.sh` | Basic Trust Pack workflow | PASS (12/12) | | `test-multi-pack-conflict.sh` | Multiple packs, same concept | PASS (7/7) - documents current behavior | | `test-pack-version-update.sh` | Pack version supersession | PASS (6/6) | --- ## Feedback Collection Enterprise feedback on these scenarios should be tracked in: - GitHub Issues with label `enterprise-feedback` - Internal `#aphoria-enterprise` channel --- *Last updated: 2026-02-05*