Three-ring architecture

@@ -8,21 +8,25 @@ quality: complete
short_description: "The durable composition pattern for the PointSav platform: three concentric rings with strict one-way dependencies, where the AI ring is structurally optional and the deterministic data pipeline operates fully without it."
status: active
bcsc_class: public-disclosure-safe
last_edited: 2026-05-15
last_edited: 2026-05-22
editor: pointsav-engineering
cites: []
paired_with: three-ring-architecture.es.md
---

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.
Before a regulated organization buys an AI platform, it has to answer one question: can AI silently touch the authoritative record? On most platforms the answer is procedural — a policy, a configuration flag. A flag can be flipped, and a policy is only as strong as its enforcement.

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.
PointSav answers the question architecturally. <!--claim id=three-rings confidence=structural cites=[]-->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 processing — function fully without the outer AI ring.<!--/claim-->

<!--claim id=ai-optional-by-construction confidence=structural cites=[]-->Rings 1 and 2 contain no import, no dependency, and no runtime call that reaches Ring 3. A deployment can exclude Ring 3 entirely; where Ring 3 is included, it is a read-only consumer that produces proposals, never record writes.<!--/claim-->

For a regulated buyer the verification is structural rather than procedural. A deployment without Ring 3 has no AI to audit; a deployment with it keeps the deterministic core as the sole authoritative record. This article covers the ring layout, the service taxonomy, the multi-tenant isolation model, and why AI is optional by construction.

## Ring layout

```
 Ring 3 — Optional Intelligence
 service-slm + Yo-Yo (multi-cloud burst)
 service-slm + GPU burst orchestrator
 + Tier C external API integration
 ↓ queries (read-only)
 Ring 2 — Knowledge and Processing
@@ -35,10 +39,7 @@ This arrangement answers a compliance question that surfaces in every regulated 
 (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.
<!--claim id=directional-invariants confidence=structural cites=[]-->Ring 1 produces raw data and depends on nothing else. Ring 2 reads from Ring 1, writes structured records, and depends only on Ring 1. Ring 3 reads from Ring 2 and never writes to it.<!--/claim-->

## Service taxonomy

@@ -48,60 +49,58 @@ This arrangement answers a compliance question that surfaces in every regulated 
| 1 | [[service-people]] | Identity Ledger | Optional |
| 1 | [[service-email]] | Communications Ledger | Optional |
| 1 | service-input | Generic document ingestion | Optional |
| 2 | [[service-extraction]] | Deterministic parser (no AI; structured data never routes through Ring 3) | Required |
| 2 | [[service-extraction]] | Deterministic parser; structured data never routes through Ring 3 | Required |
| 2 | [[service-content]] | Taxonomy Ledger and knowledge graph | Required |
| 2 | [[service-search]] | Search index (Tantivy, DARP-compliant) | Required |
| 2 | [[service-search]] | Search index | Required |
| 2 | [[service-egress]] | Physical release valve | Required for output |
| 3 | [[service-slm]] | AI Gateway — the Doorman | Optional |
| 3 | (slm-yoyo) | Multi-cloud GPU burst orchestrator | Optional |
| 3 | GPU burst orchestrator | Ephemeral multi-cloud burst | Optional |

## 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.
Ring 1 is the per-tenant data boundary. Each service 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 Ring 1 data 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.
<!--claim id=ring1-mcp confidence=structural cites=[]-->Every Ring 1 service implements a Model Context Protocol server interface, and Ring 2 talks to Ring 1 as an MCP client. A customer who needs a new data source adds another MCP server without modifying any existing service.<!--/claim-->

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|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 reads from Ring 1 and produces structured knowledge: parsed records, knowledge graphs, classified entities, search indexes. <!--claim id=ring2-deterministic confidence=structural cites=[]-->All Ring 2 processing is deterministic, and a binding architecture decision prohibits AI from writing to the knowledge graph or the structured record stores. Ring 2 output is reproducible: the same Ring 1 input replays to the same result.<!--/claim-->

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.
An audit that questions a classification can replay the deterministic parse against the unchanged Ring 1 ledger and get the same answer. No AI variance enters the authoritative record. Ring 2 services are multi-tenant by `moduleId`: one process serves all tenants, and each tenant's knowledge graph and search index are isolated behind a `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.
<!--claim id=ring3-read-only confidence=structural cites=[]-->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; its only outputs are proposals — text the operator reviews, drafts the operator approves. Every accepted output enters the record through a Ring 2 write path with a human at the checkpoint.<!--/claim-->

`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.
`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, 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:
The three compute tiers available to Ring 3:

- **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.
- **Tier A — local.** A 7B-class model on the customer's own hardware. Zero marginal cost, full data locality. The default for most requests.
- **Tier B — GPU burst.** A larger model 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:
Tenant isolation varies by ring, by deliberate design.

- **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.
- **Ring 1** — hard isolation by service instance. Each tenant's boundary ingest runs as a separate process with separate storage. No code path reaches from one tenant's Ring 1 data to another's.
- **Ring 2** — logical isolation by `moduleId`. One process, one set of indexes, strict namespace separation at every read and write. A query for tenant A cannot return tenant B's records.
- **Ring 3** — a single `service-slm` instance with per-`moduleId` adapter loading. The Doorman writes the `moduleId` into every audit-ledger entry.

## 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.
The three-ring pattern makes AI optional by construction, not by configuration. A deployment that excludes Ring 3 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.
For a deployment that includes Ring 3, the read-only constraint keeps the deterministic core as the authoritative record. An operator auditing AI involvement in any output inspects the audit-ledger entry for the Doorman call, compares the proposal against the Ring 2 record it drew from, and confirms that no AI path modified the underlying structured data.

## See also

- [[compounding-substrate]] — the five structural properties that the Three-Ring Architecture implements
- [[compounding-substrate]] — the five structural properties 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
- [[architecture-decisions]] — the binding decisions that govern how rings interact and where AI is permitted