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 · f25eaab1

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

Capability-based security

Correction — rehedged to planned/intended (2026-07-30): this article originally described a live, enforced capability system in unhedged present tense. No matching code exists today: neither a single-archive check nor a subsequent broader cross-archive sweep (grep for "capability manager"/CapabilityManager across every .rs file in all ~25 Totebox archives) found any implementation; moonshot-hypervisor — the crate that would house a hypervisor-mediation layer — is a 4-file scaffold with an empty dependency list. This is consistent with the separately-confirmed finding that seL4 itself is not yet running anywhere in the platform today. Per operator direction, this describes real, intended design rather than a fabrication — the body below is rewritten to present it as planned/intended architecture, not current state.

Capability-based security is the access-control model PointSav is designed to use at the hardware and operating-system layers, where each software component will be required to hold a mathematically verified cryptographic token to communicate with any other component. This is a planned architecture, not yet implemented.

Capability-based security is the access-control model intended to replace traditional operating-system privilege hierarchies in the PointSav platform, once implemented. Where conventional operating systems (Windows, macOS, Linux) grant broad permissions through administrative accounts and assume components at the same privilege level can be trusted, the design calls for each isolated component to hold an explicit, mathematically verified cryptographic token — called a capability — before it can communicate with any other component. A capability would be unforgeable and uncopyable, granted by the kernel at process start and revoked when withdrawn. 1 The intended effect is that the blast radius of any compromise is mathematically bounded to the components the compromised process held capabilities for. See also the capability ledger substrate and pairing as permission.

Overview

Standard operating systems are vulnerable to privilege escalation: a single compromised application can, in many architectures, reach the core memory of the host machine and gain access to other components on the network. The capability model is designed to eliminate this class of vulnerability at the architecture level rather than through policy controls.

The PointSav implementation is planned to build on a microkernel foundation. In the intended design, the microkernel would handle only the most primitive routing of physical memory and CPU time, with every driver, network interface, and service process running in isolated memory and none holding general administrative rights. To communicate with another isolated component, a process would present a cryptographic capability token, which the kernel would validate before permitting or denying the operation. As of this writing, no such implementation exists — no capability-manager code, isolation-wrapper, or hypervisor-bridge crate was found anywhere in the monorepo, and seL4 itself is not yet running in any shipped component.

Architecture (planned)

The intended capability layer would sit between the seL4 microkernel and the Rust service processes that make up the PointSav Ring 1 and Ring 2 services, with Rust-based capability managers engineering the isolation wrappers and hypervisor bridges that mediate communication between components.

The design calls for a strict, one-way command flow between isolation domains: an isolated edge delivery process — for example, the MediaKit OS — would be unable to issue commands back into the secure ToteboxOS vault, so a compromised edge process would be contained within its own memory sandbox with no capability grants reaching the broader system, enforced by the kernel rather than a policy document.

Intended properties

  • Formal verification. The seL4 microkernel that would underlie the capability manager is formally verified in Isabelle/HOL 2 as a kernel in its own right — meaning the isolation properties of seL4 itself are mathematically proven, independent of whether PointSav's own capability-manager layer has been built on top of it.
  • Least privilege by default. Intended: components start with no capabilities; the system grants only the minimum set required for their declared function.
  • Blast-radius containment. Intended: compromise of one component could not propagate to components it holds no capability grants for.
  • Auditability. Intended: capability grants would be recorded, with the set of grants in force at any time inspectable.

How it is intended to work

At deployment time, a PointSav capability manager would read a system policy file declaring which processes communicate with which others and what operations each is permitted. The microkernel would enforce this policy at runtime. No such capability manager or policy-file mechanism exists today.

Intended applications

Once built, the capability model is intended to apply across the full PointSav deployment stack:

  • ToteboxOS — the primary secure vault OS; data at rest would be accessible only to processes holding the appropriate capability token.
  • MediaKit OS — the edge delivery environment; intended to hold no capability grants reaching ToteboxOS, so a compromised delivery node could not reach stored data.
  • service-fs — the WORM ledger; append capability would be granted to Ring 1 ingest services only.

See also

  1. Lampson, B. W. 'Protection.' ACM SIGOPS Operating Systems Review, 8(1):18–24, 1974. https://dl.acm.org/doi/10.1145/775265.775268 ↩

  2. Klein, G. et al. 'seL4: Formal Verification of an OS Kernel.' ACM SOSP, 2009. https://dl.acm.org/doi/10.1145/1629575.1629596 ↩

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 →