Date: 2026-02-28 Status: Architectural aspect note Priority: Immediate architecture clarification

Related:

• settings_and_control_surfaces_spec.md
• ../2026-02-28_ux_contract_register.md

Policy authority: This file is the canonical policy authority for the Control aspect. Supporting control docs refine contracts/implementation detail and must defer policy authority to this file. Policy in this file should be distilled from canonical specs and accepted research conclusions.

---

This note defines the Control aspect as the architectural owner of app-owned tool and control panes.

It exists to keep one boundary explicit:

• tool surfaces are application control surfaces,
• not graph semantic owners,
• and not workbench-layout owners beyond the fact that they are hosted in panes.

---

• settings surfaces
• history manager surfaces
• diagnostics tool surfaces
• app-owned control pages
• apply / revert / return-path semantics inside those surfaces

---

Liquid, Gas, and Solid may expose tunable controls in these surfaces, but the subsystem only hosts and edits those settings. The preset semantics still belong to the owning runtime policies.

---

• Workbench -> Control Surfaces: pane hosting and lifecycle
• Command -> Control Surfaces: open / close / navigate actions
• Focus -> Control Surfaces: return path and active tool ownership

---

If a behavior answers "how does the app expose settings or tool controls?" it belongs to the Control aspect.