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.

Fleet aggregator

os-orchestration exists today as a registered, empty scaffold crate — its entire source is a placeholder status function, with no aggregation logic behind it. Everything this article describes is the intended design, not a shipped feature.

os-orchestration is planned as the commercial-tier operating system intended to let a single operator see, query, and command many Totebox archives at once. Where os-console connects to one os-totebox, os-orchestration is intended as the hub between an operator's Console and a fleet of Toteboxes — what an executive would view to see the position of every property in a portfolio, every entity in a holding company, or every project in a development pipeline, in a single unified answer to "what is the state of the entire estate, right now?" This article covers the intended design: what os-orchestration is planned to do, what it is designed to deliberately not do, how aggregation is intended to work, the commercial features planned for it, and when it would be deployed. None of this is built yet — see the correction above.

What it is designed not to do

os-orchestration is designed not to store raw records — to be stateless. The intent is that it would pull metadata from Toteboxes, synthesise a unified view, and present it through os-console, with raw data never leaving its Totebox. Under this design the aggregator would see only what the Totebox is permitted to expose.

This boundary is intended to be structurally important: even if os-orchestration were compromised, the underlying Toteboxes would remain sealed, since the aggregator is not meant to hold keys to the archives.

Where it is planned to sit in the product line

Component Role Licence model (planned)
os-console Operator-facing terminal AGPL-3.0-or-later source; free BETA today
os-totebox Data archive per entity FSL-1.1-ALv2 source-available now; converts to Apache-2.0 after 2 years; free BETA today
os-orchestration Fleet aggregator (planned) Proprietary per the monorepo LICENSE file's own directory table — though the crate's own Cargo.toml SPDX header currently states FSL-1.1-ALv2, an unresolved mismatch between the two declarations

The commercial line is intended to be drawn at the aggregator. The Console and the Totebox are intended to be free and freely transferable. The Orchestration aggregator is planned as the paid product — an individual operator managing one entity would never need it.

How aggregation is intended to work

The design intent is for os-orchestration to connect to Toteboxes through a capability-based protocol tunnelled through standard TLS at the edge — no specific protocol name is committed to code today. Inside the tunnel, the intended flow is:

  1. The aggregator would send a signed capability object granting permission to read a specific row of a specific Totebox for a fixed time window.
  2. The Totebox would verify the capability, run the query internally, and emit only the result — never the raw record.
  3. The aggregator would combine results from many Toteboxes into a single unified view.

If built as designed, promise pipelining and zero-copy memory mapping are intended to make the experience feel local even when Toteboxes are distributed across multiple regions.

The commercial features (planned)

Three capabilities are planned to be reserved exclusively to os-orchestration:

Feature What it is intended to enable
Aggregation Reading metadata from multiple Toteboxes simultaneously
Multi-tenancy Serving multiple operators against the same underlying fleet
Complex viewports Cross-archive dashboards — portfolio rollups, cross-entity reconciliation, executive summaries

These features are intended to be intentionally absent from the open os-console codebase — planned to live in the os-orchestration codebase and nowhere else, once built.

The Diode discipline (planned)

The design calls for os-orchestration to be able to issue commands downstream to the Toteboxes it manages, with Toteboxes unable to issue commands back up. The aggregator is intended to itself be a Diode subject: receiving commands only from os-console, never from a Totebox. This is designed to make lateral movement structurally impossible — a compromised Totebox would not be able to use the aggregator as a bridge to the operator's Console. The Totebox Orchestration article covers the coordination layer's provisioning and lifecycle management.

When it would be deployed

os-orchestration is planned as a commercial product for multi-entity operators. Single-entity operators managing one Totebox would not need it. Multi-entity operators — real-estate portfolios, public companies with subsidiaries, family offices with multiple holdings — would be the intended customer once the cognitive load of running separate Consoles against individual Toteboxes justifies the aggregator.

See also

Cite this record: /wiki/os-orchestration — revision f754176e, last updated 24 August 2026.

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 →