Consumers // design-system-ASK
Known landed consumers of design-system-ASK patterns and tokens — the public downstream repos below, plus design-system-ASK's own first-party same-repo consumers (its three public surfaces, its generated reading pages, and its pattern-preview gallery).
This file records landed consumption only — which repo or first-party surface already consumes which pattern or token module. It is a transparency record, not a customer list, not the full propagation ledger, and not a future-state plan. Queued, in-flight, or planned consumption, private/firewalled consumers, vendored commit pins, re-sync obligations, and pin drift are tracked operator-side, not here, by design — a pin is operational provenance and does not belong in the public registry.
Two lifecycles govern how these patterns are inherited, and they are not interchangeable.
Artifact scaffolds are inherited at generation time. A downstream consumer vendors the complete canonical artifacts for the modules it actually renders, then generates its own output, seals it, stamps it where the pattern requires, and freezes it for audit. That consumer owns its source data, chrome, generation, sealing, and frozen artifact; design-system-ASK owns the engine, CSS, and export script.
Surface patterns frame or run on a live deployed surface. A consumer takes one by same-repo reference or as a pinned local vendored copy, and nothing seals — the page keeps running, and the consumer re-syncs when the owner contract changes. Tier 3, payload, deployment, and local instance adaptations stay with the consumer; design-system-ASK owns the shared pattern contract and its canonical files.
Neither lifecycle uses a CDN or a live hot-link. Ordinary downstream diagram / artifact consumers take the foundations through their local, pinned _dsa-tokens/ mirror; the ASK front door vendors the foundations (tokens, fonts, wordmark) directly rather than via a _dsa-tokens/ mirror (see its row below). Re-sync is the downstream consumer's responsibility when an upstream pattern or token module changes.
on this page
Public consumers
| Consumer | Public status | Consumes | Notes |
|---|---|---|---|
Consumerasset-pipeline-ASK |
Public statusproduction repo + live-surface consumer (live: asset-pipeline.a-s-k.studio) | Consumesdiagram-static-H · diagram-static-V · diagram-static-FLOW · diagram-interactive-spine · Spectral State · Evidence State · Review Semantics · Three Functions · output-artifact · surface-shell (CSS + navigation runtime) · surface-panel.css · surface-action.css (with the attention edge) · surface-text-link.css · surface-document.css · surface-document-overflow.js · surface-treatments.css · static responsive chrome (diagrams-chrome.js) · shared diagram text-layout · shared diagram pointer controller · canonical browser-icon package · logo-ASK wordmark |
NotesArchitecture-tree + ontology-tree (H), inheritance-spine (V), convergence-flow / Visual Payload Architecture (FLOW), interactive IA state spine, and the bounded-generativity system-model figure — its one bespoke figure, on the shared visual contract, which consumes the Three Functions primitive (vendors three-functions.css): legislative / executive / judicial function color at 30%, with candidate variance as negative cutouts through the executive chamber. First diagram-static-FLOW consumer — the pattern graduated upstream from AP's own reference implementation. Among its diagrams, only the interactive spine loads spectral-state.css; the review-artifact renderer below inlines it into each sealed file. Historical: AP was also the first diagram-static-SEQ consumer (SEQ likewise graduated upstream from AP's reference); the diagram-static-SEQ / discretion-chain implementation is now retired on the AP surface — the discretion-chain diagram it rendered was replaced by the bounded-generativity figure. Separately from the diagrams, asset-pipeline-ASK runs an ASK-branded live diagram front door at asset-pipeline.a-s-k.studio/diagrams/ — the index for its six figures and their maintained orientation entrance. One grouping surface holds the three views of its governed visual-payload information architecture — ontology, visual payload architecture and inheritance — and bounded generativity, the architecture tree and the IA state spine follow as cards of their own. The grouping surface is not a link: panel material with no elevation, composed from the axis classes of surface-panel.css and surface-treatments.css, with its label in the caption role and its note's two links on surface-text-link.css. Six inert panels carry their own action links — nineteen card actions in all, three, four, three, four, three and two — while the repository / asset-pipeline-ASK / method-ASK / design-system-ASK / A-S-K.studio routes, and in the built site the documents route, are full-panel links, the project-name cards each opening that project's public site, so both panel forms are in use and divide as the modules intend. Two cards link the repo's existing committed raster mirrors — the bounded-generativity dark page render and the visual-payload chrome-free diagram render — and the front-door unit generated and regenerated no raster; the committed diagram-raster population remains exactly two. It vendors pinned local copies of surface-shell.css, surface-panel.css, surface-action.css, and the mode-aware logo-ASK wordmark pair, also loads the diagram folder's existing pinned copies of surface-treatments.css and surface-text-link.css (the latter also for the README link in its page note), and hot-links nothing. It reuses the repo's existing _dsa-tokens/ token and font mirror rather than adding a second copy of either. asset-pipeline-ASK owns its payload, destinations, deployment, and local adaptations. The front door carries ASK Tier 3, which is a property of that 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 front door's current settled assignment; changing it would be a separate identity decision, and a project mark assigned to another context does not by itself replace it. It carries the canonical browser-icon package — favicon.svg, favicon-32.png, favicon.ico and apple-touch-icon.png — vendored byte-identical at the deployed-origin profile with root-absolute references. Its static tree pages consume the shared diagram text-layout contract, which is indivisible from the static engines: the engine fails closed when the helper is absent. The front door adopts the shell's navigation runtime and shows its full public ancestry, derived from the visible breadcrumb rather than authored twice. The site root serves asset-pipeline-ASK's public introduction, which sets its prose through surface-document.css and its textual links through surface-text-link.css, pinned local copies vendored beside the shell's. It is the entrance to the diagrams, the technical documentation and the repository: three title actions on surface-action.css, the same three in its logo menu, and a closing Explore the architecture section of three full-panel links on surface-panel.css. Its links into the technical documentation are build-only fragments, so opened from a clone it offers the diagrams and the repository only. asset-pipeline-ASK owns that page's composition and payload; the modules supply the document roles, the textual-link presentation and the action and panel presentation. The interactive IA state spine takes its responsive composition from the spine engine: on a compact canvas its inspector, legend and caption close behind triggers in the shared disclosure grammar, so the spine page loads surface-panel.css then surface-treatments.css, pinned local copies vendored beside the shell's, and its bundle carries the shared diagram pointer controller for pan, pinch and wheel. That is the spine's own composition. Each of its five static figure pages adopts the static family's optional responsive chrome (diagrams-chrome.js, vendored with the diagram bundle), which keeps each figure's caption, and its legend where it has one, open together while they fit and, on a narrow or crowded canvas, closes them behind triggers in one control area with the HUD; the triggers take the same disclosure grammar from the same two modules, and the pages hand their gestures to the same pointer controller. The attention edge is adopted by class on the public introduction's linked illustration. The owner governs only the edge; asset-pipeline-ASK keeps the element, its destination and its placement. Historical: the front door's orientation layer was once a seventh figure, the architectural representation atlas, which also adopted the edge, with .surface-attention-edge on its card links and .surface-attention-edge-shape on its linked node boxes; the atlas is now retired on the AP surface, its orientation carried by the front door, and its old page, builder and source-view addresses redirect there. In the built site, /read/ serves reading pages for the README's reader path and concrete example, the Start Here documents under docs/, the documents the diagram front door links and the diagram-folder records, with read-only source views of the five figure sources and the state spine's data file; the rest of docs/ stays held and opens on GitHub. They are generated from the repository's Markdown and source files when the site is built (tools/read/), and none is committed. They load surface-shell (CSS + navigation runtime), surface-panel.css, surface-action.css, the logo-ASK wordmark pair and the _dsa-tokens/ token and font mirror from the diagram folder's existing local copies, and take the document register — surface-text-link.css, surface-document.css, surface-treatments.css and the optional surface-document-overflow.js helper — from their own pinned local copies under tools/read/carriers/, vendored separately from the diagram folder's own copies of surface-text-link.css, surface-document.css and surface-treatments.css, which serve the public introduction, the diagram front door and the state spine page. The register sets the documents' headings, prose, contents entries, code and preformatted text, and each blockquote takes the role its declaration names. In the built site the diagram front door opens the reading pages and source views in place of the raw files and adds a documents route; opened from a clone it still opens the raw files. The reading pages are live pages, rebuilt at each deployment and sealed nowhere, and the review-artifact renderer below keeps its separate per-render, sealed relationship. asset-pipeline-ASK owns the pages' composition, declarations and build; the modules supply presentation. Separately from its live pages, asset-pipeline-ASK renders its review artifacts through a maintained renderer, scripts/render_review_artifact.py, under its usage contract, docs/application/review-artifact-rendering.md. Each render seals one self-contained file on the Class B output-artifact pattern, with the document register, Spectral State, Evidence State and Review Semantics. The renderer reads every owner file it uses from one design-system-ASK commit, which the render records, and inlines them in the owner's sealed order: colors_and_type.css, its font sources rewritten to embed Inter and JetBrains Mono; then surface-panel.css, surface-text-link.css, surface-document.css and surface-treatments.css, then spectral-state.css, evidence-state.css and review-semantics.css, all seven verbatim; then the output-artifact template's overlay, with a local block before its Tier 3 slot. These are per-render inputs, not repository copies: the renderer keeps no copy of them in the repository, and the pinned copies its live pages carry are a separate relationship. Every review mark is the shared bordered label. An annotation range over the whole blocks one review judgment covers is the shared labeled range. A whole list item judged on its own is its own range. The exact words a pending or decided judgment concerns take the shared scope underline. Apart from the local block, which lays out figures and keeps figure references unbroken, geometry and color are the owner's. The renderer checks each sealed file against its inputs, and it provides a separate step that runs the owner's rendered checker on a sealed file, as that checker stands at the same commit. asset-pipeline-ASK owns its sources, its review records, which content carries which mark, and each sealed file. |
Consumerurban-observatory |
Public statuspublic project + live-surface consumer (live: urban-observatory.a-s-k.studio) | Consumesdiagram-static-H · diagram-interactive-spine · Spectral State · Evidence State · Review Semantics · output-artifact v3 · surface-shell (CSS + navigation runtime) · surface-panel.css · surface-action.css · surface-text-link.css · surface-document.css · surface-document-overflow.js · surface-treatments.css · static responsive chrome (diagrams-chrome.js) · shared diagram text-layout · shared diagram pointer controller · canonical browser-icon package · logo-ASK wordmark |
NotesStatic architecture-tree + ontology (both H). The interactive IA-state spine consumes Spectral State directly (loads spectral-state.css; roles earned / structural / partial / proposed / deflated / held / external / neutral). UO's assessment / artifact layer consumes the Evidence State profile by reference; UO keeps its local assessment vocabulary (confirmed / weakened / contradicted / unresolved / not yet testable) while design-system-ASK owns the reusable Evidence State profile vocabulary, value mapping, and presentation contract. Its Class B renderer, tools/artifact-template/, is on the output-artifact v3 contract: the documents it renders inherit Tier 1 + Tier 2 and take their text roles and treatments from the document register, whose four modules — surface-panel.css, surface-text-link.css, surface-document.css and surface-treatments.css — it vendors as build inputs beside its token mirror. Separately from the assessment layer's by-reference alignment, a document that carries a review annotation also takes the opt-in Review Semantics composition: the renderer vendors spectral-state.css, evidence-state.css and review-semantics.css beside the register modules and inlines them, in that order, into such a document only. urban-observatory keeps its own review anatomy and decides which content carries which mark; the composition supplies the presentation. Built three diagrams, not four — no diagram-static-V (no Axis-B inheritance ladder in UO). Separately from the diagrams, urban-observatory runs an ASK-branded live diagram front door at urban-observatory.a-s-k.studio/diagrams/ — the index for the three figures above. It indexes them through three inert panels carrying their own action links, eight card actions in all: three, three, and two, the state spine taking only its own page and its data file because it has no separate governing-prose document to link. The repository / urban-observatory / method-ASK / design-system-ASK / A-S-K.studio routes, and in the built site the documents route, are full-panel links, the project-name cards each opening that project's public site, so both panel forms are in use and divide as the module intends. It vendors pinned local copies of surface-shell.css, surface-panel.css, surface-action.css, surface-text-link.css (for the README link in its page note), and the mode-aware logo-ASK wordmark pair, and hot-links nothing. It reuses the repo's existing _dsa-tokens/ token and font mirror rather than adding a second copy of either, and it does not use the separate tools/artifact-template/ token mirror. urban-observatory owns its payload, destinations, deployment, and local adaptations. The front door carries ASK Tier 3, which is a property of that navigation surface: it does not propagate into the three Tier 1 + Tier 2 diagram artifacts it indexes, does not make urban-observatory ASK-the-entity, and does not come from surface-shell, which ships a mark slot and no mark. ASK branding is the front door's current settled assignment; changing it would be a separate identity decision, and a project mark assigned to another context does not by itself replace it. The folder carries no committed diagram raster. It carries the canonical browser-icon package — favicon.svg, favicon-32.png, favicon.ico and apple-touch-icon.png — vendored byte-identical at the deployed-origin profile with root-absolute references. Its static tree pages consume the shared diagram text-layout contract, which is indivisible from the static engines: the engine fails closed when the helper is absent. The front door adopts the shell's navigation runtime and shows its full public ancestry, derived from the visible breadcrumb rather than authored twice. The renderer's tools/artifact-template/ build inputs, its token mirror included, belong to this consumption; among them is the token mirror's vector wordmark, assets/logo-ASK.svg, which the renderer inlines as the masthead mark of each document it renders. The interactive IA-state spine takes its responsive composition from the spine engine: on a compact canvas its inspector, legend and caption close behind triggers in the shared disclosure grammar, so the spine page loads surface-panel.css then surface-treatments.css, pinned local copies vendored beside the shell's, and its bundle carries the shared diagram pointer controller for pan, pinch and wheel. That is the spine's own composition. The two static pages adopt the static family's optional responsive chrome (diagrams-chrome.js, vendored with the diagram bundle), which keeps each figure's caption and legend open together while they fit and, on a narrow or crowded canvas, closes them behind triggers in one control area with the HUD; the triggers take the same disclosure grammar from the same two modules, and the pages hand their gestures to the same pointer controller. The site root serves a generated urban-observatory home page, and /read/ serves reading pages for the declared scope, method and architecture documents and the diagram-folder records, with read-only source views of the architecture-tree and ontology sources and the state spine's data file. All of them are generated from the repository's Markdown and source files when the site is built (tools/read/), and none is committed. They load surface-shell (CSS + navigation runtime), surface-panel.css, surface-action.css, the logo-ASK wordmark pair and the _dsa-tokens/ token and font mirror from the diagram folder's existing local copies, and take the document register — surface-text-link.css, surface-document.css, surface-treatments.css and the optional surface-document-overflow.js helper — from their own pinned local copies under tools/read/carriers/, vendored separately from the diagram folder's surface-text-link.css and surface-treatments.css, and from the renderer's tools/artifact-template/ build inputs. The register sets the documents' headings, prose, contents entries, code and preformatted text, and each blockquote takes the role its declaration names. The home page's seven routes are full-panel links. In the built site the diagram front door opens the reading pages and source views in place of the raw files, and its breadcrumb links the home page; opened from a clone it still opens the raw files. The reading pages are live pages, rebuilt at each deployment and sealed nowhere; the renderer above keeps its separate sealed-artifact relationship, and the site build does not touch it. urban-observatory owns the pages' composition, declarations and build; the modules supply presentation. |
Consumermethod-ASK |
Public statusmethod-surface consumer (live: method.a-s-k.studio) | Consumesdiagram-static-H · Three Functions · surface-shell (CSS + navigation runtime) · surface-panel.css · surface-action.css · surface-text-link.css · surface-document.css · surface-document-overflow.js · surface-treatments.css · static responsive chrome (diagrams-chrome.js) · shared diagram text-layout · shared diagram pointer controller · canonical browser-icon package · logo-ASK wordmark |
NotesFive diagram-static-H shells: topology (D02), intent-artifact ontology (D10), activation and lifecycle comparison (D05), relay / feeding / ingestion (D06), and adversarial relay graph + PTX projection (D07). Four bespoke figures also use the shared visual contract: system-ASK (D11), bounded generativity, SMGI doctrine, and SMGI ontology. The bounded-generativity system-model figure (docs/diagrams/method-ASK_bounded-generativity.*) was the first Three Functions consumer and uses legislative / executive / judicial function color at 30%, with candidate variance as negative cutouts through the executive chamber. The SMGI doctrine figure (docs/diagrams/method-ASK_seed-mediated-generated-interface.*) is method-ASK's second Three Functions-consuming bespoke figure, licensing the grammar node only. The SMGI ontology figure (docs/diagrams/method-ASK_seed-mediated-generated-interface-ontology.*) is intentionally neutral and does not load three-functions.css. The system-ASK hero (docs/diagrams/method-ASK_system-ASK-hero.*, D11) is method-ASK's third Three Functions-consuming bespoke figure, and the first to bind the primitive on a worked example rather than on doctrine: examples/system-ASK.md is an ASK-specific realization of the method, and the figure projects that accepted claim set. It carries legislative on the source-of-intent role, as the constitutive source, and on the execution grant and the enforced path-scoped grant, as delegated apparatus; executive on the executor chamber and on the realization span inside the grant; and judicial on the adjudication gate and disposition. The human ASK actor is drawn as a neutral envelope around the source-of-intent role and the adjudication gate, so the figure classifies the role, not the actor who occupies it. Artifact governance and the governed artifact remain neutral on their own grounds — selection is not governance. The executor chamber is drawn as an even-odd path with the grant cut out, and the grant with the realization span cut out, so no two 30% role fills stack. It is also the first registered consumer of the opt-in --fg-high-contrast foreground role, bounded to its own light-theme diagram text. Separately from the diagrams, method-ASK runs an ASK-branded live diagram front door at method.a-s-k.studio/diagrams/ — the index for the figures above. It vendors pinned local copies of surface-shell.css, surface-panel.css, surface-action.css, surface-text-link.css (for the README link in its page note), and the mode-aware logo-ASK wordmark pair, and hot-links nothing. It reuses the repo's existing _dsa-tokens/ token and font mirror rather than adding a second copy of either. The two panel forms are both in use and divide as the module intends: diagram cards are inert panels carrying their own action links, while the repository / method / design-system / ASK routes, and in the built site the documents route, are full-panel links. method-ASK owns its payload, destinations, deployment, and local adaptations. The front door carries ASK Tier 3, which is a property of that navigation surface and does not propagate into the Tier 1 + Tier 2 diagram artifacts it indexes; method-ASK's ASK branding is its settled identity posture, not a placeholder. It carries the canonical browser-icon package — favicon.svg, favicon-32.png, favicon.ico and apple-touch-icon.png — vendored byte-identical at the deployed-origin profile with root-absolute references. Its static tree pages consume the shared diagram text-layout contract, which is indivisible from the static engines: the engine fails closed when the helper is absent. The front door adopts the shell's navigation runtime and shows its full public ancestry, derived from the visible breadcrumb rather than authored twice. method-ASK additionally carries the public system-ASK topology projection as landed content. It is a generated public projection of an operator-side canonical that remains outside this repo family's public surfaces: it is not method-ASK doctrine, it is not the operator canonical, and it confers no authority over it. Every diagram page — the five diagram-static-H shells, the four bespoke figures and the public topology projection — adopts the static family's optional responsive chrome (diagrams-chrome.js, vendored with the diagram bundle), which keeps each figure's caption, and its legend where it has one, open together while they fit and, on a narrow or crowded canvas, closes them behind triggers in one control area with the HUD. The triggers take the shared disclosure grammar from surface-treatments.css, a pinned local copy vendored beside the shell's, which every diagram page loads after surface-panel.css, and each page hands its gestures to the shared diagram pointer controller for pan, pinch and wheel. The site root serves a generated method-ASK home page, and /read/ serves reading pages for the declared doctrine documents, worked examples and diagram-folder records, with read-only source views of the declared figure sources. All of them are generated from the repository's Markdown and source files when the site is built (tools/read/), and none is committed. They load surface-shell (CSS + navigation runtime), surface-panel.css, surface-action.css, the logo-ASK wordmark pair and the _dsa-tokens/ token and font mirror from the diagram folder's existing local copies, and take the document register — surface-text-link.css, surface-document.css, surface-treatments.css and the optional surface-document-overflow.js helper — from their own pinned local copies under tools/read/carriers/, vendored separately from the diagram folder's surface-text-link.css and surface-treatments.css. The register sets the documents' headings, prose, contents entries, code and preformatted text: each blockquote takes the role its declaration names, and each declared structured block its peer groups. The home page's six routes are full-panel links. In the built site the diagram front door opens the reading pages and source views in place of the raw files, and its breadcrumb links the home page; opened from a clone it still opens the raw files. method-ASK owns the pages' composition, declarations and build; the modules supply presentation. |
Consumercontrol-surface |
Public statusprotocol-surface consumer (live: control-surface.a-s-k.studio) | Consumesdiagram-static-H · surface-shell (CSS + navigation runtime) · surface-panel.css · surface-action.css · surface-text-link.css · surface-document.css · surface-document-overflow.js · surface-treatments.css · static responsive chrome (diagrams-chrome.js) · shared diagram text-layout · shared diagram pointer controller · canonical browser-icon package · logo-ASK wordmark |
NotesTwo diagram-static-H shells: the architecture tree (D01) and the intent-inbox lifecycle (D08). Both adopt the static family's optional responsive chrome (diagrams-chrome.js, vendored with the diagram bundle), which keeps each figure's caption and legend open together while they fit and, on a narrow or crowded canvas, closes them behind triggers in one control area with the HUD. The triggers take the shared disclosure grammar from surface-treatments.css, a pinned local copy vendored beside the shell's, which both pages load after surface-panel.css, and both pages hand their gestures to the shared diagram pointer controller for pan, pinch and wheel. Separately from the diagrams, control-surface runs an ASK-branded live diagram front door at control-surface.a-s-k.studio/diagrams/ — the index for the two figures above. It vendors pinned local copies of surface-shell.css, surface-panel.css, surface-action.css, surface-text-link.css (for the README link in its page note), and the mode-aware logo-ASK wordmark pair, and hot-links nothing. It reuses the repo's existing _dsa-tokens/ token and font mirror rather than adding a second copy of either. Both panel forms are in use and divide as the module intends: the two diagram cards are inert panels carrying their own action links, while the repository / control-surface / method-ASK / design-system-ASK / A-S-K.studio routes, and in the built site the documents route, are full-panel links. control-surface owns its payload, destinations, deployment, and local adaptations. The front door carries ASK Tier 3, which is a property of that navigation surface and does not propagate into the Tier 1 + Tier 2 diagram artifacts it indexes; control-surface's ASK branding is its settled identity posture, not a placeholder. The folder carries no committed diagram raster. It carries the canonical browser-icon package — favicon.svg, favicon-32.png, favicon.ico and apple-touch-icon.png — vendored byte-identical at the deployed-origin profile with root-absolute references. Its static tree pages consume the shared diagram text-layout contract, which is indivisible from the static engines: the engine fails closed when the helper is absent. The front door adopts the shell's navigation runtime and shows its full public ancestry, derived from the visible breadcrumb rather than authored twice. The site root serves a generated control-surface home page, and /read/ serves reading pages for the declared workflow docs, protocol notes, templates, prompts, examples and diagram-folder records, with read-only source views of the declared figure sources. All of them are generated from the repository's Markdown and source files when the site is built (tools/read/), and none is committed. They load surface-shell (CSS + navigation runtime), surface-panel.css, surface-action.css, the logo-ASK wordmark pair and the _dsa-tokens/ token and font mirror from the diagram folder's existing local copies, and take the document register — surface-text-link.css, surface-document.css, surface-treatments.css and the optional surface-document-overflow.js helper — from their own pinned local copies under tools/read/carriers/, vendored separately from the diagram folder's surface-text-link.css and surface-treatments.css. The register sets the documents' headings, prose, contents entries, code and preformatted text, and each blockquote takes the role its declaration names. The home page's seven routes are full-panel links. In the built site the diagram front door opens the reading pages and source views in place of the raw files, and its breadcrumb links the home page; opened from a clone it still opens the raw files. control-surface owns the pages' composition, declarations and build; the modules supply presentation. |
ConsumerASK |
Public statuspublic reference implementation (live: A-S-K.studio) | Consumescolors_and_type.css (Tier 1 + Tier 2 tokens) · Inter + JetBrains Mono fonts · logo-ASK wordmark · surface-shell · surface-panel.css · surface-action.css (with the attention edge) · surface-text-link.css · surface-document.css · surface-document-overflow.js · surface-treatments.css · canonical browser-icon package · Spectral State · diagram-interactive-radial · shared diagram pointer controller |
NotesThe ASK meta-brand front door — a live static reference implementation of design-system-ASK. Vendors the canonical tokens, fonts, and wordmark directly (not the diagram _dsa-tokens/ mirror), and vendors the surface-shell pattern together with the surface-panel and surface-action visual rules as pinned local copies rather than hot-linking them from a design-system deployment. Every non-home content page consumes the shell, and each opts into its responsive navigation by authoring its own navigation source, so the optional runtime is vendored alongside the shell CSS. The homepage is the explicit exception and keeps its own independent composition — though it does consume both visual rules. Its three tier panels take surface-panel, as do the asymptotic system key and studioLeoV pages' external cards and the conclusions page's held-question rulings and panels; the disclosures of the asymptotic system key page and its lineage page also consume surface-panel.css for their panel material and free attachment. Compact controls take surface-action across every page, the homepage included. The two rules divide differently, and the split is the durable part. The panel rule governs a panel's arrangement, its paint, and the type roles of its title and supporting copy, but deliberately sets no supporting foreground — panel support-copy foreground stays ASK-local. The action rule owns a compact control's base surface, foreground, border, geometry, hover, press, and focus, while ASK keeps element semantics, destination, copy, row, and placement. One bounded exception is deliberate: the two gallery gal-link controls carry an on-image contextual-paint adaptation over that canonical base, so they stay legible above a photograph. Separately, the gallery cards, the video facades, the p5 launch cards and the gallery dialog's close, previous and next controls adopt the action rule's attention edge by class, the dialog's three controls on its borderless variant: the owner governs only their hover and keyboard-focus edge, and ASK keeps their surface, geometry and behavior. site.css owns ASK's payload layout, its instance adaptations around the inherited shell, and the homepage's own composition — it no longer carries a second, competing page shell across the content pages, nor local duplicates of the panel and action paint. Carries ASK's own Tier 3 by identity, as ASK-the-entity, and supplies that wordmark into the shell's mark slot. Other ASK-family projects may also carry the ASK wordmark where ASK assigns that Tier 3 locally; sharing the mark does not make them ASK-the-entity, and does not make Tier 3 an inherited shell value. Consuming the shell does not by itself make it a Class A diagram consumer — it is not one. It is a Spectral State consumer, through exactly one named route: the consciousness + free will interactive mind map over its typed relation atlas, which is a route of its own beneath the conclusions page. The conclusions page itself is an ordinary shell page. The map route alone is the named full-viewport interactive-application exception to surface-shell — a fixed application rather than a scrolling document — and it is drawn by the diagram-interactive-radial surface pattern: the pattern's stylesheet, its contract, layout, label and engine scripts, all six optional modules (legend, chrome, inspector, facets, export and theme), the shared pointer controller and the shared Fit helper, vendored byte-identical with spectral-state.css beside the route, in the conclusions page's folder. The map's own code — its adapter, its mount and its stylesheet — and its page are ASK's. Color on that surface encodes governed state only, through Spectral State roles the map's adapter binds. The route also loads surface-panel.css then surface-treatments.css for its controlled disclosure triggers — the inspector's collapse control, and the About and Legend triggers used where the canvas cannot hold its caption and legend open — and surface-action.css and surface-text-link.css for its bar controls and the inspector's source links. The exception is specific to the map route and creates no exemption for ordinary non-home content pages — including the conclusions page that introduces the map — which continue to consume the shell; the homepage remains the independent-composition exception. It carries the canonical browser-icon package — all four files at the deployed-origin profile, vendored byte-identical. It is now also a surface-text-link.css consumer: the rule is opt-in by class and governs unboxed textual traversal, and the split is again the durable part — the owner governs that link's rest, hover, active and focus presentation and sets no foreground, while ASK keeps the contextual text color, semantics, destination, copy, row and placement. The shell's footer destinations are compact actions, so the shell owns the footer ROW and surface-action owns each destination's presentation. It is also a document-register consumer, and the split is by page. The consciousness + free will conclusions page sets its document through surface-document.css and consumes surface-treatments.css and the optional surface-document-overflow.js helper. The apex solar kiss, asymptotic system key and studioLeoV pages use the register's document-body and authored-inline-emphasis treatment in their opening paragraphs. The apex solar kiss, design, ASKproduKtion and studioLeoV pages use its section-title role for content headings, and the asymptotic system key page uses its quotation role for the Like Art founding statement and surface-treatments.css for its disclosures, as its lineage page does for its own. The overflow helper remains confined to the conclusions page. The modules own presentation; ASK keeps its markup, its semantics and which passage takes which role. Its own Tier 3 is supplied locally into the shell's mark slot; surface-shell itself stays Tier-3-neutral. |
First-party consumers
Same-repo consumers, distinct from the public downstream repos above: they consume the canonical bundles by same-repo reference, not a vendored _dsa-tokens/ mirror. There is no vendored pin and no copied bundle, and referenced canonical assets resolve at repo HEAD. Two different relationships live here, and they do not share a maintenance verb.
Live first-party surfaces consume the canonical assets by direct same-repo reference. When an owner contract changes they need rendering and behavior verification, not regeneration — a page does not rebuild its chrome because the stylesheet it references changed.
Generated preview artifacts are regenerated and reverified from their canonical pattern sources, through generator --check, generated-set parity, and visual verification. That is a separate relationship from a page consuming surface-shell for its own chrome.
Operational currency is tracked operator-side, as for public consumers.
| Consumer | Status | Consumes | Notes |
|---|---|---|---|
Consumerdesign-system-ASK public surface family (/ · preview/styleguide.html · patterns/) |
Statusfirst-party same-repo consumer | Consumessurface-shell · colors_and_type.css (Tier 1 + Tier 2 tokens) · logo-ASK wordmark pairings |
NotesThe repo's three authored public surfaces, sharing one page shell so they read as one artifact family with different payloads rather than three lookalikes. The generated reading pages share the same shell and mark; their own row below records them. Consumed by same-repo reference — no vendored pin, no copied bundle. Flush-left header and flush-right footer on all three, per the pattern. All three adopt the shell's optional responsive navigation and load surface-shell.js, so the identity mark discloses the hierarchical panel on every one of them — the mark's meaning does not change between pages of the same family. Their panels differ only in shape: the style guide, the gallery and, in the built site, the documents index are siblings under design-system-ASK, while the root page is design-system-ASK and carries those three as its children. The wordmark is listed here as a separate consumption: surface-shell is Tier-3-neutral (though not ASK-neutral — it inherits Tier 1 + Tier 2) and ships an empty mark slot, and these three surfaces fill it from assets/ because they carry ASK's own Tier 3 — a property of the consumer, not something inherited from the shell. The style guide alone places a forced-mode selector in the shell's optional control slot; that control (styleguide-theme-control.js plus its own page CSS) is style-guide-only, is not part of the surface-shell pattern, and is not vendored with it. The root and the gallery carry no control and load no theme script. |
Consumerdesign-system-ASK reading pages — /read/ (the built site only) |
Statusfirst-party same-repo consumer (generated at deployment) | Consumessurface-shell (CSS + navigation runtime) · colors_and_type.css (Tier 1 + Tier 2 tokens) · surface-panel.css · surface-action.css · surface-text-link.css · surface-document.css · surface-document-overflow.js · surface-treatments.css · logo-ASK wordmark pairings · canonical browser-icon package |
NotesReading pages for the README, CONSUMERS.md, the four semantic primitives, the pattern READMEs and hard-fail checklists, the tests README and the site build's own README, with a documents index. tools/read/ generates them from the repository's Markdown at each deployment, and none is committed. They consume the owner's canonical files by same-repo reference, as the public surface family does: no vendored copy, no pin and no hash gate, so each deployment's pages take the owner contract that deployment builds from. They share the family's shell and mark, and the documents index is a sibling of the style guide and the gallery under design-system-ASK. The document register sets their headings, prose, contents entries, code and preformatted text, and each blockquote takes the role its declaration names. This is a live first-party surface relationship: an owner contract change needs rendering verification at the next build, not regeneration, because nothing generated is committed. In the built site the three authored surfaces are composed as front doors: their documents entries and the pattern gallery's Markdown links open these pages. Opened from a clone, the documents entries are absent and the gallery's links open the raw files. design-system-ASK owns the pages' declarations and build; the modules supply presentation. |
Consumerdesign-system-ASK live panel populations — / route panels · patterns/ catalog cards |
Statusfirst-party same-repo consumer | Consumessurface-panel.css |
NotesThe two semantic forms the module supports, both consumed by same-repo reference. Root route panels are full-panel native links — the panel element is the anchor and contains no other link. Pattern-gallery cards are inert panels with their own action links. The module owns presentation only: each surface keeps its markup, its semantics, and its support-copy foreground, and only the link form receives interaction. It creates no generated-preview obligation and is neither a surface pattern nor an artifact scaffold. |
Consumerdesign-system-ASK compact-action controls — patterns/ gallery actions · preview/styleguide.html compact-action specimen · all three public surfaces' footer destinations · the navigation panel's utility controls |
Statusfirst-party same-repo consumer | Consumessurface-action.css |
NotesFour relationships on one module, all consumed by same-repo reference; the generated reading pages, which also load it for their action rows and navigation panels, are recorded in their own row. The footers are the newest: a shell footer destination is a compact action, so /, patterns/ and preview/styleguide.html each carry four of them in the built site, and three opened from a clone, where the documents destination is a build-only fragment. The navigation panel carries both its close control and its utility destinations on the same module — hierarchy rows deliberately do not, because rendering every tier as a pill would flatten the hierarchy. The root page has no compact control in its own payload, but it loads the module for three generated reasons rather than one: its footer destinations, its panel's close control, and its panel's utility destination. The pattern gallery carries the live controls: each pattern card's preview links and its README, and each semantic-foundation card's visual key and contract, all native anchors, with the ten README and four contract controls on the foreground-only --secondary variant. The gallery owns its action-area composition: one preview, a labeled group of peer previews or a visual key, followed by a separate README or contract action for the whole entry. The complete action area is bottom-anchored as one unit; grouping, spacing and wrapping stay local to the gallery, because action-area composition is the consuming card's, not the contract's. The style guide carries the canonical specimen: a native <a> and a native <button> exercising both semantic forms, plus a long-label pair at one explicit width exercising the wrapping and box-model cases the contract permits. It loads the real module, so the specimen's rendered control styling resolves from the canonical module; its descriptive copy remains maintained and may require update when the contract changes. The style guide's separate .btn Primary / Ghost pair is not a consumer of this module: it is an 18px Inter CTA, a deliberately different role, labeled as such beside the compact-action specimen and never conformed to it. |
Consumerdesign-system-ASK static diagram bundles — patterns/diagram-static-H/ · patterns/diagram-static-V/ · patterns/diagram-static-SEQ/ |
Statusfirst-party same-repo consumer (generated mirror) | Consumes_diagram-shared/diagrams-text-layout.js |
NotesThe three static engines consume one canonical text-layout contract — line breaking, measurement, role metrics (per-role cap, line height, and the has-note predicate), and tspan emission. None of the three keeps a private cap table, line-height table, or rendered-secondary predicate: they request layout by role and receive the resolved metrics, because three private copies is exactly how V's predicate came to drive geometry from notes V never draws — measured on the base engine, a note on a group selected BOX_H_NOTE and grew the box 26→44px, while a note on a section cost no height but still added ~434px of band width. This is a generated-mirror relationship, not same-repo reference: tools/sync-diagram-shared.mjs emits a byte-identical copy into each bundle so a downstream vendor takes a self-contained folder and acquires no cross-folder path dependency, and --check exits non-zero on any divergence, so a hand edit to a mirror fails loudly rather than surviving as a silent fork. Each member declares its own target set — the shared folder confers no authority over every diagram pattern, and diagram-static-FLOW, diagram-static-peer, diagram-interactive-spine and diagram-interactive-radial are explicitly excluded, FLOW because it carries a different source grammar, the peer pattern because its plates set single letters and the key's words, which never wrap, the interactive spine because it takes no text-layout dependency at all, and the radial pattern because its own label solver places its names. The helper owns text only: topology, placement, connector geometry and the final SVG envelope stay with each engine, which is why there are three engines rather than one wearing three names. Both shared carriers fail closed — an engine loaded without diagrams-fit.js or without a complete diagrams-text-layout.js interface throws a named error and renders nothing, so a partial re-vendor is visible immediately. Public downstream consumers have taken this contract; the applicable ones are the diagram consumers recorded in the public rows above, and because the mirror ships inside each bundle, a consumer that vendors an in-scope engine takes the helper and that engine atomically — there is no state in which one arrives without the other. Exact pins, per-consumer exceptions and re-sync state stay operator-side, as for every other pin. |
Consumerdesign-system-ASK diagram bundles — patterns/diagram-interactive-radial/ · patterns/diagram-interactive-spine/ · patterns/diagram-static-H/ · patterns/diagram-static-V/ · patterns/diagram-static-SEQ/ · patterns/diagram-static-FLOW/ |
Statusfirst-party same-repo consumer (generated mirror) | Consumes_diagram-shared/diagrams-pointer.js |
NotesThe radial surface pattern, the interactive spine and the four static engines take gesture recognition — pan past a tap slop, pinch, the click a moved gesture swallows, and the wheel — from one canonical pointer controller; each engine keeps its own camera, hit test and selection, and decides what a tap means. As with the text-layout contract above, this is a generated-mirror relationship: tools/sync-diagram-shared.mjs emits a byte-identical copy into each bundle, so a downstream vendor takes a self-contained folder, and --check exits non-zero on any divergence. The member declares its own target set, these six bundles. The radial and spine engines fail closed without the controller, so a partial re-vendor is visible at once. The static engines (v2 of the controller, which leaves the panels laid over a static canvas native) keep their legacy mouse drag and wheel without it and say so in the console, so a page generated from an older shell still draws; a controller older than v2 fails them closed. Public downstream consumers have taken it: the radial and spine consumers recorded in the public rows above, which receive the controller atomically with the bundle that ships it. Exact pins and re-sync state stay operator-side. |
Consumerdesign-system-ASK textual-link specimen — preview/styleguide.html |
Statusfirst-party same-repo consumer | Consumessurface-text-link.css |
NotesThe canonical specimen for the module, consumed by same-repo reference; the style guide also uses it for the README link in its high-contrast foreground note. (Other first-party pages also load the module, each for the links it composes: the document-register key, whose uses its own row describes; the Review Semantics key, for the link in its passage-mark demonstration; the output-artifact template and its generated preview, for their body-text and table-header links; tests/role-conformance-fixture.html, for its table-of-contents, prose, metadata, quotation and table-cell links; tests/document-table-fixture.html, for a link in a table header; and the radial pattern's reference and synthetic shells, their generated previews and tests/radial-stack-fixture.html, for the inspector's source links; the peer pattern's generated specimen preview, for its README link; the pattern gallery, for the CONSUMERS.md link in its page note; and the generated reading pages, for their textual links.) The style guide loads the real module, so the specimen's rendered link treatment resolves from the canonical module rather than from a local restatement; its descriptive copy remains maintained and may require update when the contract changes. It exercises the cases the contract turns on: an ordinary prose link, one anchor long enough to fragment across lines at a narrow viewport, one anchor carrying an explicit role color — which the module must not overwrite, since it declares none — and one shaped compact action alongside, carrying no textual-link class, so the shaped-object boundary is visible on one line. The style guide's own breadcrumb and navigation-panel hierarchy rows are not consumers of this module: .surface-title a and a.surface-nav-row are the two roles surface-shell.css governs through direct selectors, and adding the payload class to either would duplicate a contract the shell already owns — from two separately pinned files, so whichever changed first would win silently. Its footer destinations are not consumers either, for a different reason: they are shaped compact actions owned by surface-action.css, not textual links at all. This module keeps ordinary opted-in unboxed links and nothing else. |
Consumerdesign-system-ASK style-guide authorial callouts — preview/styleguide.html |
Statusfirst-party same-repo consumer | Consumessurface-treatments.css (with its load dependency surface-panel.css) |
NotesThe style guide's two standing notes are authorial callouts on the magenta emphasis rail, consumed by same-repo reference. The page composes no panel; it loads surface-panel.css only because the treatments extend it. |
Consumerdesign-system-ASK public surfaces (/ · preview/styleguide.html · patterns/) |
Statusfirst-party same-repo consumer | Consumescanonical browser-icon package | NotesThe owner surfaces serve the same four-file browser-icon package they vend — favicon.svg, favicon-32.png, favicon.ico and apple-touch-icon.png — at the deployed-origin profile. design-system-ASK is the canonical implementation owner of the ASK browser-chrome expression; consumers vendor these bytes rather than authoring their own. |
Consumerdesign-system-ASK owner pattern-preview gallery (patterns/) |
Statusfirst-party same-repo consumer | Consumesall previewed Class A patterns + output-artifact + message-archive + surface-shell + diagram-interactive-radial |
NotesGenerated shells under patterns/_preview/, consumed by same-repo reference (no _dsa-tokens/ mirror). Regenerate with tools/gen-pattern-previews.mjs and pass --check + visual verification whenever an adopted pattern changes. The surface-shell specimen additionally resolves surface-action.css from the repo root through the generator's declared rootRefs mapping, and loads the optional surface-shell.js from the canonical pattern directory — so the generated preview exercises the navigation panel rather than only the static chrome. The diagram-interactive-radial card's two previews, the captured research reference and the synthetic parks composition, each load the complete module stack from the canonical pattern directory and resolve spectral-state.css, surface-panel.css, surface-treatments.css, surface-action.css, surface-text-link.css and fonts-embedded.js from the repo root through the generator's mappings; the reference also takes the two wordmark pairings from assets/. The diagram-static-peer preview draws its plates from the canonical pattern directory's source, glyph carrier and engine, and resolves surface-text-link.css and surface-document.css from the repo root through the generator's _dsa-surface/ mapping. The static diagram previews — diagram-static-H, -V and -SEQ, and both diagram-static-FLOW previews — adopt the static family's responsive chrome: each mounts diagrams-chrome.js from its canonical bundle and resolves surface-panel.css then surface-treatments.css from the repo root, as the diagram-interactive-spine preview does for the triggers of its own compact composition. The output-artifact specimen resolves the four document-register modules (surface-panel.css, surface-text-link.css, surface-document.css, surface-treatments.css) from the repo root through the same rootRefs mapping. Preview-only theme selection, and the forced static mode of one FLOW preview — no canonical engine, CSS, token or fit change; every diagram preview whose engine has a Fit takes that engine's own Fit, and the diagram-static-peer plates, which have none, take their figures' width, so each preview shows what a consumer receives. The gallery holds two independent relationships, and surface-shell appears in both rows for two different reasons. Its inclusion here records the catalog preview — the gallery presents the shell as one of the patterns it exhibits. The public-surface-family row above records the separate fact that the gallery page also consumes the shell for its own chrome. |
Consumerdesign-system-ASK document-register and surface-treatment key — surface-document.html |
Statusfirst-party same-repo consumer | Consumessurface-document.css · surface-document-overflow.js · surface-action.css · surface-panel.css · surface-text-link.css · surface-treatments.css |
NotesThe owner's rendered key for the document register and the surface treatments, consumed by same-repo reference. It loads the text-link module for the links it composes with .surface-text-link: its table-of-contents entries and its prose, table-header, relation and locator links. The relation links sit in record metadata (.doc-meta); the locator links sit inside document code (code.doc-code). |
Consumerdesign-system-ASK primitive keys — three-functions.html · spectral-state.html · evidence-state.html |
Statusfirst-party same-repo consumer | Consumessurface-document.css |
NotesDocument-register headings on the owner's own keys |
Consumerdesign-system-ASK Review Semantics key // review-semantics.html |
Statusfirst-party same-repo consumer | Consumesreview-semantics.css · spectral-state.css · evidence-state.css · surface-document.css · surface-document-overflow.js · surface-action.css · surface-panel.css · surface-text-link.css · surface-treatments.css |
NotesThe owner's rendered key for Review Semantics, drawn on the document register, consumed by same-repo reference |
Vendoring granularity
Shared contract, selective renderer. The window.DIAGRAMS.render interface is a shared contract across the static patterns diagram-static-{H,V,SEQ,FLOW}: H, V and SEQ share one tree grammar, so their source data is portable between those engines, and FLOW keeps a convergence-flow grammar of its own. The concrete pattern engines (diagram-static-{H,V,SEQ,FLOW}, diagram-interactive-spine) are renderer capacity — the code a consumer actually runs. diagram-static-peer stands outside that contract: its relation grammar, engine and exporter are its own, and a consumer vendors its whole bundle when it first renders a peer plate.
Downstream consumers vendor the complete canonical artifacts for the patterns/modules they actually render. Optional capabilities inside an adopted module travel with that module, even if unused, and must not be cherry-picked or locally forked. Unused pattern engines are not pre-vendored speculatively; a consumer adopts and vendors the current canonical engine when it first renders that pattern. Shared artifacts — the static exporter, the token mirror — remain whole shared artifacts, not split by dormant internal branches. The vendoring boundary traces the code seam: selective by pattern where engines diverge, whole where an artifact is genuinely shared — which keeps each consumer's re-sync obligation to exactly the patterns it exercises.
What this file is not
- Not a customer or marketing list. It records implementation relationships — public downstream repos and design-system-ASK's own first-party same-repo surface — nothing more.
- Not the full propagation ledger. Queued / in-flight consumption, private/firewalled consumers, vendored commit pins, re-sync obligations, and pin drift are tracked operator-side, outside this public repo.
- Not a currency guarantee. Listing a consumer here does not assert it tracks the latest upstream; a downstream consumer may lag until it re-syncs, and the first-party generated preview set until it is regenerated and reverified. Specific vendored pins and currency are operator-side provenance, deliberately not published here.
A private operator-internal consumer has also exercised the Class B output-artifact flow end-to-end under its v2 contract; its contents remain firewalled and it is not listed here.