Product design and specifications
Start with the product, then follow the system beneath it. These retained specifications describe the full original ERP direction; current implementation evidence is in RELEASE-STATUS.md.
| Subject | Contract |
|---|---|
| Product and shared systems | System, object map, architecture, schema |
| Interaction and workflow | Interaction, journeys, implementation |
| Catalogue and interpretation | Catalogue, product sheet, parsing |
| Quantity and stock | Units, stock lots |
| Documents and physical work | Outputs, paper, QR |
| Runtime and intelligence | AI, intelligence, runtime, Copilot |
| Channels and source access | Connections, source privacy, voice |
| Cedar’s concrete workspace | Product, operations hub, onboarding |
| Native collection | Payments, Money, service |
The product brief and shared kit explain the interaction language. New code should use their actual components and semantic tokens. Product visuals come from those rendered components, with source and capture evidence; the artwork library keeps its generation/normalization records.
Specifications distinguish an intended system from an adopted/wired capability. Follow their relevant source and the release’s current proof before claiming provider acceptance, a connected UI/backend path or a completed intelligence module.