Language-protocol substrate

@@ -5,10 +5,10 @@ slug: language-protocol-substrate
category: substrate
type: topic
quality: complete
short_description: "The Language-Protocol Substrate is the Foundry editorial infrastructure that provides four adapter families, eighteen genre templates, a frontmatter validator, and a banned-vocabulary list, making editorial work a per-tenant, audited, and forkable practice."
short_description: "The editorial infrastructure that encodes register, brand voice, document sub-type, and target audience as reusable prompt scaffolding — four adapter families, eighteen genre templates, a frontmatter validator, and a four-service split that lets a customer replace any single component without touching the rest."
status: active
bcsc_class: public-disclosure-safe
last_edited: 2026-04-30
last_edited: 2026-05-15
editor: pointsav-engineering
cites:
 - ni-51-102
@@ -16,10 +16,13 @@ cites:
paired_with: language-protocol-substrate.es.md
---

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.

> The Language-Protocol Substrate is the Foundry editorial infrastructure that provides four adapter families, eighteen genre templates, a frontmatter validator, and a banned-vocabulary list, making editorial work a per-tenant, audited, and forkable practice.
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` (knowledge graph), `service-slm` (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.

**The Language-Protocol Substrate** is a cross-cutting architecture pattern in the Foundry platform. It carries four families, eighteen genre templates, and a four-service split that lets a customer replace any single component without touching the rest. The substrate makes editorial work in Foundry an audited, per-tenant, forkable practice by encoding register, brand voice, document sub-type, and target audience as reusable prompt scaffolding rather than ad-hoc instruction. This article explains what it does, why it exists, and how it composes with the other Foundry substrates.
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

@@ -30,7 +33,7 @@ The substrate provides four artefacts:
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 Foundry 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.
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

@@ -51,14 +54,14 @@ Three adapters compose at request time:

```
composed_weights =
 base_model
 ⊕ tenant_adapter[<tenant_id>] // brand voice
 ⊕ protocol_adapter[PROSE | COMMS | LEGAL | TRANSLATE]
  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). Foundry stays at three.
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. This is the Writer Brand IQ pattern and the Jasper brand-voice configuration — fewer adapters, richer scaffolding, retrieval grounding, decode-time constraints. The 2026 industry consensus.
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

@@ -73,26 +76,24 @@ 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.

This matches Microsoft's synced-versus-federated-connector framing, LangChain's swappable-retriever pattern, and llama-agents' independently-deployable-microservice approach. Foundry's contribution is the per-tenant audit ledger that makes the substitution composable across regulatory contexts.
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

The standard 2024–2026 pattern, drawn from Pinecone, Microsoft 365 Copilot Semantic Index, and AWS Bedrock Knowledge Bases, is namespace-per-tenant inside one service instance — not separate per-tenant deployments.

For Foundry: one `service-content` instance per Foundry deployment, with `moduleId` partitioning Woodfine, PointSav, and future 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 Foundry instance in their own substrate and get their own `service-content` there.
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.

## Configuration

Eight editorial task-types are defined in the project-language 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.
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 Foundry-shaped 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 substrate.
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

- [[style-guide-topic]]
- [[style-guide-readme]]
- [[customer-hostability]]
- [[anti-homogenization-discipline]]
- [[apprenticeship-substrate]]
- [[citation-substrate]]