Language-protocol substrate

Every editorial action that passes through the PointSav platform — document generation, schema validation, training-tuple capture — is shaped by a substrate that encodes register, brand voice, document sub-type, and target audience as reusable prompt scaffolding rather than ad-hoc instruction. The result is editorial work that is audited, per-tenant, and replaceable at any layer without rebuilding the rest.

Correction (2026-08-02, verified against canonical origin/main): this article names service-disclosure and service-proofreader as real, shipped Rust crates (here and at 5 further places below, including a table attributing them to owner clusters "project-language"/"project-proofreader"). Neither crate exists anywhere in the monorepo — a corpus-wide grep for both names returns zero hits, and neither "project-language" nor "project-proofreader" appears in the current archive list. Real editorial-assist code exists only as app-console-content/src/proofreader.rs (a module, not a crate) and a local-proofreader.service systemd unit. This is presented in unhedged present tense, not as planned/intended — unlike this article's own correctly-hedged treatment of its training pipeline elsewhere. Flagged, not resolved — this article needs a structural rewrite around the real service boundaries, not a line-by-line fix.

The substrate provides four artefact families, eighteen genre templates, a frontmatter validator that returns all schema violations in a single pass, and a banned-vocabulary list of eight cross-genre prohibited terms. These ship as a Rust crate (service-disclosure) split across four services — service-content — entity extraction and knowledge-graph host (knowledge graph), AI inference service (Doorman and inference), service-disclosure (schema and templates), service-proofreader (HTTP write-assistant) — where any single service can be replaced by a customer-owned equivalent while the rest hold.

Three adapters compose at request time: base model, tenant adapter (brand voice), and protocol adapter (PROSE | COMMS | LEGAL | TRANSLATE). Register, brand voice, and target audience live as prompt scaffolding rather than additional adapters — five or more adapters per request crosses into multi-task interference per the 2025 LoRA literature; the platform stays at three. Every editorial action produces a verdict-signed training tuple through the Apprenticeship substrate pipeline, feeding continued pretraining on the customer's adapter without the customer's text leaving their infrastructure.

For regulated buyers, the four-service split matters because every editorial action is audited in the per-tenant ledger before it exits the customer's network. The customer can fork any adapter, inspect the prompt scaffolding, and verify that their brand voice is not pooled with another tenant's training data. Per [ni-51-102] and [osc-sn-51-721], the training pipeline is described in planned terms; the substrate architecture is operational today.

Overview

The substrate provides four artefacts:

1. A 4-family adapter taxonomy. PROSE for long-form English, COMMS for short-form interpersonal, LEGAL for volume-gated formal documents, TRANSLATE as a meta-protocol layered on top of any other family.
2. A genre-template registry. Eighteen templates, each carrying its required sections, register parameters, bilingual-pair convention, frontmatter schema, and prompt scaffolding.
3. A frontmatter validator. Returns every per-genre rule violation in one pass rather than first-fail.
4. A banned-vocabulary list. Eight cross-genre prohibited terms that survive in marketing prose and have no place in precise writing.

These four artefacts ship as a Rust crate (service-disclosure) that any platform component can consume. The Doorman composes the templates into prompts at request time; the per-tenant write-assistant validates inbound and outbound text against the schema; the apprenticeship pipeline produces verdict-signed training tuples on every editorial action.

Ring and Role

The Language-Protocol Substrate spans Ring 3 — Optional Intelligence (inference via the Doorman) and Ring 2 — Knowledge and Processing (schema validation and template management via service-content — entity extraction and knowledge-graph host and service-disclosure). It has no Ring 1 component: editorial work begins after boundary ingest completes. The substrate is activated on every editorial action that passes through the Doorman, whether that action is a document generation request, a validation pass, or a training-tuple capture.

Architecture

The four families

Three adapters compose at request time:

composed_weights =
  base_model
  ⊕ tenant_adapter[<tenant_id>] // brand voice
  ⊕ protocol_adapter[PROSE | COMMS | LEGAL | TRANSLATE]

Five or more adapters per request crosses into multi-task interference per the 2025 LoRA literature (LoRAX, S-LoRA, TC-LoRA, LoRI). The platform stays at three.

Register, brand voice, document sub-type, and target audience live as prompt scaffolding rather than additional adapters. Fewer adapters, richer scaffolding, retrieval grounding, decode-time constraints — this is the 2026 industry consensus for production editorial systems.

The four-service split

The editorial-write path runs through four services. Each owns one shape:

A customer can replace any one without touching the rest. Replace service-slm with a customer-owned GPU host while keeping service-content and service-disclosure. Replace service-content with a customer's existing knowledge graph while keeping service-slm. The contract between services is the only thing that needs to hold.

The platform's contribution to this pattern is the per-tenant audit ledger that makes each substitution composable across regulatory contexts — a replacement service produces the same audit trail the original produced.

Multi-tenant via moduleId namespacing

One service-content instance per platform deployment, with moduleId partitioning tenants inside. Per-tenant isolated deployment is the escalation path — when a customer needs key-management-per-tenant or stronger isolation, they spin up their own platform instance in their own infrastructure and get their own service-content there.

This is the meaning of "tenant escalation happens at the deployment boundary, not the service-naming boundary." The service stays multi-tenant; the deployment topology grows isolation when warranted.

Architectural grounding

The substrate sits on three interconnected mechanisms.

The foundry-draft-v1 schema is the frontmatter envelope every draft artifact carries. It requires a language-protocol field, a destination field, and a routing field — the machine-readable instructions the schema enforces at staging time. A workspace-level routing table maps each protocol value to a gateway project and destination; the table is the single source of truth for that mapping, so no archive hard-codes routing logic for another archive's artifacts. A mailbox message-prefix convention then carries the routing intent between archives: a staged draft generates an outbound message that a relay picks up automatically, with no manual hand-off step required.

The substrate differs from a content management system in two ways. It does not store content — content lives in git, in the receiving archive's tracked directories. It does not own routing logic — each gateway project implements its own pipeline against the incoming draft shape. The substrate makes content machine-routable across archives without requiring archives to know each other's internals. It also differs from a language-server protocol: a language-server protocol defines a real-time bidirectional session, while the substrate has no session state — the protocol declaration on a draft is a per-artifact stamp, made once at staging time, that travels with the artifact through every hand-off.

Why explicit protocol selection

The substrate's foundational design choice is to require the caller to declare a language protocol on every editorial request rather than auto-detecting one from the input. A 2023 Cornell University study on writing-style auto-detection found that automatically inferring style from input text narrows the range of voices a model produces — the detection step homogenizes output toward the model's expectation of the genre rather than the author's own register. Explicit selection sidesteps this: the operator declares the intended register at the request boundary, and the pipeline applies genre-specific rules from that declared position. The operator already knows what register they are writing in; the substrate reflects that knowledge structurally rather than inferring it.

Configuration

Eight editorial task-types are defined in the platform's editorial cluster manifest: prose-edit, comms-edit, frontmatter-normalize, citation-insert, register-tighten, cross-link-verify, schema-validate, template-author. Each generates verdict-signed training tuples through the Apprenticeship substrate pipeline. The tuples feed continued pretraining on the customer's adapter when corpus volume warrants.

Per [ni-51-102] continuous-disclosure language and in accordance with the forward-looking information principles of [osc-sn-51-721], the substrate's training pipeline is described in planned terms. The shape is in place; the operational throughput is what matures over time. The pipeline target: every editorial action a customer deployment performs is one tuple of training data for the customer's adapter. The customer's voice deepens over time without their text leaving their infrastructure.

See also

• Customer hostability
• Anti-homogenization discipline
• Apprenticeship substrate
• Citation substrate