Rotation, retirement, successor chain

audience: ai

The oracle has bound consumers (binding), read its sources (source-reads), terminated them inside the enclave (wrapping), aggregated ticks (aggregation), and published per-pair streams (publication). This chapter closes the loop: how Measurements rotations are staged without a subscriber flap, how a multi- operator fleet composes, how retirement chains preserve stream continuity, and where the operator’s exit remains the substrate’s ultimate non-compulsion guarantee.

Measurements rotation

The oracle rotates Measurements whenever:

The underlying image changes (security patches, upstream crate updates, new aggregation policy version).
A source in the catalog changes its TLS SPKI pin, and the pin is folded into MR_CONFIG_ID.
A declared constant changes (cadence, staleness threshold, quorum floor).

Any such change is a new OracleParameters, a new ORACLE.content_hash(), a new self-quote, a new signing key. The operator’s publication step is one release page update carrying both the new content hash and the new Measurements.

Staged rotation

A blunt rotation — switch off the old image, switch on the new — drops every consumer who pinned the old Measurements. Most deployments stage rotations so consumers can follow:

Stand up the new image alongside the old. Two TDX guests on the operator’s hardware, two distinct MR_TD, two distinct signing keys, two distinct bond surfaces. Both committing to the same StreamId is not possible (ORACLE.stable_id() changes on retirement); both committing to a new StreamId under a new oracle instance is the normal path.
Publish both ORACLE_MEASUREMENTS_OLD and ORACLE_MEASUREMENTS_NEW on the release page. Consumers update their AdmitsMeasurements::in_set(&[OLD, NEW]) composition ahead of the cutover.
Emit a retirement marker pointing from OLD to NEW. The marker is an on-stream commit in the old organism’s retirement channel pointing at the new organism’s stable_id and content_hash.
Keep OLD running in read-only mode for a declared grace window. Consumers who have not followed the retirement chain continue to read OLD’s last ticks; consumers who followed it resubscribe to NEW.
Decommission OLD at the end of the grace window.

The RetirementMarker shape is the same one from the rest of the book:

pub struct RetirementMarker {
    pub retired_at:    SeqOrTimestamp,
    pub reason:        RetirementReason, // Rotation, Retired, Operator exit, …
    pub replacement:   Option<OrganismRef<'static>>,
}

A rotation is reason: Rotation with a non-empty replacement. A shutdown is reason: Retired with None. Operator exit is reason: OperatorExit with None; see below.

Multi-operator fleets

The oracle’s trust model admits any number of independent operators running the same image. Two operators running identical binaries on identical source catalogs land identical Measurements and therefore the same ORACLE.content_hash(); each publishes its own coalition (oracle-γ-op1, oracle-γ-op2) and its own organism instance (each with a distinct stable_id because the instance name differs).

From a consumer’s perspective:

Each operator’s oracle is a distinct organism with its own stable id but the same content hash.
The consumer’s TicketValidator admits the shared Measurements regardless of which operator’s instance it bonds against.
A consumer that wants redundancy subscribes to two operators’ pair streams and applies a consumer-side aggregation (a second-order median, for instance).

A multi-operator fleet is the first-order answer to operator failure, collusion resistance (modulo the shared image), and geographic diversity. The substrate’s non-compulsion property holds here too: operators join or leave the fleet voluntarily, and no one instance compels any other.

Chronicle: auditing rotations

For operators who want a tamper-evident record of rotations and retirement markers, oracle-γ may ship the Chronicle basic service:

pub const ORACLE_GAMMA_WITH_CHRONICLE: CoalitionConfig<'static> =
    CoalitionConfig {
        schema_version:    SCHEMA_VERSION_U8,
        coalition_seed:    COALITION_ROOT_SEED,
        instance_name:     "oracle-γ",
        lattices:          &[],
        organisms:         &[ORACLE_ORG],
        atlas:             None,
        almanac:           None,
        chronicle:         Some(CHRONICLE_CONFIG),
        compute:           None,
        randomness:        None,
        ticket_issuer:     None,
        retirement_policy: Default::default(),
    };

The Chronicle records every coalition-level event: oracle rotations, source-catalog updates, retirement markers. It does not record every tick; the per-pair streams are already an immutable audit of the ticks. The Chronicle complements them with a single authoritative log of operational events.

Self-replication and self-modification

Under the TDX/non-TDX split (ai/sustainability.md), the oracle image may author its own successor: a new image, a new Measurements set, a new OracleParameters instance, a retirement marker pointing at itself.

The honest limit is narrow and explicit. The autonomous-successor path only runs when the operator has configured the oracle to run an autonomous policy (one that can, for instance, detect outdated upstream crates and republish). Even then:

Compute cannot compel an operator to host the successor. The new image schedules itself on Compute; the operator-side running-the- binary decision remains the non-compulsion anchor.
Consumers are not forced to follow. A consumer that pinned the OLD Measurements strictly (no in_set) does not follow a successor. The retirement chain is a signal, not a command.
A successor whose policy changed discontinuously loses consumers. Consumers who followed the chain on the assumption of a bugfix find a policy they did not admit; the next rotation gives them the option to follow a version they did admit, or leave.

The operator exit

At any time, the oracle operator can:

Emit a RetirementMarker with reason: OperatorExit and replacement: None.
Stop running the image.

Consumers who had pinned the oracle’s Measurements see the streams stop. Consumers subscribed to a multi-operator fleet fail over to another operator. Nothing in the substrate keeps the operator running.

This is load-bearing. The oracle’s trust model is strong precisely because the operator can leave, because the Measurements pin is a voluntary admission on the consumer side, and because no coalition-level machinery binds the operator to continue publishing. The substrate does not compel.

What ends here

Every mosaik surface the book’s thesis names is exercised across the three Part II examples:

web3 — consumer-side bonding to a lattice, Compute as requester, sealed submission.
web2 — provider-side bonding to a coordination market, Compute as provider, sealed receipts.
oracle — publisher-side bonding with an attestation anchor, standalone organism as a family of keyed streams, rotation and retirement under a pure TDX trust model.

Part II ends here. Part III carries the role- specific guidance for builders standing up any of the three shapes, or a fourth shape the catalog admits because it stays open by design.

ai on mosaik