Trajectory substrate
Every commit to the platform's code repositories, every editorial session, every operator correction that marks a suggestion wrong — these interactions are not discarded. They are captured as structured JSONL tuples, tagged with provenance metadata, and routed into a training corpus whose accumulated signal improves the OLMo base model each time a continued-pretraining run closes — the mechanism behind the compounding substrate.
Three orthogonal corpus types determine the architecture. The constitutional corpus captures what the platform's governance charter says a session of each role may and may not do — universal, loaded by every platform deployment. The engineering corpus captures contributor session trajectories and is vendor-scoped. The tenant-runtime corpus captures what flows through Ring 1 inside each customer deployment and never leaves that deployment unless the customer explicitly opts into the federated adapter marketplace (a planned forward-looking feature).
Capture is automatic — no operator decision is required to generate a training tuple. Every JSONL record carries provenance fields (tuple_type, doctrine_version, tenant, role, scope, redaction_class) that let the training pipeline assemble each corpus without trusting prose. Vendor data never co-mingles with customer data at training time; tenant data never crosses tenants — the separation is directory-level and pipeline-level, not policy-level.
An operator's specific correction shapes their own cluster's adapter exclusively — no other tenant benefits or is burdened by it. This per-contributor inverse of aggregate preference learning is structurally inaccessible to platforms whose preference signal is averaged across all users. Per [ni-51-102] and [osc-sn-51-721], the continued-pretraining pipeline is described in planned terms; the capture infrastructure and corpus accumulation are operational today.
Overview
The Trajectory Substrate converts operational work into continued-pretraining signal without interrupting that work. It operates in the background of every commit, every session, and every operator feedback exchange.
Three properties distinguish a trajectory substrate from a generic fine-tuning pipeline:
- Capture is automatic. No operator decision is required to generate a training tuple. The
git post-commithook fires; the session-end script fires; the rejected-suggestion script fires. Work produces signal by existing. - Provenance is structural. Every JSONL record carries the governance version it was produced under, the tenant it belongs to, the role of the session, the cluster, and its redaction class. The training pipeline does not trust prose; it filters on these fields.
- Corpus boundaries are enforced by infrastructure. Vendor data never co-mingles with customer data at training time. Tenant data never crosses tenants. The separation is directory-level and pipeline-level — not policy-level.
Ring and Role
The Trajectory Substrate does not map to a single ring. Capture happens at every layer — Ring 1 runtime events, Ring 2 processing events, Ring 3 inference interactions, and deployment-level commit hooks. The substrate is the infrastructure that runs beneath all three rings per the Three-ring architecture, converting their operational outputs into training material. AI inference service (Ring 3) is the primary consumer of the resulting adapters at inference time.
Architecture
Three corpora, three adapter families
Three orthogonal corpus types are defined. Each produces a different adapter class. Mixing them is the failure mode.
Constitutional corpus
Captures what the platform's governance charter says a session of each role may and may not do. Lives at data/training-corpus/doctrine/<doctrine-version>/ within the deployment. Produces the constitutional adapter (constitutional-doctrine-vM.m.p.lora). Retrains on every platform MINOR version bump. Universal — loaded by every platform deployment, regardless of tenant.
The doctrinal basis is [constitutional-ai-2212-08073]: a model whose behaviour is governed by a written charter, not only by aggregate preference signal.
Engineering corpus (Vendor side)
Captures contributor session trajectories on vendor repositories: commit diffs, session logs, and governance amendments in flight. Lives at data/training-corpus/engineering/ in the vendor workspace. Tenant scope: PointSav only. Produces the engineering adapter (engineering-pointsav-vN.lora), which PointSav may offer as a "platform-builder personality" to customers via service contract.
Tenant-runtime corpus (per Customer)
Captures what flows through Ring 1 inside each customer deployment: service-fs, service-people, service-email, service-input events; curated graph deltas from service-content; operator usage trajectories. Lives inside the customer deployment instance at <deployment-instance>/training-corpus/<tenant>/. Never in the vendor workspace. Produces the tenant adapter (tenant-<tenant>-vK.lora) inside and held by the customer deployment.
Tenant adapters do not leave the customer's deployment unless that customer explicitly opts into the federated adapter marketplace (a planned forward-looking feature). This is structural privacy by infrastructure.
Capture mechanics
One capture script is live today: capture-edit.sh (service-slm/scripts/), installed as a git post-commit hook. It does not write a JSONL file directly — it posts the commit's diff (stat header plus unified 3-line context, truncated at 64 KiB) and commit message to the Doorman's shadow-brief endpoint (POST /v1/shadow), where it becomes the actual_diff field of the pending brief. It is a no-op when no brief is pending for that repository. It carries no redaction or PII-scrubbing step of its own — matching the already-established finding that outbound sanitization elsewhere in the platform covers only the apprenticeship-corpus write path this script feeds, not a separate, general-purpose redaction layer.
The remaining four capture points this article names — session-end trajectory capture, doctrine capture on MINOR bumps, rejected-feedback capture, and tenant-runtime capture — describe intended future capture points, not scripts that exist in the monorepo today under any name found by a repo-wide search. Whether their eventual names match what's written here is not yet confirmed against any implementation plan.
Every JSONL record the live capture path produces carries a provenance header with fields including tuple_type, doctrine_version, tenant, moduleId, cluster, role, scope, source_commit, session_id, and created. The training pipeline is intended to filter on these fields to assemble each corpus once the pipeline itself is built; any adapter version is intended to be re-derivable from its source records.
Adapter composition at request time
At inference time the Doorman (service-slm) composes adapters per request:
composed_weights =
base_model[OLMo-3-7B-Instruct]
⊕ constitutional[doctrine_v0.0.x] ← always
⊕ engineering[pointsav_vN]? ← if request is platform-build context
⊕ tenant[<tenant>_vK]? ← if request is tenant-data context
⊕ role[<role>] ← what role is asking
⊕ cluster[<cluster>_vJ]? ← if cluster scope applies
Multi-LoRA serving infrastructure — [s-lora-2024], [lorax-predibase] — serves thousands of concurrent adapters with hot-swap per request via the Yo-Yo GPU tier. The composition algebra is specified in Adapter composition algebra.
Each cluster manifest declares adapter_routing.trains: (which adapters this cluster's commits and sessions feed) and adapter_routing.consumes: (which adapters the Doorman composes when this cluster's sessions query the SLM). Every cluster defaults to training the engineering-pointsav adapter — the substrate is always improving from every cluster's work.
Negative-trajectory distillation
When an operator rejects a suggestion, asks for a revision, or marks a result as wrong, that exchange is a training signal of the highest quality. The capture-feedback.sh script records the triple:
(rejected_trajectory, corrected_trajectory, constraint_violation_tag)
These pairs feed Direct Preference Optimisation (DPO) training, per the RLAIF literature lineage [constitutional-ai-2212-08073]. The adapter family learns, per cluster and per role, which outputs to avoid and which corrections to prefer.
This per-contributor inverse of aggregate preference learning is structurally inaccessible to platforms whose preference signal is averaged across all users. An operator's specific correction pattern shapes their own cluster's adapter — no other tenant benefits or is burdened by it.
Configuration
The Trajectory Substrate currently operates at L1 (edit-corpus capture, live since v0.1.1). Per [ni-51-102] continuous-disclosure language, and in accordance with the forward-looking information principles of [osc-sn-51-721], the statements below describe planned and intended development. Material assumptions: continued-pretraining technology matures on the current trajectory; OLMo 3 base model [olmo3-allenai] remains openly licensed; engineering corpus accumulates at the current platform development cadence. Actual outcomes may differ.
Planned subsequent tiers:
- L2 — Trajectory capture (
bin/capture-trajectory.sh+ sanitize-outbound): intended for the v0.2.x release window; adds full session-log tuples to the corpus. - L3 — Fine-tuning prototype: intended for the v0.5.0 target; the
router-trainerservice reads the accumulated corpus and produces the first trained adapter against the OLMo 3 base. - L4 — Federated marketplace: long-horizon; depends on L3 operational maturity and the federated-LoRA research lineage
[federated-lora-2502-05087]proving out in production at scale.
The quarterly pretraining cadence is intended once L3 is operational. Substrate baselines are designed to improve monotonically as the corpus accumulates; the mechanism is in place and the signal is accumulating.