In the Design Tokens Community Group format, how is a token's type resolved without $type, and why must tools not guess it?

## Why tokens need an unambiguous type In the **Design Tokens Community Group format**, a token's **type** tells every tool how to read and use its value: a translation tool converts a `dimension` into each platform's size unit, a design editor shows a color picker for a `color`, a documentation tool renders a swatch or a type specimen. The draft says tokens always have an unambiguous type, and every token must end up with one of the types the format defines. ## The resolution order When a token omits `$type`, tools determine it like this: 1. **Explicit `$type` on the token** - highest precedence. 2. **The referenced token's type** - if the value is a reference such as `{campaign.progress.fill}`, the token has the resolved type of the token it points at. 3. **The closest parent group's `$type`** - walk up the nesting and take the first group that declares one. 4. **Otherwise invalid** - if nothing above supplies a type, the token must be treated as invalid. And separately: if a token has a declared type but its value does not match that type's syntax, the token is invalid and tools should say so, much like a compile error for a mistyped variable. | Situation | Resolved type | |---|---| | token has `$type: duration` inside a group typed `dimension` | `duration` - explicit wins | | token has no `$type`, value `{donate.action-fill}` which is a color | `color` - from the target | | token has no `$type`, parent group has none, grandparent group typed `dimension` | `dimension` - closest typed ancestor | | no `$type` anywhere, literal value | invalid | ## Why guessing from the value is forbidden The format tells tools not to attempt to infer a type from a token's value. Several reasons make that rule essential: - **Shapes overlap.** A plain number could be a `number` (a unitless line height) or a `fontWeight`. A dimension and a duration are both an object with a numeric value and a unit. A string could be a font family name or a stroke style such as `dashed`. - **Tools would disagree.** If one tool guessed that `400` was a weight and another that it was a plain number, the same file would produce different outputs in the design editor, on the web and in the native apps. Interchange only works if every reader gets the same answer. - **Errors would hide.** A token meant to be a dimension but written without a unit is an error the author should see. A guessing tool would quietly accept it as a number. ## Groups type nothing by name Groups are for organisation, and the format says tools should not use them to infer the type or purpose of tokens. So a group **named** `color` or `spacing` does not type its children. Only a group that **declares** `$type` passes it down. Two practical consequences: - Setting `$type` once on a group of related tokens - every step of a charity site's spacing ladder, every duration for the donation confirmation animation - removes repetition and keeps each child's value checked against the type. - Moving a token to a different group can change its inherited type silently. A careful team either states `$type` on tokens that could be moved, or validates the file after every restructure. ## A charity example A charity's token file has a group `motion` with `$type: duration`, holding `thanks-reveal` and `progress-fill`. Both inherit `duration`. A contributor adds `progress-easing` to the same group with a curve as its value; the file now fails validation because a curve is not a duration. The fix is an explicit `$type: cubicBezier` on that token, or a separate group. Nobody had to guess, and the error surfaced at the point it was made. ## What to take into an interview The order - explicit, reference target, closest typed group, else invalid - and the reason behind the ban on guessing: a shared file must mean one thing to every tool that reads it, on every platform.