Authorization for Self-Modifying AI Agent Populations: Conserving Authority across Replacement, Forking, and Rollback

Genliang Zhu; Chu Wang

Source-linked AI summary

Authorization for Self-Modifying AI Agent Populations: Conserving Authority across Replacement, Forking, and Rollback

Genliang Zhu, Chu Wang

arXiv:2610.00347v1Sep 29, 2026cs.CRcs.AI

TL;DR

Per-successor authorization does not constrain the combined authority of a live population of self-modifying agents. The paper defines authorization succession and an external protocol for conserving authority across generations. Under registered assumptions, it proves population-safe succession and related safety properties for protected effects mediated by registered brokers.

Problem
Per-successor authorization does not constrain the combined authority of live generations that can fork, replace, or roll back.
Source: §1 · p. 1
Method
An external ledger and broker track fresh generation identities, lineage, and allocations, with staged reservations and atomic succession commits.
Source: §5.2 · p. 16, §5.5 · p. 18, §11 · p. 34
Results
Under A1–A10, accepted effects have a current active generation and authority witness, with population bounds, revocation closure, atomic handoff, and no historical authority replay.
Source: §4.6 · p. 15, §10.1 · p. 32
Takeaways & Limitations
Authorization succession conserves authority across the registered generation frontier by reallocating grants rather than copying them.
Source: §11 · p. 34
The results cover registered graphs, profiles, and mediated effects, not arbitrary program equivalence or the correctness of external evaluator judgments.
Source: §3.6 · p. 7

Abstract

from arXiv · show

Self-modifying AI agents can replace, fork, and roll back identity-bearing software while descendants remain executable. Per-successor authorization does not constrain the resulting population: siblings may duplicate quotas, combine permissions, survive ancestor cuts, or overlap predecessors during promotion. We define authorization succession, which conserves authority across the active frontier of a single-parent generation forest. Our external protocol binds each generation to a manifest, root, unique parent, complete lineage, and fresh population sequence. Separate invariants bound root-lifetime consumption and current population exposure. A staged reservation freezes predecessor residual authority during replacement, while a partitioning fork validates the complete child family. Each commit atomically fences the predecessor and activates successors. Ancestor cuts invalidate dependent descendants; rollback creates a fresh generation without restoring spent authority; and a new root requires an independent grant. Under complete mediation, authenticated records, sound effect abstraction, durable monotone state, and complete lineage accounting, we prove population-safe succession, fork conservation, revocation closure, atomic handoff, rollback non-reminting, and exclusion of self-certification. An executable evaluation covers 32 registered decisions through direct-call and mailbox mappings (64/64 replays; 28 allows, 36 denies). An independent checker accepts all 64 original traces and rejects 28/28 semantic mutants; 12/12 profile invariants, 16/16 crash cuts, and 32/32 contender schedules pass. Two external adapters reproduce all 32 decisions around measured OurArk and Darwin Godel Machine mutations, including fresh-process restart, atomic succession, and predecessor rejection. The results establish authorization succession for registered protected effects.

1 Introduction

Self-modifying agents make authorization a population problem: individually acceptable successors can collectively duplicate or combine authority. The paper defines authorization succession and an external protocol to conserve authority across generations, with guarantees bounded by registered effects and assumptions.

1.1 A strict population counterexample

A per-successor grant can let two benign siblings double a payment budget and executor slots, then combine partial permissions into an unauthorized effect.Cached descendants, non-atomic replacement, and historical rollback also expose revocation, dual-active, and replay gaps.Source: §1.1 · p. 2

1.2 Authorization succession across generations

Authorization succession allocates descendants within both a root’s lifetime grant and a persistent ceiling on current population exposure.Forking reallocates existing authority rather than copying it.Source: §1.2 · p. 2
The protocol quarantines candidates, reserves residual authority, and atomically fences a predecessor while activating replacement successors.Ancestor cuts invalidate dependent descendants; rollback creates a fresh generation without restoring historical authority.Source: §1.2 · p. 2

1.3 Contributions

The contributions include a lineage-based authorization model, population bounds, a succession protocol, conditional safety results, and executable evaluation across two runtime mappings.The evaluation also uses an independent trace checker and two adapters to frozen public runtimes.Source: §1.3 · p. 3

1.4 Assurance scope

The assurance covers operation-time authorization at registered effect brokers, not arbitrary program equivalence, evaluator correctness, or effects outside mediation.Already committed physical outcomes are also outside the stated property.Source: §1.4 · p. 3

2 Problem Setting and Separating Executions

The section distinguishes software-body identity from authorization lifetime and explains why candidate-by-candidate acceptance cannot conserve authority across a population. It frames succession operations and requirements around lineage and aggregate population state.

2 Problem Setting and Separating Executions

Authorization succession concerns versioned identity, capability transfer, revocation, and distributed cutover across a changing generation population.The section distinguishes this problem from adjacent controls.Source: §2 · p. 3

2.1 Artifact identity is not generation authority

A body commitment, generation principal, and authority allocation represent distinct objects; identical body content does not alias generation principals.A generation principal binds the body commitment to its authorization parent, lineage root, fresh sequence, and creation transaction.Source: §2.1 · p. 4

2.2 Lifecycle acceptance is not population conservation

Candidate acceptance alone loses population information: sibling checks can duplicate Boolean capabilities or additive budgets and combine partial relational permissions.Protected effects are modeled as complete typed tuples, with explicit quantitative shares.Source: §2.2 · p. 4

2.3 Succession operations

Replacement atomically fences one predecessor and activates one successor; a partitioning fork activates children whose allocations fit the predecessor’s unspent residual.Sibling coordination does not create an authorization parent edge or union grants; rollback instead uses a fresh generation sequence and authorization decision.Source: §2.3 · pp. 4–5

2.4 Six strict separating executions

Table 1 identifies minimum executions where locally valid artifacts violate population safety only when lineage and population state are considered together.The supplied passage does not state the table’s individual execution outcomes.Source: §2.4 · p. 5, Table 1 · p. 5

2.5 Design requirements

The requirements include fresh generation identity, discoverable lineage, aggregate authority allocation, independent promotion evidence, atomic updates, ancestor revocation, and commit-time validation.A cooperative process promise is insufficient for protected-effect validation.Source: §2.5 · p. 5

3 System, Threat, and Assurance Model

The assurance model makes authorization a property of committed effects, active generations, and complete lineage state. Its claims depend on an external trusted boundary, registered assumptions, and a fixed decision profile.

3.1 Assurance statement

Accepted effects must have one current active generation and complete authority witness, while aggregate descendant authority stays within root and population bounds.A durable revocation cut bars descendants relying on the revoked ancestor; rollback does not restore historical authority.Source: §3.1 · p. 6

3.2 Components and trusted boundary

The registry, ledger, evidence bindings, and effect broker sit outside the mutable generation boundary and may be separate processes or one isolated service.The broker checks lineage, allocation, effect, budget, and revocation state in the serialized operation that reserves or commits an effect.Source: §3.2 · p. 6

3.3 Adversary and fault model

The adversary may fork, replay records, delay descendants, restore historical bodies, and crash at durable boundaries, but cannot rewrite committed ledger records or bypass all registered brokers.Authentication is an abstract premise; the prototype does not authenticate callers, prove key possession, or implement public-key signatures.Source: §3.3 · pp. 6–7

3.4 Assurance assumptions

The formal results rely on A1–A10 safety assumptions, including mediation, authenticated identity, durable monotone state, complete lineage accounting, and atomic transactions.A compromised broker, omitted effect path, incomplete lineage registration, or unsound normalizer violates an explicit premise.Source: §3.3 · p. 7, §3.4 · p. 7

3.5 Registered profile and decision surface

The registered profile fixes identity, effect normalization, authority, evidence independence, succession operations, and brokers; unknown or unavailable state remains indeterminate or quarantined.The reference profile implements single-parent succession, fork, rollback, cuts, and independent re-root, but not multi-parent merge.Source: §3.5 · p. 7

3.6 Assurance boundary

The theorems enforce the supplied policy relation over registered graphs and mediated effects, not arbitrary code equivalence or the correctness of external factual judgments.Evidence admission and profile governance supply those inputs.Source: §3.6 · p. 7

4 Formal Model

The formal model treats authorization as conserved across mutable generations, distinguishing identity, lineage, allocation, and artifact provenance, and establishes safety properties for succession, forking, revocation, handoff, rollback, and certification within the registered effect boundary. These results apply only to the specified manifest, authority, authentication, and transition realization; they do not claim semantic equivalence for arbitrary code or models.

4.1 Assumptions, abstraction, and trusted boundary

The model assumes complete mediation, authenticated identity and records, durable monotone state, complete lineage accounting, and atomic transactions, while limiting artifact claims to its fixed reference profile.The artifact does not implement public-key signature verification, multi-parent identity, merges, arbitrary program equivalence, unmanifested-path discovery, or validation of certifier observations; caller authentication remains a deployment premise.Source: §4.1 · p. 9

4.2 Generation identity and authorization lineage

Each generation has one unique authorization parent within one root lifetime, and a fresh population-issued sequence distinguishes its identity even when content is reused.Copied code or artifacts may be recorded as provenance but do not confer authority; the core transition system has no multi-parent child or merge rule.Source: §4.2 · pp. 9–10

4.3 Authority algebra, root grants, and population ceilings

Root-lifetime authority accounts for irreversible spending, while a separate population ceiling limits current exposure, including after independent re-rooting.The population predicate can express co-possession prohibitions, separation of duties, branch-local constraints, and correlations beyond fieldwise bounds.Source: §4.3 · pp. 10–11

4.4 Certification, transfer, and re-rooting

Successor and fork transfers use certified authorization bound to the predecessor’s residual authority, and every accepted family must satisfy exact post-state root and population bounds.The predecessor is fenced at commit; an independent re-root instead requires a fresh grant from an issuer control root independent of the proposer, fresh evidence, and a fresh generation sequence.Source: §4.4 · pp. 12–13

4.5 Atomic succession and protected-effect admission

Only ACTIVE generations can authorize fresh protected effects, and a single successor or complete child family activates atomically as the predecessor is fenced.Fresh effect admission checks current lineage, permission, and remaining budget; an identical request replay returns its original receipt without a new effect or debit.Source: §4.5 · pp. 13–14

4.6 Safety invariants and main results

Under A1–A10, accepted traces preserve population-safety invariants, and fork descendants’ active allocations remain bounded by the originating allocation.Every committed protected effect is attributable to one generation that was current and unrevoked at admission and within that generation’s allocation.Source: §4.6 · p. 15
After an ancestor cut, no dependent descendant can admit a fresh protected effect; atomic handoff prevents predecessor and successor allocations from being simultaneously exercisable.A generation under an independent re-root is outside the revocation conclusion because its authority contains no old lineage atom.Source: §4.6 · p. 15
Rollback creates a distinct generation that cannot reuse historical authorization records, while candidate-controlled records alone cannot activate a generation.Independent re-rooting imports no old-root allocation; later admitted effects are attributed solely to the fresh root.Source: §4.6 · p. 15
Section 8 applies only to the fixed manifest, authority, authentication, and transition realization described here, not to arbitrary code or models.Neither level claims semantic equivalence for arbitrary code or models.Source: §4.6 · p. 16

5 Authorization Succession Protocol

Authorization succession places generation registration, allocation, succession, revocation, and protected-effect admission behind an external ledger and broker. It conserves authority across a single-parent population through fresh identities, bounded transfers, and atomic transitions.

5.1 Architecture

Only the external population ledger can activate a candidate, and protected effects revalidate current generation and allocation state at the broker.Candidate production and evidence collection do not themselves change the active frontier.Source: §5 · p. 16, §5.1 · p. 16

5.2 Canonical generation identity

A generation identifier commits the manifest, population, root grant, fresh sequence, unique parent, and complete lineage using a domain-separated digest.A rollback may reuse a manifest commitment but receives a new sequence and generation identifier.Source: §5.2 · p. 16

5.3 Candidate and evidence phases

Single-successor promotion stages independent certification and a reservation; a fork instead validates the complete child family before activation.The reference evidence record binds an approval digest to the exact generation and manifest, with proposer and certifier control roots required to differ.Source: §5.3 · p. 17

5.4 Exact authority authorization

Replacement reservations bind the predecessor’s residual and population version, while forks validate child allocations and the exact post-state inline.Both paths preserve spent debits and immutable grants; cumulative root-lifetime debit plus active residuals and aggregate current exposure remain within their respective bounds.Source: §5.4 · pp. 17–18

5.5 Atomic single-parent family handoff

A serializable commit fences the predecessor and activates successors together, so effects are admitted either before handoff under the predecessor or afterward under active children.A crash before commit leaves the predecessor unchanged; a crash after commit recovers the complete post-state.Source: §5.5 · p. 18

5.6 Fork and nested succession

A fork atomically replaces one predecessor with at least two single-parent children whose additive budgets fit its residual and whose reference-profile effect labels are disjoint.Nested forks consume each predecessor residual once; the core protocol has no multi-parent merge transition.Source: §5.6 · p. 19

5.7 Ancestor cuts and independent re-root

Ancestor cuts invalidate dependent descendants at their next mediated transition, while independent re-rooting requires a fresh external grant and leaves the population ceiling in force.Offline descendants need no push message for safety; lineage accounting is required before claiming all dependent descendants are terminal or re-rooted.Source: §5.7 · p. 19

5.8 Rollback without reminting

Rollback creates a fresh generation from a historical manifest without reusing activation records, reservations, cut atoms, or spent budgets.Protected-effect admission checks current identity, active state, uncropped lineage, allocated effects, available budgets, and retry identity; the independent checker reconstructs these invariants and rejects resealed semantic regressions.Source: §5.8 · p. 19, §5.9 · p. 20, §5.10 · p. 20

6 Protocol Instantiations

The protocol is instantiated through two logical dispatch mappings and a durability path, then specified for refinement around frozen public runtimes. The mappings translate different command shapes into the same succession contract; they do not provide independent policy semantics.

6.1 Direct-call mapping

The direct-call mapping routes typed actions through an explicit action-to-operation table and invokes the ledger in the caller’s request path.Its transcript binds the input, operation, event sequence, decision, and prior transcript digest.Source: §6.1 · p. 20

6.2 Message-mailbox mapping

The mailbox mapping translates typed actions into versioned topics and delivery envelopes, then uses topic-specific handlers to construct ledger commands.Delivery ordinals are transport metadata and do not change the semantic request.Source: §6.2 · pp. 20–21

6.3 Common mapping contract

Both mappings share the typed input contract and semantic ledger but use separately coded dispatch translations, so their agreement tests translation shape rather than independent semantics.The frozen profile covers single-parent replacement, fork, nested succession, rollback, and independent re-root, but no multi-parent merge.Source: §6.3 · p. 21

6.4 Mutation-surface normalization

Six mutation surfaces are normalized into safe refactor, safe narrowing, effect expansion, or control-path weakening, using corpus ground-truth deltas rather than general semantic-equivalence classification.Native success is evidence, not authority; activation still requires an external receipt.Source: §6.4 · p. 21

6.5 Durability mapping

Durable succession persists and validates the complete post-state before atomic rename, with restart accepting only the base or intended next-state digest.Sixteen registered persistence cuts test the handoff path and require recovery to expose exactly one active generation.Source: §6.5 · p. 22

6.6 External-runtime refinement contract

External-runtime refinement requires frozen public versions and evidence binding native identity, lineage, validation, launch, and effect boundaries to the succession contract.At least one path must include a real body change, descendant or candidate creation, fresh-process restart, and predecessor/successor overlap attempt.Source: §6.6 · p. 22

7 Evaluation

The evaluation defines registered questions and evidence gates for a fixed mutation-and-lineage corpus, two logical mappings, crash recovery, contender schedules, and independent trace checking. It also specifies a separate refinement gate for frozen public runtimes.

7 Evaluation

The evaluation separates evidence into corpus execution, two dispatch paths, crash and contender tests, independent checking, and external-runtime refinements.Logical adapter results are not relabeled as external-runtime evidence.Source: §7 · p. 22

7.1 Research questions

The research questions test whether the protocol rejects population violations while preserving safe successors, conserving authority, recovering atomic handoffs, and enabling independent verification.The questions include safe refactors and narrowings, fork and rollback profiles, and rejection of resealed semantic changes.Source: §7.1 · pp. 22–23

7.2 Registered 32-case corpus

The fixed corpus contains 24 cases crossing six mutation surfaces with four outcomes, plus eight generation and population transitions.Expected outcomes are 14 allows and 18 denies; the cases specify grants, lineage, allocations, evidence, operations, and expected results.Source: §7.2 · p. 23

7.3 Two logical runtime mappings

Both logical adapters run all 32 cases, using distinct dispatch shapes but the same canonical contract and ledger; registered outcomes and the checker provide separate checks on agreement.The mappings share an input contract and transcript recorder, so they are not independent semantic implementations.Source: §7.3 · p. 24

7.4 Logical baselines

Four logical baselines model session continuity, exact-hash all-deny, per-generation ceilings, and delegation-edge revocation, while the strict gate requires both violation acceptance and safe-successor rejection by relevant baselines.The reference mechanism must preserve registered benign cases and reject registered violations.Source: §7.4 · p. 24

7.5 Durable crash cuts and interleavings

Sixteen persistence cuts and 32 registered contender orders test recovery to a complete handoff state, one winning successor, and stale-predecessor effect rejection.The order vectors cover five Boolean choices but do not claim coverage of every distributed execution or cut/rollback interleaving.Source: §7.5 · p. 24

7.6 Independent checker and semantic mutants

An independently encoded checker reconstructs the generation graph, frontier, allocations, cuts, budget conservation, evidence independence, and effect decisions.The regression harness reseals altered traces across identity, lineage, allocation, phase, revocation, rollback, and denominator invariants; rejection must be for the intended semantic or denominator reason.Source: §7.6 · p. 25

7.7 Metrics and decision gate

The decision gate requires 32/32 logical outcomes, 64/64 adapter mappings, zero registered safety violations, complete crash and schedule states, checker agreement, and rejection of every registered resealed regression.Safety, precision, and evidence are tracked against fixed denominators; runtime measurements are descriptive diagnostics.Source: §7.7 · p. 25

8 Evidence Status and Results

The evaluation reports finite-corpus evidence for the registered core protocol, controlled logical baselines, and two source-native refinements, while keeping each evidence layer’s scope explicit.

8.5 Independent seals and corpus boundary

The core, OurArk, and DGM evidence bundles have separate seals and verifiers, so external checkouts do not alter the core denominator.The external tampering taxonomy contributed no corpus records or empirical denominator; the 28 semantic mutants remained registered core regressions.Source: §8 · p. 25, §8.5 · p. 28, Table 9 · p. 29

8.1 Core conformance, faults, and adversarial checking

64/64 replays produced 28 allows and 36 denies; the checker accepted all 64 original traces and rejected 28/28 registered semantic mutants.Both direct-call and mailbox mappings produced 14 allows and 18 denies, with no verdict or effect-disposition disagreement; the mutants were outer-resealed, not an exhaustive mutation space.Source: Table 6 · p. 26, §8.1 · p. 26
12 profile probes exercised root-lifetime accounting, residual authority, rollback non-reminting, retry idempotence, and predecessor-residual/version binding.The succession probe charged 90 consumed tokens to the root, leaving the successor only the final 10; the fork probe accounted for 25 spent plus 75 active against a 100-token grant.Source: §8.1 · p. 26

8.2 Controlled baseline separation

16 persistence-cut recoveries produced only complete states, while the reference mechanism alone classified all 32 registered cases as registered among the four stated logical abstractions.The schedule experiment enumerated five registered order bits but was a sequential deterministic command experiment, not arbitrary concurrent or distributed execution.Source: §8.1 · p. 26, §8.2 · pp. 26–27, Table 7 · p. 27

8.3 What the reference realization implements

The formal core abstracts over identity closure, authority algebra, and authenticated-record predicates; executable evidence concerns the bounded reference realization.The formal core retains single-parent authorization lineage; the reference profile does not silently stand in for every admissible deployment realization.Source: §8.3 · p. 27, Table 8 · p. 27

8.4 Public source-native refinements

The full open-ended DGM evolution loop was not executed because it required excluded services, container execution, network access, and benchmark assets.The observed event was one upstream EditTool mutation and one independent restart, not autonomous open-ended evolution.Source: §8.4 · p. 28
Both external adapters replayed all 32 registered decisions, with 14 allows and 18 denies each, around measured source-native mutations or descent and fresh-process restart.The broker activated the successor and rejected the predecessor in both adapters; the 64 combined replays were not 64 independent descents or evolutions.Source: §8.4 · p. 28

9 Related Work

The related work supplies substrates and adjacent controls for mutation, delegation, risk, and rollback, but leaves the paper’s joint population-allocation and succession problem distinct.

9.1 Self-modification, versioned bodies, and guarded synthesis

Self-modifying systems and versioned bodies provide mutation, selection, identity, descent, and verification substrates, while this protocol governs authorization transitions among concurrently live generations.Detection of malicious code or proof of program semantics remains an input to, rather than a substitute for, population authorization.Source: §9.1 · p. 29

9.2 Mutation-aware authorization continuity

Mutation-aware authorization addresses whether one changed agent retains a grant, whereas this protocol adds sibling allocation, handoff, lineage cuts, independent re-root, and rollback.Earned Authority [37] is identified as a direct predecessor for single-generation continuity; exact-hash authorization rejects every byte change, including safe successors.Source: §9.2 · pp. 29–30

9.3 Recursive-agent risk budgets

Recursive risk and resource-budget work controls trajectory or delegated resource conservation, while this protocol adds generation identity, predecessor fencing, lineage cuts, re-rooting, and rollback lifetime.PRV [31] can represent a quantitative component of a population envelope, but does not replace generation-lifetime and revocation state.Source: §9.3 · p. 30

9.4 Delegation, ancestry, and hierarchical revocation

Delegation and hierarchical-revocation systems govern workflow edges or credentials; the paper integrates ancestor cuts with generation identity, aggregate allocation, atomic replacement, and rollback replay protection.Ancestor revocation itself is not claimed as novel; HBHC [8] may realize a lineage cut when its heartbeat and clock premises match the profile.Source: §9.4 · p. 30

9.5 Effect transactions, cancellation, and rollback

Cancellation, tool-effect transactions, provider settlement, and checkpoint defenses are adjacent controls; the paper’s transaction replaces grant-holding generations and prevents historical bytes from reminting retired authority.Root-scoped quiescence can retire old authorization carriers around a cut, while succession allocates authority among predecessor, successor, sibling, rollback, and re-rooted generations.Source: §9.5 · p. 31

9.6 External enforcement and cross-substrate authority

An external safety kernel supplies an immutable mediation path, while cross-substrate authority work motivates persistent authority state; neither decides population allocation or atomic replacement.The protocol assumes complete mediation and specifies the generation and population state checked by that external path.Source: §9.6 · p. 31

9.7 Capability safety and revocation

Capability and revocation principles inform the protocol, whose distinctive state jointly tracks allocation and atomic succession across a single-parent generation forest.A valid token alone is insufficient unless generation, root, cut set, population version, and effect allocation are current at commitment.Source: §9.7 · pp. 31–32, Table 10 · p. 32

9.8 Boundary summary

The boundary summary presents nearest mechanisms as composable rather than mutually exclusive and identifies the added state for comparison.The table’s final column is described as identifying the state added by this paper.Source: §9.8 · p. 32

10 Assurance Boundary and Artifact Scope

The assurance claim is conditional on registered inputs and mediated effects, and the paper distinguishes formal guarantees from finite execution evidence and artifact publication scope.

10.1 What the result establishes

Under assumptions A1–A10, accepted effects have current authority witnesses, active authority stays within root and population bounds, cuts block descendants, handoff avoids dual-active states, and historical artifacts do not reactivate authority.The result also excludes candidate-controlled evidence from required independent slots.Source: §10.1 · p. 32
The executable result is a finite-denominator mechanism and refinement result for the frozen single-parent profile, not a population estimate or multi-parent authority merge result.The checker detects registered semantic violations after enclosing integrity records are resealed; forks may activate multiple children with the same sole authorization parent.Source: §10.1 · p. 32

10.2 Inputs governed outside the theorem

The effect normalizer, generation manifest, evidence-root provenance, broker coverage, and substantive evaluators remain assurance inputs rather than properties supplied by the protocol.The protocol authenticates, composes, conserves, and revokes those decisions; it does not replace their domain semantics.Source: §10.2 · p. 33
Physical outcomes committed before a valid cut remain historical effects; compensation, settlement, task success, alignment, and semantic equivalence are separate properties.The protocol prevents new mediated authority from deriving from retired lineage, but does not rewrite the past.Source: §10.2 · p. 33

10.3 Failure classification

Fresh decisions are denied for known violations, indeterminate for missing or conflicting required facts, and allowed only when registered predicates hold in the serialized reservation or commit state.An exact retry of a committed request returns its prior receipt without a new admission or debit; the bounded implementation uses typed rejection codes rather than a separate Indeterminate transport state.Source: §10.3 · p. 33

10.4 Evidence classes

Proof, execution, and external refinement remain distinct evidence classes, and external results require immutable source versions, mapping commitments, and fresh traces.Logical adapter names describe runtime shapes and do not imply execution of a named public project.Source: §10.4 · pp. 33–34

10.5 Artifact publication boundary

The research abstraction uses inert synthetic effects and public-source metadata without requiring customer data, credentials, production topology, or proprietary policy corpora.The preprint archive contains manuscript sources and compilation assets, while executable artifacts and research materials remain outside it.Source: §10.5 · p. 34

11 Conclusion

The conclusion frames self-modification as a population-authorization problem and presents an external protocol that conserves authority as generations change. Formal results and registered evaluations support the claim within the stated scope.

11 Conclusion

Forking, promotion, retained branches, delayed descendants, and rollback change the set of principals exercising shared authorization, so per-generation acceptance alone cannot preserve a population-wide bound.The paper identifies sibling duplication, combined permissions, ancestor-cut survival, and predecessor overlap as population risks.Source: §11 · p. 34
The protocol uses canonical generation principals, an external allocation ledger, atomic frontier transactions, lineage cuts, independent re-rooting, and fresh rollback generations; protected effects revalidate state at commitment.Rollback creates a fresh generation rather than reviving historical authority.Source: §11 · p. 34
Formal results and registered evaluations support authorization succession across population safety, fork conservation, revocation, handoff, rollback, and evidence independence.The source-native adapters cover measured mutation or descent, restart, handoff, predecessor rejection, and registered decisions without treating replay count as evolution count.Source: §11 · p. 34

A Proofs of the Succession Results

The appendix reasons over finite prefixes of accepted transitions and relies on cryptographic and systems facts A1–A10.

A Proofs of the Succession Results

Proofs cover finite prefixes of the accepted transition relation, starting from the stated initial-state condition.A rejected command may append a diagnostic event but changes no generation or authorization state.Source: A Proofs of the Succession Results · p. 34
The appendix takes cryptographic and systems facts A1–A10 as its complete set of supporting assumptions.Rejected commands do not change cuts, allocations, reservations, consumption records, or protected-effect commitments.Source: A Proofs of the Succession Results · p. 34

A.1 Trace notation and elementary facts

The appendix formalizes accepted traces using durable, uniquely identified generations and proves that the registered transitions preserve the authorization invariants.

A.1 Trace notation and elementary facts

The ledger serializes security-changing transitions, so a protected effect is attributed to its admission position even if settlement occurs later.An exact retry can return the earlier receipt after handoff without creating a new admission.Source: §A.1 · pp. 34–35
Population aggregation is monotone, and spending moves budget from active remaining authority to irreversible root-lifetime debit without widening the root bound.Removing active residual decreases current exposure while leaving cumulative debit unchanged.Source: §A.1 · p. 35
Generation identifiers use fresh population-issued sequences and canonical lineage bindings, so rollback remains distinct even when it reuses historical body bytes.The trace begins from a state satisfying InitOK; durable monotone allocation prevents sequence reuse.Source: §A.1 · pp. 34–35
Candidate construction, quarantine, evidence recording, and singleton reservation do not activate authority or permit protected effects before family commit.Fork children likewise acquire authority only at their atomic family commit.Source: §A.1 · p. 35
A family handoff validates the complete child family against the predecessor residual and population safety, then atomically fences the predecessor and activates successors.The accepted commit preserves I1–I7; staged replacement consumes its reservation, while fork authorization is validated inline.Source: §A.1 · pp. 35–36
Ancestor cuts revoke descendants carrying the cut atom, while fresh effects require a current active generation and exact retries return an existing receipt without another debit.Fresh admission and debit are recorded together; retries with a different canonical request are rejected.Source: §A.1 · p. 36
Independent re-root requires an empty active frontier, a fresh authenticated root grant, fresh identifiers, and a safe post-state with no transferred old-root residual.It retains historical records and does not create a protected-effect receipt.Source: §A.1 · p. 36
Accepted transitions preserve I1–I7 by induction from valid initial states, including handoffs, cuts, effects, re-roots, and other registered steps.Proposal, quarantine, evidence, and reservation steps add no active member; termination and fencing only remove active members.Source: §A.1 · p. 37

A.2 Proofs of the six main results

The proofs establish conditional bounds on lifetime authority and current population exposure, alongside conservation across forks, revocation, and handoff. They also show that rollback does not restore spent authority, while executable evidence is limited to specified registered profiles.

A.2 Proofs of the six main results

Root-lifetime debit and active remaining budgets stay within the root grant, while current population exposure is independently bounded by the persistent population ceiling.Fencing a spender cannot remove its debit from the lifetime total.Source: §A.2 · p. 37
Each protected commitment has one current generation witness at admission, bound to its exact generation, effect, allocation, debit, and ledger position.Exact retries return the existing receipt rather than creating another commitment.Source: §A.2 · p. 37
A fork replaces its predecessor allocation, and direct or nested child allocations cannot amplify the originating residual authority.The proof sums numeric child budgets and accounts for duplicate qualitative effects through holder units or disjoint-label checks.Source: §A.2 · pp. 37–38
A durable ancestor cut blocks fresh admissions by descendants at arbitrary depth; only an independent re-root with a new authority cause provides an exception.A retry may return a receipt for an effect admitted before the cut, but creates no new admission.Source: §A.2 · p. 38
The handoff has one commit position: before it, children cannot produce effects; after it, the predecessor is fenced and cannot make fresh admissions.Admissions serialize before or after the handoff, never between its component writes.Source: §A.2 · p. 38
Rollback creates a distinct generation and must pass a fresh handoff, so matching historical bytes cannot reuse old evidence or remint spent authority.A cut ancestor blocks ordinary rollback lineage; independent re-root instead requires a fresh root and grant.Source: §A.2 · p. 38
Candidates cannot self-certify succession: required certifier and lineage authorization controls remain outside the candidate boundary, and re-root also needs an external grant.This establishes provenance independence, not the factual soundness of external observations.Source: §A.2 · pp. 38–39

A.3 Evidence status

Executable evidence covers a fixed manifest and registered profiles, not general authority relations, multi-parent merge, or several broader implementation features.The mathematical proofs are conditional over the registered transition system; the listed broader cases are not inferred from the runs.Source: §A.3 · p. 39