Skip to content
PointSav Digital Systems

Last updated · e7f56415 · Español

Federation via content mounts

Federation via content mounts

The content-federation pattern combines two complementary authoring modes in a single wiki instance: curated editorial articles committed directly to the knowledge repository, and declarative mounts that pull content from domain-specific repositories. The two modes share a URL surface, navigation chrome, and search index while keeping their source repositories independent. This pattern is planned for Phase 6 of app-mediakit-knowledge; the single-repository model is the current deployed form.

The hybrid model

A deployed wiki instance is configured by a knowledge.toml manifest at the content directory root. The manifest declares zero or more mounts alongside any articles committed directly to the repository. Both sources render into the same URL namespace; readers encounter no visible distinction between a curated article and a mounted article.

Direct commits are the correct choice for content that is editorial in nature — platform reference articles, design-system notes, governance documents — where the knowledge repository is the canonical home and editing flows through the standard staging-tier commit path. Declarative mounts are the correct choice for content that originates in a domain-specific repository — per-project documentation, per-deployment operational records, architectural decision records — where the source repository is the canonical home and the wiki is a read surface over it.

How mounts work

A mount entry in knowledge.toml is intended to specify four elements:

  • Source repository. A git remote URL or a local path that the engine can pull.
  • Mount path. The local directory path under which the fetched content is placed.
  • Blueprint. The named schema that validates and routes files in the mount.
  • Edit URL template. A URL pattern the engine uses to construct the "edit this page" link for mounted articles, routing editors back to the source repository rather than accepting writes locally.

The engine is intended to fetch the source repository on startup and on a configured refresh interval, write fetched content to the mount path, and process it identically to directly committed articles.

Blueprints

A blueprint is a named schema that constrains what content a mount may contain. Two blueprints are intended to be built in:

topic. The standard wiki article format. Files must conform to the content contract's frontmatter schema and body conventions. Rendered at /:category/:slug and included in the primary article index and search.

guide. Operational documents addressed to practitioners. Rendered with a distinct chrome that emphasises procedural steps over prose sections. Excluded from the primary article index but discoverable via search and the guide catalog.

Operators are intended to register additional blueprints as plugins when Phase 6 ships. Candidate domain-specific blueprints include regional-market (structured location articles), adr (architectural decision records with a fixed decision/status/context schema), and changelog (time-ordered release notes). Each plugin blueprint would define its frontmatter schema, the URL pattern it occupies, and the chrome template it uses.

Per-instance isolation

Each wiki instance is intended to read only the mounts declared in its own knowledge.toml. Two instances sourcing the same repository may present entirely different article sets depending on their mount configurations. There is no global mount registry — isolation is a configuration property of the instance, not a coordination problem.

This isolation property is what allows a single canonical content repository to serve multiple distinct wiki deployments. The content repository is the source of truth; each deployment is a view over it shaped by its mount manifest.

Provenance and edit-routing

Every article rendered from a declarative mount is intended to carry provenance fields in its frontmatter:

  • source_repo — the remote URL of the source repository.
  • source_path — the file path within the source repository.
  • edit_url — the URL the engine renders as the "edit this page" link.

The edit_url is intended to route editors to the canonical editing path in the source repository rather than accepting writes locally. This keeps the source-of-truth inversion intact across a federated content surface: a mounted article's canonical home is the source repository; the wiki instance is a read surface over it, not a second canonical store.

Relationship to source-of-truth inversion

This pattern is intended to extend source-of-truth-inversion from a single-repository topology to a multi-repository topology. The invariant is the same: git is canonical; the running binary is a view. The extension is that "git" may be one of several named repositories, each the canonical home for its domain, and the wiki instance a view over all of them simultaneously.

The federation model is not intended to introduce a central coordination layer. Each source repository is autonomous; the mount manifest is a per-instance declaration; and the engine's fetch-and-render pipeline is stateless with respect to source repositories.

See also

Important Information

Important Information

Corporate structure. PointSav Digital Systems ("PointSav") is a trade name of Woodfine Capital Projects Inc. ("Woodfine"). 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. See TRADEMARK.md in this repository for the full trademark notice.

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 →