Questions People Actually Ask
Not the polite questions. The real ones — about utility classes, AI reviewers, and why there are no hex codes.
Correct. Zero padding. Zero margin. Zero color values. Zero font-size declarations. A subdomain SCSS file contains only ontological mixin calls: @include genesis-entity('primary') for surface treatment, @include genesis-cognition('axiom') for headlines, @include genesis-environment('focused') for reading layout. The theme engine resolves these to the correct CSS output. If the engine changes, every subdomain updates automatically.
Tailwind describes HOW content looks: 'p-4 bg-gray-800 rounded-lg text-white'. Genesis describes WHAT content IS: genesis-entity('primary'). Tailwind classes are visual instructions scattered across HTML. Genesis mixins are semantic roles declared in SCSS, resolved by an engine that enforces property ownership, hierarchy rules, and accessibility constraints. Change 'primary' in the engine and every entity-primary surface in every subdomain updates. Try that with a find-and-replace across ten thousand utility classes.
Every CSS property belongs to exactly one ontological category. Padding belongs to entity — no other category can set it. Font-size belongs to cognition. Grid and flex belong to environment. Box-shadow belongs to atmosphere. Hover states belong to synapse. Animation belongs to state. When two mixins affect the same element, they NEVER compete for the same property. Specificity conflicts are architecturally impossible, not just discouraged.
Hex and RGB lie about lightness. Pure blue (#0000FF) and pure green (#00FF00) have the same RGB 'intensity' but wildly different perceived brightness. OKLCH is perceptually uniform — when two colors have the same L (lightness) value, they actually look equally bright to human eyes. This means contrast ratios can be guaranteed by lightness constraints rather than tested after the fact. Plus: OKLCH values can exceed the sRGB gamut, making every token HDR-ready without additional code.
Yes. When a subdomain developer needs a variant the system does not have, they write an ontological proposition — a formal document describing the semantic gap, proposing a variant name, specifying CSS properties, and arguing for universal applicability. Dedicated AI agents (theme-genome-agent) evaluate whether the proposal maintains semantic purity, respects property ownership, and benefits multiple subdomains. Approved variants are documented in GENOME.md with their complete origin story.
The hierarchy system prevents this. Page wrappers (Level 1) REQUIRE environment + atmosphere and FORBID entity and cognition. Sections (Level 2) require environment. Components (Level 3) require entity. Leaf elements (Level 4) require cognition or synapse. You cannot apply entity to a layout wrapper or atmosphere to a heading — the rules are architectural constraints, not suggestions.
Because the ontological SCSS engine IS the styling system. Shadow DOM creates a boundary that prevents global stylesheets from reaching component internals. Light DOM means genesis-entity('primary') works identically inside a and outside it. One styling system, one source of truth, zero style-boundary debugging. The Lit 3 base class provides reactive properties and lifecycle management without Shadow DOM isolation.
Through atmosphere variants, not media queries. genesis-atmosphere('void') produces deep dark surfaces (OKLCH L = 0.08), inverted text, and inset shadows. genesis-atmosphere('ethereal') produces light translucent surfaces with glassmorphism. A page can contain BOTH — a void header above an ethereal body. The atmosphere engine resolves colors through OKLCH tokens that maintain contrast in any combination.
The living memory of the design system. It records every ontological variant — 33 foundational plus 56 evolved — with its origin story: which subdomain proposed it, what semantic gap it filled, when the AI agent approved it, and how it integrates with existing variants. Six months from now, when someone asks 'why does entity have an ancestral variant?', GENOME.md answers with history, not just documentation.
Absolutely. The ontological engine powers the theme, but you do not need to understand it to use it. Write HTML with YAML front matter, pick a layout (post, article, landing, dashboard, docs, gallery — 20+ options), and the theme handles typography, spacing, color, responsive behavior, and accessibility. The ontology is there when you need customization, invisible when you do not.