What existed
A React application with OKLCH semantic variables, Instrument Sans, CVA button variants, Radix-based UI primitives and product-level scheduling patterns.
Corpus Design System / a chapter of the product case
One identity.
Many working contexts.
A semantic foundation for scheduling, professional identity and the different rhythms of the studio.
01 / SOURCE AUDIT
Start from the product.
The same class is an operational decision for staff, a quick attendance task on a tablet and a place in the student’s weekly routine. Identity must remain consistent while the task and density change.
What needed structure
The implementation had reusable parts, but the relationship between material palette, semantic roles and product patterns needed an inspectable documentation layer.
What this chapter adds
Fourteen documented components, a portable token contract and responsive role compositions. The existing product remains the source for operational rules and permissions.
The light palette follows the source’s documented color values. Corpus dark is a proposed documentation mode. The examples use fictional data and demonstrate presentation only; they do not implement product access control or write attendance.
02 / ARCHITECTURE
Make decisions
reusable.
A semantic layer keeps brand choices separate from component behavior. Product patterns compose primitives, and the consuming application owns its data and rules.
Preserve the material identity
Warm paper, olive, sage, sand and clay remain brand decisions. The portfolio’s square editorial shell does not overwrite the shape language inside product specimens.
Identity is not status
A professional’s color accompanies a name and stays distinct from availability, success or errors. ProfessionalTag and ClassSlot keep that distinction visible.
Show the decision together
Time, professional and capacity belong in one component. WeekStrip narrows the day first; ClassSlot makes the remaining place visible before selection.
Brand values → semantic roles → component tokens → product patterns 4px spacing base · 12 / 14 / 16 / 24 / 40px type roles 44px control targets · explicit light and dark alias sets
03 / LIVE DOCUMENTATION
Inspect the system.
Try the contract.
Select a component to inspect its properties, variants and states. Switch to Tokens to trace aliases, or Application to see the same library composed across screen sizes.
Loading the interactive component catalogue…
04 / IMPLEMENTATION & HANDOFF
A system needs
an adoption path.
The existing Corpus case specimen shares the light semantic roles through a scoped adapter. Team, tablet and student compositions below demonstrate presentation differences; permissions continue to belong to the real application and its server rules.
One contract, explicit responsibility.
Import the component and compiled tokens. Scope the brand and mode at the root of the product surface. Pass controlled state from the application, rather than letting a component talk to storage or infer permissions.
<div data-ds-brand="corpus" data-ds-mode="light">
<ClassSlot
time="09:00" teacher="Lia"
occupied={3} capacity={4}
selected={selected}
onSelect={chooseClass}
/>
</div>Review before adoption.
- Choose a representative product screen.
- Compare the existing styles with the semantic adapter.
- Verify contrast, labels, focus, disabled states and responsive behavior.
- Document intentional visual differences and migrate incrementally.
No Figma library is required. A future MCP integration is documented as a mapping proposal; no Figma connection or automated synchronization is claimed.