Adapter composition algebra

The Adapter Composition Algebra is the designed model for how AI intelligence will be assembled at request time in a PointSav deployment. Its central metaphor maps precisely to an operating system: the Doorman (AI inference service) is the kernel; LoRA adapters are processes; service-content — entity extraction and knowledge-graph host is the filesystem; the base model is firmware. The composition mechanism itself is not yet built — one adapter exists today, trained but not yet promoted to production — but the shape below is the substrate's committed target, not a hypothetical.

The algebra

At request time, the Doorman is designed to compose adapters by stacking onto the base model:

composed_weights =
 base_model[OLMo-3-7B-Instruct]
 ⊕ constitutional_adapter[doctrine_vM.m.p]
 ⊕ engineering_adapter[pointsav_vN]?
 ⊕ tenant_adapter[<tenant>_vK]?
 ⊕ role_adapter[master | root | task]
 ⊕ cluster_adapter[<cluster-name>_vJ]?

Where ? denotes an optional adapter loaded only when the request context applies. ⊕ is the LoRA-stacking operator — a rank-r delta added to the base model weights at runtime.

The composition is intended to be deterministic given the request context — no runtime decision about which adapters to use, only what the context determines.

Composing weights at runtime depends on an upstream llama.cpp capability that has not yet landed. Until it does, the fuse step returns a symbolic composed ID rather than merged weights — it wires the rest of the substrate together end to end without blocking on the missing piece. Only one adapter is registered today, evaluated but not yet promoted past that stage; the five-family typology below is the target shape the registry is built to hold, not its current population.

Adapter typology and routing rules

Adapter	Loaded when	Ownership
constitutional	Always — every platform deployment	Constitutional adapter; ships with the knowledge commons (Apache 2.0)
engineering	Request scope is "build or modify the platform"	Vendor-curated; offered to Customers via service contract
tenant	Request scope operates on tenant data	Inside Customer Totebox; per-tenant; never leaves customer storage
role	Request originates from a Master/Root/Task session	Universal across deployments; learned from doctrine and role-tagged trajectories
cluster	Request scope is a specific project cluster	Per-cluster; declared in the cluster manifest

The constitutional adapter is universal and is loaded by every platform deployment. The tenant adapter is strictly per-tenant and is produced and held inside the Customer Totebox. The engineering adapter ships with the Knowledge commons and service commerce and is not treated as private vendor IP.

Implementation

The algebra runs on production 2026 multi-LoRA serving infrastructure:

• LoRAX (Predibase) — multi-LoRA inference server; thousands of adapters per GPU; per-request hot-swap; per-tenant private adapters
• S-LoRA — adapter isolation per dynamic computation; shared static backbone via secure IPC; significant time-to-first-token reduction
• vLLM Multi-LoRA — hot-swap at request time without reloading the base model

PointSav's contribution is the composition pattern — which adapters compose, in what order, under what doctrinal constraint — not the serving layer itself.

Adapter versioning

Each adapter carries a name, a semver version, the doctrine version it was trained against, a provenance field naming the corpus shards it was distilled from, and a signature signed by the trainer's identity. A composed request must reconcile adapter versions. The default policy loads adapters whose doctrine_version matches the deployment's current doctrine_version. Version mismatch surfaces as an operational signal — the deployment's MANIFEST records the active doctrine version and the discrepancy becomes visible.

This solves AI drift at the substrate level: the model is verifiably aligned to a specific doctrine version, and any mismatch is a first-class observable rather than a silent degradation.

The OS-of-AI metaphor

The analogy maps precisely:

OS concept	AI concept	Platform artifact
Firmware	Pretrained base model	OLMo 3 7B / 32B GGUF
Kernel	Request router	Doorman (service-slm)
Process	Composable behavior unit	LoRA adapter
Filesystem	Structured knowledge	service-content (LadybugDB graph)
System call	Tool invocation	MCP server interface
Virtual memory	Per-tenant isolation	moduleId-keyed partitions
Kernel module	Cluster-scoped capability	Cluster adapter
User profile	Role boundary	Role adapter
Constitution / charter	OS license + principles	Constitutional adapter
Package manager	Adapter library + signing	data/adapters/ + signed manifests

Customers install and uninstall adapters as packages. Adapter signatures are verified before composition. Per-tenant isolation is enforced at the serving layer the way virtual memory isolation is enforced at the kernel layer.

This frames the substrate for small and medium businesses as the operating system of AI — composable intelligence with a flat architecture rather than a single closed product. Any adapter can be swapped without touching the others. The customer owns the adapters trained on their own corpus. The doctrine is the soul; the corpus is the mind; the adapters are the personality.

Practical composition ceiling

Production multi-LoRA research demonstrates that composing 2–3 adapters per request works cleanly. Composing 5 or more adapters per request crosses into multi-task interference. The algebra stays at a maximum of three runtime adapters per request by design. Register, brand voice, document sub-type, and target audience parameters live in prompt scaffolding (the genre template layer), not as additional adapters.

The Vendor LLM tier

When the Vendor's engineering corpus accumulates sufficient scale — planned for Year 2 or later, at version 0.5.0 onward — continued pretraining may produce a model whose capability crosses an inflection from SLM to a larger model. This larger model may be offered as a Doorman tier in Customer deployments alongside Tier C external APIs, under service contract. Customer Doormans would then be able to route to the Vendor LLM for queries that exceed local Tier A capacity and where Tier C is undesirable.

This tier is intended to be a byproduct of the substrate work as the corpus matures, not a separately developed product.

See also

• Compounding Doorman — the Doorman that implements the kernel role in this algebra
• Apprenticeship substrate — the mechanism that produces the per-tenant adapter corpus
• Language-protocol substrate — the language-family adapter taxonomy that extends this algebra for editorial work
• Knowledge commons and service commerce — how constitutional and engineering adapters are published as commons artifacts