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 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.