# 3.23 Designated Acts

### 3.23 Designated Acts, Dual-Logging, and Force-of-Effect Across Register and Ledger

#### 3.23.1 The governing proposition

Designated Acts are those acts within Nexus whose constitutional significance, reliance consequence, interoperability effect, or downstream sensitivity is so material that they do not acquire full force through ordinary institutional activity alone. They require heightened formalization, heightened traceability, and heightened convergence between the legal-constitutional record plane and the protocol-integrity record plane. The architecture answers that requirement through dual-logging. Dual-logging is the doctrine under which certain acts achieve their full operative effect only when they are both validly entered in the authoritative Register and validly anchored in the Ledger under the correct schema, identity, and version posture.

This doctrine is one of the central constitutional inventions of the ecosystem. It recognizes that in a sovereign-grade, multi-layer, multi-actor architecture, neither legal-formal record nor technical state trace alone is sufficient for the highest-consequence acts. The Register preserves legal intelligibility, institutional memory, public-authority readability, and challengeable constitutional form. The Ledger preserves protocol continuity, machine-tractability, anti-tamper lineage, and distributed interoperability. Designated Acts therefore sit at the intersection of both. They are the acts for which the architecture says, in effect, that meaning and machine state must converge before full force can be claimed.

#### 3.23.2 Why Designated Acts require special treatment

Not all acts in Nexus carry the same consequence profile. Many acts are routine, bounded, informational, or operationally local. Others alter status, standing, routeability, host condition, continuity posture, public claims, or downstream reliance in ways that can materially affect sovereign interpretation, partner conduct, capital confidence, public communications, or execution-side interface. If such acts were treated as ordinary workflow events, the architecture would become too easy to misread and too hard to audit. If they were treated as purely legal records, the machine-usable discipline of the rail would weaken. If they were treated as purely technical events, their institutional force would become opaque.

Designated Acts therefore exist because some decisions and transitions are too important to leave in one plane only. They need a stronger doctrine of reality. They need the architecture to be able to say not only that an act occurred, but that it occurred in the right form, through the right authority surface, with the right records effect, in the right version relation, and with the right protocol trace attached. This is what dual-logging provides.

#### 3.23.3 Designated Acts in their strongest definition

A Designated Act is a formally classified act whose force, validity, or reliance consequence is conditioned upon heightened procedural sufficiency and dual-plane traceability. It is not simply an act that feels important. It is an act that the architecture has explicitly identified as requiring:

a) a defined decision schema;

b) a competent authority surface;

c) a record-valid Register entry;

d) a corresponding Ledger anchor or state event;

e) version, correction, and supersession discipline;

f) clear force-of-effect boundaries.

A Designated Act is therefore an architectural class, not a rhetorical label. Once an act is designated, it enters a stricter constitutional regime. It becomes subject to stronger publication discipline, stronger traceability, stronger challenge posture, and stronger mismatch sensitivity. That is exactly as it should be. The more consequential the act, the less the architecture should rely on informal inference.

#### 3.23.4 Why force-of-effect must be graduated rather than binary

The architecture does not benefit from pretending that all acts are equal or that every valid act carries the same force. Force-of-effect must therefore be graduated. Some acts create internal workflow consequences only. Some create recorded governance consequences. Some create recognized readiness consequences. Some create routeability consequences. Some alter public or partner-facing posture. Some establish preconditions for downstream incorporation into licensed execution. Designated Acts sit at the upper end of this spectrum.

This graded force structure is essential because it prevents both inflation and unnecessary rigidity. It prevents the system from treating every memorandum as if it were an amendment, and it prevents the system from treating every constitutional act as if it were just another process step. Designated Acts are the point at which the architecture signals that an act matters enough that both the Register and the Ledger must agree, or at least converge within the allowed logic, before the strongest claims may attach.

#### 3.23.5 The Register in the dual-logging doctrine

Within the doctrine of Designated Acts, the Register is the legal-constitutional record plane. It is where the act becomes visible as an attributable, classed, versioned, reviewable, and institutionally legible event. The Register preserves the act in a form that can be interpreted by Boards, Councils, public institutions, sovereign readers, regulated partners, and later auditors without requiring them to inspect or understand internal protocol machinery.

For Designated Acts, the Register must carry, at minimum:

a) subject identity;

b) act class;

c) authority surface and decision basis;

d) date and time of valid recording;

e) version posture;

f) scope of force;

g) correction or supersession relation where relevant.

Without the Register, a Designated Act may still be technically visible in some machine-readable environment, but it would lack the institutional legibility necessary for serious consequence. That is why Register entry is indispensable.

#### 3.23.6 The Ledger in the dual-logging doctrine

The Ledger is the protocol-integrity plane of the same doctrine. It is where the act acquires machine-tractable continuity, cryptographic or integrity-bearing anchoring as appropriate, traceable linkage to artifact sets, state transitions, entitlement posture, and interoperable protocol identity across the wider ecosystem. The Ledger ensures that Designated Acts do not live only in prose or committee memory. They become part of the distributed operational truth of the rail.

For Designated Acts, the Ledger should preserve, in bounded and non-PII-sensitive form where relevant:

a) act identifier and class;

b) linked subject and object references;

c) state transition logic;

d) version and supersession pointer;

e) timing and sequencing integrity;

f) distribution or entitlement implications where material;

g) integrity anchor sufficient to support later verification.

Without the Ledger, the act may remain legally legible but technically weak. It may be difficult to propagate, hard to verify across layers, or vulnerable to silent divergence between documents and systems. That is precisely why the second plane exists.

#### 3.23.7 Why dual-logging is not duplication for its own sake

Dual-logging is sometimes misunderstood as ceremonial redundancy. It is not. It is a deliberate response to the reality that legal-institutional force and protocol-operational force are different kinds of reality that must converge for certain acts. The Register and the Ledger are not duplicates because they do not do the same work. The Register preserves formal intelligibility. The Ledger preserves operational integrity. The Register answers, “What is the recognized institutional act?” The Ledger answers, “How is that act fixed inside the living protocol and state system?”

The value of dual-logging therefore lies not in repetition but in cross-confirmation. It gives the architecture a stronger answer to disputes, correction, interoperability, and audit. It reduces the risk that one institutional surface believes a matter is in force while another surface behaves as though it is not. For Designated Acts, that reduction in ambiguity is one of the main sources of trust.

#### 3.23.8 The doctrine of convergent validity

The deeper constitutional logic of dual-logging is convergent validity. A Designated Act reaches full architecture-grade force when the Register and Ledger converge on the same act identity, class, subject, state, and version posture within the accepted timing and procedural rules. Convergence does not always require simultaneity in the narrow temporal sense, but it does require that the two planes resolve to one coherent event rather than two loosely related interpretations.

Convergent validity is one of the architecture’s most important anti-drift devices because it prevents the familiar failure mode in which:

a) the legal record says one thing;

b) the technical state says another;

c) public summaries say a third; and

d) counterparties rely on whichever version is most convenient.

Nexus does not allow that fragmentation for high-consequence acts. It requires convergence. That is why Designated Acts occupy a distinct category.

#### 3.23.9 What kinds of acts should be designated

Not every act should be designated. Over-designation would make the system slow and ceremonial. Under-designation would make it fragile. The correct class of Designated Acts generally includes those acts that alter constitutional or routeable reality in a meaningful way. These may include:

a) recognition or withdrawal of significant standing;

b) activation, suspension, downgrade, or restoration of high-consequence pathway states;

c) formal designation of major host or continuity-bearing arrangements;

d) routeability-class changes for materially consequential pathways;

e) major corrections, supersessions, or withdrawals of high-force artifacts;

f) reserved-matter decisions affecting rights, architecture, or force boundaries;

g) any act whose downstream reliance consequence is materially increased by its occurrence.

The exact schedule of Designated Acts belongs to the constitutional instruments and decision schemas, but the logic is clear: designate the acts whose ambiguity would be structurally costly.

#### 3.23.10 Designated Acts and the rule of explicit classification

A matter does not become a Designated Act by atmosphere. It must be explicitly classified as such. This is essential because otherwise participants will later argue about whether heightened sufficiency was required. The system must therefore identify, at or before the moment of action, whether the act belongs to the designated class.

Explicit classification should disclose, in controlled form:

a) that the act is designated;

b) the category of designation;

c) the required Register conditions;

d) the required Ledger conditions;

e) the expected force-of-effect if convergence is achieved;

f) the interim posture if convergence is incomplete.

This discipline protects the system against retrospective inflation and retrospective excuse-making. The act either entered the higher regime or it did not.

#### 3.23.11 Force-of-effect across three states: pending, converged, and impaired

For practical purposes, the force of a Designated Act should be understood across at least three states.

A **pending** state exists where one plane has been validly completed and the second is required but not yet completed within the allowed logic. The act may have limited interim effect, but not full designated effect.

A **converged** state exists where both Register and Ledger conditions have been satisfied and no material contradiction exists. This is the state of full designated force.

An **impaired** state exists where divergence, failed logging, invalid classification, later correction, or other material defect has weakened, narrowed, or suspended the act’s strongest force.

This three-state model is useful because it allows the architecture to remain honest without overreacting to every timing difference. It also makes clear that full force is something earned through convergence, not something assumed from one partial success.

#### 3.23.12 Interim effect and the doctrine of limited force pending convergence

There will be cases in which one plane validly records an act before the other completes its side of the dual-logging process. The architecture must therefore specify whether any limited interim effect exists. In most cases, the correct doctrine is limited force pending convergence. That means the act may be treated as initiated, provisionally recognized, or not-yet-final depending on class, but may not yet support the strongest downstream claims attached to full designated force.

This doctrine is superior to both extremes. It is better than pretending nothing exists until every plane closes, and it is better than pretending full force has already arisen from partial logging. Limited force pending convergence gives the system a disciplined middle. It also creates a clear incentive to complete the convergence path quickly and correctly.

#### 3.23.13 Mismatch lock as a constitutional safeguard

Mismatch lock is one of the most important controls in the dual-logging system. A mismatch lock is the rule that when Register and Ledger materially diverge on a Designated Act, the system may not silently continue as though full force exists. Instead, the act enters a protected posture in which stronger claims, further derivative actions, or certain downstream uses are paused, narrowed, or marked until the mismatch is resolved.

This safeguard is essential because divergence is not merely a technical bug or clerical discrepancy. In a high-consequence architecture, divergence creates ambiguity about what the system believes to be true. The correct response is therefore neither denial nor chaos. It is controlled suspension or narrowing. Mismatch lock is the architecture’s way of saying: integrity first, motion second.

#### 3.23.14 Types of mismatch that matter

Not every difference between the Register and Ledger is material. The architecture should distinguish between benign timing lag and material mismatch. Material mismatch typically includes:

a) disagreement on act identity;

b) disagreement on subject or object of the act;

c) disagreement on state transition or class;

d) disagreement on version or supersession status;

e) missing anchor where required for full force;

f) contradictory correction or withdrawal posture.

Benign timing lag may be tolerated within defined windows if the rest of the alignment remains intact. Material mismatch may not. This differentiation is crucial because otherwise the system either becomes over-sensitive or dangerously casual. The correct doctrine is proportional integrity.

#### 3.23.15 Resolution logic for mismatch events

A mismatch event requires an explicit resolution path. The architecture must not rely on informal coordination to restore convergence in high-consequence cases. Resolution logic should therefore answer:

a) who detects and classifies the mismatch;

b) which authority surface owns the review;

c) what interim force posture applies while review is underway;

d) what record is created to track the mismatch;

e) how the resolution outcome is itself dual-logged or otherwise validated.

This is one of the places where the authority-surface doctrine, records-validity doctrine, and correction doctrine come together. A mismatch cannot be fixed merely by editing whichever plane seems easier to change. It must be resolved through the correct constitutional-operating path.

#### 3.23.16 Designated Acts and derivative artifacts

A high-consequence problem often arises not in the act itself, but in the derivative artifacts built around it. Public-safe summaries, host notes, routeability briefs, dashboards, investor-facing documents, or regional extracts may continue to treat the act as fully force-bearing when dual-logging has not converged or has been impaired. The architecture must therefore make clear that no derivative may exceed the force of the underlying Designated Act.

This means derivative artifacts must inherit:

a) the act’s current force posture;

b) any pending or impaired markers;

c) any mismatch or correction warnings relevant to reliance;

d) the version and supersession state of the underlying act.

Without this rule, the dual-logging discipline could remain technically sound while being textually undermined by its own summaries. Nexus must not allow that loophole.

#### 3.23.17 Dual-logging and public claims discipline

The doctrine of public claims discipline becomes especially strict around Designated Acts. A public statement that implies recognition, standing, activation, routeability advancement, host status change, institutional validity, or another high-consequence state must not outpace the dual-logged reality of the underlying act. If convergence is pending, the public claim must reflect that. If convergence is impaired, the public claim must narrow accordingly. If full force exists, the claim may say so in the right terms.

This is one of the strongest anti-inflation controls in the entire system. It ensures that the architecture’s most visible claims remain downstream of its strongest internal truth mechanisms, not upstream of them.

#### 3.23.18 Dual-logging and entitlement logic

Some Designated Acts may have entitlement consequences inside the system. For example, an act may change who may publish, who may route, who may present as standing in a certain role, who may access certain controlled environments, or what a given pathway may claim. In such cases, dual-logging becomes especially important because entitlement changes are one of the fastest ways a classification error can turn into operational drift.

The correct doctrine is that entitlement-sensitive Designated Acts should not achieve their strongest operative consequences until the required convergence exists. This keeps the architecture from turning provisional or disputed acts into live capability changes too early. It is another form of integrity before speed.

#### 3.23.19 Designated Acts and amendment-grade decisions

Some decisions are not merely designated; they approach amendment-grade or architecture-grade consequence. These include acts that materially alter the one-rail doctrine, stack boundaries, family roles, ownership logic, or force-of-effect doctrines themselves. Such acts require the highest combination of authority, quorum, record precision, and dual-logging rigor. They should be treated as the most sensitive class in the entire act taxonomy.

This distinction matters because it prevents the system from treating all designated acts as equal. A routeability classification change and a constitutional architecture change may both be designated. They are not identical in consequence. The dual-logging doctrine must therefore remain scalable across classes of seriousness, with stronger acts receiving stronger procedural treatment.

#### 3.23.20 Correction, supersession, and force rollback

A major advantage of dual-logging is that it makes force rollback more disciplined. When a Designated Act must be corrected, superseded, narrowed, or withdrawn, the architecture can do more than merely issue a new memorandum. It can explicitly mark the old act’s Register state, explicitly alter or anchor the new state in the Ledger, and visibly preserve the transition. This gives the system a much cleaner approach to force rollback.

Force rollback matters because the highest-consequence acts are also the hardest to correct in ordinary institutions. Participants resist admitting change because too many downstream uses depend on the prior act. Nexus solves this by making correction part of the act architecture from the outset. Designated force is strong, but it is not uncorrectable.

#### 3.23.21 Designated Acts and audit-grade accountability

Dual-logged Designated Acts are the architecture’s most audit-grade events. They should be readable not only in the moment, but later, by internal reviewers, external reviewers, sovereign partners, finance actors, and authorized auditors. This is one of the strongest strategic benefits of the doctrine. It does not simply strengthen internal order. It creates a more convincing evidentiary footprint for any later question about what the system recognized, when, how, and on what basis.

This matters enormously in high-consequence, multi-actor pathways. A system that cannot reconstruct its own most important acts loses trust not only prospectively, but retrospectively. Nexus is designed to do better. Designated Acts are where that ambition becomes visible.

#### 3.23.22 Why dual-logging strengthens both sovereignty and interoperability

Dual-logging is not only a control technology. It is also a political and economic architecture. It strengthens sovereignty because it preserves a legally legible, institutionally reviewable Register plane that sovereign and public actors can understand and challenge. It strengthens interoperability because it preserves a machine-tractable, portable, and protocol-aware Ledger plane that allows the same act to be understood across layers, regions, and systems without manual reinvention.

This synthesis is one of the reasons Nexus is stronger than architectures that choose one plane at the expense of the other. Legal-only systems become too slow and opaque in technical interoperability. Tech-only systems become too weak in sovereign and institutional legitimacy. Dual-logging lets the architecture keep both.

#### 3.23.23 The anti-shortcut rule for Designated Acts

The architecture should adopt a strict anti-shortcut rule for Designated Acts. No act may be treated as if it were designated-and-converged merely because:

a) the Register entry exists and the Ledger can be “filled in later” without formal allowance;

b) the Ledger anchor exists and the Register entry is assumed to be obvious;

c) the act is strategically important and therefore “should count”;

d) all relevant people informally agree on the outcome;

e) a derivative artifact has already been circulated.

This anti-shortcut rule is essential because Designated Acts are where pressure to move fast will be greatest. The architecture must therefore say clearly: the more important the act, the less acceptable procedural improvisation becomes.

#### 3.23.24 Practical test for a Designated Act

Every potential Designated Act should be testable through a compact but rigorous sequence.

a) Has the act been explicitly classified as designated.

b) Has the competent authority surface acted within the right decision schema.

c) Has the Register entry been validly created with the right class, scope, and version posture.

d) Has the required Ledger anchor or state event been validly created.

e) Do the two planes converge sufficiently for the class of act.

f) What is the resulting force-of-effect state: pending, converged, or impaired.

g) What derivative claims are therefore permitted or prohibited.

This test turns a potentially abstract doctrine into daily institutional discipline.

#### 3.23.25 Strategic conclusion

Designated Acts, dual-logging, and force-of-effect doctrine together define how Nexus treats its most consequential internal realities. The architecture does not allow such realities to float on informal consensus, single-plane recording, or stylistic implication. It requires convergence between the Register as legal-constitutional memory and the Ledger as protocol-integrity memory. It uses that convergence to determine when full force can arise, when only limited force is permissible, and when mismatch must trigger controlled restraint.

This is one of the central reasons Nexus can carry sovereign seriousness, finance-legibility, technical interoperability, and public-trust discipline at the same time. It knows that the most important acts in a modern governance-and-readiness system must be real in more than one language at once. They must be real to institutions and real to systems. Dual-logging is how the architecture makes that possible without sacrificing truth.

#### 3.23.26 Closing formulation

Designated Acts, dual-logging, and force-of-effect across Register and Ledger may therefore be stated in one integrated formulation: Nexus identifies a defined class of high-consequence acts whose strongest legal, institutional, reliance, interoperability, or entitlement effects arise only when the act is explicitly classified, validly decided, validly entered in the Register, validly anchored in the Ledger, and brought into convergent state across both planes; and it treats any divergence, incompleteness, or later correction as a direct modifier of the act’s force, derivative usability, and public-claims posture.


---

# 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.23-designated-acts.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.