Four-tier SLM substrate ladder

@@ -27,9 +27,9 @@ The ladder is the operational form of the platform's designed-for-breakout princ

## Tier 0 — API Gateway Abstraction

At Tier 0 the Doorman operates as a pure API gateway. No language model runs locally. The Doorman holds the customer's keys for whichever Tier C external service they have configured, routes requests through a per-purpose allowlist, and logs every call to the local audit ledger.
At Tier 0 the [[compounding-doorman|Doorman]] operates as a pure API gateway. No language model runs locally. The Doorman holds the customer's keys for whichever Tier C external service they have configured, routes requests through a per-purpose allowlist, and logs every call to the [[worm-ledger-architecture|local audit ledger]].

Tier 0 is available on any hardware that can run ToteboxOS. It is appropriate for solo operators, community contributors, and customers evaluating the platform before committing to local hardware. The Ring 1 and Ring 2 services — all deterministic knowledge and processing — function fully without a language model at Ring 3. Intelligence is optional.
Tier 0 is available on any hardware that can run [[totebox-orchestration|ToteboxOS]]. It is appropriate for solo operators, community contributors, and customers evaluating the platform before committing to local hardware. The Ring 1 and Ring 2 services — all deterministic knowledge and processing — function fully without a language model at Ring 3. Intelligence is optional.

## Tier 1 — Local Edge Inference

@@ -37,13 +37,13 @@ At Tier 1 the customer runs OLMo 3 7B Think locally. A consumer GPU with 8 GB of

Tier 1 is the baseline for SMB Customer deployments. It provides offline-capable narrow AI participation and selective access to larger inference capacity, without giving up data locality for routine operations.

At Tier 1, the customer's per-tenant LoRA adapter training is available. A first adapter can be trained on a corpus of roughly 1,000 to 5,000 high-quality preference pairs from the customer's own operational history. That adapter lives on the customer's ToteboxOS instance and does not leave it unless the customer explicitly opts into the federated marketplace. [^1]
At Tier 1, the customer's per-tenant LoRA adapter training is available (see [[adapter-composition]]). A first adapter can be trained on a corpus of roughly 1,000 to 5,000 high-quality preference pairs from the customer's own operational history. That adapter lives on the customer's [[totebox-archive|ToteboxOS instance]] and does not leave it unless the customer explicitly opts into the [[sovereign-ai-commons|federated marketplace]]. [^1]

## Tier 2 — Vendor-Hosted Burst Compute

At Tier 2 the vendor operates a 32B model on a GPU burst instance with idle-shutdown discipline. From the customer's perspective, this is a Tier C service accessed by their local Doorman — a hosted endpoint that handles requests the local 7B model is not well-suited to. From the vendor's perspective, it is the same infrastructure the vendor uses for its own heavyweight inference tasks, made available to customers as a subscription service.

The Tier 2 model is OLMo 3.1 32B Think. At runtime, a composition of adapters is applied per request: a constitutional adapter reflecting current platform doctrine, an engineering adapter trained on accumulated platform corpus, and tenant-specific adapters where applicable. No external API keys are held by the inference engine itself; key custody remains exclusively at the Doorman boundary.
The Tier 2 model is OLMo 3.1 32B Think. At runtime, a [[adapter-composition|composition of adapters]] is applied per request: a constitutional adapter reflecting current platform doctrine, an engineering adapter trained on accumulated platform corpus, and tenant-specific adapters where applicable. No external API keys are held by the inference engine itself; key custody remains exclusively at the Doorman boundary.

The pricing structure is intended to sit structurally below that of fully-managed AI platforms requiring annual contracts in the six-figure range. This is a planned commercial position, not yet published rate-card pricing.

@@ -51,25 +51,25 @@ The pricing structure is intended to sit structurally below that of fully-manage

Tier 3 is a planned standalone AI service trained via continued pretraining on the vendor's aggregated multi-tenant corpus. It is not a LoRA adapter applied to a base model — it is a new base model, produced by following the published AI2 continued-pretraining recipe: 100 billion tokens of midtraining, long-context extension, and post-training alignment. [^2]

The intended result, at the planned scale of 32B parameters, is a model with deep operational familiarity with the PointSav platform: archive deployment and configuration, standard editorial patterns, code generation aligned to platform conventions, and the mechanics of federated contribution. It would operate as a multi-tenant API service, accessible from customer Doorman instances via a per-customer authentication token with the same shape as any Tier C external key.
The intended result, at the planned scale of 32B parameters, is a model with deep operational familiarity with the PointSav platform: [[totebox-archive|archive]] deployment and configuration, standard editorial patterns, code generation aligned to platform conventions, and the mechanics of [[sovereign-ai-commons|federated contribution]]. It would operate as a multi-tenant API service, accessible from customer [[compounding-doorman|Doorman]] instances via a per-customer authentication token with the same shape as any Tier C external key.

Tier 3 incorporates a structured escalation path: queries the model cannot handle with adequate confidence are flagged for human review. Human responses to flagged queries are captured as training signal that feeds the next continued-pretraining cycle, closing the loop between customer support and model improvement.
Tier 3 incorporates a structured escalation path: queries the model cannot handle with adequate confidence are flagged for human review. Human responses to flagged queries are captured as training signal that feeds the next continued-pretraining cycle, closing the loop between customer support and model improvement (see [[apprenticeship-substrate]]).

The first PointSav-OLMo-N continued-pretraining run is planned to begin in 2027, subject to corpus accumulation targets and operational readiness. The timeline carries material uncertainty.

## Cryptographic Boundary Custody

A single rule applies across all tiers: API keys are held only at the Doorman boundary. No downstream service, no inference engine, and no Ring 2 process holds a vendor key. The Doorman is the single point of key custody, the single point of call auditing, and the single point of per-purpose allowlist enforcement. This matches the consensus pattern for production AI gateway deployments in 2026.
A single rule applies across all tiers: API keys are held only at the [[compounding-doorman|Doorman]] boundary. No downstream service, no inference engine, and no Ring 2 process holds a vendor key. The Doorman is the single point of key custody, the single point of call auditing, and the single point of per-purpose allowlist enforcement. This matches the consensus pattern for production AI gateway deployments in 2026.

## Non-Destructive Tier Transitions

Tier graduation is additive. Moving from Tier 0 to Tier 1 adds local hardware and the first LoRA training cycle. Moving from Tier 1 to Tier 2 adds the burst subscription. Moving from Tier 2 to Tier 3 adds the specialist service subscription. At each graduation, the capabilities of the lower tier remain fully functional.

Downgrading is equally clean. A customer who drops the Tier 3 subscription retains their local Tier 1 substrate. Their LoRA adapters, their audit ledger, and their knowledge graph remain on their own hardware. This is the structural guarantee that the commercial relationship is about capability, not captivity.
Downgrading is equally clean. A customer who drops the Tier 3 subscription retains their local Tier 1 substrate. Their LoRA adapters, their audit ledger, and their [[knowledge-graph-grounded-apprenticeship|knowledge graph]] remain on their own hardware. This is the structural guarantee that the commercial relationship is about capability, not captivity (see [[customer-hostability]]).

## Unclaimed Market Positions

The federated LoRA marketplace — where customers contribute privacy-preserved adapter signal to a commons that improves the base for all participants — has no shipping commercial analogue in 2026. All technical components (privacy-preserving federated learning frameworks, differential privacy primitives, adapter-only exchange protocols) are mature. The marketplace with payment rails is an unclaimed position.
The [[sovereign-ai-commons|federated LoRA marketplace]] — where customers contribute privacy-preserved adapter signal to a commons that improves the base for all participants — has no shipping commercial analogue in 2026. All technical components (privacy-preserving federated learning frameworks, differential privacy primitives, adapter-only exchange protocols) are mature. The marketplace with payment rails is an unclaimed position.

The open-substrate customer-service specialist — a domain-expert AI accessible at per-token pricing within reach of SMB contract values, built on a fully open model base — is also unclaimed in 2026. Managed AI services for the customer-service vertical operate at price floors that structurally exclude PointSav's target market. Tier 3 as described is intended to occupy this gap, pending the continued-pretraining timeline above.