Foundations

Terminology

Canonical terms give designers, developers, tools, and documentation one vocabulary for authority, assembly, behavior, targets, and delivery.

Design and contract terms

TermDefinition
BrandA complete design identity containing token primitives, identity assets, and design-language choices.
Primitive tokenA raw design value in a Brand's token graph.
Semantic tokenA token named for design intent that references a primitive or another governed token.
Component tokenA token scoped to a Component role or part and resolved through semantic intent.
Component contractThe normative machine-readable public definition of one reusable Component.
ComponentA reusable UI type whose identity and public surface are owned by its Component contract.

Sources for block 1: product-brand-term, product-primitive-token-term, product-semantic-token-term, product-component-token-term, product-component-contract-term, design-tokens-format

Assembly and behavior terms

TermDefinition
CompositionA target-neutral declarative representation of assembled UI. It is not a synonym for Component and is not owned by Studio.
Composition bodyThe versioned assembly embedded in a Component contract when Composition is that Component's implementation strategy.
ScreenAn application-owned Composition that is a navigation destination.
ShellAn application-owned Composition that persists across navigation and hosts Screens through an Outlet.
OutletThe distinguished Shell slot where the active Screen renders. Outlet is a planned contract/Layout-DSL primitive; until it exists in the schema, Shells are describable but not machine-expressible.
BehaviorA reusable declarative statechart with typed events, inputs, context, states, actions, and outputs.
Behavior bindingThe typed join between Component events or Composition inputs and one Behavior instance's events, state, context, and outputs.

Sources for block 1: product-composition-term, product-screen-term, product-shell-term, product-outlet-term, product-behavior-term, studio-composition

Collection and target terms

TermDefinition
CatalogThe authoritative collection of Component contracts, implementations, Behaviors, and generated projections under one manifest identity.
Private CatalogA Catalog whose visibility or distribution is restricted; it uses the same artifact model as a shared Catalog.
TargetA declared implementation environment, primarily React or Flutter.
ProjectionA deterministic target-specific or tool-specific artifact derived from authored authority.
ParityConformance of declared targets to the same contract and obligations, proven by validation rather than identical source.
StudioThe visual workbench for editing and reviewing governed design-system artifacts and their projections.

Sources for block 1: product-catalog-term, projection-norms, studio-composition

Delivery terms

TermDefinition
VisibilityThe policy controlling who can discover or read an authority or carrier.
DistributionA versioned channel that carries an artifact to another workspace or application.
PublicationThe deliberate release of a validated version through a distribution channel.
ProvenanceEvidence connecting a released artifact to its exact source revision, generator, compatibility facts, and immutable carrier.
AvailabilityThe current support state of a capability or acquisition path; normative definition alone does not imply release.

Sources for block 1: product-catalog-term, catalog-bundle