Learning Datagraph — SLM trajectory loop and apprenticeship queue
The platform builds a compounding substrate: every operator interaction with an AI session becomes a structured training tuple, routed through a single auditable boundary (Doorman), captured to an append-only ledger, and folded back into the local SLM via periodic fine-tuning. The result is a development environment that learns from how it gets used — code completions improve toward the patterns this operator writes, draft suggestions align closer to the editorial voice this house produces, entity extractions tighten as the graph thickens.
Key Takeaways
- The substrate accumulates training signal through several distinct mechanisms: trajectory capture at session end, an apprenticeship queue that fires on every commit, and a GLiNER→OLMo distillation pipeline that produces entity-extraction DPO pairs.
- All training signal passes through the same auditable boundary — Doorman — and lands in the append-only audit ledger. Graph queries made in this loop are tenant-scoped at that same boundary.
- Corpus-size figures (tuple counts, pair counts) change too often to publish a reliable number here.
POST /v1/draft/generateis real, built, and live. Its own doc comment calls it the "Tier C Drafting Pipeline" and it proxies to Claude Haiku 4.5.
Training signal mechanisms
Trajectory capture. A session-end hook fires at session close and posts a free-text session summary wrapped in an apprenticeship-brief JSON schema (brief_id/senior_role/task_type/body).
Apprenticeship queue. A post-commit hook fires a shadow brief for commits across 8 clusters. The local model in this loop is OLMo 3.
The DPO mechanism is GLiNER→OLMo distillation. GLiNER (Tier 0 extraction) proposes entities, OLMo 7B (Tier A) is asked to reproduce or improve on the extraction, and the delta becomes a DPO pair — an entity-extraction-quality signal, distinct from editorial-voice training.
Negative-trajectory distillation. An inbox-scanner script reads operator corrections from archived messages and emits negative-trajectory signals to the feedback corpus.
The structured-entity loop, and its tenant-scoping behavior
POST /v1/draft/generate grounds generation in graph entities — it queries the graph and an induced edge subgraph before calling out. What it does not do: call a LoRA scheduler or wake Tier B GPU compute. It is a synchronous Doorman audit-proxy call to a cloud model (Claude Haiku 4.5, see above), full stop.
Every graph query this endpoint makes is subject to the same tenant-isolation enforcement described in Doorman protocol — graph_query/graph_mutate scope strictly to the caller's own module, with no cross-tenant merge. A structured-entity draft for one tenant cannot ground itself in another tenant's graph entities, so a customer's graph IP never aggregates across tenants without opt-in.
The substrate compounds in two directions in principle. Structurally, citation density and supersedence chains thicken with each draft. Generatively, each adapter raises the floor of "raw" so refinement starts closer to publish-ready — that generative half depends on the LoRA training pipeline described in Elastic Compute #1 nightly LoRA training pipeline.
See also
- Compounding substrate — the substrate discipline this architecture instantiates
- AI inference service — the local SLM service that executes model inference in the loop
- Totebox session — the session model that trajectory capture instruments at session end
- Mailbox atomicity — flock-based prepend and msg-id idempotency — the atomic prepend discipline that protects the audit ledger from concurrent write races
Cite this record: /wiki/learning-datagraph-architecture — revision b25703b8, last updated 17 August 2026.