apexSolarKiss urban-observatory diagrams

Three figures for the civic implementation observatory — two structural, one operational state. Diagrams are orientation aids 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_ARCHITECTURE

architecture tree

Where the repo's surfaces live — the execution files, the docs/ prose that carries the method, the Class B artifact template, the Class A diagrams, external context, and what is authorized but not yet built. A structural atlas, not a state claim.

open source architecture
tree // TREE_ONTOLOGY

ontology

Axis A — the kinds of concepts the method reasons over: the interpretive chain, candidate signal subtypes, supporting primitives, the assessment vocabulary, and output classifications. Structural classification, asserting no maturity state.

open source object model
interactive spine // IA_STATE_SPINE

information architecture — state

The operational whole read as state: which surfaces and seams are earned, structural, partial, held, proposed or external, and where the open questions sit. Hover a node to preview it, click to lock it, and the inspector holds its state and evidence. Color encodes state only.

open data
repository github.com/apexSolarKiss/urban-observatory urban-observatory What the observatory is for, what it reads, and the scope and method documents that carry it. method-ASK The upstream methodology layer this project's working practice draws on. 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 data file beside it — .source.js for the two static trees, .data.js for the state spine. Source advances when the authored content changes; the renderer advances only when its realization does. See README.md for why this repo builds three diagrams and not four, and for 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.