Mechanism
The mutation-validation pipeline is the path along which a language model's output travels before it can affect anything the agent does. Every output produced by every language model integrated into the platform is treated as a proposal: a candidate semantic mutation that must be independently evaluated, validated, and either accepted, modified, or rejected by agent-resident infrastructure before it can affect any agent field, any execution state, or any downstream behavior. No language model output is authoritative. The language model occupies the role of proposal-maker, and the agent, through its resident validation engine, occupies the role of decision-maker.
This confinement is structural rather than procedural. The execution pathways are constructed so that no language model output can reach any agent field, governance decision, certification token, capability gate, or external-facing behavior without first passing through the validation engine and, where multiple models produce competing proposals, through the arbitration engine. There is no bypass path, no trusted-model exception, and no escalation mechanism by which a language model can promote its own output to authoritative status. The model is confined to a bounded proposal zone on the proposal side of the proposal-validation boundary, and the confinement is enforced by the execution substrate itself, not by runtime checks that could be misconfigured or disabled.
Why the Model Is Structurally Untrusted
The structural untrust is motivated by an epistemic asymmetry between the language model and the semantic agent. The agent possesses verified state: its fields, including intent, context, memory, policy reference, mutation descriptor, lineage, and affective state, are populated through governed mutation events that are cryptographically signed, policy-validated, and lineage-recorded. Each field value has a provenance chain that traces its origin through a sequence of verified mutations.
The language model possesses no verified state. Its parameters were acquired through a training process that aggregated statistical patterns from a corpus of uncertain provenance, accuracy, and completeness. Its output at any step is a function of its trained parameters and the prompt context supplied at that step. The model does not maintain persistent state across inference calls, does not track the provenance of its own outputs, and cannot distinguish between outputs that are well-grounded in verified information and outputs that are hallucinated, confabulated, or statistically plausible but factually incorrect. The pipeline exists to bridge this asymmetry: it admits the model's generative capacity while denying its output authority until the agent has independently verified it.
The Mutation Engine
The mutation engine is interposed between the language model output boundary and the validation engine input boundary. Its function is to impose structural discipline on the inherently unstructured output of the language model. It performs four operations on each raw proposal, and it does so without judging whether the proposed values are good, correct, or desirable, since that assessment is the exclusive responsibility of the validation engine.
The first operation is schema mapping: the raw output, which may be natural language text, structured JSON, or an intermediate representation, is mapped onto the agent's field schema to identify which fields the proposal seeks to modify. A proposal that addresses multiple fields is decomposed into a set of per-field candidate mutations, each independently evaluated. The second operation is bounds normalization: proposed values are normalized to each field's defined value range, data type, and representational format, and a value outside the field's representational bounds is flagged as malformed and rejected prior to validation. The third operation is conflict detection: when multiple proposals from multiple models target the same field, the competing proposals are packaged as a conflict set for the arbitration engine. The fourth operation is lineage annotation: each candidate mutation is annotated with the originating model's identity, the prompt context supplied to it, a timestamp, and a hash of the raw proposal, producing a provenance record that is incorporated into the agent's lineage if the mutation is ultimately accepted.
The Validation Engine
The validation engine evaluates each candidate mutation against the full set of agent-resident constraints to determine whether the mutation may be incorporated into the agent's state. It is resident within the agent's execution environment and operates on the agent's verified state. It does not consult the language model, does not consult external oracles, and does not defer to any authority other than the agent's own policy, lineage, and structural constraints. It is the enforcement boundary that gives operational meaning to the structural untrust of the model: proposals that fail validation are discarded.
Each candidate mutation is evaluated against a plurality of constraint categories. Policy compliance checks whether the proposed field value falls within the policy-permitted range for that field, as defined by the agent's policy reference. Lineage consistency checks whether the proposed value is consistent with the agent's mutation history, rejecting a mutation that would reverse a previously governed decision without a corresponding governance event or introduce a value contradicting a cryptographically sealed prior state. Integrity compliance checks the mutation against the integrity engine to determine whether it would drive the agent's integrity score below the threshold at which coherence is maintained. Capability feasibility checks the mutation against the capability envelope system to determine whether the proposed action can be structurally executed on the available substrate. Affective bounds checks whether the mutation would drive the agent's affective state outside its policy-bounded range.
The engine produces a structured validation record for each candidate, indicating whether the mutation passed or failed, which constraint categories were evaluated, which were satisfied, which were violated, and the specific violation details for each failed constraint. The record is persisted in the agent's lineage regardless of whether the mutation was accepted or rejected, so that rejected mutations and the reasons for their rejection remain available for governance audit, for analysis of proposal-failure patterns that indicate model miscalibration, and for dispute resolution.
Synchronous, Atomic Evaluation
The validation engine operates synchronously with respect to the mutation it evaluates: a candidate mutation receives a validation determination before any subsequent mutation for the same agent field is evaluated. This prevents a race condition in which two competing mutations to the same field are both validated against the pre-mutation state and both accepted, producing an inconsistent post-mutation state.
The engine locks the target field during evaluation, computes the validation determination, and either applies the mutation and releases the lock or discards the mutation and releases the lock. The atomicity of this operation is enforced by the agent's execution substrate and is not dependent on the behavior of the language model or the mutation engine.
The Arbitration Engine
When multiple language models produce competing candidate mutations for the same field or operation, the arbitration engine resolves the conflict. It receives conflict sets from the mutation engine, sets of two or more candidate mutations that target the same field and cannot be simultaneously applied, and selects a single winning candidate or synthesizes a reconciled candidate from the competing proposals. The system does not aggregate model outputs through voting, averaging, or ensemble techniques that would produce a blended output inheriting the authority of multiple models; each model's output remains an independent proposal that must independently satisfy validation.
The arbitration engine applies trust-weighted evaluation in which each model's proposal is weighted according to the model's accumulated trust score within the agent's governance context. The trust score is dynamic: proposals that have been validated and accepted increase the score, proposals that have been rejected decrease it, and proposals accepted but later determined to have introduced errors, inconsistencies, or policy violations produce a retroactive penalty. The score is maintained per agent and per domain, so the system can recognize that a model may be reliable for one category of proposal and unreliable for another. Each candidate in the conflict set is scored on dimensions including semantic coherence with the agent's current state, consistency with the intent field, alignment with the policy reference, and compatibility with the lineage trajectory; the per-dimension scores are multiplied by the originating model's trust weight to produce a trust-adjusted composite score, and the highest-scoring candidate is selected. Where the competing proposals are partially compatible, the engine may synthesize a reconciled candidate from their highest-scoring elements; the reconciled candidate is then submitted to the validation engine as though it were a new proposal, because reconciliation does not bypass validation.
Arbitration as a First-Class Semantic Event
Every arbitration decision is recorded as a first-class semantic event in the agent's lineage. The arbitration event record includes the identities of the competing models, the candidate mutations they produced, the trust weights applied, the per-dimension scores computed, the selection or reconciliation logic applied, and the identity of the winning or reconciled candidate. The record is cryptographically signed and sealed into the agent's lineage chain, and the sealed event cannot be retroactively altered, deleted, or reordered.
Treating arbitration as a first-class event produces three consequences. Arbitration decisions become part of the agent's persistent memory and influence future trust weighting: an event in which one model's proposal was selected and subsequently proved correct increases that model's trust weight and decreases the overridden model's. Arbitration decisions become auditable governance artifacts: an auditor can trace any field value back through the lineage to the arbitration event that selected it, and from there to the specific proposals, trust weights, and scoring logic that produced the selection. And arbitration decisions become inputs to cross-agent governance: when an agent's arbitration history reveals a pattern, such as a model that consistently produces proposals which fail validation or are overridden, that pattern can be propagated to other agents using the same model for network-wide trust recalibration. Because the sealed record is tamper-resistant, the trust-weight feedback loop operates on a historical record an adversary cannot manipulate to inflate or deflate a particular model's trust score.
Disclosure Scope
The mutation-validation pipeline, comprising the structural treatment of every language model output as a non-authoritative proposal, the mutation engine that performs schema mapping, bounds normalization, conflict detection, and lineage annotation, the agent-resident validation engine that evaluates each candidate mutation against policy compliance, lineage consistency, integrity compliance, capability feasibility, and affective bounds and persists a structured validation record regardless of outcome, the synchronous field-locked evaluation that preserves atomicity, and the trust-weighted arbitration engine that resolves competing proposals and records each decision as a signed, sealed first-class semantic event, is disclosed in the cognition filing (U.S. Application No. 19/647,395 and its international counterpart). This article describes that disclosed mechanism. The scope extends to embodiments invoking one model or several in parallel or in sequence, to reconciliation that synthesizes a candidate from competing proposals provided the reconciled candidate is itself re-submitted to validation, and to per-agent and per-domain trust scoring, provided that no model output reaches agent state without passing through the validation boundary and that arbitration decisions are recorded as auditable lineage events.
