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.

PointSav Digital Systems

Revision as of · 3daa0bd3

Historical revision — this record as it stood on 3 August 2026, not the current version. View the current record →

os-orchestration: The Stateless Aggregation Layer

Correction (2026-08-02, verified against canonical origin/main): the elaborate capability-broker/federation/statelessness-enforcement architecture described below doesn't exist. The real os-orchestration/src/lib.rs is a 2-line placeholder scaffold ("SYSTEM EVENT: os-orchestration scaffold verified.") — no capability brokers, no federation model, no commercial-tier Ring logic. Its own README even names a different aggregation crate, app-interface-command, not the app-orchestration-exchange/app-orchestration-market names this article uses elsewhere. The "Yo-Yo GPU Broker" section is closer to accurate — app-orchestration-slm is real (crates/orchestration-slm/src/{allocation,fleet,yoyo_proxy}.rs, port 9180) — though it's framed differently in real code (a chassis connecting service-slm Doorman instances, not "a pool of GPU capacity from PPN + external providers"). Resolved 2026-08-03: the whole article is re-hedged to planned/intended language below; the Commercial Model section's Tier B revenue/metering claim — which this correction had not yet flagged as a separate defect — turned out to be misattributed to os-orchestration entirely and is corrected to name app-orchestration-slm (the real crate that actually implements per-tenant usage metering, crates/orchestration-slm/src/metering.rs, confirmed on origin/main) as the system that owns that model.

The PointSav platform is designed around a deliberate architectural boundary: an aggregation layer intended to coordinate work across Totebox Archives while holding no customer data, storing no keys, and writing nothing to any WORM ledger. This layer is planned as os-orchestration — today a registered but unimplemented scaffold crate, not a running system (see the correction above).

Understanding what os-orchestration is intended to be requires first understanding what it is designed not to be. It is not planned as a database, not a credential store, and not a custodian. Every archive in the PointSav network is designed to maintain its own isolated state — its own WORM audit trail, its own key material, its own DataGraph segment. os-orchestration is planned to sit above that layer as a coordinator: routing requests, enforcing capability boundaries, and brokering cross-archive work without ever touching the underlying data.

The Federation Model (planned)

Access between Totebox Archives is designed to be governed by Protection Domains (PDs). Each archive would run its own capability-broker PD, holding the only authority to grant or deny cross-Totebox access for that archive. The intended rule is strict: no application-layer PD would contact a Totebox directly. Every cross-archive request would pass through the capability-broker PD of the target archive, which would apply the per-org capability boundary defined for that organization.

os-orchestration is planned to operate on the federation tier, above the per-archive PDs — able to observe that a request exists and route it to the appropriate capability broker, but not to authorize the request itself. Authorization is designed to live where the data lives — in the archive.

This design is intended to reflect Capability Geometry at the federation layer. Each organization's data would be enclosed within a capability boundary that os-orchestration could not cross on behalf of another organization. A request from one organization would not be routable to another organization's archive by exploiting the aggregation layer — by design, not merely by policy, once built.

What Statelessness Is Intended to Mean for Trust

Statelessness is designed as a trust property, not merely an implementation detail. Because os-orchestration is intended to write nothing and store nothing, it would not be compellable to produce customer data it does not hold. Under this design, a subpoena directed at the aggregation layer would return nothing of substance, and a breach of the aggregation layer would expose routing topology, not content.

This is intended to stand in contrast to hub-and-spoke architectures where the hub accumulates session state, cached credentials, or derived data — designs where the hub becomes a target. In the planned PointSav model, the aggregation layer would be structurally inert with respect to customer data: the archives are the custodians; os-orchestration is intended as the switchboard.

Practically, this design intends for os-orchestration to carry no obligation under data residency or data custody regulations, with regulatory obligations attaching instead to the archives, which can be provisioned in specific jurisdictions. The aggregation layer, once built, is intended to be able to run anywhere.

The Commercial Model

The commercial structure of the PointSav platform is intended to follow a Rings model. The first two planned Rings of capability — the foundational services every Totebox would require to operate — are intended to be provided free of charge with each Totebox provisioning. This is meant to cover the local inference tier (Tier A), basic DataGraph access, and the standard service stack.

This section previously misattributed a working revenue and metering system to os-orchestration. It does not have one — os-orchestration is an unimplemented scaffold (see the correction above). The real Tier B usage-based revenue and metering model belongs to a different, real crate: app-orchestration-slm. app-orchestration-slm is a working "Yo-Yo broker chassis" (confirmed on canonical origin/main, port :9180) connecting Totebox Archives' service-slm Doorman instances to a shared Yo-Yo GPU fleet. It implements real per-tenant cost metering (crates/orchestration-slm/src/metering.rs): each inference request's cost is computed from measured inference time and a configured hourly USD rate, and recorded to a per-tenant ledger that a Tier B customer is billed against. Tier A — the free, local inference tier — is unaffected by this and requires no metering. If os-orchestration is ever built as an aggregation/federation layer, it may in principle route requests toward app-orchestration-slm's Tier B service, but the metering, billing, and revenue-accrual logic itself lives in app-orchestration-slm, not in os-orchestration.

The Yo-Yo GPU Broker

app-orchestration-slm is the real, working Yo-Yo GPU broker chassis (see the Commercial Model correction above), implementing on-demand GPU allocation and per-tenant metering today. When a Totebox Archive's service-slm Doorman submits an inference request that exceeds local Tier A capacity — either because the model is too large for the local hardware or because concurrent load has exhausted available compute — the request is routed to app-orchestration-slm's chassis.

The chassis connects to a Yo-Yo GPU fleet and routes the inference request, returning the result to the originating archive. The archive does not need its own GPU hardware for Tier B workloads; the chassis provides elasticity, and records the cost of each request against the requesting tenant.

The name reflects the design metaphor: compute capacity extends outward from the archive on demand and retracts when the request completes. No persistent GPU allocation is held by the archive between requests.

What This Is Intended to Mean at Deployment

When an operator eventually provisions an os-orchestration instance, the intent is that they would be deploying a routing and brokering surface, not a storage system. The provisioning checklist is designed to be shorter than for a Totebox Archive: no WORM storage configuration, no key provisioning beyond the TLS certificates that would be required for mutual authentication with the archives it serves, no data migration.

An os-orchestration instance is intended to be replaceable, scalable, or relocatable without data loss, because it is designed to hold no data. This property is meant to make the aggregation layer straightforward to operate: its failure modes would be limited to availability (it is unreachable) rather than integrity (its state has drifted or been corrupted).

For the same reason, os-orchestration is designed never to be the system of record for any business process. Operators who need to audit what happened — which archive processed which request, when, under whose authorization — would read the WORM ledger of the relevant Totebox Archive. The aggregation layer is intended to be absent from that audit trail except as a routing node.

Design Anchors

The intended design of os-orchestration draws on several architectural positions. The planned commercial structure, including the Rings model, sets the frame within which app-orchestration-slm's real on-demand GPU allocation and metering mechanism operates today — see the Commercial Model correction above for how that split actually works. The data marketplace provisions, if built, are intended to govern the per-org capability boundaries that would prevent cross-organizational data leakage. A WORM audit obligation is intended to apply to archives and to deliberately exclude the aggregation layer. The browser-facing orchestration surfaces (app-orchestration-exchange, app-orchestration-market) are intended to operate as the customer-visible face of the aggregation tier, once built.

Together these positions describe a platform where coordination is intended to be separated from custody. The design goal is for the aggregation layer to be effective precisely because it does not hold what it routes — though today, only app-orchestration-slm's piece of this picture is real.

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 →