Design-system substrate
enrich wikilinks: documentation substrate body (EN+ES) batch 2 of 4
@@ -24,7 +24,7 @@ The PointSav design-system substrate is a self-hosted, customer-owned design-sys Enterprise-scale managed design systems place tokens, components, and design decisions inside the platform provider's own infrastructure. The customer's theme files live in the vendor's storage; the vendor's continued operation is a dependency for every UI build. Enterprise SaaS tools in this space carry entry pricing that is prohibitive for SMB customers. The substrate inverts that pattern on three structural axes: the customer's design system lives in the customer's Git repository, signed by the customer's key, replayable into any tool; design-decision research lives in the same vault as the tokens and components, served through the same Model Context Protocol endpoint `[mcp-spec]` that AI agents use; and tokens are stored in the W3C Design Tokens Community Group (DTCG) format, keeping the substrate editor-agnostic by construction. The substrate inverts that pattern on three structural axes: the customer's design system lives in the customer's Git repository, signed by the customer's key, replayable into any tool; design-decision research lives in the same vault as the tokens and components, served through the same [[mcp-substrate-protocol|Model Context Protocol]] endpoint `[mcp-spec]` that AI agents use; and tokens are stored in the W3C Design Tokens Community Group (DTCG) format, keeping the substrate editor-agnostic by construction. ## Immutable Vault Architecture @@ -41,7 +41,7 @@ The substrate's content lives in a per-tenant vault directory: The vault is the only canonical layer. Rendered exports — Figma Variables JSON, Tailwind config, CSS variables, Style Dictionary builds — are derived caches recomputable from the canonical four directories above. The substrate engine is a stateless HTTP service that reads the vault from disk. Per-tenant isolation is achieved by running one engine process per tenant, each pointed at its own vault. Persistence above the vault filesystem is via the substrate's WORM ledger (service-fs). Token and component history is anchored monthly to Sigstore Rekor `[sigstore-rekor-v2]`, producing a customer-rooted Merkle log using the C2SP tlog-tiles format `[c2sp-tlog-tiles]`. The substrate engine is a stateless HTTP service that reads the vault from disk. Per-tenant isolation is achieved by running one engine process per tenant, each pointed at its own vault. Persistence above the vault filesystem is via the substrate's [[worm-ledger-architecture|WORM ledger]]. Token and component history is anchored monthly to Sigstore Rekor `[sigstore-rekor-v2]`, producing a customer-rooted Merkle log using the C2SP tlog-tiles format `[c2sp-tlog-tiles]`. ## Machine-Readable Context Backplane @@ -63,7 +63,7 @@ ai_consumption_hint: "When generating a button for a primary --- ``` The frontmatter is machine-readable; the body is prose-readable. AI agents consume the research through the substrate's MCP endpoint `[mcp-spec]` at decode time. Methods include `list_tokens`, `list_components`, `list_research`, and `describe`. An AI agent registers the substrate as an MCP server, then queries it during UI generation to align with the SMB's brand intent. The frontmatter is machine-readable; the body is prose-readable. AI agents consume the research through the substrate's [[mcp-substrate-protocol|MCP endpoint]] `[mcp-spec]` at decode time. Methods include `list_tokens`, `list_components`, `list_research`, and `describe`. An AI agent registers the substrate as an MCP server, then queries it during UI generation to align with the SMB's brand intent. Design systems that publish only token values and component shapes omit the rationale behind those choices. The substrate publishes both, in the same machine-readable tier, served through the same endpoint. @@ -104,7 +104,7 @@ The customer ends up with a fully self-hosted, customer-owned design-system subs **AI-readable research backplane in customer-owned form** requires per-customer hosting. A platform can publish its own design research; it cannot publish the SMB customer's research, because it does not host the SMB customer's design system. **Customer-rooted attestation.** The substrate's quarterly Trustworthy System Attestation combines the WORM ledger, Sigstore Rekor anchoring `[sigstore-rekor-v2]`, and per-tenant `allowed_signers`. The resulting attestation covers the customer's design data — not the platform provider's controls. **Customer-rooted attestation.** The substrate's quarterly [[capability-ledger-substrate|Trustworthy System Attestation]] combines the [[worm-ledger-design|WORM ledger]], Sigstore Rekor anchoring `[sigstore-rekor-v2]`, and per-tenant `allowed_signers`. The resulting attestation covers the customer's design data — not the platform provider's controls. **Editor agnosticism.** Commercial design-system platforms have an incentive to keep the customer in their editor ecosystem. The substrate has no such incentive — DTCG is the common denominator.