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

The diagram conforms to 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.

• 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

README.md                                       this file
index.html                                      ASK-branded live navigation surface for the six figures below
_dsa-tokens/                                    pinned design-system-ASK Tier 1 + Tier 2 mirror (no CDN)
_dsa-surface/                                   pinned surface-shell (css + navigation runtime) + surface-panel + surface-action + surface-text-link + surface-document carriers and the mode-aware ASK wordmark pair — used by index.html and the AP-ASK landing page at the deployed root (../index.html), and, for the shell, panel, action and wordmark, by the /read/ pages; index.html also loads surface-treatments, for its grouping plane, and surface-text-link, for that plane's prose links; all five static pages load surface-panel then surface-treatments, the disclosure grammar of the responsive chrome's About / Legend / Detail triggers; the IA state spine loads the same pair for the About / Legend / Inspector triggers its engine adds on a narrow or short canvas

# 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 v0.2 (@ a7c5530) + shared static exporter (@ b3e34d95, #169); 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)

# Shared scaffold files — one copy each; diagrams-fit.js, diagrams.css and export-png.js are byte-identical across the three Class A static patterns and reused by the bespoke bounded-generativity figure; diagrams-text-layout.js serves the H and V patterns only
diagrams-fit.js                                 DS-owned shared fit contract (#77-#80, #169; v3: balanced vertical placement, drawn-mark clearance for FLOW, compact clearance; current through #175); vendored + loaded BEFORE each engine; engines and the bespoke figure fail closed without it or with a copy older than v3
diagrams-chrome.js                              DS-owned responsive chrome (current through #175); loaded after the chrome markup and BEFORE diagrams-fit.js on all five static pages
diagrams-pointer.js                             DS-owned shared pointer controller (v2: pan, pinch, tap, wheel; the panels over the canvas stay native; current through #175); loaded BEFORE diagrams-fit.js, and so before each engine and the bespoke figure
diagrams-text-layout.js                         DS-owned shared text-layout contract (#135); vendored + loaded BEFORE the H and V engines, which fail closed without it; the FLOW page and the bespoke figure do not load it (the owner's helper excludes diagram-static-FLOW)
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 @ b3e34d95 (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; page chrome through the semantic diagram roles #145; every caption line kept, caption + legend sharing the page width, and a landscape figure fitted below the panel band where a drawn mark would come within a panel's gutter #169 (current) — consumed by the bespoke bounded-generativity figure)

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)
  diagrams-pointer.js                            DS-owned shared pointer controller (pan, pinch, tap, wheel; current through #175); loaded BEFORE the engine, which fails closed without it (re-vendored by reference)

Phones and touch. All five static pages carry the design-system responsive chrome (diagrams-chrome.js): on a narrow or crowded canvas the caption, legend and — on the VPA page — the explanatory panel close behind About / Legend / Detail triggers beside or above the HUD, the header keeps identity, title and its cue, and the subtitle and stamp move into About, so the drawing takes the canvas instead of the panels. Every engine and the bespoke figure hand their gestures to the shared pointer controller: one finger pans from anywhere on the drawing, nodes included, two pinch the drawing rather than the page, and the panels keep their own taps and scrolling.

This folder hosts three Class A static diagram patterns inherited by reference from 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 #175). (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 the bespoke bounded-generativity figure — 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 and FLOW engines, the shared fit helper (diagrams-fit.js), the shared pointer controller (diagrams-pointer.js, static and interactive-spine copies), the responsive chrome (diagrams-chrome.js) and the shared diagrams.css are current through design-system #175. The engines drive the pointer controller (v2) and require the fit helper at its v3 contract — balanced vertical placement, compact clearance and, in FLOW, drawn-mark clearance — and the shared diagrams.css carries the stage gesture rule the controller needs; the shared text-layout helper (diagrams-text-layout.js) is current through #135, the static exporter (b3e34d95) through #169, and the interactive spine's engine and stylesheet through #173. 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, diagrams-chrome.js, diagrams-pointer.js, diagrams-fit.js and export-png.js.)

The architecture diagrams depict different axes of the architecture and must not be collapsed into one picture (basis: docs/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). 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 (v0.2): legislative = the source-of-intent role, drawn as a role box outside the frame (constitutive), and the brief inside it (delegated) — one role value, ranked by placement; executive = the realization chamber (variance as negative cutouts); judicial = selection + closure; the aperture and every connecting beam stay neutral; 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 @ a7c5530) and the DS shared static exporter (export-png.js @ b3e34d95, #169) — 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. At source-v2 // render-v2 the figure conforms to Three Functions v0.2: the source-of-intent role takes a legislative role box on the main axis and the neutral source beam leaves it, as in method-ASK's figure. 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 — the semantic-role mapping as in method's figure at source-v5, conformed to Three Functions v0.2, not as pinned at 2e5d8c4. 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 (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). It is the first consumer of the diagram-static-FLOW scaffold AP graduated upstream and re-vendored here (current through design-system #175). 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. 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 diagram gallery (index.html, below) is this folder's orientation entrance. The figures depict different objects and are not one picture: no single diagram is the master picture. The gallery groups them by the object each one represents — 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). Axis C, shared versus variable, is historical / superseded and has no live diagram (basis: docs/layer-disambiguation-note-v1.md). Prose homes for this taxonomy: docs/architecture.md §Source-of-Truth Routing and this file; the gallery follows that prose, it does not establish it. Because the grouping depends on the set of figures and the representational taxonomy rather than on any one figure's content, the gallery is refreshed 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.

Retired: the architectural representation atlas. A bespoke orientation figure, asset-pipeline-ASK_architectural-representation-atlas.html with its figure.js, gave this orientation from #381 (2026-07-15) until ASK's decision of 2026-10-17 to retire it, as a seventh figure drawn over the other six. It predated the gallery; once the gallery carried the same taxonomy, the atlas was removed from the tree, and Git history keeps it. The site redirects its page, its builder and its generated source view to /diagrams/.

index.html is an ASK-branded live navigation surface for this folder's six figures. It is asset-pipeline-ASK-owned composition over pinned, byte-identical design-system-ASK carriers vendored under _dsa-surface/ — the surface-shell pattern with its optional navigation runtime, the surface-panel, surface-action and surface-text-link visual rules, the separate-surface axes of surface-treatments for its one grouping plane, and the mode-aware logo-ASK wordmark pair. It adopts the shell's responsive navigation: the identity mark discloses one panel whose current path is derived from the visible breadcrumb, so the public ancestry is authored exactly once. 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.

In the built site. Opened from a clone, the page's source, data, document and README links open the raw files they name. The site build (tools/read/) serves a composed copy, in which those links open the reading pages and source views generated from the same files, and a documents route and a documents action in the navigation panel are added. Its project cards open each project's public site, and its mark links the landing page. Those pages, under /read/, load surface-shell.css, surface-shell.js, surface-panel.css, surface-action.css, the wordmark pair and the _dsa-tokens/ foundation stylesheet, colors_and_type.css, with its fonts, from this folder, and take their own document-register carriers from tools/read/carriers/, never this folder's surface-document.css, surface-text-link.css or surface-treatments.css. tools/read/declared.json records the sha256 of each stylesheet and script they load, and the build stops when one of them moves without it.

Grouped by object, not by form. The figures are ordered by the object each one represents. The three views of the governed visual-payload information architecture share one grouping plane — ontology and visual payload architecture as its principal views, inheritance as the orthogonal view that supports them — and the bounded-generativity system model, the architecture tree and the architecture-state spine follow as cards of their own. The plane is a separate surface, not a content panel and not a link: panel material, free corners and no elevation, composed from the surface-panel and surface-treatments axes, with a label on the foundation's caption role and the same inert cards inside it as outside. A short note in the plane records that the runtime axis, Axis D, has no dedicated diagram, and links the architecture and the layer note. No single diagram is the master picture.

Both panel forms are in use and divide as the modules intend: the six 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 state spine carries 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 six 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 mark slot's current settled assignment. The page's link-preview card carries the AP-ASK wordmark under a separate assignment, which does not replace it; changing either is a separate identity decision.

vercel.json at the deployed docs/ root states the deployment contract: it runs the site build (tools/read/), which serves docs/ as authored, except the two composed front doors, this folder's index.html and the landing page, plus reading pages under /read/; / serves the AP-ASK landing page (../index.html) as the static index, composed by the build only to render its build-only links, and that page links this folder's index.html, the technical documentation under /read/ and the repository as its technical destinations; its redirects send /diagrams to /diagrams/ and /read to /read/, and the retired atlas's page, builder and generated source view to /diagrams/; four security headers apply across the surface, the vendored font and wordmark paths revalidate rather than caching immutably, and the landing page's figure files under ../images/ are served noindex, so search results do not use the figure as the page's image; the page's declared og:image is the AP-ASK card.

AP adopts the design-system-ASK theme-by-embedding-surface convention (canonical in 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/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.
• Shared pointer, settled Fit, compact chrome. The shell loads the DS-owned shared pointer controller (diagrams-pointer.js) and the shared fit helper (../diagrams-fit.js) before the engine, which fails closed without either; pan, pinch, tap and wheel run through the pointer controller, and the engine fits once its chrome settles. On a narrow or short canvas the engine folds the inspector, legend and caption behind About, Legend and Inspector triggers beside or above the HUD, styled by the shared disclosure grammar the shell loads from ../_dsa-surface/ (surface-panel.css, then surface-treatments.css).
• 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.

• 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:

  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.

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/ (TREE_D01) and apexSolarKiss/method-ASK/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-v17 (2026-09-03). 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.

• TREE_D01 (control-surface architecture tree) — lives in apexSolarKiss/control-surface/docs/diagrams/
• TREE_D02 (method-ASK topology) — lives in apexSolarKiss/method-ASK/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 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)