Operating rules
Contracts
Design contracts turn principles into reusable operating rules for artifacts, interfaces, and review.
Designesy Contracts are portable design agreements that let people and agents carry design judgment across tools, sessions, codebases, and artifacts. They make design judgment inspectable — not reliant on slogans or vibes.
Why contracts matter
The question a contract answers
What exact value should I use? Why does this value exist? Where may this value be applied? What behavior does this component need? What should I avoid? How do I know if I broke the system?
A useful contract helps a future agent or team member answer all of these without relearning the design system from scratch. Contracts are the operational bridge between philosophy and execution.
Contract contents
A Designesy Contract should include all of the following — structured values for machines, rationale for humans, and verification criteria for both.
- Source and provenance
- Primitive tokens
- Semantic tokens
- Typography rules
- Spacing and layout rules
- Shape and surface rules
- Component behavior and states
- Accessibility requirements
- Motion and reduced-motion guidance
- Anti-patterns
- Implementation notes
- Verification criteria
- Open tensions
Contract discipline
Keep upstream-compatible schema names visible when compatibility matters: colors, typography, rounded, spacing, components. Use local extensions for doctrine, review, provenance, agent instructions, and verification — but do not hide the standard contract from tools.
Anti-patterns
- Prose-only style guides with no exact values
- Token dumps with no rationale
- Component values that duplicate raw colors instead of referencing roles
- Rules that do not change implementation behavior
- Public copy pretending the contract is more mature than it is
- Treating screenshots as final proof without visual and accessibility checks