auri

Atoms and catalogs

The obvious question about auri's architecture: why ship curated catalogs instead of a bag of atoms you compose yourself? Because our components have two consumers — and the second one is a language model with a context window.

Every component is an atom

Under the hood, auri is atoms-first: every component is independently importable (import { Stat } from '@aurilabs/ops'), tree-shakeable, free of cross-component dependencies, and drawing from the same @aurilabs/core tokens. And atoms live once — if a future catalog needs a component another one has, it references the same atom, never a fork.

Why atoms alone aren't enough

A human developer browses docs and imports what they need. An agent can't — it only speaks a vocabulary that has been taught to it, in its system prompt, before the conversation starts. That changes the economics of "just pick what you want":

  • Context is a budget. Every component in the prompt-pack costs tokens on every request, forever.
  • Choice dilutes reliability. Models emit small, coherent vocabularies cleanly; sprawling menus breed prop confusion and hallucinated components. Our emission gate measures this on every change.
  • Trust is a set property. "These twelve components, taught by this exact pack, emit cleanly across model families" is a claim about the collection — it can't be inherited by an untested hand-rolled subset.

A catalog is the answer to all three at once: the subset an agent needs, taught coherently (one intent scale, one action idiom, shared rules), evaluated as a set, versioned at a stable URL that agents can cache.

A catalog is three thin artifacts over the atoms

  • The contract — a JSON Schema scoping exactly this set of components.
  • The prompt-pack — the teaching text for exactly this set, evals included.
  • The registration — one object handing the set to the renderer.

That's it. The catalog isn't a wall around the atoms; it's the packaging that makes them teachable and testable for models.

Catalogs mix — by design, today

Mixing is the protocol's sanctioned mechanism, not a special case:

const catalog = createCatalogRegistry([basicCatalog, opsCatalog /*, formsCatalog */]);

Components from every registered catalog coexist on one surface — the console on this site's front page mixes basic-catalog layout with ops components in every frame. A future forms catalog slots in identically.

ops, concretely

ops is short for operations: the vocabulary agents use to report, monitor, and ask permission — stats, charts, tables, timelines, logs, approvals. It's the first catalog because it's the shape of nearly every agent-to-human conversation about work in progress.

Compose your own

The end state honors both instincts: curated catalogs as the front door, and the catalog composer for teams that want their own vocabulary — pick atoms across catalogs, get a generated contract, a merged prompt-pack, and an emission-eval run against your composition. Ownership of the vocabulary itself, with the same evidence behind it.