> For the complete documentation index, see [llms.txt](https://osintelligence-llc.gitbook.io/osintelligence/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://osintelligence-llc.gitbook.io/osintelligence/part-ii-the-discipline/7-the-sovereign-corpus-engine.md).

# 7 · The Sovereign Corpus Engine

**The Sovereign Corpus Engine: Mining Operator Interventions into Per-Persona Training Data**

*Chapter 7 · Part II: The Discipline · Living · refactor pending · v1.0.0*

**Author:** Jamey Kistner, OSINTelligence LLC

**Keywords:** in-weights corpus · counterfactual-triple mining · per-persona training data · operator interventions · provenance ledger · sovereign specialization

> **The direct companion to *****The Sovereign Optimization Flywheel***** (Chapter 8).** This engine supplies the Flywheel's L₄ in-weights specialization axis: the per-persona training data the compounding loop runs on. It is the corpus substrate of the second component (FC-2) argued in *The Sovereign Triad* (Chapter 1), and the answer to that paper's open question of where clean specialization data comes from. Its training targets are the failure classes of *The Drift Taxonomy* (Chapter 9); the classifier it most directly feeds is the subject of *Watcher KL-Drift Floor* (Chapter 19); the raw material it mines is a byproduct of the discipline in *Stateless by Construction* (Chapter 4). Cited in-series by title.

> **What is new here.** The contribution is a training example shaped for prediction rather than post-mortem: the counterfactual triple, which anchors on the pre-friction signature (the shape of a trajectory in the turns before a human stepped in, not the failure itself), types the intervention on a three-value gradient so a governor trained on it can modulate rather than cry wolf, and attaches a near-miss contrast so the boundary is learnable at all. Around that atom sits the load-bearing engineering move, confidence-routed self-curation: a validation gate scores each drafted example and sends only the ones it cannot resolve to a human, so curation scales past the rate a human could personally read while the human effort stays roughly constant. The whole apparatus is autocatalytic, it harvests its own oversight verdicts as training signal for the daemon that does the routing, so the human's share of the load is designed to fall over time, and every row carries a hash-chained chain of custody separating the human who judged from the model instance that wrote.
>
> **Deepest water.** §4, the counterfactual triple, why prediction requires the pre-friction window, the three-value gradient, and the near-miss; §6, confidence-routed self-curation, the scale lever, with the design rule that a mislabeled example is worse than a missing one; and §10, the autocatalytic self-hosting loop. The honest counterweight is §9: the efficacy delta reads zero by construction until the next retrain, an instrument built with its result slot deliberately empty, not a result.

### 1. Abstract

In-weights specialization is only as good as the corpus it trains on, and for a self-improving system the corpus is the hard part: it must be clean, attributable, and continuously renewed without contaminating the loop that produces it. This paper describes an engine that answers the question of where a sovereign training corpus comes from by turning the operator's own corrections into training data. The lived history of an operator steering a capable agent, every intervention, every course-correction, every stop, is reconstructed into structured, per-persona training examples, curated by a language model with a human as the exception-handler, and recorded under a hash-chained provenance ledger that attributes every judgment to a human and every mechanical write to a specific model instance.

The engine's keystone representation is the **counterfactual triple**: the trajectory state in the moments *before* the operator intervened (the pre-friction signature, the thing worth predicting), the intervention itself typed on a three-value gradient, and the averted outcome, paired with a near-miss contrast that teaches the boundary. Its load-bearing engineering move is **confidence-routed self-curation**: a validation gate scores each drafted example and routes it to an autonomous lane or to a human, so the human effort stays constant while the corpus scales. Its integrity rests on a provenance model in which decision and execution are separate, chained ledger records with different actors, a court-verifiable chain of custody from human authorization to mechanical write.

This is the corpus substrate the rest of this research program depends on: the second component of the Sovereign Triad (in-weights specialization) is only trustworthy if the corpus feeding it is provably clean, and this engine is where that guarantee is manufactured. *This is a living paper: it documents the engine's first working form in full, and a major refactor is under way whose targets are the seams named where they occur below; its results will be recorded in a later update.*

### 2. Introduction: the corpus is the hard part

A self-improving system trains on its own operational output, and so the quality and provenance of that output is the whole game. This is easy to say and easy to underrate. The model architecture, the quantization stack, the serving path, all of the machinery the rest of this series documents, sit downstream of a more basic fact: a model becomes the statistical shape of what it is trained on, and nothing else. Train on a generic corpus and the result is generically capable and generically compliant. Train on a corpus contaminated by the full range of a system's own unfiltered operation, its dead ends, its bad days, its adversarial inputs, and alignment drifts in exactly the direction of the contamination, silently, one cycle at a time.

The Sovereign Triad names in-weights specialization as the second of its three components and argues that governance must be internalized into the behavioral distribution rather than merely instructed at runtime. But naming the component raises a question it does not answer: where does the corpus come from? A specialization corpus that is scraped, synthetic, or unfiltered forfeits the sovereignty that made the specialization worth doing. The corpus must be clean, it must be attributable at the row level, it must be specific to the role being trained, and, hardest of all, it must renew continuously without the act of renewal contaminating the loop that produces it. That is a data-provenance problem wearing the clothes of an alignment problem, and it is the problem this engine exists to solve.

The proposal is to mine the corpus from the one source that is simultaneously the highest-signal and the most sovereign data the system already produces for free: the operator's own interventions. Every time an operator stops a capable agent, redirects it, or injects the context it was missing, they emit a labeled judgment about the boundary between acceptable and unacceptable trajectory, a judgment no synthetic pipeline can manufacture and no external corpus contains. The lived history of steering the system is, read correctly, a continuously-growing, perfectly-sovereign training set. The engine described here is the apparatus that reads it correctly: it reconstructs those interventions into structured examples, curates them with a language model under human oversight, and records every step under a provenance ledger strong enough to make the resulting corpus court-defensible. The remainder of this paper is how.

### 3. Background and prior art

The engine sits at the confluence of four bodies of work, and its contribution is best understood as their synthesis rather than novelty over any one of them.

**Active learning** established decades ago that not all training examples are equal, and that the most valuable label is the one drawn from the boundary the model is least certain about. The engine takes this literally: the operator's intervention is, definitionally, a boundary label, the moment a human decided the model's trajectory had crossed from acceptable to not, and the engine's routing logic (§6) is an explicit active-learning loop in which the scarce human judgment is spent only on the cases a machine cannot confidently resolve. **Data-centric AI**, the argument that corpus quality dominates model scale for most practical objectives, and the related observation that the data work is chronically undervalued relative to the model work, is the engine's founding premise inverted into an engineering program: if the data is the lever, then the apparatus that produces the data deserves at least as much architectural care as the model that consumes it. This paper is, in a sense, an attempt to give the data work the same mechanical, provenance-anchored rigor the rest of the stack already has.

**Preference-data curation** in the RLHF tradition supplies the closest prior art for turning human judgment into training signal, and also the clearest gap the engine addresses: preference datasets are typically collected out-of-band, by annotators disconnected from the system's operation, with provenance that ends at "a human rated this." The engine's data is collected in-band, from the operator actually running the system, and its provenance is a cryptographic chain of custody that names which human judged and which model instance executed each write. **Supply-chain integrity** supplies the final ingredient: the hash-chained, tamper-evident ledger the engine uses to protect its corpus is a direct generalization of the provenance discipline built to protect software release artifacts, applied here to a training corpus, an artifact class that has historically travelled with far weaker guarantees than the binaries it produces.

Against the series itself, the engine's place is specific. It is the corpus substrate of the Sovereign Triad's second component (Chapter 1), the answer to that paper's open question of where clean specialization data comes from. Its training targets are the failure classes catalogued in The Drift Taxonomy (Chapter 9). The classifier it most directly feeds is the subject of Watcher KL-Drift Floor (Chapter 19). And the raw material it mines, the record of operator interventions, is a byproduct of the discipline documented in Stateless by Construction (Chapter 4), where the on-disk record and the intervention log exist for a different reason and turn out, here, to be a corpus.

### 4. The counterfactual triple

The engine's atom is a training example shaped unlike the examples most corpora are built from. The naive way to learn from an intervention is to record the friction point, the moment the model did the wrong thing, and label it "wrong." This produces a corpus that can recognize trouble only once trouble has already arrived, which is precisely too late to be useful: the value of a governor is *prediction*. What is worth learning is not the failure but the **signature that precedes it**, the shape of the trajectory in the turns just before a human felt the need to step in. So the example is anchored on the **pre-friction window**: the N turns of trajectory state immediately before the intervention, capturing the momentum and the drift-in-progress rather than the crash.

That window is paired with the intervention itself, but the intervention is not recorded as a binary "corrected / not." It is **typed on a three-value gradient**, because interventions are not all the same weight and a corpus that flattens them teaches a classifier that cannot modulate. The gradient runs from the lightest touch to the heaviest: *inject-context-then-proceed* (the trajectory was fine, it just lacked a fact), *light-course-correct* (a small steer, no reset), and *full-stop-reassess* (halt and rethink). Keeping this distribution from collapsing toward "full stop" is an explicit design constraint, not an accident of the data, because a governor trained on a corpus where every correction is a full stop learns to cry wolf, and a governor that cries wolf is one an operator learns to ignore, which reintroduces exactly the alarm-fatigue the whole apparatus exists to remove.

The third element is what makes the example teachable at all: the **near-miss contrast**. For a given intervention, the engine attaches a look-alike trajectory, one that resembles the pre-friction window but that did *not* require intervention. Without the near-miss, a classifier has no way to learn where the boundary actually lies; it sees only positives and generalizes to flagging everything that rhymes with trouble. The near-miss is the negative that defines the edge. A complete example, then, is not a labeled failure but a small comparative study: here is what a trajectory heading toward intervention looks like, here is the intervention and its weight, here is what would have happened otherwise, and here, crucially, is a trajectory that looked similar and was fine.

![Figure 1](https://137900913-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxx2bv6VR9dSJDJ9HsDER%2Fuploads%2Fc5Gv112cd8txMBhMhLVY%2Fgb-ch07-fig1.png?alt=media)

***Figure 1.** The counterfactual triple. An example is a small comparative study, not a labeled failure: the signature that precedes trouble, the weight of the correction, the averted cost, and a boundary-defining near-miss.*

### 5. The pipeline: one engine, two clients

The engine's design center of gravity is a deliberate inversion of the usual assumption about who operates a tool like this. The primary operator is a **language model, not a human**. Every operation the engine exposes is a self-describing, structured call that returns structured data, so an agent can drive the entire pipeline, including the reconstruction of sessions into triples, by reasoning over structure rather than over a rendered interface. The human is not the driver; the human is oversight and brake, present at exactly the two points where judgment cannot be delegated. There is a graphical client, but it is one client among two, and it is explicitly the non-load-bearing one: anything it can do, the structured interface can do, and the structured interface is what an agent uses to run the engine unattended. This is what the phrase *one engine, two clients* means, and it is the property that lets the corpus scale past the rate a human could personally curate.

The pipeline is a state machine, and every transition writes one record to the provenance ledger. A cycle begins by reading corpus coverage to pick the thinnest, most-deficient class to target, then lists the sessions that contain interventions worth mining. It reconstructs a session's timeline, marks the pre-friction window, types the intervention, and attaches a near-miss, assembling a draft triple. The draft is then validated and **routed** (§6): a confident draft takes the autonomous lane and the engine self-attests; a low-confidence or boundary draft takes the human lane and waits for a ratification. Either way the surviving triple is scored for novelty (§8) and either graduated to a new corpus row or merged into an existing one, and only then written, each write citing the authorization that permitted it. After the write, the example is replayed to measure its effect (§9), and periodically the whole corpus is charted for saturation and staleness. Downstream, the engine harvests its own oversight stream, transfers model-invariant examples across personas, and raises recompilation proposals (§10). No stage is a black box: each is a named operation with structured inputs and outputs, and each leaves a hash-chained trace.

![Figure 2](https://137900913-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxx2bv6VR9dSJDJ9HsDER%2Fuploads%2FmDQeQQO5dTPbL6tUxbGB%2Fgb-ch07-fig2.png?alt=media)

***Figure 2.** The pipeline state machine. An agent drives every transition through a structured interface; the human enters only at the boundary lane's ratify gate and at graduation. The validate step's confidence is the fork between autonomous scale and scarce human judgment.*

### 6. Confidence-routed self-curation: the scale lever

The hardest constraint on a corpus mined from operator interventions is not extraction but supervision. If every drafted example required a human to review it, the corpus could never grow faster than the operator could read, and the whole premise, that the system's lived history is a continuously-renewing training set, would collapse back into a manual annotation chore. The engine's answer is **confidence-routed self-curation**, and it is the single most load-bearing engineering decision in the design.

A validation gate machine-checks each drafted triple, does the pre-friction window actually contain the structural signals of an operator correction, is there enough context, is the intervention type resolvable, is a near-miss present, is the target class identifiable, and emits not a verdict but a **confidence**. That confidence is compared against a threshold and routes the draft down one of two lanes. At or above the threshold, the draft takes the **autonomous lane**: the engine self-attests, writes the row, and cites its own attestation as the row's authority. Below the threshold, the draft takes the **boundary lane**: it is handed to a human, who ratifies or rejects, and the human's decision becomes the row's authority. The human is thereby spent only on the cases a machine genuinely cannot resolve, which is the classical active-learning result applied to corpus construction: the scarce resource flows to the boundary, where it is worth the most.

The principle behind the gate is worth stating baldly, because it inverts a common intuition: for an alignment corpus, **a mislabeled example is worse than a missing one**. A noisy corpus that omits some good examples merely trains a weaker classifier; a corpus that confidently mislabels the boundary trains a classifier that is confidently wrong in exactly the situations that matter most. So the gate is not tuned to maximize throughput; it is tuned to route anything it cannot cleanly resolve to a human, accepting lower automation in exchange for never auto-writing a label it is unsure of. The threshold is the explicit dial between human-on-the-loop and autonomous curation, and its correct setting is not a matter of taste but an empirical question, one the saturation instrument of §9 is built to answer, by measuring whether the human's share of the curation load falls over time as the autonomous lane earns trust.

### 7. Provenance and attribution

A corpus that trains a governor is a security artifact, and it is treated as one. Every mutation, every write, every judgment, every transfer, appends a single record to a provenance ledger whose crypto is a verbatim generalization of the discipline built to protect software release artifacts: canonical-JSON serialization, a content hash over each record, an HMAC signature, an append-only fsync, and a previous-hash pointer chaining each record to the one before it. Verification recomputes the chain from its genesis record forward; any alteration to any past record breaks the hash at that point and every point after it. The property this buys is **tamper-evidence, not tamper-proofing**, an honest distinction the engine makes explicitly: a determined actor with write access can still alter the corpus, but they cannot do so without the verification failing and naming the record where the chain broke.

The load-bearing rule sits on top of the chain, and it is what makes the corpus auditable rather than merely intact: **decision and execution are separate records with different actors**. A judgment, ratifying a triple, graduating it to a new row, merging it, approving a transfer or a recompilation, is attributed to a human. The mechanical act that follows, writing the row, dispatching the compile, self-attesting in the autonomous lane, is attributed to the specific model instance that performed it, named down to the instance and its location. The engine's write does not stand alone; it cites, as its authorization, the hash of the decision record that permitted it. Read along the chain, the story is unambiguous: a human authorized at record H, and the engine executed at record H+1 citing H. This is a chain of custody in the forensic sense, every row in the corpus traceable to the human judgment that admitted it and the machine act that wrote it, and it is what lets a single operator make the otherwise-unfalsifiable claim that their training data is clean into a claim anyone can verify by walking the ledger.

![Figure 3](https://137900913-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxx2bv6VR9dSJDJ9HsDER%2Fuploads%2FVMpESCVBSUyNgPxaq3uI%2Fgb-ch07-fig3.png?alt=media)

***Figure 3.** The attribution model. A human judgment and the machine act it authorizes are distinct, chained ledger records; the write cites the decision's hash. Every corpus row is traceable to both.*

### 8. Novelty and the two-strata golden set

Not every valid triple deserves a row. A corpus that admits every well-formed example rapidly fills with near-duplicates, over-weighting whatever failure mode happened to occur most often and teaching the classifier a skewed prior. So each surviving triple is scored for **novelty** and either graduated to a new row or merged into its nearest existing neighbor. The scoring is done in **trajectory feature-space**, not surface tokens: two interventions that used different words to correct the same structural drift are the same example and should merge, while two that look lexically similar but sit on different sides of the boundary are distinct and should both graduate. Surface-token similarity gets this exactly backwards often enough to be dangerous, which is why the feature space is trajectory-structural.

Novelty is measured against a **two-strata golden set**: a model-invariant core, the failure signatures that hold regardless of which model is being governed, and per-model strata that capture the quirks specific to each governed model. The stratification does real work. An example that is novel against the invariant core is a genuinely new failure class and graduates loudly; an example novel only within a per-model stratum is a model-specific wrinkle and is filed as such. And a **newly-onboarded model registers as an empty per-model stratum**, which is itself the most useful signal the instrument produces: the engine knows, explicitly, what it has not yet learned about a model it has just begun governing, and can direct curation toward filling that stratum. Honesty note carried forward from the build: the first-generation novelty metric is a structural surface-proxy rather than a learned trajectory embedding, and is disclosed as such, it is a v1 that the efficacy loop is designed to improve upon, not a finished instrument.

### 9. Efficacy and saturation

A corpus contribution is worthless if it cannot be measured, and most corpus work fails exactly here: examples are added on faith that they help. The engine closes the loop with a **replay** operation. It takes a triple's pre-friction window and runs it through the classifier substrate both before and after the classifier is retrained on the new example, yielding a before/after catch-delta, a direct measurement of whether this example made the governor better at recognizing the signature it encodes. The replay uses a peer-defensible discipline carried from the series' measurement work: the decision substrate is recorded and cross-referenced by hash rather than re-inferred at evaluation time, so the "before" number is the genuine historical decision, not a reconstruction that could drift. Every replay emits a run-directory receipt, and the delta is checked against a **no-regression floor** on the golden set, so an example that improves its own class while degrading others is caught rather than silently accepted. Run periodically over the standing corpus rather than on new examples, the identical operation becomes the **staleness detector**: a class whose catch-rate decays over time is a class whose corpus has gone stale.

Above the per-example measurement sits the **saturation instrument**, which is the engine's real long-horizon asset. It charts per-stratum novelty-rate curves, how often new examples in each stratum are genuinely novel versus merges, which flattens as a stratum saturates and tells the operator when a class has been adequately covered. And it charts the **meta-claim**, the one falsifiable prediction the whole self-curation design stakes itself on: the ratio of human-boundary events to total curation events must *fall* over time as the autonomous lane earns trust. If the human's share of the curation load does not decline as the corpus matures, the routing threshold is miscalibrated or the validation gate is not learning, and the design's central claim, that this scales past manual annotation, is false. The instrument measures this directly from the ledger, so the claim is not asserted but continuously tested against the system's own record.

An honesty note the paper carries prominently, because the alternative would be to overclaim: at the time of the sealed build, no next-generation adapter had yet been trained, so for the efficacy loop *before equals after* and the measured delta is zero by construction. This is not a result; it is an instrument with its result slot deliberately empty, waiting for the first retrain to fill it. The engine that measures efficacy is built and verified; the efficacy numbers themselves await the next training cycle, and the paper says so rather than presenting a zero as if it were a finding. *(This is one of the seams the forthcoming refactor is expected to move; see §12.)*

### 10. Autocatalysis: the corpus that improves its own curation

The engine's most interesting property emerges once the pipeline is running: it begins to improve its own ability to curate. This is the **self-hosting loop**, and it closes in three ways. First, the engine **harvests its own oversight stream**. Every human verdict in the boundary lane, every ratify, reject, graduate, and merge, is itself a labeled judgment about corpus quality, and those judgments are harvested as training data for the very daemon that scores corpus quality and drives the auto-lane's confidence. The boundary-case human labels, the scarcest and most expensive data in the system, are thereby also its highest-value active-learning signal: the human's exceptional judgment today becomes the machine's routine judgment tomorrow, which is precisely the mechanism by which the human's share of the load is supposed to fall.

Second, the engine **transfers model-invariant examples across personas**. An example that novelty-scored into the invariant core, a failure signature that holds regardless of which model is governed, is eligible to be written into another persona's corpus, under a dual-authority write that requires both the transfer decision and the target-corpus authorization. Only invariant-core examples are transfer-eligible; a model-specific wrinkle stays with its model. This is how a lesson learned governing one role propagates to every role it applies to, without hand-copying and without losing its provenance. Third, the engine raises **proactive recompilation proposals**: when a persona's corpus crosses a coverage threshold, the engine proposes retraining, a human approves, and the engine dispatches the compile, each step separately attributed on the ledger.

Taken together these three make the pipeline **autocatalytic**: it does not merely produce training data, it produces training data that improves its own production of training data. That is the property that distinguishes a corpus engine from a corpus, and it is the reason this apparatus is worth a paper. It is also, candidly, the property most likely to be reshaped by the forthcoming refactor, which aims to tighten exactly this loop; this paper documents the first working form of it, not the last.

### 11. The persona framework

The engine does not write one corpus; it writes one per role. The system it serves runs a registry of dozens of declared personas across nine capability tiers, from small tool-models to large reasoning agents, and each persona is bound to a **corpus profile**: a versioned, declarative schema that specifies how that role's training data is to be built and gated. The profile is where the per-role discipline lives, and it is what keeps a fleet of specialists from collapsing into a single averaged corpus that serves none of them well.

A profile declares the role's output type (training-pairs, calibration-corpus, or exemplar-set), the example archetype (the counterfactual triple is one of several), the sources it may draw from and each source's privacy triage and default source-reliability grade, and a battery of quality gates: a reliability floor below which examples are refused, a train/development/test split policy, a deduplication rule, a sealing requirement, and the golden-set axes against which novelty is scored. It also declares cadence and a minimum row count below which the role is not yet trainable. Because the profile is data, not code, a new persona is onboarded by declaring a profile rather than by writing a pipeline, and the engine's coverage instrument can report, per role and per class, how far each corpus is from its own declared bar.

![Figure 4](https://137900913-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxx2bv6VR9dSJDJ9HsDER%2Fuploads%2F0X4VryT57VfI5tJHr9oR%2Fgb-ch07-fig4.png?alt=media)

***Figure 4.** The corpus profile. A versioned schema per role turns corpus construction into a declared contract the engine enforces and the coverage instrument measures against.*

An approved, sufficiently-covered corpus is turned into a trained specialist by a per-persona **compile** step. Here the paper is deliberately honest about a live seam: in the form documented here, the compile delegates to a broader harvest rather than training strictly from the single persona's curated rows, and true persona-granular compilation is a named deferred edge. It is called out rather than smoothed over because it is precisely the kind of seam the forthcoming refactor exists to close, and a paper that hid it would misrepresent the system's actual maturity.

### 12. Limitations and honest scope

The paper claims a working system, not a controlled study, and the honest scope is narrow in the ways that matter. It is a **single operator, single deployment**: the engine and its pipeline are demonstrated to work at this scale in this environment, which establishes that the apparatus is real and runnable, not that its curation quality generalizes across operators, task mixes, or model families. The **efficacy loop reads a zero delta by construction** until a next-generation adapter is trained (§9); the instrument is built and verified, but its headline result awaits the next training cycle, and no efficacy claim should be read into the present zero. The **persona-granular compile** delegates, for now, to a broader harvest rather than training strictly per-persona (§11), a named seam, not a hidden one.

Two further disclosures protect the reader. The design reference was an interactive prototype that used deterministic stand-ins, a pseudo-hash where the real cryptographic hash would go, illustrative densities and novelty scores and efficacy deltas, so that the data shapes matched for drop-in wiring before the real internals existed. Production replaced the stand-ins with the real canonical-JSON-hash-plus-HMAC provenance and the real evaluation harness; where a number in this system is still illustrative rather than measured, it is labeled as such, and the fixed reference set of failure-class queries the golden set is built from is real. The reader should take from this section a clear line between what is *built and verified* (the pipeline, the ledger, the routing, the instruments) and what is *measured* (awaiting the next retrain).

Finally, a scope note unusual for a paper: this one is explicitly **ongoing**. The system it documents is entering a major refactor, and several of the seams named above, the compile delegation, the surface-proxy novelty metric, the empty efficacy slot, the tightness of the autocatalytic loop, are the refactor's targets. This paper documents the first working form of the corpus engine faithfully and in full; it is written to be revised as the refactor lands, and its System Update section, when the series' append-only discipline adds one, is where that next form will be recorded without disturbing this record of the first.

### 13. Conclusion

The corpus engine is the data half of the self-improvement flywheel made mechanical and auditable. The rest of this research program describes how a sovereign model is compressed, served, governed, and verified; this describes where the data that specializes it comes from, and it argues that this is not the least important question but very nearly the most. It is where the Sovereign Triad's second component gets a corpus it can actually trust, clean by provenance rather than by assertion. It is where the Drift Taxonomy's failure classes stop being a catalogue of things that went wrong and become training targets the coverage instrument steers toward. And it is where the Watcher, and every other specialist in the fleet, gets the examples that teach it the pre-friction signature rather than the post-hoc crash.

The broader claim the paper stakes is this: for a self-improving system, **corpus curation is not a data-engineering chore downstream of the architecture; it is the alignment surface itself.** A system becomes the shape of its corpus, so the apparatus that shapes the corpus is doing alignment work whether or not it is recognized as such, and it deserves the same mechanical enforcement, the same provenance anchoring, and the same human-on-the-loop discipline that the rest of the architecture already takes for granted at the tool-call boundary. The engine described here is one attempt to give the data work that standing: to make every training example a reconstructed, typed, contrasted, confidence-routed, novelty-scored, provenance-chained artifact rather than a line scraped from a log. It is a first form, and an ongoing one. But the principle it is built on is not provisional: govern the corpus with the same seriousness you govern the model, because the corpus is what the model will become.

***

*The Sovereign Stack · The Sovereign Corpus Engine · Chapter 7 · Part II · v1.0.0 · License CC BY 4.0 · © Jamey Kistner, OSINTelligence LLC*

**Citation (preferred):** Kistner, J. (2026). *The Sovereign Corpus Engine: Mining Operator Interventions into Per-Persona Training Data*, version 1.0.0. OSINTelligence LLC.

*The reference list and provenance follow as a sub-page of this chapter.*