• index.html — ASK-branded live navigation surface for this folder's diagram set. It consumes the local Tier 1 + Tier 2 mirror and the vendored _dsa-surface/ carriers; its Tier 3 does not propagate into the diagrams. Opened from a clone, its source, doctrine, example, README and method 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, a documents route and a documents action in the navigation panel are added, and the breadcrumb's method-ASK links the site's home page.
• _dsa-surface/ — pinned, byte-identical design-system-ASK carriers, used by two different consumers in this folder.
  • Index navigation. surface-shell.css, surface-panel.css, surface-action.css, surface-text-link.css and the mode-aware ASK wordmark pair, loaded by index.html.
    • surface-shell.js — the shell's responsive-navigation runtime, adopted by index.html. The identity mark is the disclosure: the runtime upgrades the authored anchor in place, so with JavaScript unavailable the mark stays an ordinary home link and no panel, trigger or dead control appears. No diagram page loads the shell, its runtime, surface-action.css or the wordmark pair.
  • Diagram disclosure. surface-panel.css, then surface-treatments.css, loaded by every diagram page that adopts the responsive chrome (Responsive chrome, below). surface-treatments.css supplies the controlled disclosure trigger their About and Legend triggers take.
  • Reading pages. The site build's pages, the home page at the site root and the reading pages under /read/ (tools/read/), also load surface-shell.css, surface-shell.js, surface-panel.css, surface-action.css, the wordmark pair and the _dsa-tokens/ mirror. They take their own document-register carriers from tools/read/carriers/, and never this folder's 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.

• README.md — this file.
• method-ASK_topology.html — renders TREE_D02.
  • method-ASK_topology.source.js — TREE_D02 data (source-v9).
• method-ASK_intent-artifact-ontology.html — renders TREE_D10.
  • method-ASK_intent-artifact-ontology.source.js — TREE_D10 data (source-v2): source of intent as a locatable ROLE; context / intent / provenance families; the claim-level vs artifact-level discipline.
• method-ASK_activation-lifecycle-comparison.html — renders TREE_D05.
  • method-ASK_activation-lifecycle-comparison.source.js — TREE_D05 data (source-v1): five artifact forms and their distinct activation + lineage models; prevents every artifact form from inheriting the fresh routed-handoff filename lifecycle merely because it is read, fed, or co-located. Terminal -TBI remains an orthogonal overlay.
• method-ASK_relay-feeding-ingestion.html — renders TREE_D06.
  • method-ASK_relay-feeding-ingestion.source.js — TREE_D06 data (source-v1): direct relay vs payload-bearing feed; the envelope supplies force, the payload supplies content; ingestion as a resulting state; disposition separate.
• system-ASK-topology-public.html — renders TREE_D03_PUBLIC, the governed PUBLIC PROJECTION of the operator-side system-ASK topology. It is generated, not authored here, and it is not method doctrine: the four intent-architecture figures and the two SMGI figures state what this repo argues, while this page reports a structure the operator canonical owns.
  • system-ASK-topology-public.source.js — the projected TREE_D03_PUBLIC data: eight public top-level branches derived from the canonical's twelve.
  • system-ASK-topology-public.generation.json — the generation receipt. It records the exporter, the operator canonical and its source-v/render-v tuple, the input manifest, the HTML shell, and the produced outputs, each by SHA-256, plus the include/exclude classification that makes the 12 -> 8 reduction checkable rather than asserted.
• method-ASK_relay-graph-ptx-projection.html — renders TREE_D07.
  • method-ASK_relay-graph-ptx-projection.source.js — TREE_D07 data (source-v1): the native partially-ordered multi-thread topology vs the linear PTX projection; three labels on one relayed passage.

• Bounded generativity
  • method-ASK_bounded-generativity.html — renders the bounded-generativity system-model figure.
  • method-ASK_bounded-generativity.figure.js — figure builder (source-v5).
  • method-ASK_bounded-generativity-dark.png — sole committed doctrine mirror (dark full-page); the light-page + chrome-free diagram variants are on-demand exporter outputs, not committed.
• system-ASK // one apex · distributed owners · governed return (D11 — worked example)
  • method-ASK_system-ASK-hero.html — renders the system-ASK causal-orientation figure.
  • method-ASK_system-ASK-hero.figure.js — figure builder (source-v2).
  • method-ASK_system-ASK-hero-dark.png — committed worked-example mirror (dark full-page).
  • Projects the accepted claim set in examples/system-ASK.md, which is source of truth for the figure; the two are one delivery unit, while neither is authority for the distributed system they depict. It answers one question — how a single normative apex governs a recursive ecology of distributed owners and plural reasoning while evidence returns upward and authority does not — and it is not derived from the operator topology map or from that map's generated public projection, which sits in this folder and shares the subject.
• Seed-Mediated Generated Interface // doctrine
  • method-ASK_seed-mediated-generated-interface.html — renders the SMGI DOCTRINE figure.
  • method-ASK_seed-mediated-generated-interface.figure.js — figure builder (source-v1).
  • method-ASK_seed-mediated-generated-interface-dark.png — committed doctrine mirror (dark full-page).
• Seed-Mediated Generated Interface // ontology
  • method-ASK_seed-mediated-generated-interface-ontology.html — renders the SMGI ONTOLOGY figure.
  • method-ASK_seed-mediated-generated-interface-ontology.figure.js — figure builder (source-v2; dual-profile — ?layout=screen default / ?layout=page).
  • method-ASK_seed-mediated-generated-interface-ontology-dark.png — committed doctrine mirror (dark full-page).

Every diagram page here adopts the design-system-ASK responsive diagram chrome: the five tree pages, the four figures, and the generated system-ASK public projection. Each wraps its caption and, where it has one, its legend in one .diagram-info block with About and Legend triggers, and each figure builder follows the tree engine's Fit rules. The public projection's HTML is generated from its pinned operator shell (system-ASK-topology-public.generation.json), so it carries the chrome because that shell does.

• Wide. The two panels sit together at the top of the canvas.
• Compact. When the canvas is narrower than 640px, or the open panels would take more than a third of its height, more width than it gives, or leave the drawing less room above the HUD than the fit needs to keep it clear, the panels close behind their triggers in one control area with the HUD. The header keeps its identity, its title and an illustrative cue; the subtitle and stamp move into About. At most one panel is open, and it scrolls within the space above the control area.
• Fit. At Fit the drawing is centered vertically between the chrome above and below it. The view stays at Fit until the reader zooms or pans, and a resize or a chrome change refits only a view still at Fit. An open panel moves the drawing only where the drawing keeps its size; otherwise it overlays the drawing until it closes. ⤢ closes a panel that would cover the drawing.
• Export. PNG page reads the subtitle and stamp wherever they sit, so the page export does not depend on the live layout.
• Touch. Every engine page and figure hands its gestures to the shared pointer controller (diagrams-pointer.js): one finger pans the drawing from anywhere on it, two pinch the drawing rather than the page, and the panels keep their own taps and scrolling.

When bounded generativity and the SMGI doctrine figure first adopted it, their live composition changed, so their render stamps advanced while their source did not, to source-v5 // render-v6 and source-v1 // render-v3. They advanced again when their Fit began centering the drawing and capping its compact clearance, which moved their at-rest view on narrow or crowded windows: bounded generativity is source-v5 // render-v7, and the SMGI doctrine figure is source-v1 // render-v4. The generated public projection took the chrome and the controller from its operator shell, at the operator canonical's render-v28. The tree pages share the engine's Fit behavior, so a reader's zoom survives a resize, and the four figures follow the same Fit rules.

• diagrams-chrome.js — DS-owned responsive chrome controller, loaded by every page in Responsive chrome, BEFORE diagrams-fit.js. A page without the .diagram-info block is untouched by it.
• diagrams-pointer.js — DS-owned shared pointer controller (v2); loads after diagrams-chrome.js and BEFORE diagrams-fit.js, so before the engine and every figure builder, each of which throws a named error without it. The engine itself does not: a page that does not load it keeps the mouse drag and wheel.
• diagrams-fit.js — DS-owned fit support (v3); loads BEFORE the engine AND before every figure builder — the engine and each builder throw a named error if it is missing or older than v3. Its v3 balance option centers each drawing vertically between the chrome above and below it, and compactClearance caps the clearance while the responsive chrome is compact. Chrome may declare the edge it is anchored to with data-diagram-fit-edge; with nothing declared, the fit reserves exactly the panels it did before.
• diagrams-text-layout.js — the DS-owned shared text-layout contract: it measures and wraps long node labels for the static tree engines. It loads AFTER diagrams-fit.js and IMMEDIATELY BEFORE the engine.
• diagrams-static-H-engine.js — layout + pan/zoom engine.

The helper and the engine are indivisible. The engine throws Diagram text-layout support is missing or incomplete. Load diagrams-text-layout.js before the diagram engine. when the carrier is absent, and it further requires DIAGRAM_TEXT_LAYOUT.TARGETS to name its own pattern. Neither file may be re-vendored, moved or upgraded without the other, and a page may not load one alone — the failure is loud by design rather than a silently unwrapped label.

• _dsa-tokens/ — vendored Tier 1 + Tier 2 token mirror.
• diagrams.css — compiled Tier 1 + Tier 2 style, including the responsive chrome's layout, which applies only to a page that wraps its panels in .diagram-info.
• export-png.js — 3840×2880 PNG export. PNG page keeps the caption, the legend and the drawn marks apart.

They are a pair with different jobs, and neither substitutes for the other:

• doctrine figure (…_seed-mediated-generated-interface) — the instantiation path and the loading-boundary seam. Authored seed >> loading boundary >> grammar grants the aperture >> runtime >> generated interaction >> return, or, at the boundary, fork-at-load. Consumes the Three Functions primitive for one licensed node: the grammar box, where the grammar is operative apparatus in the runtime path.
• ontology figure (…_seed-mediated-generated-interface-ontology) — the category boundaries. Four orthogonal layers (mechanism · application · authored control · conformance) around one membership node, joined by typed relations. Fully neutral — no function colour, because it classifies concepts rather than diagramming the functions; it does not load three-functions.css.

The SMGI doctrine figure is source-v1 // render-v4; the ontology figure is source-v2 // render-v2.

Responsive behavior. 1440×900 is the reference read-all composition (doctrine about 0.75, ontology about 0.67 on the default screen profile). The doctrine figure takes the responsive chrome (Responsive chrome, above): on a narrow or crowded window its panels close behind triggers, and fit-all gives the drawing the canvas as a navigable overview. The ontology now takes the same responsive chrome; on shorter and narrower windows fit-all is still a navigable overview, its macrostructure and membership gate remain identifiable, and zoom/pan exposes the authored detail. Read-all composition at every aspect ratio would require content reduction, which neither figure takes.

Ontology dual-profile (source-v2). The ontology is height-limited at a normal viewport, so a single fixed canvas cannot both stay read-all at 1440×900 and fill the 3840×2880 page. One semantic model is laid out under two coordinate profiles selected by ?layout=: screen (default) is compact-but-recomposed and stays read-all at 1440×900 without zoom; page (?layout=page) is the taller, page-optimized composition that spends the available 3840×2880 page height below the chrome. The committed dark full-page mirror is generated from the page profile (?layout=page&export=png). Text, categories, held status, branch asymmetry, and typed relations are identical across profiles — only coordinates differ (the recomposition itself — Application's two cards, Conformance's deepened gate / outcomes / test-strip — is present in both).