8. Views

The model is one. The audiences are many. A platform engineer cares about the service topology; a security reviewer cares about which services touch PCI data; a product manager cares about the user-facing flow. They all need different diagrams of the same underlying architecture.

A view is a saved projection — a recipe that says what to include, how to group, how to lay it out. Views never modify the model; they only choose how to display it.

view PaymentsLandscape {
    focus domain: Payments
    group by team
    layout elk
}

Three view directives: focus on modules with domain: Payments, group them by team, lay out with the ELK algorithm.

Why views exist

Without views, you have one diagram: every module, every interface, every process arrow, all at once. For anything beyond a tiny system, that diagram is unreadable.

Views let you slice:

• Show only the Payments domain.
• Group the architecture by team for an org chart of the system.
• Hide everything outside PCI scope for a security review.
• Include only what’s reachable from the Checkout process.

Each view is a saved query. Recipients open the same view URL and see the same diagram.

Directives

A view body uses a small set of directives:

Directive	Effect
focus <label>: <value>	Include only nodes carrying this label. Multiple focus lines combine.
group by <label>	Group included nodes into clusters by the value of this label.
layout <algorithm>	Choose the layout engine: elk, dagre, force, or manual.
include <pattern>, ...	Add nodes matching name patterns.
exclude <pattern>, ...	Remove nodes matching name patterns.
"description"	Bare string description for the view itself.

Patterns are glob-style on qualified module names: Payments.*, *.Internal, acme.shared.*.

Worked example:

view PaymentsDashboard {
    focus domain: Payments
    focus security.zone: PCI

    group by team
    layout elk

    include "Payments.*", "PaymentGateway.*"
    exclude "*.Internal"

    "Overview of payment-domain services in PCI scope."
}

Reads as: include modules labeled domain: Payments and security.zone: PCI, plus anything matching Payments.* or PaymentGateway.*, minus anything matching *.Internal; group the result by team; lay it out with ELK.

Layouts

Four layout choices ship with the viewer:

• elk — hierarchical, ELK.js. Best for service topologies; produces tree-ish diagrams.
• dagre — directed-graph layout. Compact, good for dependency-heavy views.
• force — force-directed. Useful for exploring clusters without imposing hierarchy.
• manual — positions are taken from view-local overrides (see below).

The choice is presentation only. Switching layouts doesn’t change the model.

Manual adjustments

Sometimes the layout engine puts a node in a confusing place. Drag it in the viewer; the position is persisted as a view-local sidecar, never on the module itself. Reload, switch views, or hand the URL to a teammate — the saved positions travel with the view, not with the canonical model. Another view of the same modules can use a totally different layout. The same module has the right to look different in different views.

The serialized form of those overrides is a viewer concern, not part of the language grammar — the engine reads them when layout manual is selected and otherwise ignores them.

Planes emerge from labels

Archlang doesn’t have a built-in “network plane” or “security plane.” Planes emerge from how you label modules and what you focus a view on.

// Network plane — group by network segment, ignore everything else.
view NetworkDiagram {
    group by network.segment
    layout dagre
}

// Business plane — group by business entity.
view BusinessDomains {
    group by business.entity
    layout elk
}

// Security plane — focus on PCI scope, group by security zone.
view PCIScope {
    focus security.zone: PCI
    group by security.zone
}

Same model, three views, three audiences. Labels do the work; views surface the slices.

What views can’t do

• Modify the model. Adding a node to a view doesn’t add it to the architecture. Views are read-only on the canonical state.
• Define new structure. A view can’t say “draw a synthetic edge here.” If you want an edge, declare a process step.
• Reuse another view’s content. Each view is self-contained. There’s no extends for views. (If this becomes a real need, it’s a future addition.)

Stable IDs

Views carry stable IDs the same way modules and processes do. The formatter mints #view42 on save. Renaming a view is detected as a rename, not delete-plus-add.

Summary

• A view is a saved projection of the canonical model.
• Directives: focus, group by, layout, include, exclude, "description".
• Layouts (elk, dagre, force, manual) are presentation-only.
• Manual positions persist on the view, never on the model.
• Planes (network, security, business) emerge from labels + focused views, not from a separate ontology.

What’s next

Chapter 9: Fields and Labels → — the value layer that labels and views run on.