A regulated deployment of PointSav can operate without any AI component — not by flipping a configuration flag, but because the platform's architecture makes AI structurally optional from the ground up. The Three-Ring Architecture organises every service into one of three concentric rings with strict one-way dependencies. The two inner rings — boundary ingest and deterministic knowledge processing — function fully without the outermost ring, which adds AI inference and can be excluded entirely.

This arrangement answers a compliance question that surfaces in every regulated procurement: how does a buyer verify that AI has not touched the authoritative record? The answer is architectural rather than procedural. Rings 1 and 2 have no import, no dependency, and no runtime call that reaches Ring 3. A deployment that excludes Ring 3 runs fewer processes, exposes less attack surface, and satisfies the network-isolation requirements common to regulated financial and property operations. For deployments that include Ring 3, the read-only constraint on AI ensures that the deterministic core remains the sole authoritative record — AI proposals enter the record only after a human approves them through the platform's mandatory checkpoint.

Ring layout

                 Ring 3 — Optional Intelligence
                 service-slm + Yo-Yo (multi-cloud burst)
                 + Tier C external API integration
                          ↓ queries (read-only)
                 Ring 2 — Knowledge and Processing
                 service-content + service-extraction
                 + service-search + service-egress
                          ↑ feeds              ↓ writes
                 Ring 1 — Boundary Ingest (per-tenant)
                 service-fs + service-people
                 + service-email + service-input
                 (data flows in; per-tenant; MCP servers)

Directional invariants:

• Ring 1 produces raw data and depends on nothing else.
• Ring 2 reads from Ring 1 and writes structured records; it depends only on Ring 1.
• Ring 3 reads from Ring 2 and never writes to it. Ring 1 and Ring 2 function without Ring 3.

Service taxonomy

Ring 1 — Boundary Ingest

Ring 1 is the per-tenant data boundary. Each service in this ring accepts raw data from one external source — the filesystem, an email inbox, a document upload, an identity provider — and writes it to a durable ledger. No data in Ring 1 is transformed or classified; it is only stored.

Every Ring 1 service implements a Model Context Protocol (MCP) server interface. Ring 2 talks to Ring 1 services as MCP clients. A customer who needs a new data source adds an additional MCP server without modifying any existing service. The MCP boundary is what makes Ring 1 extensible without coupling.

Because Ring 1 is per-tenant, each tenant's data lives in a separate service instance with its own storage root. There is no shared state between tenants at this ring.

Ring 2 — Knowledge and Processing

Ring 2 reads from Ring 1 and produces structured knowledge: parsed records, knowledge graphs, classified entities, search indexes. All Ring 2 processing is deterministic. One of the platform's binding architecture decisions prohibits AI from writing to the knowledge graph or the structured record stores; those paths are exclusively Ring 2's.

The practical effect: Ring 2 output is reproducible given the same Ring 1 input. An audit that questions a classification can replay the deterministic parse against the unchanged Ring 1 ledger and get the same result. No AI variance enters the authoritative record.

Ring 2 services are multi-tenant via moduleId. One process handles requests for all tenants, but the knowledge graph and search index for each tenant are logically isolated behind their moduleId namespace.

Ring 3 — Optional Intelligence

Ring 3 is a single read-only consumer of Ring 2. It never writes to the knowledge graph, the ledger, or the structured record stores. The only outputs Ring 3 produces are proposals: text the operator reviews, drafts the operator approves, suggestions the operator accepts or discards. Every accepted output that enters the authoritative record passes through a Ring 2 write path with a human at the checkpoint.

service-slm is the single Ring 3 service. It implements the Doorman pattern: every request enters through one boundary, which sanitises outbound data, routes among the three compute tiers (local, GPU burst, external API), and logs every call to the per-tenant audit ledger. No API key lives outside the Doorman boundary.

The three compute tiers available to Ring 3 are:

• Tier A — local: OLMo 3 7B running on the customer's own hardware. Zero marginal cost, full data locality. Default for most requests.
• Tier B — GPU burst: OLMo 3.1 32B Think on a short-lived GPU instance. Used when Tier A cannot handle the request shape efficiently. The customer controls when it starts and stops.
• Tier C — external API: external vendor APIs used only with an explicit per-request allowlist. Every call is logged at the customer's audit ledger.

Multi-tenant isolation model

Tenant isolation varies by ring in a deliberate pattern:

• Ring 1: hard isolation by service instance. Each tenant's boundary ingest runs as a separate process with separate storage. There is no code path from one tenant's Ring 1 data to another's.
• Ring 2: logical isolation by moduleId. One process, one set of indexes, with strict namespace separation at every read and write path. Queries for tenant A cannot return records for tenant B.
• Ring 3: single service-slm instance with per-moduleId LoRA loading. The Doorman enforces audit-ledger writes that include the moduleId on every call.

Why AI is structurally optional

The three-ring pattern makes AI optional by construction rather than by configuration. Rings 1 and 2 have no import, no dependency, no runtime call that reaches Ring 3. A deployment that excludes Ring 3 entirely ships fewer processes, exposes less attack surface, and satisfies network-isolation requirements that prohibit external API calls.

For deployments that include Ring 3, the read-only constraint means the deterministic core remains the authoritative record. Operators who want to audit AI involvement in any output can inspect the audit ledger entry for the relevant Doorman call, compare the proposal against the Ring 2 record it was drawn from, and confirm that no AI path modified the underlying structured data.

See also

• compounding-substrate — the five structural properties that the Three-Ring Architecture implements
• service-slm — the Ring 3 Doorman service that routes among compute tiers and logs every call
• compounding-doorman — the operational pattern the Doorman implements and why it compounds over time
• worm-ledger-architecture — the Ring 1 append-only ledger that underpins the audit guarantee
• apprenticeship-substrate — how Ring 3 interactions generate training signal that improves the local model over time
• architecture-decisions — the twelve binding decisions that govern how rings interact and where AI is permitted