Skip to content

PointSav Documentation

The engineering library for the PointSav platform — operating systems and services for regulated businesses that own their data, their AI, and their record-keeping outright. Where the monorepo holds the code, this wiki holds the reasoning: architecture, services, security, and the governance commitments that bind future development.

Design-system substrate

← All revisions

707ba31b · PointSav Digital Systems ·

editorial(substrate): fix design-system-substrate vault layout + MCP tool list (Track-B) — confirmed against app-privategit-design/src/vault.rs: real sections are elements/components/guidelines/developing/designing/about/research (no tokens/ or themes/ directories); confirmed real MCP tools (get_component_recipe/list_components/get_token/search_design_system/list_token_families) via mcp/tools.rs; register-clean EN+ES

View the full record as of this revision →

@@ -34,22 +34,17 @@ The substrate's content lives in a per-tenant vault directory:

```
<tenant-vault>/
├── tokens/ DTCG primitive + semantic + component layers
├── components/ HTML+CSS+ARIA recipe files
├── themes/ per-brand semantic-layer overrides
├── research/ AI-readable design-decision rationale (markdown)
└── exports/ derived caches (Figma, Tailwind, Style Dictionary)
├── elements/    DTCG token layers, nested per slug
├── components/  HTML+CSS+ARIA recipe files, nested per slug
├── guidelines/  usage and accessibility guidance, nested per slug
├── developing/  engineering-facing reference (flat)
├── designing/   design-facing reference (flat)
├── about/       substrate-level documentation (flat)
├── research/    AI-readable design-decision rationale (markdown, flat)
└── exports/     derived caches (Figma, Tailwind, Style Dictionary)
```

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.

**Correction (2026-08-02, verified against canonical `origin/main`):** the real vault
layout (`app-privategit-design/src/vault.rs`) is `elements/`, `components/`,
`guidelines/`, `developing/`, `designing/`, `about/`, `research/`, plus a generated
`exports/` output directory — there is no `themes/` section anywhere in the codebase,
and `tokens/` is not a top-level vault directory name. This looks like an earlier
design aspiration that diverged from what actually shipped, not a stale-but-once-true
snapshot. **Flagged, not resolved.**
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 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-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]`.

@@ -73,13 +68,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-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.

**Correction (2026-08-02, verified against canonical `origin/main`):** the real MCP
tool list (`app-privategit-design/src/mcp/tools.rs::list_tools()`) is
`get_component_recipe`, `list_components`, `get_token`, `search_design_system`,
`list_token_families` — only `list_components` matches; `list_tokens`,
`list_research`, and `describe` do not exist. **Flagged, not resolved.**
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 `get_component_recipe`, `list_components`, `get_token`, `search_design_system`, and `list_token_families`. 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.

@@ -100,7 +89,7 @@ The customer chooses the editor; the substrate does not require a particular one

The substrate imports IBM Carbon's primitive token vocabulary as the floor layer of every new instance. Color naming follows Carbon's convention (`gray-10` through `gray-100`). Type scale follows Carbon's productive and expressive families. Spacing follows Carbon's 8px grid. Focus ring follows Carbon's WCAG 2.2 AAA-conformant style.

Brand-specific work happens at the semantic layer (`themes/<brand>/`), not the primitive layer. SMB customers extend with brand overrides without re-learning a new component taxonomy.
Brand-specific work happens at the semantic token layer, not the primitive layer. SMB customers extend with brand overrides without re-learning a new component taxonomy.

Carbon was chosen for three reasons: familiarity surface (wide accessible-design muscle-memory footprint among practitioners), accessibility floor (WCAG 2.2 AAA conformance built into primitive choices), and permissive licensing on the form (Carbon's token values are publicly documented; IBM Plex is permissively licensed; the naming convention is a documentation artefact, not a trademarked asset).

@@ -110,7 +99,7 @@ A planned future milestone may introduce an alternative primitive bottom — Unt

## Sovereign Forking Procedure

An SMB customer forks by cloning the source repository, building the substrate engine (a native Rust binary), initialising a vault from the canonical template, editing their brand's semantic layer in `themes/<smb-brand>.json`, and running the bootstrap script to configure the service and TLS. The operator runbook at `vault-privategit-design/GUIDE-deploy-design-substrate.md` covers the full procedure.
An SMB customer forks by cloning the source repository, building the substrate engine (a native Rust binary), initialising a vault from the canonical template, editing their brand's semantic token layer, and running the bootstrap script to configure the service and TLS. The operator runbook at `vault-privategit-design/GUIDE-deploy-design-substrate.md` covers the full procedure.

The customer ends up with a fully self-hosted, customer-owned design-system substrate. No SaaS dependency. No hyperscaler runtime. Their theme files and any research entries they author are their work product, in their Git repository, signed by their key.

Important Information

Corporate structure. PointSav Digital Systems ("PointSav") is currently a trade name of Woodfine Capital Projects Inc. ("Woodfine"), planned to become a wholly-owned Woodfine subsidiary upon incorporation. PointSav does not itself offer, sell, or solicit any security. Any securities offering associated with Woodfine's real-property direct-hold solutions is made exclusively by Woodfine, and only by means of the applicable Private Placement Memorandum.

No investment advice. This wiki's content is provided for engineering, operational, research, and development purposes. Nothing on this wiki constitutes investment advice or a solicitation to invest in any Woodfine partnership or direct-hold solution.

Intellectual property. The PointSav name, trade name, wordmark, and marks, together with all current and future PointSav- and Totebox-branded products, services, and offerings — and the software, source code, documentation, design system, and all related materials — are proprietary to Woodfine and its affiliates, except for components identified as open source. No rights are granted except as expressly set out in a written license or agreement. The full trademark notice appears in the footer of every page on this site.

Open source components. Portions of the platform are made available under permissive open-source licenses identified in the accompanying repository. Use of those components is governed by their respective license terms.

No warranty; informational use. Content on this wiki is provided for general informational purposes only and does not constitute a representation, warranty, or commitment with respect to product functionality, availability, pricing, or roadmap. Some articles describe planned or intended features, capabilities, and milestones — language such as "planned," "intended," "targeted," "may," and "expected" marks this forward-looking content, which is subject to change and does not constitute a commitment regarding future performance.

Confidentiality. Where an article describes an operational or deployment detail that is not intended for public disclosure, that article is not published on this wiki. Content here is general-purpose engineering documentation, not customer-specific configuration.

Jurisdiction. Woodfine Capital Projects Inc. is organized in British Columbia, Canada. References to the Sovereign Data Foundation on this wiki describe a planned or intended initiative only, not a current equity holder or active governance body.

Changes to this notice. PointSav may update this notice from time to time; the version posted on this page governs.

Not a filing system. This wiki is not a securities filing system, an electronic disclosure repository, or a substitute for SEDAR+ or any other regulatory filing system. Formal securities filings are made through the applicable regulatory filing system, not through this wiki.

Full disclaimer. This notice supplements, and does not replace, the full Disclaimers article. In the event of any conflict, the full Disclaimers article governs.

Read the full disclaimer →