{"id":"pattern.separate-access-experience-execution","slug":"separate-access-experience-execution","type":"pattern","version":"0.1.0","maturity":"hypothesis","status":"published","title":"Access, experience, and execution are distinct concerns","summary":"Design who may enter, what they perceive, and what effects they may cause as separate policy surfaces joined by explicit contracts.","audiences":["security","product","architect"],"relationships":{"supports":["pattern.evidenced-trust","pattern.intent-survives-execution"],"contradicts":[],"depends_on":["pattern.boundaries-increase-agency"]},"disclosure":"green","approved_by":["chrisleeddotcom"],"license":"CC-BY-4.0","created":"2026-08-21","updated":"2026-08-21","canonical_url":"https://intentarium.com/patterns/separate-access-experience-execution/","source":{"repository":"https://github.com/Intentarium/canon","commit":"a8b303818e72c20505bd9ef56f5fb2d0448aa6f3","path":"patterns/separate-access-experience-execution.md"},"body_markdown":"## Context\n\nA product or workflow combines authentication, interface behavior, and consequential operations in one application or agent experience.\n\n## Problem\n\nWhen these concerns collapse, a good experience can imply excessive authority, a security control can degrade unrelated usability, and an authenticated session can be mistaken for permission to execute every visible action.\n\n## Forces\n\n- Unified interfaces are easier to build initially.\n- People infer capability from what the interface presents.\n- Execution risk varies by action and context.\n- Access policy and product design evolve at different speeds.\n\n## Pattern\n\nModel three layers explicitly: access establishes who or what may enter; experience determines the information and choices presented; execution authorizes and records effects. Connect them through scoped claims and action-specific policy rather than shared session assumptions.\n\n## Apply it\n\nInventory each visible action and its actual effect. Determine whether visibility, request, approval, and execution require different rights. Recheck execution authority at the point of effect using current evidence, and produce a result the experience can explain.\n\n## Failure modes\n\n- Hidden buttons are treated as authorization controls.\n- Authentication is treated as universal execution permission.\n- Execution errors expose internal policy details.\n- Experience and control teams optimize independently without an end-to-end contract.\n\n## Evidence needed\n\nSecurity and usability outcomes demonstrating fewer authority leaks and clearer recovery without unnecessary prompts, denials, or duplicated policy logic."}