Interactive route
perfectUse the interactive route to explore this foundation live.
foundations / proof system
Proof System
DK docs expose proofs alongside examples so the system shows what it can guarantee, not just what it can render.
Principles
Core principles
These are the design-system rules this foundation should reinforce.
- A design system should tell you what it knows, not just show you a pretty example.
- Proofs should stay close to components so regressions are visible to humans and tests.
- Curated fixtures beat exhaustive noise when the goal is trust.
Model
How DK models it
This section connects the concept to the actual DK math and token pipeline.
- Each component registration includes curated proof fixtures built from the same token and recipe pipeline.
- Docs pages surface tokens, proofs, and live examples from one shared source of truth.
- E2E coverage keeps both stage screenshots and docs pages stable across preset changes.
Practice
How to use it in product work
These are the decisions designers and engineers should make with this foundation in mind.
- Use the proof section to understand what a component is guaranteeing today.
- Use the slot-var section when integrating components into product code or debugging theme output.
- Treat proofs as a collaborator for code review, not an optional appendix.
Proofs
What the proof layer guarantees
These are the reliability claims DK makes about this foundation today.
- Proof fixtures remain visible on every component page and fail tests when regressions land.
- The docs registry test fails if components lose required docs metadata or proof integration.
- Stage screenshot coverage ensures visual stability even as page structure evolves.
Token notes
- The proof system is inseparable from the compiled token and recipe pipeline.
- Docs productization keeps the proof layer accessible to both designers and engineers.