# 3.24 Record Planes ### 3.24 Record Planes, Mismatch Handling, Correction Clocks, and Controlled Supersession #### 3.24.1 The governing proposition Nexus does not rely on one undifferentiated record surface. It relies on record planes. A record plane is a constitutionally distinct layer of institutional memory through which an act, artifact, state, entitlement, or correction is preserved for a specific kind of force, review, interoperability, audit, or outward intelligibility. The architecture needs this plurality because legal-institutional intelligibility, protocol-integrity, runtime continuity, derivative circulation control, and public-safe traceability are not the same problem and must not be solved by the same crude object. Record planes therefore exist to preserve clarity across consequence. Mismatch handling is the doctrine that governs what happens when those planes cease to align. Correction clocks are the doctrine that prevents drift, error, stale circulation, or semantic overhang from persisting indefinitely. Controlled supersession is the doctrine that allows the system to replace, narrow, correct, or retire prior objects without destroying lineage, auditability, or public trust. These four elements belong together because a system that can create records but cannot align them, correct them, and supersede them in disciplined form will eventually become unreadable to itself. #### 3.24.2 Why a single record surface would be inadequate A single record surface is inadequate because Nexus must serve many readers, many machines, many time horizons, and many consequence environments at once. Boards, Councils, sovereign actors, public institutions, auditors, runtime teams, counterparties, technical systems, controlled-room environments, and downstream licensed actors do not all need the same rendering of truth. Some need legal and institutional legibility. Some need state integrity and machine traceability. Some need bounded operational visibility. Some need safe derivative access. A single surface would therefore become either too technical for institutional readers or too narrative for protocol integrity. The architecture accordingly rejects the false simplicity of one universal record layer. It differentiates the legal-constitutional plane from the protocol plane, the runtime plane from the derivative plane, and the public-safe plane from all stronger sources. That differentiation is not bureaucratic layering. It is the only serious way to keep each truth function from corrupting the others. The legal-constitutional plane must remain readable. The protocol plane must remain exact. The operational plane must remain usable. The derivative plane must remain bounded. The public-safe plane must remain subordinate. This differentiated memory structure is one of the reasons the category can scale without collapsing into documentary fog. #### 3.24.3 Record planes in their strongest definition A record plane is a structured layer of recorded truth with its own object classes, force rules, visibility posture, version logic, correction pathway, and audience logic. It is not merely a storage location. It is a governed semantic and operational environment. Each plane answers a distinct question. a) The **Register plane** answers what the architecture has validly recognized, determined, classified, or recorded in legal-institutional terms. b) The **Ledger plane** answers how the architecture has anchored the same or related act in protocol-integrity and machine-tractable form. c) The **Runtime plane** answers what is active, queued, escalated, in-progress, blocked, or staged in the operating system of the architecture. d) The **Derivative plane** answers how stronger artifacts have been narrowed into summaries, packs, controlled-room bundles, route briefs, and other audience-specific objects without losing lineage. e) The **Public-safe plane** answers what may be safely stated outward without implying more than the stronger planes support. These planes are related but not interchangeable. A runtime object is not a Register act. A public-safe summary is not a force-bearing determination. A Ledger anchor is not a safe substitute for institutional record. The architecture remains healthy by preserving these distinctions and by refusing to let any one plane silently absorb the constitutional role of another. #### 3.24.4 The Register plane as legal-institutional memory The Register plane is the legal-institutional memory of Nexus. It preserves those acts, states, recognitions, classifications, and transitions that must remain legible to constitutional organs, sovereign readers, auditors, serious partners, and later review bodies without requiring them to reconstruct the event from technical traces or operational logs. It is the plane of attributable institutional speech. The Register therefore holds determinations, recognition and standing acts, designated host, pathway, or role states, major corrections and supersessions, reserved-matter dispositions, and public-good constitutional and governance records. Its discipline is formal. Its purpose is not speed for its own sake. Its purpose is durable intelligibility. Where the Register is silent, the architecture must be cautious about claiming institutional force. A system that cannot point to the authoritative institutional record of a purported act is not merely incomplete. For many categories of consequence it is still substantively weak. #### 3.24.5 The Ledger plane as protocol-integrity memory The Ledger plane is the protocol-integrity memory of Nexus. It is where state transitions, entitlement changes, convergence events, object identity anchors, version lineage, and related integrity-sensitive events are preserved in a way that supports machine use, auditability, portability, and non-ambiguous state propagation across the living rail. The Ledger is therefore not a mere mirror of the Register. It preserves the operational side of truth. It captures object and act identifiers, state changes and timing relations, version and supersession anchors, entitlement and routeability-relevant state changes where appropriate, and integrity traces necessary for later verification. Where the Register answers, “what did the institution validly say,” the Ledger answers, “what did the system validly anchor and propagate.” For many ordinary matters one of these planes may matter more than the other. For the highest-consequence matters, both must converge. #### 3.24.6 The Runtime plane as controlled operational memory The Runtime plane is the architecture’s controlled operational memory. It is where work queues, evidence assembly states, decision-pack progress, readiness-action status, blocker states, escalation states, dashboard-support states, controlled distribution status, and related operating realities are preserved. This plane is not merely a project-management convenience. It is how the architecture remains recurrent rather than episodic. Yet the Runtime plane does not create force-bearing validity on its own. It records motion, not constitutional reality in the strongest sense. It is therefore indispensable and bounded at once. A runtime object may show that a matter is moving. It does not by itself prove that the matter has been determined, recognized, routed, or superseded unless the relevant force-bearing plane also reflects that outcome. This is one of the key reasons Nexus does not allow dashboards, trackers, or workflow systems to become shadow constitutions. Runtime truth matters, but it matters as operating truth, not as a substitute for formal truth. #### 3.24.7 The Derivative plane as bounded circulation memory The Derivative plane exists because the system must create controlled summaries, proof-pack variants, route briefs, diligence-room subsets, public-safe extracts, Board versions, regional views, and other bounded outputs. These derivatives cannot be treated as free-floating documents. They must remain traceable to stronger sources. The Derivative plane is therefore the memory of narrowing, packaging, audience-specific transformation, and controlled circulation. It preserves parent-source identity, derivative class, audience and handling posture, permitted reliance, distribution and onward-sharing limits, and supersession and correction relation to parent objects. This plane matters because most semantic drift happens not in master instruments but in derivatives. Nexus therefore gives derivatives their own memory discipline rather than treating them as disposable presentations. A derivative that cannot be tied back to a stronger source is not merely inconvenient. It is a governance risk. #### 3.24.8 The Public-safe plane as controlled external memory The Public-safe plane is the outermost and weakest force plane. It consists of those controlled outward-facing artifacts, summaries, notices, and explanatory objects that may be circulated more broadly without exposing restricted detail or implying stronger authority than exists. Its weakness is not a flaw. It is a safety property. A public-safe object is valuable precisely because it is bounded. This plane must therefore preserve subordinate relation to stronger artifacts, reduced or safe handling content, exact claims boundaries, and visible correction and supersession dependence on stronger planes. Without this plane, the architecture would either overexpose sensitive objects or under-communicate entirely. With it, the architecture can speak outward without letting outward speech become the real constitution. This is particularly important in a system where public, sovereign, and partner audiences may encounter derivatives long before they encounter the master record. #### 3.24.9 Why plane separation is an anti-capture device Record-plane separation is also an anti-capture device. When one plane becomes the only plane that matters, the actor closest to that plane often becomes the practical sovereign of the system. If the Register alone mattered, legal-formal control could overshadow operational truth. If the Ledger alone mattered, technical control could overshadow public and sovereign intelligibility. If runtime views alone mattered, operating teams would become hidden authors of reality. If public-safe artifacts alone mattered, communications logic would gradually rewrite force-bearing truth. Nexus prevents this by making the planes interdependent but non-substitutable. Each plane is strong in its own role and weak outside it. That is why record-plane design is not archival detail. It is governance design. Plane separation distributes memory without distributing constitutional ownership of truth. #### 3.24.10 Mismatch in its strongest definition Mismatch occurs when two or more relevant record planes materially diverge in how they represent the identity, class, state, version, force, or correction posture of the same underlying subject. Mismatch is not merely inconsistency of wording. It is a divergence that could mislead the architecture, its operators, or its counterparties about what is true. Mismatch may arise through timing lag, failed or partial dual-logging, improper supersession, stale derivative circulation, invalid runtime assumptions, human or system error, unauthorized local rewrite, or incomplete correction propagation. The architecture must therefore treat mismatch as a first-order governance event rather than as an incidental records nuisance. In a system whose strength depends on multi-plane traceability, unresolved divergence is not clerical disorder. It is a threat to validity. #### 3.24.11 Benign lag versus material mismatch Not every divergence is equally serious. The architecture should distinguish carefully between benign lag and material mismatch. Benign lag is a time-bounded, non-contradictory delay in which one plane has updated and another has not yet updated, but the intended relation remains clear and no stronger force is being claimed than the present state supports. Material mismatch exists when the planes disagree in a way that can affect authority, reliance, routeability, standing, correction posture, or public claims. Examples of material mismatch include different version states across Register and Ledger, derivative packs continuing to describe a matter as active after the Register has narrowed or suspended it, runtime dashboards showing routeable status when the underlying designated act is only pending convergence, or public-safe materials omitting a material correction already recorded elsewhere. The distinction matters because the architecture must neither panic at harmless lag nor minimize consequential divergence. The correct posture is proportional integrity. #### 3.24.12 Mismatch classes For practical governance, mismatch should be classed. A mature taxonomy would distinguish at least the following. a) **Identity mismatch**, where the planes disagree about what object or act is being referenced. b) **State mismatch**, where they disagree about current status or classification. c) **Version mismatch**, where one plane reflects supersession, correction, or withdrawal and another does not. d) **Force mismatch**, where the planes imply different reliance or consequence postures. e) **Visibility mismatch**, where public or derivative planes continue to represent an outdated posture. f) **Entitlement mismatch**, where access, standing, or role keys reflect inconsistent state. This classification allows the system to respond proportionately rather than treating every mismatch as generic disorder. It also makes later learning stronger because the architecture can see not merely that divergence occurred, but what kind of divergence the system is most vulnerable to. #### 3.24.13 The doctrine of mismatch materiality Materiality is the key to disciplined mismatch handling. A mismatch is material when, if left unresolved, it could change how a reasonable institutional, sovereign, runtime, partner, or downstream actor would understand the matter’s standing, routeability, force, or boundary. This is a stronger test than simple textual difference. It asks whether the divergence alters consequence. Materiality should be assessed by reference to subject matter, stage of the operating sequence, designated-act status, reliance class, derivative circulation breadth, proximity to routing or downstream incorporation, and potential for public or partner misinterpretation. This doctrine ensures that the architecture directs its strongest correction energy where trust is most at risk, rather than exhausting itself on low-consequence variation while missing the divergence that actually matters. #### 3.24.14 Mismatch detection and first response The architecture should assume that some mismatches will occur and design for rapid detection rather than relying on occasional discovery. Detection may arise through registry checks, ledger reconciliation, dashboard controls, derivative-review workflows, controlled-room refresh checks, runtime review, or explicit challenge from authorized actors. Once detected, the first response should not be improvisation. It should be classification. The first-response sequence should therefore be: detect, classify mismatch type, assess materiality, determine interim force posture, trigger correction clock, and assign owning authority surface. This makes mismatch handling constitutional rather than ad hoc. It converts error into governed motion. The architecture becomes more trustworthy not by pretending mismatches will never occur, but by ensuring they are surfaced and disciplined before they become normalized. #### 3.24.15 Interim force under mismatch A key doctrine of this section is that material mismatch changes interim force. The architecture must not continue using the strongest reading of an object once material mismatch is known. Depending on class and consequence, the correct interim posture may be: a) continue with no change, where mismatch is non-material; b) continue with caveat, where force is mostly intact but qualification is necessary; c) narrow claims immediately, where derivative or public-safe artifacts may no longer use prior language; d) suspend strongest force, where designated or routeability-sensitive uses must pause; e) temporarily freeze downstream use, where the mismatch could materially mislead a counterparty or public actor. This discipline protects trust by ensuring the system’s reaction to known divergence is visible and proportionate. Integrity, not convenience, governs the interim state. #### 3.24.16 Correction clocks in their strongest definition Correction clocks are the architecture’s time-discipline for restoring truth after error, drift, stale circulation, or mismatch. They are essential because a system without time-bound correction becomes too tolerant of inaccuracy. Correction clocks do not guarantee instant perfection. They guarantee that the system has a constitutional expectation of response rather than indefinite tolerance. A correction clock should always specify triggering event, responsible authority surface, maximum time to initial classification, maximum time to interim notice where required, maximum time to substantive correction or justified extension, and redistribution and reconciliation obligations. The purpose of a correction clock is not merely speed. It is integrity under time. A system that knows an error exists but has no disciplined timeline for response is already drifting toward unreliability. #### 3.24.17 Clock tiers by consequence class The most robust correction-clock architecture will be tiered. Different mismatches and corrections carry different risk. A likely tiering model would distinguish: a) **Immediate or near-immediate clocks** for public misstatement, safety-sensitive routeability drift, sanctions-sensitive artifact misuse, or entitlement mismatch with live access implications. b) **Short clocks** for material version or force mismatches affecting controlled-room use, routeability status, or designated acts. c) **Standard clocks** for derivative or runtime inconsistencies without immediate external consequence. d) **Longer clocks** for historical cleanup, metadata improvement, or low-consequence archival normalization. This tiering allows the architecture to be strict without being mechanically unrealistic. It also helps the system explain why some matters require stop-the-line response and others require disciplined but less urgent cleanup. That proportionality is critical to making correction discipline durable. #### 3.24.18 Correction notices and the doctrine of visible truth restoration A correction should not be treated as silent housekeeping where the prior state had force beyond the narrowest internal circle. Nexus therefore requires visible truth restoration when a prior artifact, record, or public-safe representation has become materially inaccurate. The exact form may differ by plane and handling class, but the doctrine remains: if the system caused others reasonably to understand a matter one way, and that understanding is now materially wrong, the restoration of truth must itself be an artifact. Correction notices therefore matter because they preserve auditability, reduce ambiguity about when truth changed, prevent stale copies from silently remaining authoritative, and keep the system from benefiting reputationally from leaving old stronger statements unchallenged. This is one of the main ways Nexus turns correctionability into trust rather than embarrassment. #### 3.24.19 Controlled supersession in its strongest definition Controlled supersession is the disciplined replacement, narrowing, or retirement of a prior object by a later object in a manner that preserves lineage, prevents silent contradiction, and makes the force transition legible across all relevant planes. Controlled supersession is not deletion, nor is it unrestricted replacement. It is a governed act. For supersession to be controlled, at minimum, the newer object must identify the older object, the type of supersession must be stated, the continuing force of the older object if any must be defined, derivative and public-safe propagation rules must be clear, ledger and register relations must be aligned as required, and redistribution or recall logic must be triggered where relevant. Supersession is therefore not only about the new object. It is equally about how the old object is retired from force without being erased from memory. #### 3.24.20 Supersession types A mature supersession doctrine should distinguish several types rather than using one universal label. a) **Full supersession**, where the older object is wholly replaced for current-force purposes. b) **Narrowing supersession**, where the older object remains partly valid but under reduced scope. c) **Corrective supersession**, where the older object remains relevant as history but must no longer be relied on without the corrective overlay. d) **Emergency supersession**, where a rapid replacement or hold is necessary to protect integrity pending fuller review. e) **Administrative supersession**, where content remains substantively unchanged but version or handling structure has been rebuilt. These distinctions are important because they help downstream readers understand not only that change occurred, but what sort of change occurred. Precision here reduces the risk that later readers mistake a narrow correction for a total collapse or a technical refresh for a substantive redesign. #### 3.24.21 Supersession and derivative propagation Supersession is incomplete if it remains trapped in the master plane. The architecture must therefore propagate supersession across derivatives, controlled-room bundles, dashboards, routeability briefs, public-safe summaries, and entitlement-sensitive interfaces. This does not always require immediate full rebuild of every derivative. It does require that no derivative continue representing the superseded posture as current once propagation thresholds are crossed. Derivative propagation may require immediate invalidation of certain outward-facing artifacts, visible warning banners or notices in controlled rooms, dashboard state change, refreshed public-safe summaries, or access restriction where stale artifacts could mislead. This is another reason the Derivative plane has its own memory logic. Without it, supersession would remain formally correct but practically ineffective. #### 3.24.22 Controlled recall and redistribution reconciliation High-consequence supersession often requires more than publishing a new object. It requires recall logic. Controlled recall does not necessarily mean literally deleting prior circulation. It means actively identifying which recipients received which versions and what correction or replacement obligations now apply. Redistribution reconciliation is the discipline that tracks this outward repair. This matters especially for proof packs in diligence environments, routeability and handoff artifacts already shared externally, public-safe summaries that may have spread widely, and host or role classification artifacts affecting standing or access. A system that can supersede internally but cannot reconcile externally remains only partially correct. Nexus must therefore know not only that truth has changed, but where the earlier truth traveled and how repair is to occur. #### 3.24.23 No-silent-edit as the binding rule across all planes The no-silent-edit doctrine binds the whole section together. Record planes may be updated, corrected, narrowed, or superseded. They may not be silently rewritten where force-bearing meaning, reliance posture, lineage, or public or external understanding would thereby be obscured. This rule is one of the core trust mechanisms of the architecture. It ensures that later exactness does not come at the price of historical dishonesty. No-silent-edit applies differently by plane, but the principle remains the same. The stronger the force of the object, the stronger the duty to preserve visible change. This is why the architecture can improve itself without rewriting its past as if it had always already been correct. Historical trace is not an embarrassment in Nexus. It is part of institutional seriousness. #### 3.24.24 Why controlled supersession is superior to brute replacement Brute replacement is attractive in fast-moving systems because it reduces clutter and simplifies the present view. But in a sovereign-grade, public-trust, finance-facing architecture, brute replacement creates severe problems. It destroys lineage, weakens audit, obscures reliance history, and makes later dispute harder to resolve. Controlled supersession is superior because it preserves both present clarity and historical trace. This matters not only for audit, but for learning. The architecture must be able to know how its objects changed, why they changed, who changed them, and what downstream environments had to adapt. Controlled supersession therefore strengthens both truth and institutional memory. It allows the system to be dynamic without becoming revisionist. #### 3.24.25 Mismatch handling as a trust discipline rather than an exception process Mismatch handling should not be seen as the emergency repair room of an otherwise clean system. It is part of normal constitutional hygiene in a multi-plane architecture. The existence of mismatch procedures does not imply weakness. It implies seriousness. A system that admits the possibility of divergence and governs it openly is more trustworthy than one that pretends its records can never fall out of alignment. This is especially important in a category designed for sovereign, public-purpose, and finance-facing use. Such environments do not reward systems that hide their correction mechanics. They reward systems that can demonstrate how disagreement, drift, and stale circulation are identified, constrained, and repaired without loss of lineage. #### 3.24.26 Strategic conclusion Record planes, mismatch handling, correction clocks, and controlled supersession together define how Nexus preserves truth across time rather than only at a moment of creation. The Register preserves legal-institutional meaning. The Ledger preserves protocol-integrity meaning. Runtime, derivative, and public-safe planes preserve controlled operational and outward-facing use. Mismatch handling prevents divergence from becoming normalized. Correction clocks prevent error from becoming stale doctrine. Controlled supersession allows improvement without erasure and replacement without confusion. This is one of the deepest reasons the architecture can claim durability. It does not merely create objects. It governs their life, their disagreement, their correction, and their retirement. In a category designed to support sovereign, public-purpose, and finance-facing consequence without becoming execution, that temporal discipline is not secondary. It is one of the foundations of trust. #### 3.24.27 Closing formulation Record planes, mismatch handling, correction clocks, and controlled supersession may therefore be stated in one integrated formulation: Nexus preserves multiple constitutionally distinct planes of recorded truth, each with its own force, audience, and operational role; treats any material divergence among those planes as a governed mismatch requiring classification, interim-force control, and time-bound repair; subjects all consequential inaccuracy to explicit correction clocks; and replaces or narrows prior objects only through controlled supersession that preserves lineage, redistribution accountability, and visible truth restoration rather than silent replacement. --- # 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.24-record-planes.md?ask= ``` 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.