See Versioning & deprecation for the decided part of this page.
Known issues
Gaps in the current rules
- No token deprecation mechanism exists. No field, no marker, no convention — verified,
not assumed: no token carries a deprecation marker (zero matches across
primitives,
semantic, component, and typography source files), and the token manifest has no
lifecycle field (each entry is name, tier, axis, $type, and values — no status,
no since, no deprecated, no replacedBy). See
the open decision above.
- No component deprecation convention is documented either, though the component pages
carry a
tag in frontmatter that could hold one.
- No breaking-change policy. What counts as breaking at the token layer — a value change,
a rename, a removal — is not stated.
- No supported-version window. How long a consumer can stay behind is undecided.
- No migration-guide convention. When a name changes, nothing says where the old-to-new
mapping is published.
Constraints Titan should enforce
These are real, currently-true rules. Nothing in code stops a builder from violating them today — each is a placeholder for a guardrail Titan hasn’t built, not a decision still being made.
Last modified on September 17, 2026
