18. Evolution

Requirements

• Bind installed and upstream revisions, local delta, locks, configuration, extension set, schema head, and platform.
• Build, merge, migration rehearsal, and verification occur in an inactive candidate.
• Test the selected built-ins and private in-process extensions with the candidate Core; pre-v1 internal imports are not a stable API.
• Keep source, package, database, runtime, and external recovery with their own owners.
• Drift, conflict, missing evidence, and exhausted repair budgets block promotion; every live effect rechecks state and authority.
• Keep source selection, verification evidence, collective promotion authorization, and each target owner's live effect as distinct decisions even when the same humans participate.

Considered Options

Decision Outcome

Ouroboros applies Creation and Packaging to a Core update:

Update Request → Inactive Candidate → Verification → Promotion Request → owned effects

Candidate verification is not activation. The repository audits source-bound wheel and sdist candidates, renders an Alembic one-shot before Vessel start, and has a mediated Host Reactor for typed Animator transitions. It does not acquire upstream, orchestrate updates, rebase local work, repair compatibility, checkpoint or restore a whole body, promote a package, replace a body, or restart through Ouroboros. The public release chain, whole-body recovery, and Smith/Forge promotion remain Designed.

This law concerns LychD and coupled local extensions, not the release process of an external service or peer. Built-ins and private in-process extensions that import internal modules are structural dependants of the exact Core: imports, registration, configuration, and behavior may break. The selected set must build and test with the candidate; no Smith repair guarantee exists. Extension law owns the tiers. An external-service Animator is decoupled only where its declared protocol and adapter remain compatible.

Replace the generation, not its memory

A promoted Core or coupled extension change activates as a new Vessel process generation. Evolution never imports replacement modules into the live Vessel and never carries its process-local object graph across that boundary. Listeners, caches, coroutines, dependency handles, and other volatile objects belong to the old generation and die with it.

The old generation closes admission and drains, parks, or resolves owned work according to its domain contracts. The new generation reconstructs its volatile world from the attested manifest, validated configuration, and compatible Phylactery records. Unresolved work and already-emitted external effects remain subject to the Graph, Workers, and Reanimation rules; process replacement does not pretend to rewind them.

This boundary optimizes for coherent recovery, not uninterrupted availability. Death of a Vessel running the same body is Reanimation. Deliberately starting a changed body is Evolution. In both cases durable truth, rather than surviving process memory, is the continuity substrate.

Record the recovery coordinate

The update record captures the exact installed artifact or image, source revision, dependency locks, configuration identity, selected extension revisions, schema head, active topology, requested upstream revision, and local delta. Before promotion, every affected owner supplies a tested recovery coordinate or declares forward-only risk and obtains authority for it. A future whole-body checkpoint may bind them; VCS history plus a database backup is not one atomic snapshot.

Reconcile into a candidate

An inactive candidate starts from an immutable upstream commit and reapplies admitted local changes with provenance. Jujutsu implementations record hexadecimal commit IDs for identity; mutable change IDs and branch names are annotations only. The installed body need not contain a source repository. Any conflict or base drift blocks promotion. Bounded repair produces a new candidate and repeats invalidated checks and authorization. Shadow and Assimilation provide future branch and repair law, not a delivered rebase service.

Its pinned dependencies and platform manifest require Core tests, typing, lint, build, archive audit, and isolated install; each manifest-bound built-in or private extension; configuration and registration; migration rehearsal from every declared source head; startup, readiness, and affected behavior; and changed external protocol/adapter boundaries. “All active extensions” is this manifest-bound set, not runtime discovery. A tested external protocol proves that contract only; deterministic failure rejects the candidate regardless of review or repair proposals.

Promote across the temporal boundary

Only an immutable, verified artifact with a request naming each live effect may promote. Under the lifecycle boundary, owners revalidate revision, schema, configuration, and authorization; close or drain admission; stage without changing the active body; migrate through the Phylactery; activate through an attested Privilege boundary; verify schema, readiness, registration, and affected behavior; then reopen only after success or proved recovery. A migration declares an expand/contract path, tested downgrade, or forward-recovery plan compatible with activation and rollback. The Host Reactor can transition typed Animators, not replace the Vessel or accept INTENT_RESTART_VESSEL.

Before any live effect, retention policy may discard or retain a failed candidate. Afterwards, each owner invokes tested rollback, compensation, or forward recovery: a source selection cannot undo a committed migration or external effect. Terminal evidence retains the request, candidate, effects, checks, traces, recovery attempts, and observed final state. An indeterminate result is contained for the operator; a revised attempt has a new identity and repeats relevant gates.

Trust split

Humans and CI currently acquire, build, and review. The designed coordinator owns identity, policy, evidence, promotion requests, and recovery orchestration. Untrusted build, test, and repair commands belong in Tomb only after that plane exists, without signing keys, migration credentials, durable workflow ownership, or host lifecycle authority.

Future quorum roster and promotion envelope

The proposed future quorum roster is a versioned roster of active human maintainer seats. Its founding profile has six seats. It is not a delivered LychD runtime object, remote identity service, or reason to share credentials. A seat belongs to one accountable person, not to each of that person's devices; automation, seeds, mirrors, runners, and agents receive no seat.

The roster's source-selection law and key separation live in Packaging. Evolution adds a separate promotion decision. For the founding six-seat profile, normal promotion requires four of six individual promotion signatures. The same humans and threshold may select the canonical source reference, but those signatures are not interchangeable: selecting a Git object does not approve its artifacts, evidence, recovery plan, or activation. Quorum removes the single-absent-founder bottleneck without creating a shared key, founder veto, or unilateral recovery key.

A future portable promotion envelope is the signed representation of Creation's Promotion Request. It binds the governance epoch and replay boundary; exact source object and artifact closure from Packaging; versioned verification plan and receipt digests; required Protected Region and owner verdicts; intended migrations, restarts, publications, and other effects; and tested rollback, compensation, or forward-recovery coordinates. Each trustee signs those exact bytes with a promotion credential distinct from source, CI-attestation, seed, deployment, migration, and lifecycle credentials. CI and builders may produce evidence but never hold quorum or effect authority.

Four signatures make an unchanged candidate eligible; they do not make a failing candidate true. Missing mandatory evidence, deterministic failure, an adverse required verdict, stale state, or a target owner's failed precondition blocks the Evolution regardless of votes. Every target owner still authorizes and records its own live effect at the temporal boundary. Rewriting a Jujutsu change, changing the Git object, artifacts, plan, or bound inputs invalidates affected evidence and authorization.

The envelope carries a unique promotion-attempt identity and monotonic sequence. Immediately before the first live effect, the verifier rechecks the current epoch, every signer's eligibility, quorum, replay and expiry state, withdrawal, and conflicts with another envelope for that attempt. An unexecuted envelope from a replaced epoch or revoked seat loses eligibility unless the successor epoch explicitly carries it forward; its signatures remain historical audit evidence. Before the first effect, a trustee may withdraw and quorum is recomputed. A seat's conflicting signatures for different candidate closures or effect sets under one attempt count toward neither once the conflict is observed; pending eligibility is recomputed and the affected credentials enter containment and governance review. The designed promotion coordinator and ledger atomically claim the attempt and sequence before admitting the first effect, reject a stale or competing envelope, and order later effect admission without taking any target owner's authority.

Recovery, rollback, or compensation already bound into an active authorized attempt remains an owner-executed recovery effect and cannot be delayed waiting for a new quorum vote. Withdrawal or an epoch change after the first effect cannot erase the emitted effect, its audit record, or the bound owner recovery authority. A conflict discovered only after that boundary cannot retroactively undo the effect; it triggers credential containment and governance review, while every remaining planned effect revalidates and may block. Deliberately selecting an older body as a later steady state is a new governed Evolution, not a mutable-ref rewind.

Key loss, compromise, or loss of quorum fails closed. Promotion-key rotation and roster membership changes create a new governance epoch through the preceding epoch's threshold authorization. An exceptional roster-recovery rule is valid only if that preceding epoch already authorized and bound it; it is limited to reconstructing membership under declared failure conditions and cannot approve a candidate or live effect. Revocation does not erase evidence that was valid in its historical epoch. Founder absence, two unavailable seats under four-of-six, compromised-key removal, total mirror loss, stale-envelope replay, conflicting signatures, and an unrecoverable quorum must be rehearsed before this design can move from Designed to Delivered.

During early development, maintainers continue to collaborate through branches and reviews on GitHub while exact-object checks and human approval remain procedural. The future protocol should be implemented only after the forge-neutral gates in Packaging pass. Radicle can be added later without changing candidate identity or Evolution semantics; adopting it early merely as an experimental replica confers no canonical or promotion authority.

Consequences