Skip to main content
Every Nika verb, builtin, feature and run-state carries a canonical icon, color role and motion pattern — declared once in an ontology and served as data from nika.sh/brand. If you’re building a dashboard, an editor integration or an agent surface on top of Nika, take the visual language from here instead of inventing one: your run view and the official surfaces stay one system.

​
The served surfaces

Entity ids are <namespace>/<name> across seven namespaces: verb · builtin · feature · state · ui · social · anim. The builtin entries track the -builtin stdlib — the ontology is parity-gated against the spec canon, so a new builtin cannot ship without its icon.

​
The color law

The four verb hues mean a run is alive — they appear only on live-run surfaces (an executing DAG, a replay). Static UI renders every icon in the surrounding text ink. If you consume the catalog, keep that rule: it is what makes color a signal instead of decoration.

​
Motion

The anim/* entities define the dot-matrix motion register: each verb’s pattern is its execution model — infer samples (a sparkle emerges from seeded noise), exec scans like stdout, invoke round-trips, agent orbits its bounded loop. The pattern names and parameters ride icons.json; the reference renderer lives in the site source.

​
Querying the ontology

The Turtle projection answers SPARQL. For example, every builtin and its glyph:
Classes: nkd:Verb · nkd:Builtin · nkd:Feature · nkd:RunState · nkd:UiGlyph · nkd:SocialMark · nkd:Animation. Relations worth knowing: nkd:parent (every builtin points at verb/invoke — everything callable is a tool reached through invoke:), nkd:sharesGlyphWith (deliberate glyph reuse, e.g. the compose builtin and the check feature share the shield — same oracle), and nkd:hueToken (the CSS custom property a hue rides on the official surfaces).