# Diagrams // illustrative

These diagrams are illustrative. They are not source truth.

Repo prose remains authoritative. If a diagram and the repo prose disagree, trust the prose and refresh the diagram; do not modify the repo prose to match the diagram.

Each diagram is a structural snapshot of the repo at a point in time. Diagrams age. Repo prose ages too, but more slowly. The diagram should track the repo, not the other way around.

## Authority cadence

- repo prose: source truth — [`docs/architecture.md`](../architecture.md) is the current architecture front door
- diagram: illustrative snapshot, refreshed when a plateau milestone marker lands per the cadence in [`AGENTS.md`](../../AGENTS.md) §Refresh Cadences / Architecture Tree Diagram
- repo [`README.md`](../../README.md): canonical front-door entry point

## Inheritance

The diagram conforms to [`apexSolarKiss/design-system-ASK`](https://github.com/apexSolarKiss/design-system-ASK) Tier 1 + Tier 2 by reference at generation time. The compiled `diagrams.css` in this folder is render support, not identity source truth. `design-system-ASK` remains the visual authority; this folder does not own visual identity.

## Update cadence

- plateau milestone marker landing on main: refresh the source data file and re-render
- per-PR repo edits: do not refresh
- per-article work: do not refresh
- ecology-level structural shift: open a new `source-vN`

## Contents

```text
README.md                                       this file
index.html                                      ASK-branded live navigation surface for the seven figures below
_dsa-tokens/                                    pinned design-system-ASK Tier 1 + Tier 2 mirror (no CDN)
_dsa-surface/                                   pinned surface-shell + surface-panel + surface-action carriers and the mode-aware ASK wordmark pair — used ONLY by index.html

# Horizontal — Class A diagram-static-H (top-aligned cascade)
asset-pipeline-ASK_architecture-tree.html       renders TREE_D04 (repo architecture / artifact structure)
asset-pipeline-ASK_architecture-tree.source.js  TREE_D04 data
asset-pipeline-ASK_ontology-tree.html           renders TREE_ONTOLOGY (Axis A — information kinds)
asset-pipeline-ASK_ontology-tree.source.js      TREE_ONTOLOGY data
diagrams-static-H-engine.js                     horizontal (top-aligned cascade) layout engine

# Vertical — Class A diagram-static-V (centered spine)
asset-pipeline-ASK_inheritance-spine.html       renders TREE_INHERITANCE (Axis B — inheritance ladder)
asset-pipeline-ASK_inheritance-spine.source.js  TREE_INHERITANCE data
diagrams-static-V-engine.js                     vertical (centered spine) layout engine

# System model — bounded-generativity figure (bespoke figure.js; not engine-rendered) — illustrative doctrine diagram
asset-pipeline-ASK_bounded-generativity.html                renders AP's bounded-generativity topology (the commercial image-production instance)
asset-pipeline-ASK_bounded-generativity.figure.js           bespoke AP figure — derived from method-ASK's bounded-generativity figure @ 2e5d8c4; consumes DS Three Functions (@ 8fb82b7) + shared static exporter (@ 2104021d, #80); AP surface-adapted geometry under ASK authorization (shared invariant = topology + semantics, not pixel-identical geometry)
asset-pipeline-ASK_bounded-generativity-dark.png            sole committed doctrine mirror (dark full-page) — embedded in docs/creative-discretion-doctrine-v1.md; the light-page + chrome-free diagram variants are on-demand PNG-page / PNG-diagram exports, not committed

# Convergence flow — Class A diagram-static-FLOW — illustrative VPA diagram
asset-pipeline-ASK_visual-payload-architecture.html              full-chrome diagram HTML (header/legend/HUD/caption + #flowPanel; FLOW_MODE='interactive'; PNG page + PNG diagram exports)
asset-pipeline-ASK_visual-payload-architecture.source.js         FLOW_DIAGRAM data (carrier/field/converge/spine/evalEdges/futureCarrier; AP-owned)
asset-pipeline-ASK_visual-payload-architecture.png               committed clean render via the PNG diagram export (chrome-free, dark gradient field) — embedded in docs/visual-payload-architecture-v2.md
diagrams-static-FLOW-engine.js                  convergence-flow layout engine (two modes; pan/zoom)

# Orientation / deconfliction — architectural-representation atlas (bespoke figure.js; not engine-rendered) — orientation across the repo's representations
asset-pipeline-ASK_architectural-representation-atlas.html          renders the atlas — orientation across the repo's existing representations (per view: object · question · live surface · authority boundary)
asset-pipeline-ASK_architectural-representation-atlas.figure.js     bespoke self-contained renderer; reuses the shared diagrams.css / export-png.js only; neutral palette (no Three Functions)

# Shared scaffold files — byte-identical across the three Class A static patterns and reused by both bespoke figures (bounded-generativity + architectural-representation-atlas); one copy
diagrams-fit.js                                 DS-owned shared fit contract (#77-#80); vendored + loaded BEFORE each engine; engines fail closed without it
diagrams.css                                    compiled Tier 1 + Tier 2 style (incl. .edge-arrowhead, FLOW classes, --diagram-* dark-ink lines)
export-png.js                                   dual PNG export — "PNG page" (chromed 3840×2880) + "PNG diagram" (canvas-only, no chrome, natural aspect, on the gradient field); re-vendored from design-system-ASK @ 2104021d (dual export #50/#51; font-embed raster fix #60; native file:// export via the _dsa-tokens/fonts-embedded.js carrier #62; PNG-page legend nowrap-fidelity + empty-column collapse #63; Three Functions semantic-legend fidelity #69; larger / lower-anchored landscape page composition #70; direct-<defs> carry #72; overlap-gated portrait page composition #80 (current) — consumed by both bespoke figures (bounded-generativity + architectural-representation-atlas))

interactive/                                     AP-owned interactive surface (different artifact class)
  asset-pipeline-ASK_ia-state-spine.html         the IA state spine
  asset-pipeline-ASK_ia-state-spine.data.js      node→state data (AP authorship)
  diagrams-interactive-spine-engine.js           DS-owned Class A interactive engine (vanilla JS + SVG; re-vendored by reference)
  diagrams-interactive-spine.css                 DS-owned interactive styling (re-vendored by reference)
```

This folder hosts three **Class A** static diagram patterns inherited by reference from [`design-system-ASK`](https://github.com/apexSolarKiss/design-system-ASK): `diagram-static-H` (horizontal cascade), `diagram-static-V` (vertical centered spine; delivered at merge `1c565e2`), and `diagram-static-FLOW` (convergence flow with two render modes; graduated upstream from AP, re-vendored here, current through design-system #78). (The `diagram-static-SEQ` pattern and its engine were retired here when the discretion-chain diagram they rendered was replaced by the bounded-generativity figure — see below.) `diagrams.css` and `export-png.js` are **byte-identical** across all three patterns — and reused by both bespoke figures (bounded-generativity + architectural-representation-atlas) — so this folder keeps **one shared copy** rather than vendoring each — a deliberate, documented choice. (`diagrams.css` re-vendored at **`b5d158e`** — DS #53, render-neutral: the diagram text roles `--diagram-ink/-muted/-faint` now **alias** the foundation `--fg-1/-2/-3` ramp instead of hardcoding `#6A637F`/`#827399`/faint, so a foundation foreground change propagates here automatically; structural line tokens stay diagram-local. At that #53 re-vendor the layout engines stayed at `98d6074` and `export-png.js` at `957a025` (later re-vendored to `9b05d9a` for the DS #60 font-embed fix — see below; both since superseded, current engine state is stated at the end of this section). Pairs with the `_dsa-tokens/colors_and_type.css` #52 re-sync at `b5d158e`; light + dark sanity-rendered, render-vN stamps held.) (FLOW first vendored at `c87aa0d`, then re-synced to `98d6074` for two DS chrome corrections: light-mode strokes are **white** — the `c87aa0d` dark-ink change was reverted, so light mode matches the other patterns again — and the FLOW engine's junction dots were removed. `export-png.js` keeps the centered/negative-origin + landscape corrections from `c87aa0d`. Light-mode strokes white across all four patterns then vendored (H / V / SEQ / FLOW); dark mode and diagram text unchanged.) The shared `export-png.js` (static) and the interactive-spine `export-png.js` were **re-vendored from design-system-ASK @ `957a025`** (DS PR #50/#51) to add a second export: every diagram HUD now offers **PNG page** (the existing chromed 3840×2880 export, byte-stable) and **PNG diagram** (canvas-only, no chrome, natural aspect, on the gradient field). The diagram export is **additive** — it revises no existing committed raster. This retires the prior chrome-free-shell + headless two-build route for clean PNGs at the scaffold level; AP's own consumer normalization (regenerating the committed embedded PNGs via PNG diagram, collapsing the VPA two-build) is a separate, later AP-scoped pass. Both `export-png.js` copies were subsequently **re-vendored from design-system-ASK @ `9b05d9a`** (DS #60): the raster exporter now inlines the page's own `@font-face` woff2 as base64 inside the exported SVG, so the SVG-as-image raster resolves the real diagram fonts instead of a wider system fallback — fixing right-edge text clipping on machines where the diagram fonts are not system-installed. The committed `asset-pipeline-ASK_discretion-chain.png` (previously clipped) and `asset-pipeline-ASK_visual-payload-architecture.png` (previously rendered with fallback glyphs) rasters were regenerated with the fixed exporter — embedded JetBrains Mono + Inter, unchanged dimensions (2614×1826 / 3376×2966), dark PNG diagram export. Then **re-vendored @ `44c6074`** (DS #62, native `file://` export): a checked-in no-fetch font carrier (`_dsa-tokens/fonts-embedded.js`, loaded before `export-png.js` in every diagram HTML) lets a double-clicked `file://` page export correct PNGs offline; the exporter prefers the carrier, falls back to the http woff2 fetch, and fails closed if neither fully embeds. The successful http export output is unchanged, so the committed rasters stay correct — **no re-render**. Then **re-vendored @ `559d492`** (DS #63, PNG-*page* legend fidelity — resolves AP's own routed request): the page exporter now honors a legend row's live `white-space` — reading the computed style off the `.sub` and skipping the fixed `SUB_BUDGET` re-wrap for genuinely non-wrapping rows (`nowrap`/`pre`) — and collapses empty swatch/label columns when the whole legend lacks them. So the discretion-chain's simplified one-line ROLES row (PR #372: a single `.sub`, `white-space:nowrap`, no swatch/label) now exports on **one line, flush at the panel padding**, instead of wrapping at `SUB_BUDGET` behind a ~108px phantom swatch gap. This changes only the **PNG page** export chrome; the committed chrome-free **PNG diagram** rasters carry no legend and are **unaffected — no re-render** (the committed `asset-pipeline-ASK_discretion-chain.png` / `…_visual-payload-architecture.png` are PNG-*diagram* exports). Swatch/label legends (architecture-tree, ontology-tree, inheritance-spine, VPA) keep their columns and stay byte-identical. The interactive-spine exporter is a separate file and was **not** touched by #63. Then **re-vendored @ `a91d9548`** (DS #72 `5674b46`, direct-`<defs>` carry — AP PR #378 `fc59a8e`): the exporter now clones the live SVG's direct `<defs>` into the raster, so the bounded-generativity figure's `userSpaceOnUse` negative-cutout mask exports correctly (variance cut through, not filled); it also carries the #70 page composition whole. The interactive-spine exporter is again untouched. Then **re-vendored @ `2104021d`** (DS #80 `2cd4610`, overlap-gated portrait page composition — AP PR #390, taken together with the #77–#79 fit contract: the `diagrams-fit.js` helper + the fit-consuming engines). The #80 change is **portrait page-composition only** and monotonic (a portrait can only grow or reproduce the prior placement exactly). For AP's diagrams the prior placement is reproduced, so the emitted **PNG raster is byte-identical base↔head across page + diagram, light + dark — measured on all seven surfaces** (headless export A/B, decoded and hashed); both committed rasters are **unchanged**, render stamps held. (The #77–#79 fit contract *does* change the **live** default-viewport fit on every surface — every surface now reserves chrome — but that live-interaction change does not enter the exported render, which is what `render-vN` versions; the measured export byte-identity is the proof.) The three layout engines (`diagrams-static-H-engine.js` / `-V-` / `-FLOW-`) are scaffold-owned and not edited locally; they are re-vendored by reference, never forked. **Current engine state:** the H / V / FLOW engines are current through design-system #78; the shared fit helper (`diagrams-fit.js`) is current through #79; the static exporter is current through #80 (`2104021d`). Exact owner blobs and propagation state live in the operator ledger. (The bounded-generativity figure is a bespoke `figure.js` instance, not an engine-rendered pattern; it reuses the shared `diagrams.css` / `export-png.js` only.)

The **architecture diagrams** depict **different axes** of the architecture and must not be collapsed into one picture (basis: [`docs/layer-disambiguation-note-v1.md`](../layer-disambiguation-note-v1.md)):

- **architecture tree** (horizontal) — repo architecture / artifact structure / plateau state.
- **ontology tree** (horizontal) — Axis A: the kinds of information the definition layer structures (a branching classification → horizontal cascade).
- **inheritance spine** (vertical) — Axis B: where information lives and how it inherits / overrides / combines (a linear chain → centered spine).

The two IA diagrams (ontology, inheritance) are **structural** maps — they assert **no** maturity state (no earned/held/legacy); their legends are repurposed as reading notes, and architectural nuance rides in the node notes. Maturity-state semantics belong to the separate interactive surface below.

The **bounded-generativity figure** is a **different class** — an illustrative **doctrine** diagram of AP's **system-model topology**, not an architecture-axis diagram. `asset-pipeline-ASK` is the commercial image-production instance of **bounded generativity**, and this figure draws that topology: a source of intent outside the frame supplies purpose and the governing standard; the creative brief inside the frame carries creative intent and **grants the aperture** of permitted creative variance; a bounded realization chamber fills the image-production span with candidate variance; creative discretion is authorized judgment **exercised within** the aperture where present; curatorial selection **ratifies** one candidate and **closes** the aperture; artifact governance **binds** the accepted result downstream; the governed asset plus governance record sits outside the frame (basis: [`docs/creative-discretion-doctrine-v1.md`](../creative-discretion-doctrine-v1.md)). The model is a **bracketed topology, not a linear chain**: the five load-bearing distinctions survive as the **non-identity line** — creative intent ≠ creative discretion ≠ variance ≠ selection ≠ governance — and can be read in a **function-order projection** (`creative intent → creative discretion → variance → selection → governance`), a reading order rather than the system's shape. Three Functions treatment: legislative = the brief, executive = the realization chamber (variance as negative cutouts), judicial = selection + closure; artifact governance is downstream, not a fourth function. This figure is a **bespoke `figure.js` instance** (`asset-pipeline-ASK_bounded-generativity.figure.js`) **derived from method-ASK's bounded-generativity figure @ `2e5d8c4`**, consuming design-system-ASK **Three Functions** (`_dsa-tokens/three-functions.css` @ `8fb82b7`) and the DS **shared static exporter** (`export-png.js` @ `2104021d`, #80) — it is **not** rendered by a layout engine. It carries **AP-specific geometry adaptations for this surface**. Per an **ASK apex ruling (2026-07-13)** the shared invariant across the AP and method figures is the **topology, the semantic-role mapping, the Three Functions treatment, and the governance boundary — not pixel-identical geometry**; method-ASK need not adopt AP's geometry, and future cross-repo conformance compares topology + semantics, not coordinates or rasters. The AP adaptations: a three-line brief box (carries creative intent · grants the aperture); the chamber / downstream / right frame shifted `+14` so the brief→aperture gap matches the 36px frame inset; the `permitted creative variance` label raised to clear the aperture arrow; and the dotted authorized-judgment rail **continued from the chamber to the selection ring** (no arrowhead, neutral) — creative discretion is exercised in realization **and at selection**, recovering the semantic the retired SEQ 2→4 edge used to carry. `method-ASK@2e5d8c4` remains the upstream conceptual and design provenance; topology, semantic-role mapping, Three Functions treatment, and export contract are otherwise as in method. Because it depicts doctrine rather than repo/architecture state, it refreshes when the **doctrine topology** changes, not on the milestone-/structure-coupled cadence of the architecture diagrams. **One** committed raster is kept alongside the HTML for direct markdown/GitHub embedding — a doctrine diagram gets exactly one supplemental raster: the **dark full-page** render (`asset-pipeline-ASK_bounded-generativity-dark.png`), embedded directly in [`docs/creative-discretion-doctrine-v1.md`](../creative-discretion-doctrine-v1.md) (repository documentation embeds dark per the theme-by-embedding convention below). The light-page and chrome-free diagram variants remain available from the HTML exporter's **PNG page** / **PNG diagram** buttons but are **not committed**. The HTML + `figure.js` remain **canonical**; the PNGs are supplemental presentation rasters, not source truth. To refresh them, open the HTML directly from the clone via `file://` or serve the folder over http, then use the **PNG page** / **PNG diagram** buttons (or the `?export=png` / `?export=png-diagram` routes). (Both `file://` and http export correct fonts — see *How to use*.)

The **visual payload architecture** (`diagram-static-FLOW`) is a third class again — an illustrative **architecture companion** diagram of the *convergence flow* a commercial image's visual decisions move through: a reference carrier qualifying a normative-source field, the field converging into a resolved slot specification, realization (candidate image ‖ set relations) reconverging into conformance, then selection → governance → governed asset, with a return loop where a governed output can later re-enter as a reference carrier (basis: [`docs/visual-payload-architecture-v2.md`](../visual-payload-architecture-v2.md)). It is the first consumer of the `diagram-static-FLOW` scaffold AP graduated upstream and re-vendored here (current through design-system #78). **One full-chrome diagram HTML** (`…_visual-payload-architecture.html`): the repo-native explanatory artifact — header / legend / HUD / caption plus a hover/click side panel carrying each node's definition / example / "not-this" note, and both `PNG page` / `PNG diagram` export controls. (The earlier chrome-free static export shell + separate `.interactive.html` build is retired now that the shared exporter emits a clean `PNG diagram` directly.) A committed PNG (`asset-pipeline-ASK_visual-payload-architecture.png`, the chrome-free **dark** render via the `PNG diagram` export) is kept alongside for direct markdown/GitHub embedding (same deliberate exception as the bounded-generativity figure); it is embedded in [`docs/visual-payload-architecture-v2.md`](../visual-payload-architecture-v2.md). Both `-light` and `-dark` render off the same source model; the repo embeds the **dark** render per the theme-by-embedding-surface convention (below). The HTML + source data remain **canonical**; the PNG is a supplemental raster. Because it is coupled to the VPA topology (`docs/visual-payload-architecture-v2.md`) rather than to plateau / repo-architecture state, it refreshes when that topology changes, not on the milestone cadence. To refresh the PNG, open the HTML directly from the clone via `file://` or serve the folder over http, then use the **PNG diagram** button (or the `?export=png-diagram` route). (Both `file://` and http export correct fonts — see *How to use*.)

The **architectural representation atlas** (`asset-pipeline-ASK_architectural-representation-atlas.html`) is an **orientation / deconfliction** class — an orientation layer over the repo's existing representations, not another architecture model. It sits one level up from the diagrams above: for each existing representation it names the **object represented**, the **architectural question it answers**, the **live diagram / surface** that carries it, and **where that view's authority ends**. It exists because this folder now carries several visual surfaces over different represented objects, and the prose above already warns they **must not be collapsed into one picture** (basis: [`docs/layer-disambiguation-note-v1.md`](../layer-disambiguation-note-v1.md) — depict one axis at a time). The atlas organizes those representations into four objects: the **governed visual-payload information architecture** asset-pipeline-ASK develops (principal payload views: ontology / Axis A · visual payload architecture; supporting orthogonal view: inheritance / Axis B; runtime / Axis D lives in prose + lifecycle artifacts — no dedicated axis diagram at present), the **generative-governance system model** it instantiates (the bounded-generativity topology), the **project / repository information architecture** that carries the work (the architecture tree), and the current **architecture state** (the interactive IA state spine) — with Axis C / shared-versus-variable noted as historical / superseded (no live diagram). It is **flat and non-causal** (containment, labels, and `view of` relations — no flow arrows), **illustrative and prose-subordinate**, and carries the governing statement *no single diagram is the master picture*. It is a **bespoke `figure.js` instance** reusing the shared `diagrams.css` / `export-png.js` on a neutral palette (no Three Functions — it is classificatory, not causal), **not** a new engine or scaffold class. It does **not** create a second system model or collapse the architectural axes: **bounded generativity remains the sole live system-model topology**, and the ontology / inheritance axes stay distinct. Because it depends on the *set* of representations and the representational taxonomy rather than on any single diagram's content, it refreshes when a represented diagram or surface is added, retired, renamed, or relocated; when the represented object or authority boundary of a view changes; or when the representational taxonomy changes — not on the plateau-milestone cadence. Prose homes for the taxonomy: [`docs/architecture.md`](../architecture.md) §Source-of-Truth Routing and this file; the diagram follows that prose, it does not establish it.

## Live navigation surface

`index.html` is an **ASK-branded live navigation surface** for this folder's seven figures. It is asset-pipeline-ASK-owned composition over **pinned, byte-identical** `design-system-ASK` carriers vendored under `_dsa-surface/` — the `surface-shell` pattern, the `surface-panel` and `surface-action` visual rules, and the mode-aware `logo-ASK` wordmark pair. It **hot-links nothing**, and it **reuses the existing `_dsa-tokens/` mirror** this folder already carries for the diagrams rather than adding a second token or font copy. The vendored carriers are never hand-edited here; re-sync them from the owner when the upstream contract changes.

**Order is semantic, not geometric.** The architectural representation atlas comes **first** because it is the orientation layer over everything below it — per view it names the object represented, the question it answers, and where that view's authority ends, and *no single diagram is the master picture*. It takes the same inert card as every other figure: one grid, one panel class, no hero variant.

Both panel forms are in use and divide as the modules intend: the seven diagram cards are **inert panels carrying their own action links**, while the repository / asset-pipeline-ASK / method-ASK / design-system-ASK / A-S-K.studio routes are **full-panel links**. Panel support-copy foreground and action-row composition remain asset-pipeline-ASK-local. Each card links the prose document that owns what its figure draws, where a current public owner exists; the atlas and the state spine carry no such action rather than borrowing one. **The two figures that keep a committed raster expose it directly** — the `PNG` action opens the committed file their governing prose embeds, and no raster is generated or regenerated by this surface.

**Tier boundary.** The page carries an **ASK-assigned Tier 3** value in the shell's mark slot. That is a property of the navigation surface: it does **not** propagate into the seven Tier 1 + Tier 2 figures it indexes, does **not** make asset-pipeline-ASK ASK-the-entity, and does **not** come from `surface-shell`, which ships a mark slot and no mark. ASK branding is the current settled assignment; any later independent asset-pipeline-ASK brand is a separate identity migration.

`vercel.json` at the deployed `docs/` root states the deployment contract: `/` redirects to `/diagrams/`, four security headers apply across the surface, and the vendored font and wordmark paths revalidate rather than caching immutably.

## Theme by embedding surface (adopted convention)

AP adopts the design-system-ASK **theme-by-embedding-surface** convention (canonical in [`design-system-ASK`](https://github.com/apexSolarKiss/design-system-ASK), pinned `7921b79`). Every FLOW/diagram package generates and retains **both** theme exports (`-light` and `-dark`); the convention selects which is *embedded*, not which exists:

- **Repository documentation + operator-system diagrams → dark** (the AP repo default; the committed `…_visual-payload-architecture.png` is the dark render).
- **Published long-form editorial → light.**
- A stated local exception may override the default for a specific figure.

Worked example: the Visual Payload Architecture FLOW diagram — the AP repo embeds the **dark** render; the *Image Is Not One Thing* editorial essay uses the **light** render. Same diagram, same source model, surface-appropriate theme; both exports retained.

## Interactive surface — IA state spine

`interactive/asset-pipeline-ASK_ia-state-spine.html` is the **state** view the static structural diagrams deliberately omit: architectural surfaces, seams, and open carrier-shape questions colored by their **current state**, with the four workflow modes as orthogonal axes that selection isolates. Hover previews, click commits a selection (dimming all but the intersecting axes), and the inspector shows the state's evidence, qualifiers, mode coverage, and the authoritative repo pointer.

- **Different artifact class.** It is an AP-owned interactive surface, not a Class A static scaffold — it renders through the DS-owned Class A *interactive* engine (`diagrams-interactive-spine-engine.js`) and styling (`diagrams-interactive-spine.css`), re-vendored by reference (AP owns the node→state data + HTML chrome). It does **not** use `diagrams.css` / the static engines / `export-png.js`.
- **Color via ASK Spectral State, by reference.** Node color comes from the design-system-ASK `--state-*` role tokens (`_dsa-tokens/spectral-state.css`, opt-in module pinned at `1231d03`; `_dsa-tokens/MANIFEST.md` owns the canonical per-file pin + sha). AP consumes by reference and does not mint or edit the palette.
- **Color encodes state only.** Evidence depth, risk, mode coverage, and repo pointers are inspector metadata — never hue. One state per node.
- **Illustrative, not source truth.** The node→state data (`…ia-state-spine.data.js`) is AP authorship over the architecture's current state; `docs/architecture.md` remains authoritative.

## How to use

- Open `asset-pipeline-ASK_architecture-tree.html` directly in a browser, or via GitHub Pages if configured.
- Drag to pan; scroll to zoom; HUD controls in the bottom-left; `⤢` to fit.
- Theme follows the OS preference (`prefers-color-scheme`); the CSS supports explicit `data-theme="light"` or `data-theme="dark"` on `<html>` if a specific theme is needed.
- The HUD carries two PNG exports in the resolved theme: **PNG page** (chromed 3840×2880, the existing page export) and **PNG diagram** (canvas-only — no header / HUD / legend / caption / ticks — on the gradient field, at the diagram's natural aspect; filename `<slug>-diagram-<theme>.png`). Routes `?export=png` and `?export=png-diagram`.
- **PNG export works from both `file://` and http.** The exporter embeds the diagram fonts from a checked-in no-fetch carrier (`_dsa-tokens/fonts-embedded.js`, loaded before `export-png.js` in every diagram HTML), so a **double-clicked `file://` page exports correct PNGs offline — no server**. Over http it can also fetch the local woff2. It **fails closed** — blocks the export with a warning — if neither path fully embeds, so it can never silently emit a fallback-font (clipped) PNG. If you ever see that warning, keep `_dsa-tokens/fonts-embedded.js` next to the diagram, or serve over http:

  ```sh
  cd docs/diagrams && python3 -m http.server 8432
  ```

  then open `http://127.0.0.1:8432/<diagram>.html` (e.g. `asset-pipeline-ASK_bounded-generativity.html`) and export.

## Lineage

This diagram is the first repo-native asset-pipeline-ASK architecture-tree absorption using the Class A diagram-bundle pattern proven across [`apexSolarKiss/control-surface/docs/diagrams/`](https://github.com/apexSolarKiss/control-surface/tree/main/docs/diagrams) (TREE_D01) and [`apexSolarKiss/method-ASK/docs/diagrams/`](https://github.com/apexSolarKiss/method-ASK/tree/main/docs/diagrams) (TREE_D02). It supersedes the prior self-contained HTML architecture-tree artifact (Claude-Design-generated, ~1.7 MB single file) at the same path.

This bundle was first absorbed here at `source-v2 // render-v9`, aligning with the other repo-native bundles. The architecture-tree current tuple is `source-v8 // render-v16` (2026-08-15). Source advances when the authored tree data changes; render advances only when the renderer realization changes.

The operator-side ecology-ASK diagram package and historical render iterations remain in `asset-pipeline-ASK-EXTERNAL/scratch/` and are not repo truth.

## What this folder does not carry

- `TREE_D01` (control-surface architecture tree) — lives in [`apexSolarKiss/control-surface/docs/diagrams/`](https://github.com/apexSolarKiss/control-surface/tree/main/docs/diagrams)
- `TREE_D02` (method-ASK topology) — lives in [`apexSolarKiss/method-ASK/docs/diagrams/`](https://github.com/apexSolarKiss/method-ASK/tree/main/docs/diagrams)
- `TREE_D03` (ecology-ASK overall) — operator-side only; not authorized for any repo absorption
- Operator-side context payload (private; conform by reference, do not absorb)
- [`design-system-ASK`](https://github.com/apexSolarKiss/design-system-ASK) Tier 3 instance identity (logo, wordmark, instance chrome) — excluded by Tier model
- Runtime dynamic import from `design-system-ASK` CSS (no; conform at generation time)
- Fast-aging state (PR numbers, commit hashes, current grounding-note version stamps, branch names, recent activity chronology)