apexSolarKiss control-surface diagrams

Two structural snapshots of the execution-protocol repo at a point in time. Diagrams are illustrative and age; the repo prose is source of truth, and each figure below links the document that owns what it draws.

illustrative >> not source of truth
tree // TREE_D01

architecture tree

The repo's own layer map and the operator-side ecology around it — upstream methodology, the shared protocol owner canonical, the human and agent surfaces, and the downstream absorption boundary.

open source architecture
tree // TREE_D08

intent-INbox routed-instance lifecycle

The routed-instance state machine as a standalone figure: four events, state-keyed resolution, closure coupling, the two evidence axes, the structural inbox-state carrier, and artifact-instance identity.

open source lifecycle owner _STATE owner
repository github.com/apexSolarKiss/control-surface control-surface The execution-protocol repo itself — what it carries and how a new ASK project is instantiated from it. method-ASK The upstream methodology layer this repo operationalizes per session. design-system-ASK The visual authority. This surface vendors its carriers; it defines none of them. A-S-K.studio The ASK meta-brand front door.

Drag to pan, scroll to zoom, and use the HUD controls in the bottom-left; ⤢ fits the figure. Theme follows the operating system, and the diagrams default to dark as repository documentation.

Each figure carries its source data file beside it. Source advances when the authored architecture changes; the renderer advances only when its realization does. See README.md for the update cadence and the full contents list.

These pages consume the vendored token mirror in _dsa-tokens/ and the surface carriers in _dsa-surface/, both pinned byte-identical to design-system-ASK and never hand-edited here.