Design System Contract reference

A design system's rules usually live where code tools can't read them: a docs site, a Figma library, a component package's source. So an AI coding agent guesses. It invents variant names, fills in props, and builds lookalike components.

The Design System Contract writes those rules down as data. One JSON file per component says which props exist, what type each one is, which values are legal, and what the defaults are. A manifest lists those files and records a content address for each one. Both formats have JSON Schema 2020-12 schemas, so any stock validator can check them.

A design system isn't documentation to consult. It's a contract to check against. These pages are the lookup: every member, every rule, every constraint.

format v0.1 spec 0.11.0

Reference topics

Schemas and examples

FileContents
schemas/v0/component.contract.schema.jsonJSON Schema 2020-12 for the component contract
schemas/v0/manifest.schema.jsonJSON Schema 2020-12 for the manifest
examples/button-primary.contract.jsonA valid component contract
examples/manifest.jsonA valid manifest listing the example contract

These reference pages render the schemas in readable form. Where prose and a schema disagree, the schema is correct.

Schema identifiers resolve to this site

The schema $id values under https://knapsack-oss.github.io/design-system-contract/schemas/v0/ are served from this site, so a validator can fetch them by $schema. See schema identifiers.

At a glance

ItemValue
Component contract required memberscontractId, component
Manifest required memberscontractVersion, artifacts
contractId pattern^[a-z0-9]+(-[a-z0-9]+)*$
Address pattern^sha256:[0-9a-f]{64}$
origin valuesinferred, synced
Additional membersNot permitted on the contract root, props, a prop schema, a slot record, slot accessibility, the manifest root, or an artifact record. props.properties is a map whose keys are prop names.
LicenseApache-2.0