The Trevarn icon system is a single, authoritative vocabulary aligned with the brand's Vera Molnár-inspired, systematic visual language. Icons are semantic instruments, not decoration. This page is the manifesto: design rules, acceptance criteria, and the discipline that keeps the library coherent across 189 icons.
What Trevarn icons communicate, and what they don't.
Trevarn icons exist to make operational software readable at a glance. They name things — devices, states, actions, places — without illustration, decoration, or branding noise. Meaning comes from shape; colour comes from context.
Calm · Intentional · Technical · Trustworthy
Icons may change colour based on context or state, never category. Icons themselves never choose colour — they inherit currentColor from the surrounding container or text.
Single icon family, single optical size, single stroke weight — 1.5 canonical (see §Stroke weight rationale). No mixing of filled vs outline styles. Icons must feel designed as a system, not collected.
Glyph = meaning. Colour = context or state. Icons must remain fully legible in monochrome at every size in the library.
Icons are never multicolour. Colour comes via currentColor inheritance from the surrounding container — never hard-coded inside the glyph.
Every icon uses viewBox="0 0 24 24". This is the optical canvas; no exceptions, no aspect-ratio drift.
Every consumer of an icon must apply these attributes on the rendering SVG. The sprite symbols themselves carry no stroke or fill — the consumer controls them, which is how currentColor propagates through.
These patterns fail review. No exceptions, no "just this once".
Multicolour icons
Category colour-coding (red = error inside the glyph, etc.)
Filled icons mixed with outline icons
Gradients, shadows, decorative effects
Branded logos as primary content (use device form, not wordmark)
Framework default icon packs without restyling
Multi-stroke families (one stroke weight; no thin/medium/bold trios)
Emojis or illustrative icons
Decorative icon backgrounds inside the glyph
If an icon draws attention to itself, it is wrong.
When a new icon is proposed, every criterion below must pass. If one fails, reject it — even if the others are excellent.
If it fails one criterion, reject it. Curation is the quality gate; the library shrinks before it grows.
A pattern introduced during the 92→189 expansion: a subset of icons depict specific commercial devices (Apple TV, Sonos Arc, Bambu Lab P1, Ubiquiti switch). These are brand-shaped, not branded — the icon shows the physical form of the device, not its wordmark or logo.
The Sonos Arc icon is a long thin bar with dotted grille perforation — that's what the speaker looks like. Not the Sonos wordmark in a box. The exception: boxy devices where the wordmark IS the visual identity (Apple TV is just a black puck — the white "tv" wordmark is the only thing distinguishing it from a generic puck). For those, the wordmark belongs in the icon.
Brand-shaped icons are designed to degrade gracefully: full silhouette + brand detail at 48px, dominant silhouette + simplified detail at 24px, recognisable silhouette only at 16px. If the brand differentiator (a sun-shade hood, an LCD panel, a logo cutout) doesn't survive at 16px and the icon collapses to a generic shape, the brand variant doesn't earn its place — drop it and let context do the work.
When multiple devices from the same brand exist (Bambu A1 vs P1, Sonos Arc vs Symfonisk, Echo vs HomePod), the discriminator is the actual physical difference — open frame vs closed cube, long bar vs compact box, flat top vs curved dome. Within a brand family, silhouette differences carry the recognition.
The library's canonical stroke weight is 1.5. This was changed from 1.75 during the 92→189 expansion. The change is brand-system-wide — it affects all icons, not just new ones.
The original library at 92 icons used 1.75-stroke. As the expansion brought in detail-heavier icons — multi-port switches, RJ45 silhouettes with cable + LED indicators, 3D-printer frames with sliding beds, network-state pairs distinguished by dash patterns — 1.75 stroke became too thick at 16px. Internal detail blurred into a heavy mass; pair-distinguishability collapsed.
Dropping to 1.5 buys the detail-heavy icons room to breathe at small sizes without requiring fewer paths. The trade-off is a slightly lighter visual feel, which is acceptable in the brand context (Trevarn's voice is calm and technical, not bold).
How the library grew from 92 to 189 icons without losing coherence. These are operating rules, not aspirations.
Once an icon is approved in review, it is frozen — no further modification without explicit consent. This rule was established mid-pilot after silent drift caused review thrash. The frozen rule means a 16px legibility check that passed in week one is still valid in week six; reviewers don't re-litigate already-decided icons.
New design vocabulary lands as a small pilot batch (10-12 icons) before bulk work begins. The pilot tests stroke weight, optical rhythm, and naming conventions on a manageable surface. Once the pilot is approved, bulk batches consume the validated vocabulary without re-deriving it.
Every batch surfaces its reuse decisions explicitly: which icons share a base form, which siblings differ only in state, which intentionally use different metaphors despite semantic similarity. Decisions are documented up front in the PR notes — reviewers see the reuse intent before approving, not after wondering why two icons look similar.
PR-driven, never via pixel-uploads or design-tool exports. The PR includes: the SVG symbol added to the canonical sprite, the metadata entry in trevarn-icons.json, the TypeScript registry entry, and a review HTML rendering the icon at 16/24/48px on light + dark backgrounds. The acceptance criteria above are checked against the rendered output, not the design intent.
| Context | Rules |
|---|---|
| Workflow Cards |
Icon appears top-left or leading Icon size consistent across all cards Icon colour inherited from section context No decorative backgrounds behind icons |
| Navigation (TopBar / LeftRail) |
Icons optional, text-first If used, icons are neutral and secondary, never dominant over labels |
| Admin Areas |
Icons inherit Violet context automatically No special admin icon styles |
| Device Insights |
Brand-shaped icons used for known devices Generic icons (e.g. device-camera-bullet) used as fallback when brand variant doesn't earn its place at 16px
|
The canonical sprite, the Vue component, and how to consume them.
Location: packages/ui-core/src/assets/icons/trevarn-icons.svg in the @trevarn/ui-core package. Served on this site at /icons/trevarn-icons.svg.
The sprite is loaded once at app bootstrap and referenced via <use>:
The sprite ships with no stroke or fill on its symbols; the consuming SVG controls them. This is what allows currentColor to flow through.
The drop-in component shipped in @trevarn/ui-core. It enforces discipline: no colours inside icons, no random sizing, no icon misuse.
Trevarn icons are SVG symbols rendered via <use>.
stroke="currentColor" and fill="none"; canonical stroke weight is 1.5Violations should fail review.
Summary Principle: Icons in Trevarn are quiet, systematic, and intentional. Meaning comes from form. Colour comes from context. Consistency builds trust.
This system applies to every Trevarn product, today and tomorrow.
The icon catalog is searchable by name and tag, grouped by category, with click-to-copy on every glyph.