Shared models and named views

Define a system once, then choose how much detail to show. Named views keep IDs, relationships, source locations, and style declarations shared while allowing different layout and presentation choices.

diagram main "Job system" type=graph layout=auto {
  node client "Client"
  node api "API"
  group backend "Backend" {
    node worker "Worker"
    node store "Store"
  }
  edge request ::client -> ::api
  edge dispatch ::api -> ::backend.worker
  edge save ::backend.worker -> ::backend.store
  view overview "System overview" flow-direction=right {
    include ::client ::api ::backend
  }
  view storage "Storage detail" flow-direction=down {
    include ::backend.worker ::backend.store
  }
}

Selection rules

• Shared nodes require explicit IDs. Each view needs a unique name and an include list.
• A container include selects its subtree. A descendant include preserves ancestor frames without including unselected siblings.
• An edge survives when both endpoints survive. Rows preserve child order and the weights of selected cells.
• Model attributes are inherited, then view attributes override them. The view's title becomes the diagram title.
• The first authored view is the default. Explicit selection uses --view or an API option.

Opaque anonymous edge IDs are assigned before filtering the complete model, so a relationship retains its ID between views. Prefer explicit IDs for steps and external integrations that should survive source edits.

Try an overview and a detail view

Example First diagramService architectureSupport decision treeJob state machineComposite connection statesRequest sequenceCJK and Arabic sequenceRight-to-left graphSlide-sized pipelineRequest/retry presentationShared architecture viewsTheme-aware paint and stylesShared syntax, scopes and annotationsView First view (default)

Layup source Updates as you type// Define the architecture once, then choose a view with --view overview/detail. // Explicit IDs keep references and presentation steps stable between views. // Ancestor containers remain around selected descendants. Unselected // siblings and connections to them disappear; endpoint IDs never change. diagram main "Job processing" type=graph layout=auto { node-style service base=node palette=blue node client "Client" style=service node api "Job API" style=service group processing "Processing" { node queue "Queue" palette=purple node worker "Worker" palette=green { code "process(job)" text "Retries failed jobs" } node store "Object storage" palette=orange } ::client -> ::api "submit" ::api -> ::processing.queue "enqueue" ::processing.queue -> ::processing.worker "consume" ::processing.worker -> ::processing.store "save" view overview "Job processing · overview" flow-direction=right { include ::client ::api ::processing } view detail "Job processing · worker" flow-direction=down { include ::processing.queue ::processing.worker ::processing.store } }

Diagram Loading renderer…

Your diagram appears here. The renderer loads once and runs in your browser.

Ctrl+Enter renders now · Tab moves focus · Click a diagnostic to select its source · Expand for pan, zoom and presentation controls

Use your own fallback fonts

CJK uses your system fonts by default. Choose standalone .ttf/.otf faces for exact measurement and embedding. Files stay in this browser; share links do not include fonts.

Switch the View selector. Add an attribute such as flow-direction=left to one view, or change a shared node title and inspect both results.

layup render model.layup --view storage --html
layup check model.layup --view overview --strict
layup check model.layup --view storage --strict

const scene = engine.compile(source, { view: 'storage' });
const rendered = engine.render(source, { view: 'storage' });

Per-view steps and validation

A view can declare step blocks; when present, its plan replaces the shared model's plan. Shared steps must still reference targets in the selected result. Models can inherit slide attributes and let individual views override the viewport or readability threshold.

All include references, duplicate identities, and shared edge references are validated before filtering. Styles, object references and every authored presentation plan are validated before selection. Layout and machine checks apply to the selected result. Unused declaration linting considers uses across the shared source. Validate each view in CI to cover all rendered variants.

State-machine views must retain valid initial scopes. Sequence notes tied to excluded participants disappear, but filtering must preserve nonempty fragments and complete alternative branches; empty branches are errors.