09D_Policy_Scope_UI_Review_Prompt.md
Memory Rebuild Docs/Memory Rebuild Review Packs/Archived Memory Rebuild Zips/DOC80_Memory_Control_Plane_PreSpec_Review_Pack_v1_0_2026-05-25/09D_Policy_Scope_UI_Review_Prompt.md
# Round D Prompt — Policy, Scope, and UI Coordination Review ## Assignment Review whether policy and scope coordinate extraction, injection, learning, and UI without becoming duplicate owner systems or unnecessary user-visible clutter. ## Required attachments - `02_Concept_Model_and_Canonical_Knowledge_Resolution.md` - `03_DAMS_V5_Spec_Outline.md` - `05_Worked_Examples_and_Fixtures.md` ## Core question Is policy correctly modeled as a separate plane, and is scope correctly modeled as an internal coordination layer rather than a user-facing mess? ## Issues to attack 1. Is Policy Plane separate from MemoryContextPlan, ExtractionContextPlan, and UserContextSurfacePlan? 2. Does `MemoryPolicyDecision` need a dimensional meet rather than a ranked union? 3. Are policy obligations sufficiently concrete for extraction, injection, export, carryover, delegation, learning, and UI visibility? 4. Does Scope coordinate identity, equivalence, containment, membranes, and injection relation without owning policy or delivery? 5. Is Scope over-structured? 6. Does the model preserve Project optionality? 7. Are Projects, Libraries, Topics, Episodes, IssueFrames, and Scope cleanly separated? 8. Does the UI default to minimal visible concepts? 9. What should the user see by default? 10. What should only appear in Inspector / Why included? 11. Does the model prevent cross-scope leakage and ethical-wall mistakes? ## Required output ```text 1. Bottom-line disposition 2. Policy plane critique 3. Scope coordination critique 4. UI visibility critique 5. Cross-scope / privacy / ethical-wall critique 6. Project optionality critique 7. Required schema or UI-contract changes 8. Required fixtures ```