# 3.30 Model Plane

### 3.30 Model Plane, Decision Plane, and Bounded Human–Machine Collaboration Across the Rail

#### 3.30.1 The governing proposition

The final architectural layer of Part III is the model plane and the decision plane. The model plane is the bounded estate in which analytical models, simulation engines, optimization routines, scoring systems, retrieval systems, agentic components, and other inferential machinery are trained, evaluated, admitted, supervised, versioned, constrained, monitored, narrowed, suspended, restored, and retired for defined classes of use. The decision plane is the bounded estate in which outputs from those systems may influence preparation, review, prioritization, sequencing, orchestration, packaging, and presentation without displacing the authority surfaces, record disciplines, force-of-effect rules, and non-execution boundaries established across this Part. Human–machine collaboration across the rail is therefore not an innovation theme layered on top of the architecture. It is a controlled constitutional-operating pattern inside the architecture.

This distinction is decisive. Nexus does not permit models to become silent constitutions, nor does it require human operators to simulate manual certainty in a system explicitly designed for high-dimensional evidence, pathway complexity, mixed-trust environments, and distributed runtime. It instead constructs a bounded collaboration regime in which models may extend sensing, synthesis, comparison, scenario generation, packaging support, anomaly detection, reconciliation support, and control assistance, while human authority surfaces retain responsibility for determination, designation, release, correction, routing, escalation, supersession, and any act carrying governance-valid or execution-sensitive consequence. Machine capability is therefore admitted as disciplined augmentation, never as an independent source of truth, standing, sovereignty, or force-bearing effect.

The core proposition may be stated more sharply. Part III does not culminate in “AI inside the system.” It culminates in a rule for how intelligence enters a force-bearing rail without corrupting the rail’s constitutional order. That rule has three inseparable elements:

a) inferential systems may participate only through admitted and classed roles;\
b) their participation remains subordinate to stage truth, artifact truth, and authority truth; and\
c) every materially consequential human–machine interaction must remain attributable, reviewable, narrowable, and correction-capable.

This is what allows Nexus to become computationally sophisticated without becoming institutionally vague. The model plane adds power. The decision plane preserves legitimacy. The collaboration doctrine prevents power from silently reauthoring legitimacy.

#### 3.30.2 Why the model plane must be treated as a constitutional-operating layer

A weaker architecture would treat models as tools hidden inside applications. Nexus cannot afford that simplification. Models alter how evidence is weighted, how routes are imagined, how anomalies are surfaced, how summaries are formed, how options are ranked, how packages are assembled, how attention is allocated, and how institutional actors perceive urgency, maturity, and comparability. Once models materially affect those functions, they cease to be mere software components. They become participants in the truth-forming and action-shaping environment of the rail. The model plane must therefore be governed as a first-order layer.

This matters because the principal risks of advanced analytical and agentic systems in a governance-grade environment are not limited to bias or technical error in the abstract. They include:

a) hidden semantic drift;\
b) hallucinated maturity;\
c) route inflation;\
d) false convergence;\
e) overconfident packaging;\
f) invisible prompt leakage;\
g) retrieval contamination;\
h) silent authority substitution;\
i) shadow release behavior; and\
j) uncontrolled carry-through from probabilistic suggestion into record-bearing consequence.

By treating the model plane as constitutional-operating infrastructure, Nexus subjects it to the same disciplines already imposed on the rest of the rail: role purity, stage truth, artifact truth, non-execution, bounded interfaces, correctionability, replay-safe lineage, and controlled human override.

There is a further reason. In many institutions, software is reviewed as technology and decisions are reviewed as governance, with too little attention to the zone where software materially shapes what governance sees, thinks, ranks, drafts, and forwards. Nexus closes that gap. It recognizes that once inferential machinery influences institutional salience and action sequencing, it belongs neither purely to engineering nor purely to policy. It belongs to a constitutional-operating layer where both must be present at once.

#### 3.30.3 The model plane in its strongest definition

The model plane is the governed estate in which inferential systems are admitted, classified, evaluated, bound to scope, versioned, attested, monitored, narrowed, withdrawn, restored, and retired for specific classes of use. It includes statistical models, optimization engines, scoring and ranking systems, retrieval systems, graph and knowledge engines, simulation stacks, forecasting components, bounded agentic routines, summarization and drafting systems, and associated prompt layers, policy wrappers, evaluation harnesses, tool contracts, monitoring logic, and release controls.

It is not enough that such systems are useful. In Nexus they must also be classed by constitutional function. At minimum, the architecture should distinguish:

a) observational and detection models;\
b) analytic and synthesis models;\
c) scenario and simulation models;\
d) packaging and translation models; and\
e) runtime-assistance or bounded agentic models.

This classification matters because the risks, reliance limits, admissible actions, monitoring burdens, and rollback requirements differ sharply across model families. A relevance-ranking model does not sit in the same constitutional risk posture as a routeability-support engine. A clustering model does not sit in the same posture as a workflow agent allowed to invoke tools. The model plane remains trustworthy only when these differences are explicit rather than assumed.

A still stronger reading requires the model plane to preserve four kinds of discipline simultaneously:

a) **identity discipline**, so the estate knows what model or inferential component is acting;\
b) **scope discipline**, so the estate knows what kind of influence that model is allowed to exert;\
c) **lineage discipline**, so the estate knows how outputs can later be explained, challenged, or replayed; and\
d) **withdrawal discipline**, so the estate can narrow or remove a model without semantic confusion about what prior outputs remain valid, provisional, or superseded.

Without all four, the model plane becomes merely a cluster of helpful engines. With them, it becomes a governable layer of the rail.

#### 3.30.4 The decision plane in its strongest definition

The decision plane is the bounded constitutional-operating layer in which proposed actions, classifications, route steps, release choices, correction choices, escalation choices, publication choices, and narrowing or restoration choices are formed, checked, contested, recorded, and, where appropriate, authorized by competent human authority surfaces. It is not identical with the governance plane, because much preparation and prioritization occurs below final determination. It is not identical with the runtime plane, because runtime may prepare options without deciding them. It is the intermediate and decisive layer in which the system moves from analysis and recommendation to valid institutional choice.

The decision plane must therefore preserve:

a) named human decision owners or human authority surfaces;\
b) role-bound competence;\
c) evidence and artifact sufficiency checks;\
d) visibility into material model contribution where relevant;\
e) escalation and challenge routes; and\
f) record conversion into force-bearing outcomes only after competent human action.

It is where the architecture ensures that machine suggestion does not quietly become institutional act. That is why it belongs at the culmination of Part III. It is the final discipline that turns a technically capable rail into a governance-grade rail.

The decision plane also serves as the architecture’s anti-compression layer. It prevents the estate from collapsing the following into one indistinct stream:

a) generated option;\
b) reviewed option;\
c) preferred option;\
d) authorized option; and\
e) recorded act.

In a weaker system, these stages blur under throughput pressure. In Nexus, the decision plane keeps them separated long enough for legitimacy to attach in the right place.

#### 3.30.5 Why model output must never be equated with decision

A recurring failure mode in digitally mature institutions is the gradual compression of recommendation into action. First the system proposes, then operators habituate to acceptance, then challenge declines, then the recommendation becomes the practical decision while the human role is reduced to confirmation theater. Nexus explicitly rejects that trajectory. Model output, however useful, is not decision. It is input to a decision process governed by the authority surfaces, escalation paths, artifact classes, and validity disciplines already established.

This distinction is not anti-automation. It is pro-truth. In a rail designed for sovereign, public-purpose, routeability-bearing, and evidence-bearing consequence, the cost of unacknowledged machine substitution is too high. If a model proposes:

a) a route class;\
b) a readiness sequence;\
c) a prioritization ranking;\
d) a proof-pack structure;\
e) a correction recommendation; or\
f) a publication narrowing,

the proposal may be excellent. It remains a proposal unless and until the competent human or institution acts. This is one of the most important safeguards in the whole architecture because it preserves the difference between computational assistance and constitutional force.

The architecture should therefore be read under a strong non-equation rule:

a) model confidence is not authority;\
b) model consistency is not standing;\
c) model fluency is not evidence sufficiency;\
d) model ranking is not institutional prioritization; and\
e) model recommendation is not valid determination.

That rule is what prevents the decision plane from being hollowed out by convenience or habituation.

#### 3.30.6 The doctrine of bounded human–machine collaboration

Bounded human–machine collaboration is the rule that machines may augment perception, memory, synthesis, consistency, simulation, drafting, anomaly surfacing, and constrained orchestration, but may not originate force-bearing acts, expand their own scope, widen claims, reclassify standing, override handling boundaries, or silently route the system into stronger consequence states. Humans, in turn, may rely on machine assistance, but may not use machine opacity, machine speed, or machine fluency as an excuse to evade their own role-bound responsibilities for review, judgment, escalation, recusal, and correction.

This creates a reciprocal discipline. Machines are bounded by admitted function, policy, environment, tool scope, and reviewability. Humans are bounded by accountability for the acts they take with or through machine assistance. The doctrine preserves the strengths of both sides. Machines carry scale, pattern detection, synthesis, and procedural consistency. Humans retain authority for legitimacy, proportionality, accountability, public consequence, and institutional meaning. Neither side is romanticized. Each is governed.

The doctrine can be expressed as a three-part operating rule:

a) the machine may extend capability;\
b) the human remains responsible for effect;\
c) the record must preserve where the extension materially shaped the path to effect.

This is how Nexus avoids both naive automation and naive manualism. It does not demand that humans do everything themselves. It demands that force remain institutionally attributable even when machine assistance is substantial.

#### 3.30.7 Model classes by consequence posture

Not all models should be treated equally. A mature Nexus deployment should classify models not only by technical type but by consequence posture. At minimum, the following consequence classes should be distinguished.

First are **assistive models**, whose outputs are informational or exploratory and may support orientation without materially shaping consequence on their own.

Second are **decision-support models**, whose outputs may materially affect prioritization, comparison, or recommendation but require explicit human review before any force-bearing use.

Third are **control-adjacent models**, whose outputs may influence workflow movement, alerting, gating, or operational routing and therefore require stronger attestation, monitoring, and no-bypass controls.

Fourth are **restricted high-impact models**, whose outputs bear directly on routeability, publication posture, designated-artifact composition, standing-sensitive logic, or other high-consequence functions and therefore require the strongest admission, review, and rollback discipline.

This classification should govern admission, evaluation, explanation requirements, observability, override, revocation, and restoration. A summarization model and a routeability-ranking engine do not inhabit the same constitutional risk category. Nexus must make that difference explicit or it will gradually allow low-friction model use to bleed upward into higher-consequence domains without the controls those domains require.

A practical corollary follows. Consequence posture should determine:

a) what evidence is required for admission;\
b) what level of human review remains mandatory;\
c) what traces must be preserved;\
d) what rollback conditions must be tested; and\
e) what forms of autonomous action are categorically prohibited.

This prevents “AI” from being treated as a single undifferentiated class across the estate.

#### 3.30.8 The admission doctrine for models

No model should be admitted to the rail merely because it performs well on generic benchmarks or because a vendor markets it as enterprise-ready. Admission is a constitutional-operating decision. A model is admitted only when the architecture can state clearly:

a) what function class the model belongs to;\
b) what stages of the operating sequence it may influence;\
c) what artifact classes it may touch;\
d) what data classes it may access;\
e) what reliance posture its outputs may support;\
f) what human review remains mandatory; and\
g) what withdrawal, rollback, narrowing, and re-attestation logic applies.

This doctrine is particularly important for externally sourced foundation models, commercially provided AI services, and general-purpose agent frameworks. Their utility may be substantial. Their admissibility must still be bounded by the architecture’s own truth regime rather than by vendor claims, benchmark theater, or implementation excitement. Admission is therefore not a procurement event. It is a controlled entry into the constitutional-operating estate.

The model admission file should therefore, at minimum, answer:

a) what this model may do;\
b) what this model may never do;\
c) what conditions must remain true for continued operation;\
d) what failure signatures trigger narrowing or suspension; and\
e) what recovery path exists if the model is later restored.

Only when those questions are answered does the model belong inside the rail rather than merely adjacent to it.

#### 3.30.9 Model provenance, versioning, and reproducibility posture

A governance-grade model plane requires strict provenance and version discipline. The estate must know which model, which version, which weights or configuration set, which prompt or instruction layer, which retrieval pattern, which post-processing logic, which policy bundle, and which tool-contract envelope contributed materially to an output. Without this, the system may be powerful but it remains challenge-weak, correction-weak, and governance-weak.

Model provenance must therefore preserve:

a) model identity and lineage;\
b) release version and effective dates;\
c) configuration and instruction overlays where material;\
d) retrieval or context dependencies where material;\
e) evaluation posture and known limitations; and\
f) linkage to the build, release, and attestation architecture already established across Part III.

Perfect scientific reproducibility for every interaction is not required. Sufficient reconstructibility for consequential outputs is required. That is how the estate later explains, narrows, replays, or supersedes machine-shaped artifacts without guesswork.

A mature reproducibility posture should distinguish:

a) **bit-level reproducibility**, which may be feasible for some deterministic components;\
b) **procedural reproducibility**, meaning the same governed steps can be replayed; and\
c) **explanatory reproducibility**, meaning the estate can explain what materially shaped the output even if stochastic variation exists.

Nexus primarily requires the third, and where consequence rises, increasingly the second. That is what makes provenance operationally useful rather than merely archival.

#### 3.30.10 Model attestation and environment trust

Model trust does not depend only on the model artifact. It also depends on the environment in which the model runs. A model admitted for sensitive synthesis in a protected environment should not automatically be trusted when moved to a less protected, differently governed, or differently tooled environment. The model plane must therefore integrate with the broader attestation architecture.

A serious model-attestation posture should answer:

a) what model is running;\
b) in what environment class;\
c) under what prompt, retrieval, and policy constraints;\
d) with what surrounding tool access;\
e) under what logging and review posture; and\
f) with what current trust and standing state.

This is especially important for bounded agentic systems, where the risk is not merely incorrect output but incorrect sequencing, scope escape, silent retrieval drift, or hidden side effects in the runtime estate.

The architecture should therefore reject any assumption that “the same model” implies “the same trust posture.” In practice, trust posture is a joint product of:

a) the model;\
b) the environment;\
c) the tool envelope;\
d) the policy wrapper; and\
e) the present standing of the runtime in which the model is acting.

That is why model attestation belongs inside the trust plane rather than being handled as a separate model-ops curiosity.

#### 3.30.11 Retrieval, context assembly, and semantic integrity

Many useful model functions in Nexus will be retrieval-augmented, graph-informed, or context-assembled. This makes context assembly itself a governance-sensitive function. If the model plane draws from stale, superseded, insufficiently classed, or handling-incompatible artifacts, then even a capable model may produce semantically distorted outputs. The architecture must therefore govern retrieval and context assembly as part of semantic integrity.

Retrieval-aware model use should preserve:

a) source-class visibility;\
b) version and supersession awareness;\
c) handling and audience constraints;\
d) stage-aware artifact selection;\
e) stronger-source precedence over weaker derivatives; and\
f) limitation signaling where the retrieval set is incomplete or stale.

Without these controls, the model plane becomes a semantic drift engine. With them, it becomes an instrument for disciplined synthesis that remains subordinate to the artifact and record doctrines already established.

The key point is that context is not neutral fuel. In a governance-grade rail, context determines what the model is allowed to think *with*. That means context assembly is already close to consequence. Nexus therefore requires that retrieval logic itself remain:

a) stage-aware;\
b) supersession-aware;\
c) handling-aware; and\
d) source-precedence-aware.

Only then can model-assisted synthesis remain compatible with the rail’s common semantic order.

#### 3.30.12 Decision-support models and the doctrine of visible assistance

Where model output materially influences a decision-support process, that assistance must be visible to the decision plane. The estate should not require performative skepticism, but it must preserve the ability to know when machine assistance was material, what class of assistance was involved, and what remaining human judgment obligations applied.

A mature visible-assistance doctrine should therefore preserve, where consequence warrants:

a) the fact of model use;\
b) the model class involved;\
c) the scope of its contribution;\
d) the points at which human review or modification occurred; and\
e) the points at which human override, acceptance, or rejection occurred.

This is not anti-innovation bureaucracy. It is what allows later review to distinguish “the system suggested” from “the institution decided.” In a rail built on validity-by-record, that distinction is indispensable.

Visible assistance also protects humans. It prevents later false narratives in which:

a) operators are blamed for machine-originated overconfidence they were not positioned to detect; or\
b) machines are blamed for choices that humans in fact ratified knowingly.

The architecture wants clearer attribution than either of those distortions allows.

#### 3.30.13 The human decision owner remains indispensable

The decision plane requires named human decision owners or human authority surfaces even where substantial model assistance exists. This is non-negotiable. A model may generate ranked options, propose classification language, recommend artifact structure, or surface correction candidates. It may not become the holder of the office that decides.

This must remain true across all consequential domains, including:

a) governance determination;\
b) standing or role classification;\
c) host designation and narrowing;\
d) routeability advancement;\
e) publication and public-safe release;\
f) major correction or supersession;\
g) emergency narrowing or containment; and\
h) any action capable of changing reliance conditions for others.

Human authority may be collective, institutional, and record-bound. It may not be quietly replaced by a statistically persuasive engine or by an interaction pattern in which people merely ratify what the system has already practically decided.

The indispensability of the human decision owner is not a nostalgia claim. It is a legitimacy claim. In Nexus, consequence-bearing acts must remain tied to bodies capable of:

a) justification;\
b) recusal;\
c) challenge;\
d) correction; and\
e) public or institutional answerability.

No model, however capable, can presently occupy that constitutional posture.

#### 3.30.14 Prohibited machine substitutions

The architecture should expressly prohibit several forms of machine substitution. These include:

a) machine-generated determination without competent human act;\
b) autonomous widening of claims or artifact class;\
c) autonomous routeability upgrade or standing change;\
d) autonomous public-safe or external release of consequential materials without the required human release gate;\
e) autonomous override of correction, supersession, or mismatch-hold logic;\
f) autonomous assumption of a role key or standing state not explicitly granted; and\
g) autonomous action that crosses the governance-only boundary into licensed execution or execution implication.

These prohibitions are essential because most serious failures in advanced operational systems arise not when the model is explicitly declared sovereign, but when practical workflows allow it to become sovereign by habit. Nexus prevents that by naming the prohibited substitutions in advance and by treating their appearance as constitutional drift rather than as mere product overreach.

The list should be read strictly and conservatively. If a proposed automation pattern would cause uncertainty as to whether the model is merely assisting or effectively determining, the narrower reading should prevail. That is consistent with the broader most-restrictive-reading rule already established across the architecture.

#### 3.30.15 Assistive automation versus bounded agentic action

Nexus should distinguish sharply between assistive automation and bounded agentic action. Assistive automation may prepare drafts, normalize inputs, generate summaries, suggest metadata, cluster anomalies, validate formatting, or perform other bounded non-decisional tasks. Bounded agentic action may be admitted in narrower domains where the architecture can define explicit goals, tools, constraints, review gates, rollback logic, and interrupt rights, such as tightly constrained workflow assistance, anomaly-handling orchestration, or low-consequence technical hygiene routines.

This distinction matters because the governance burden increases sharply once a system can choose tools, sequence operations, or initiate state transitions. Agentic systems are not forbidden in principle. They are admissible only where the architecture can prove that:

a) scope is explicit;\
b) tools are allow-listed;\
c) policies are executable;\
d) side effects are bounded;\
e) human interruption remains meaningful; and\
f) replay and audit remain intact.

A useful operational rule is that assistive automation works *inside* a human-owned step, while bounded agency may carry out limited sub-steps *between* human-owned gates. That distinction prevents the estate from misdescribing workflow autonomy as constitutional competence.

#### 3.30.16 Tool access, tool allow-lists, and consequence gating

Any model or agentic component with tool access must operate under consequence-aware allow-lists. Not every tool is equal. The ability to query a knowledge graph, propose a local draft, or classify a low-consequence queue item does not carry the same constitutional risk as the ability to modify standing state, publish artifacts, alter policy bundles, trigger routeability movement, change environment class, or influence release promotion.

Tool governance should therefore classify tools by consequence and require:

a) explicit admission;\
b) role-bound access;\
c) context-sensitive invocation controls;\
d) logged invocation and result traceability;\
e) tighter review gates for higher-consequence tools; and\
f) emergency disable plus rapid revocation.

This is one of the clearest applications of the earlier non-execution and no-bypass doctrines to the model plane. Tool use must never become the back door through which machine suggestion acquires hidden institutional force.

The allow-list discipline should also remain environment-aware. A tool admitted in one trust domain, handling class, or stage context should not automatically be callable in another. That is how the architecture prevents the model plane from quietly widening its own effective sovereignty through tooling sprawl.

#### 3.30.17 Model evaluation as a constitutional-operating process

Model evaluation in Nexus cannot be reduced to generic accuracy, benchmark wins, or abstract quality metrics alone. Those may matter, but they are insufficient. The estate must also evaluate models against constitutional-operating criteria, including:

a) stage-truth preservation;\
b) artifact-class fidelity;\
c) handling and confidentiality obedience;\
d) prompt and context-injection resistance;\
e) deference to stronger sources over weaker derivatives;\
f) uncertainty-expression discipline;\
g) refusal or narrowing behavior where consequence exceeds standing; and\
h) absence of execution implication in governance-only contexts.

This evaluation doctrine should apply both before admission and continuously after admission through red-team testing, live sampling, drift monitoring, challenge review, replay analysis, and consequence-aware audits. A model that is statistically strong but constitutionally unreliable is not fit for the rail. The measure of admissibility is therefore not raw intelligence. It is disciplined behavior inside the architecture’s truth regime.

A stronger formulation is that Nexus evaluates models not only for *capability* but also for *obedience to constitutional boundaries*. A model that performs brilliantly while widening claims, misreading supersession, or compressing stage truth is not a high-quality model in this estate. It is an unsafe one.

#### 3.30.18 Uncertainty, confidence, and the duty against false precision

A mature model plane must preserve uncertainty rather than conceal it. One of the most dangerous machine behaviors in a governance-grade system is false precision: outputs that appear crisp, complete, or final beyond what the underlying evidence, retrieval, or model class supports. Nexus must therefore require uncertainty-aware output behavior in consequential domains.

Models used in synthesis, routeability support, or artifact drafting should be constrained to:

a) surface uncertainty where material;\
b) distinguish sourced content from inference;\
c) narrow rather than widen under ambiguity;\
d) avoid language implying stronger force than the artifact class supports; and\
e) defer to stronger human and record-based review pathways rather than manufacturing false certainty.

This is not merely a user-experience preference. It is an extension of the stage-truth and artifact-truth doctrines into the model plane. False precision is especially dangerous in systems that sound fluent. Nexus must govern fluency so that it does not become a disguised source of overclaim.

The duty against false precision also has institutional meaning. It protects decision owners from being pushed into accepting outputs whose rhetorical confidence exceeds their actual evidentiary support. In this sense, uncertainty-aware modeling is not only epistemic hygiene. It is a fairness and authority-preservation discipline.

#### 3.30.19 Decision logs, model traces, and replay-safe collaboration

Where model assistance materially shapes a consequential output, the estate should preserve enough trace to support later challenge, review, and replay. This does not mean preserving every token of every interaction in every circumstance. It means preserving sufficient decision-relevant trace.

Depending on consequence class, this may include:

a) model identity and version;\
b) relevant prompts or instruction layers;\
c) source-set references;\
d) retrieval context posture;\
e) tool invocations;\
f) human edits or overrides;\
g) approval markers; and\
h) resulting artifact identity.

This trace discipline is one of the ways the model plane integrates with replay-safe state. It allows the estate to reconstruct not only what was decided, but how human and machine collaboration contributed to the decision-support path. That is essential if the system is to remain correctable and reviewable under increasing machine assistance.

The estate should therefore preserve trace in proportion to force. The stronger the possible consequence, the stronger the need to know:

a) what the machine contributed;\
b) what the human changed;\
c) what was accepted; and\
d) what would have to be revisited if later correction is required.

That is how collaboration remains replay-safe rather than merely productive.

#### 3.30.20 Bounded autonomy in the runtime estate

Bounded autonomy may be useful in the runtime estate where latency, scale, or continuity needs make continuous human micro-approval impractical. Examples may include anomaly routing, low-consequence classification, retry logic, degraded-mode buffering, evidence packaging preparation, or policy-driven workflow transitions. But bounded autonomy remains subordinate to three rules.

a) The autonomous scope must be explicitly defined and narrow.\
b) The autonomous system must not create new authority or stronger stage posture than already allowed.\
c) Human interruption, rollback, and post hoc review must remain real.

This means the runtime estate may benefit from advanced automation without allowing “automation” to become a euphemism for undocumented constitutional change. The system may automate movement. It may not automate force. That distinction is one of the most important hidden design rules in the entire architecture.

A mature bounded-autonomy design should therefore specify:

a) entry conditions;\
b) allowed actions;\
c) prohibited escalations;\
d) stop conditions;\
e) audit requirements; and\
f) restoration conditions if the autonomy envelope is later narrowed or disabled.

Only then can the estate use machine speed without surrendering institutional authorship.

#### 3.30.21 Model plane and evidence integrity

The model plane must never be allowed to weaken evidence integrity. Models may help discover, organize, summarize, cluster, compare, or package evidence. They may not silently alter provenance, rewrite lineage, erase uncertainty, or convert weak evidence into stronger evidence by rhetorical compression. Evidence-bearing objects remain governed by the evidence plane and its promotion rules, not by model fluency or packaging strength.

This is a critical boundary. A strong model may assist evidence formation. It does not authorize evidence mutation. The moment a model can materially reshape the evidentiary record without visible review, replay discipline, and bounded authority, the rail’s truth regime begins to weaken. Nexus must therefore preserve a strict separation between evidence support and evidence authorship.

That separation can be formulated operationally:

a) models may assist evidence navigation;\
b) models may assist evidence synthesis;\
c) models may assist evidence packaging;\
d) models may not silently change evidentiary class, provenance, or parent-child truth relations.

This rule is especially important in retrieval-augmented and graph-informed environments, where the temptation to let machine synthesis substitute for underlying evidentiary discipline is high. Nexus insists that the evidence plane remains stronger than the model plane, not the other way around.

#### 3.30.22 The model plane and the non-execution doctrine

The model plane must also remain inside the non-execution doctrine. No model or bounded agentic system may originate lending, underwriting, placement, guarantee issuance, settlement action, sovereign appropriation, or execution implication through autonomous behavior, persuasive output, workflow positioning, or tool invocation. Even if a model becomes extremely capable at shaping finance-compatible packaging, scenario logic, pricing support, or routeability dossiers, it remains inside the governance-only core.

This rule matters because machine fluency can create the illusion of near-execution competence. Nexus must resist that illusion. The more sophisticated the model plane becomes, the more firmly it must remain bounded by the earlier doctrines of routeability, handoff, and non-execution. Machine strength does not relax constitutional limits. It makes them more important.

The estate should therefore be explicit that models may support:

a) preparedness;\
b) comparability;\
c) packaging;\
d) scenario exploration; and\
e) routeability legibility,

but may not cross into:

a) binding decision by an external execution actor;\
b) market-facing execution authority;\
c) payment, settlement, or underwriting action; or\
d) any output that would reasonably be read as already carrying those effects.

This is how machine capability remains useful without becoming constitutionally misleading.

#### 3.30.23 Human–machine collaboration as a productivity rule, not a sovereignty rule

The correct strategic reading of human–machine collaboration in Nexus is that it is a productivity rule, a quality rule, a resilience rule, and a scaling rule, but not a sovereignty rule. It should make the estate faster at sensing, better at synthesis, stronger at consistency, richer in scenario exploration, more disciplined in packaging, and more capable under scale and degraded conditions. It should not become a separate constitutional source of standing, classification, routeability, public meaning, or outward consequence.

This formulation matters because it allows the architecture to embrace advanced AI without either romanticizing humans or romanticizing automation. The system can become far more capable while remaining explicit that sovereignty, force, and legitimacy still travel through the institutional and record-bearing surfaces established throughout Part III. Machine collaboration is therefore welcomed as capability, but refused as constitutional substitution.

A helpful way to state the rule is:

a) machines may increase throughput;\
b) machines may increase analytic reach;\
c) machines may increase internal coherence;\
d) machines may not create new force-bearing centers of the architecture.

That single clarification prevents a great deal of future confusion. It makes plain that the point of advanced intelligence in Nexus is to improve the rail’s capacity, not to alter the constitutional location of authority.

#### 3.30.24 The final synthesis of Part III

Part III has progressively built the architecture from semantics and protocol, through validity-by-record, firewall doctrine, invariants, layering, runtime and host geometry, sequence truth, artifact doctrine, routeability, non-execution, role purity, authority surfaces, dual-logging, trust, sovereign compute, multi-plane runtime topology, and replay-safe state. The model plane and decision plane are the final synthesis of all of those disciplines. They are where the rail proves that advanced intelligence and advanced automation can be admitted without dissolving the constitutional-operating order that gives the rail its legitimacy.

That synthesis can be stated plainly.

a) The semantic and protocol layers define what objects are and how they may change.\
b) The record, authority, and dual-logging layers define when those changes become real.\
c) The trust, compute, control, and multi-plane runtime layers define how those realities are carried across the estate.\
d) The model and decision layers define how intelligence may augment the estate without becoming its hidden sovereign.

This is the correct conclusion to Part III. The architecture is now complete enough to support consequential operation without sacrificing constitutional truth. It can carry dense technical capability, distributed runtime, bounded routeability, machine-governable standing, and advanced analytical assistance while still preserving the decisive fact that force, legitimacy, and consequence remain institutional and record-bound.

The real achievement is therefore not that Nexus has “AI.” It is that Nexus has rules strong enough for AI to enter without collapsing the prior architecture. That is the distinction between a technologically ambitious system and a constitutionally serious one.

#### 3.30.25 Closing formulation of Part III

The model plane, decision plane, and bounded human–machine collaboration doctrine may therefore be stated in one integrated formulation: Nexus admits advanced models, simulations, retrieval systems, assistive automation, and bounded agentic components into the rail only as governed participants within a constitutional-operating order in which identity, standing, attestation, policy, artifact class, stage truth, human authority, record validity, replay-safe traceability, and non-execution boundaries remain controlling. Models may extend the rail’s perception, memory, synthesis, procedural capacity, and bounded operational responsiveness. They may not replace the authority surfaces through which force, legitimacy, and consequence are made real.

With this, Part III reaches its final form. It establishes the constitutional-operating substrate of Nexus as one rail, two stacks, multiple record and runtime planes, bounded routeability, sovereign compute, trust-anchored topology, replay-safe state, and machine-governable but human-authorized intelligence across the estate. The architecture is now ready to move from substrate to realization.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/acceleration/nexus-compute/iii.-doctrine/3.30-model-plane.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.