To render a resource as a readable page, you SHOULD declare a Look and let the universal renderer produce the HTML, CSS, and SVG. Do NOT hand-author a Transformation that emits page HTML.

Declarative bands express the common page (hero + properties + cross-references) in a fraction of the YAML, with built-in cascade semantics for multi-publisher styling. Hand-rolled HTML transformations diverge across publishers and rot.

Author a Transformation (bound via Derivations) only for output that is NOT a resource page — a data format, a generated file, or a bespoke visualization the band catalogue cannot produce.

Transformations are the escape hatch for genuinely novel output. Using one where a look would do throws away the cascade and the shared band library.

Use a View when you need to select, filter, or aggregate instances into a NEW result shape — not to style an existing resource. A view materializes into a Ephemeral Package. The full data-View authoring guide is the kanonak.org/view-language protocol; this guide is the visual (look) side of the same view.View base.

A view is a query; a look is presentation. They share the view.View base — a look view is its visual specialization, a data view its projecting one — but the surfaces are disjoint (bands vs projections). Conflating them leads to looks that try to compute and views that try to render; route by intent and follow the matching guide.

A Look declaration SHOULD live on a class (or a Package / publisher), so it applies to every instance. Declaring it on an individual instance MUST be a deliberate override, not the way you style a kind of thing.

Styling the type is what makes the system scale: one declaration styles a thousand instances, and the class hierarchy carries it to subtypes. Per-instance looks are duplication waiting to drift.

When presentation should follow an instance's STATE — a status, a severity, a phase — declare a Instance Variant on the class's View rather than styling the affected instances. The variant's When Condition matches a property value, and every instance in that state follows it.

State-driven presentation is the one case that looks like it needs per-instance styling and does not. A variant is still a declaration on the TYPE — one rule covers every instance that enters the state, including ones authored later — so it scales the way the rest of the cascade does, while styling each affected instance by hand does not.

A class's page look MUST be a Resource View whose bands is an ordered list of band instances, each pointing (via look.source or a band-specific slot) at a property of the resource. Render order follows list order.

An ordered list of declarative bands reading real properties is what lets the renderer produce a page with no per-class code, and keeps labels and values sourced from the graph (DRY).

Every band *Path carrier MUST be a Expression evaluated against the band's node (bound to input) — never a /-separated path string. Use a Property Read for a direct or embedded field (nested for embeds) and a Traverse for a reference step.

A string path matched by stripped local name is a magic string: it fails silently to undefined at render time and is invisible to validation. A typed expression resolves every step through the object model, so kanonak validate (the LookBandPath rule) reports an out-of-scope or misspelled property as an error rather than rendering an empty band.

A diagram band MUST NOT be given data of its own. Do not model "steps", "messages", "edges" or "cardinality" so that a picture can be drawn: a Sequence reads object properties the ontology already declares, in the order a prose property's [[references]] tell it; a Entity Relationship reads Min Count / Max Count and Functional Property for cardinality. If a diagram is wrong, the graph is wrong — fix the triple, the shape, or the prose.

A diagram with its own data is a second copy of the model that drifts from the first. Reading the graph makes the picture a proof of the data — and lets kanonak validate report drift between the narrative and the triples, which no hand-drawn diagram can do.

A Sequence MUST declare look.source naming a property whose Range is Markdown, and look.connectors listing one or more Connector whose look.relation is an object property between the participants. Direction is taken from the triple, never from the sentence.

Order can only come from prose (a list has order but no narrative; a set has neither), and a message can only be a triple that holds. Both are checked at validate time — a non-prose source, a missing connector list, a relation that is not a property, and an unknown lineStyle / nodeTier are each an error on the declaring class.

A Sequence SHOULD be placed beside a Markdown band over the SAME look.source property, so the narrative and the diagram render from one statement.

The prose is the diagram's annotation. Rendering both from one property means they cannot disagree, and a reader can follow the numbered messages back into the sentences that name them.

Prefer the ontology's own structure to a look slot: declare Inverse Of to get a dotted reply, Symmetric Property to get an undirected edge, a SHACL shape or Functional Property to get a cardinality. Use lineStyle (solid / dotted / open / thick) only for what OWL cannot say — an asynchronous or a critical-path message — and look.nodeTier on the band or Diagram Tier on the participants' class only to size the node tiles.

Structure declared once serves every consumer — the ER diagram, the sequence, kanonak validate --conformance, generated code — while a look slot serves one picture. Reserving the overlay for what the ontology cannot express keeps the two from contradicting each other.

A custom Semantic SVG SHOULD author its tiers as Expression values, never as raw string templates, so each embedded property reference is resolved and validated rather than leaking unrendered.

A typed expression fails at kanonak validate time when a referenced property is wrong; a string template fails silently at render time, leaking an unsubstituted placeholder.

When a class's display name or one-line summary is NOT in Label / Comment, it SHOULD declare Display Label / Display Summary pointing at the property that holds it, rather than duplicating the value.

The lens keeps one value in one place and teaches every renderer to find it; duplicating into rdfs.label invites the two copies to drift apart.

Every resource MUST render even when its class declares no look: the universal floor on Resource provides the default page, glyph, and lenses. A class declares a look only to refine that default.

A guaranteed floor is what makes the system safe to adopt incrementally — you style what matters and inherit the rest, rather than authoring a full page for every class up front.

A site-wide palette SHOULD be declared as Tokens on the publisher's Publisher resource, not repeated per class and not by overriding the Resource floor. Override the floor only to change what an UNSTYLED resource inherits everywhere, including resources from packages you import.

The publisher level exists so one declaration themes a site while leaving each class free to refine it. Repeating a palette per class is duplication waiting to drift. Overriding the floor does work — it is where look-tokens puts the defaults — but it is a blunter instrument: it restyles every resource the render closure reaches, so a change intended for your own pages also lands on imported vocabularies rendered alongside them.