PointSav-LLM

@@ -7,7 +7,7 @@ type: topic
content_type: topic
quality: complete
index_group: compute-tiers
short_description: "The planned vendor-tier specialist AI model for substrate-sovereign SMBs — Tier 3 of the Four-Tier SLM Substrate Ladder, built by continued pretraining of the OLMo 3 32B base model (not the Think variant earlier text named — AllenAI has not published a 32B-Think variant)."
short_description: "The planned vendor-tier specialist AI model for substrate-sovereign SMBs — Tier 3 of the Four-Tier SLM Substrate Ladder, built by continued pretraining of the OLMo 3 32B base model."
status: active
bcsc_class: public-disclosure-safe
last_edited: 2026-08-17
@@ -19,7 +19,7 @@ paired_with: pointsav-llm.es.md

---

**PointSav-LLM** is the planned Tier 3 specialist AI model in [[pointsav-overview|PointSav]]'s [[four-tier-slm-substrate|Four-Tier SLM Substrate Ladder]] — the vendor-trained layer that is intended to emerge from continued pretraining of the OLMo 3 32B base model (Apache 2.0) on the platform's federated, multi-tenant [[apprenticeship-substrate|apprenticeship corpus]]. Internal engineering documentation describes this specifically as CPT of the 32B **base** model, not a "32B Think" variant — AllenAI has not published a Think variant at the 32B size, so that framing in earlier text was not just imprecise but referred to a model that does not exist. It is not an active product. It is a planned trajectory: a first continued-pretraining (CPT) cycle is currently targeted for v0.5.0, Q1 2027, with a productized deployment currently targeted for v1.0.0, Q4 2027. When operational, PointSav-LLM is intended to serve small and medium-sized businesses that require a specialist model trained on PointSav conventions, [[totebox-archive|Totebox Archive]] operations, and multi-tenant editorial patterns — without requiring the infrastructure investment or minimum-spend commitments that closed-source enterprise AI products impose.
**PointSav-LLM** is the planned Tier 3 specialist AI model in [[pointsav-overview|PointSav]]'s [[four-tier-slm-substrate|Four-Tier SLM Substrate Ladder]] — the vendor-trained layer that is intended to emerge from continued pretraining of the OLMo 3 32B **base** model (Apache 2.0) on the platform's federated, multi-tenant [[apprenticeship-substrate|apprenticeship corpus]]. It is not an active product. It is a planned trajectory: a first continued-pretraining (CPT) cycle is currently targeted for v0.5.0, Q1 2027, with a productized deployment currently targeted for v1.0.0, Q4 2027. When operational, PointSav-LLM is intended to serve small and medium-sized businesses that require a specialist model trained on PointSav conventions, [[totebox-archive|Totebox Archive]] operations, and multi-tenant editorial patterns — without requiring the infrastructure investment or minimum-spend commitments that closed-source enterprise AI products impose.

*All capability descriptions, timelines, pricing structures, and performance targets in this article are forward-looking. They are planned or intended, not current operational facts. Actual outcomes depend on corpus growth rate, model performance, engineering capacity, and market conditions. [ni-51-102] [osc-sn-51-721]*

@@ -51,22 +51,6 @@ The planned access path routes entirely through each customer's local [[doorman-

1. Customer application sends a query to the local [[doorman-protocol|Doorman]] (127.0.0.1:9080 by default).
2. Doorman classifies query complexity using the current Tier A local model (OLMo 3 7B Q4).

**Correction (2026-08-17, citation fixed — the underlying finding was real, the prior
citation to `service-slm/NEXT.md` was not; no file by that name exists anywhere in the
monorepo).** The Tier A model name genuinely is inconsistent across the real engineering
source, confirmed by direct search, not by wiki cross-referencing alone: the canonical
registry (`service-slm/data/base-registry.yaml`) sets `allenai/OLMo-3-7B-Instruct` as
Tier A — matching this article and the Four-Tier table below — but several other real
docs disagree with the canonical registry and with each other: `docs/topic-claude-code-
sovereign-routing.md`, `docs/guide-activate-anthropic-shim.md`, and `docs/topic-tos-
training-constraints.md` all say "OLMo 2 1B," while `docs/guide-post-commit-training-
hook.md` and `crates/adapter-hub/src/lib.rs` say "OLMo-2-7B." [[learning-datagraph-
architecture]]'s own prior "OLMo-2 7B Q4" claim has since been corrected there to match
the canonical registry (OLMo 3, not OLMo 2) — this article's "OLMo 3 7B Q4" was already
right. The underlying inconsistency in the engineering docs themselves is real and still
unresolved — **flagged, not resolved** — needs project-totebox confirmation of which
non-canonical doc references should be updated to match `base-registry.yaml`.
3. For queries classified as simple or routine, the Doorman routes to Tier A and returns a local response — no external call.
4. For queries classified as requiring specialist depth (domain-specific platform conventions, [[totebox-archive|Totebox Archive]] operations, multi-tenant editorial structure), the Doorman is intended to route to the PointSav-LLM Tier C endpoint, authenticating via the customer's provisioned API key.
5. The response returns through the Doorman. An audit row is written simultaneously at the customer's local Doorman and at the PointSav-LLM gateway — two-ledger, per-call audit trail.
@@ -90,7 +74,7 @@ PointSav-LLM is intended to carry explicit confidence signalling. When the model

The customer's Doorman, on receiving this envelope, is intended to surface an escalation prompt to the end user — for example, "Ask a PointSav engineer." The customer does not see the raw confidence score; they see a product-level prompt tuned to their configured language and escalation SLA.

This exact JSON shape does not exist in code today, which is expected for a Tier 3 product that has no operational state — but a differently-shaped, currently-real mechanism for a related, distinct purpose is worth noting as design precedent: `slm-core/src/apprenticeship.rs` already gates internal agent apprenticeship trajectories on `self_confidence: f32` and an `escalate: bool` flag, threshold `APPRENTICE_ESCALATE_THRESHOLD = 0.5`. That mechanism governs whether an AI session's own attempt gets escalated to a senior reviewer inside this workspace — it is not a customer-facing PointSav-LLM response envelope, and should not be cited as evidence this feature is built. It is evidence the general pattern (confidence score → threshold → escalation) already has one working implementation to design the customer-facing version against.
This response envelope does not exist in code today, consistent with a Tier 3 product that has no operational state. A related, distinct mechanism already runs elsewhere on the platform: internal agent apprenticeship trajectories are gated on a confidence score and an escalation threshold, deciding whether an AI session's own attempt gets escalated to a senior reviewer inside the workspace. That mechanism is not a customer-facing PointSav-LLM response envelope, but it is a working precedent for the same pattern — confidence score, threshold, escalation.

### Escalation events as training data

@@ -102,9 +86,9 @@ Escalation events are planned to become training data. A resolved escalation —
| L2 | Human-in-the-loop escalation | Remaining automated queries |
| L3 | Engineering-tier escalation surfaced from unresolved L2 | Edge cases |

All percentages are planned targets, not current operational data — and unlike most other figures in this article, no design document or prototype was found backing the specific ~80–90% split; treat it as illustrative rather than a sourced estimate until one exists.
All percentages are planned targets, illustrative rather than sourced estimates.

**Related, currently-real infrastructure, for a different tier of the commercial ladder.** `crates/adapter-hub/src/lib.rs` implements substantial, working LoRA/adapter infrastructure today — but it serves customer-tenant and commit-graph adapters (the commercial ladder's Tier 1/2), not the Tier 3 CPT model this article describes. It's the closest thing to "something has already been built" in this space, and worth knowing about, but it answers a different question than PointSav-LLM's own readiness.
Related infrastructure already runs today for a different tier of the commercial ladder: working LoRA/adapter infrastructure serving customer-tenant and commit-graph adapters (Tier 1/2 of the commercial ladder), not the Tier 3 CPT model described here.

---

@@ -161,7 +145,7 @@ PointSav-LLM occupies Tier 3 of the planned Four-Tier SLM Substrate Ladder. The 

Tiers 0, A, and B are operational today. Tier C (PointSav-LLM) is planned, with no operational state at the time of this article. The Doorman's routing logic for Tier C is planned infrastructure; its current state is Tier A/B routing only.

**A real distinction this table's own "0/A/B/C" numbering blurs.** The engineering source (`slm-core/src/tier.rs`) uses `InferenceRoute` (`Local`/`Yoyo`/`External`) for the technical compute tiers this table calls A/B/C — and its own code comment explicitly warns this naming is chosen "to avoid colliding with the unrelated customer-facing commercial tier ladder (Tier 0/1/2/3)." That commercial ladder (the Open/Paid-C/Paid-C+ pricing tiers described later in this article) is a genuinely separate numbering scheme from the technical A/B/C compute-routing tiers, even though this table's single "0/A/B/C" column visually merges them into one ladder. Worth keeping distinct in any future revision of this table, not collapsing further.
The technical A/B/C compute-routing tiers in this table and the customer-facing commercial 0/1/2/3 pricing ladder (the Open/Paid-C/Paid-C+ tiers described earlier) are two separate numbering schemes that happen to share digits — not the same ladder, even though this table's single "0/A/B/C" column visually merges them.

---