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

Last updated · 1eb3bbcc · Español

Single-boundary compute discipline

The Single-Boundary Compute Discipline is the structural rule that all AI inference traffic in a platform deployment passes through one and only one boundary point: the Doorman (service-slm). No process, session, or service reaches an inference tier — local, GPU burst, or external API — except through this boundary.

It is not a preferred-path routing convention that allows bypass by configuration; it is enforced at the kernel and secret boundaries so that no other process on the system can reach inference compute.

Why one boundary

A single boundary makes four properties structurally guaranteed rather than policy-dependent:

Audit completeness. The audit ledger records every inference call. An operator asking "did AI touch this record?" inspects the ledger and receives a definitive answer. If bypass were possible, the ledger would have gaps — and a gapped ledger is inadmissible as a compliance record.

Corpus completeness. The apprenticeship substrate captures every Doorman-mediated call as a training tuple. Bypass produces no shadow brief. The training corpus has gaps, and those gaps permanently degrade the quality of the per-tenant adapter that accumulates from the corpus.

Cost control. Budget caps and kill-switches operate at the Doorman boundary. Bypass routes around the cap. A deployment with a monthly inference budget has no enforceable budget if bypass is possible.

Sovereignty. API keys for external providers and the bearer token for GPU burst capacity live exclusively in the Doorman's environment. No other process holds these credentials. When a key is rotated or revoked, the change happens in one place.

What actually enforces the boundary today

Bearer-only-in-Doorman. The GPU burst bearer token and external provider API keys are read from the Doorman's own environment; no cluster session holds them directly.

Loopback binding. The Doorman's default bind address is 127.0.0.1, not a network-reachable interface — a caller on the same machine can reach it, but nothing off-machine can, without a separate reverse proxy or port-forward the operator would have to set up deliberately.

Two mechanisms this article previously described as already enforced are not, currently, backed by code: a kernel-level, UID-scoped iptables rule restricting the local inference server to Doorman-process connections only, and a startup check that refuses to boot with a missing GPU burst bearer token. The real startup behavior defaults an unset bearer token to an empty string rather than refusing to start — a real gap between the intended discipline and what's enforced today, not a design choice. Firewalling the GPU burst instance to the Doorman's host IP is a real, standard cloud-networking control at the infrastructure level, independent of application code.

What callers send

The Doorman exposes a standard OpenAI-compatible HTTP interface. Callers — whether a task session, the operator TUI, or a customer-built agent — send requests to the Doorman's local binding. The Doorman selects the appropriate compute tier, assembles graph-grounded context (see Knowledge-graph-grounded apprenticeship), routes the request, records the audit entry, and returns the response.

This interface is also the MCP gateway endpoint (see MCP as substrate protocol). There is no separate path for MCP clients.

Relationship to the three-ring architecture

The Doorman is the entry point to Ring 3. The Three-ring architecture makes Ring 3 structurally optional — a deployment may operate without AI inference entirely and the deterministic Ring 1 and Ring 2 services remain fully functional. The single-boundary discipline is what makes that optionality safe: because all inference passes through one point, disabling that point produces a clean degraded state rather than a partially-bypassed one.

Composition

This discipline composes with several other substrate patterns. The Knowledge-graph-grounded apprenticeship depends on it: graph context is assembled at the Doorman before dispatch; bypass means ungrounded inference. The MCP as substrate protocol designates the Doorman as the MCP gateway; bypass breaks the MCP graph. The sovereign substrate enforces customer sovereignty at the Doorman boundary; bypass is a sovereignty leak.

See also

Cite this record: /wiki/single-boundary-compute-discipline — revision 1eb3bbcc, last updated 1 May 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 →