Reputation, retirement, successor chain

audience: ai

The searcher has bound to the lattice (binding), read the market (market-reads, wrapping), run inference on Compute (inference), and submitted sealed bundles that settle via tally::Refunds (submission). This chapter closes the loop: how the searcher’s reputation accumulates, how retirement and successor chains land the autonomous-renewal cycle from ai/sustainability.md — self-replication and self- modification, and where the operator’s exit remains the substrate’s ultimate non-compulsion guarantee.

The web3 example ends here. The book’s parallel examples continue with the web2 compute-bridge operator (web2 — Overview) and the TDX-attested price oracle (oracle — Overview).

The accuracy-reputation organism

The searcher’s reputation surface is an accuracy-reputation standalone organism — in the minimal example, operated by the searcher-α team itself; in a mature deployment, a shared organism across many searchers. Its role:

• Subscribes to every participating searcher’s submissions stream and the lattice’s tally::Refunds.
• For each submission, looks up the realised refund and scores the searcher on a declared utility function (hit rate, EV-weighted accuracy, fee- efficiency).
• Commits a ReputationCard per searcher per window.

pub const ACCURACY_REPUTATION: OrganismRef<'static> =
    OrganismRef {
        role:      "accuracy-reputation",
        stable_id: const_blake3!(
            b"instance|searcher-α.accuracy-reputation|",
            UNIVERSE.bytes(),
        ),
        content_hash: Some(REPUTATION_IMAGE_MRTD),
    };

The reputation organism’s Config.content folds the utility function’s parameters (window length, decay rate, EV weight). Any change to those parameters is a new Config fingerprint — the utility itself is a shared policy the scored searchers and the scoring organism agreed to at their TicketValidator bond.

Folding reputation into admission

Back in binding the searcher’s validator carried a commented-out reputation-floor clause. With a scoring history in hand, the clause is un-commented:

use coalition::acl::ReputationFloor;

fn searcher_ticket_validator_v2()
    -> TicketValidator<'static>
{
    TicketValidator::new()
        .require_ticket(
            Tdx::new().require_mrtd(
                TALLY_READER_MEASUREMENTS
            )
        )
        .require_ticket(
            Tdx::new().require_mrtd(
                ZIPNET_SEAL_MEASUREMENTS
            )
        )
        .require_ticket(
            ReputationFloor::from(
                ACCURACY_REPUTATION.stable_id(),
                0.55, // 30-window average threshold
            ),
        )
        .verify_peer(
            Tdx::new().require_mrtd(
                UNSEAL_COMMITTEE_MEASUREMENTS
            )
        )
}

Adding ReputationFloor changes the searcher’s Config fingerprint; the republication sequence is part of the successor chain below.

When the searcher’s reputation falls below the floor, its own admission stops issuing new tickets; downstream consumers whose validators mirror the floor stop receiving new bonds; the searcher degrades voluntarily. This is strategy A from ai/sustainability.md in the searcher’s concrete deployment.

The autonomous-renewal cycle in full

The staging → promote → publish cycle from ai/sustainability.md lands here. The searcher’s renewal loop:

1. Drift in staging. Between TDX deployments, the searcher’s policy runs candidate decoding variants in a non-TDX staging committee searcher-α authored itself (inference — the experiment loop). The staging committee’s Config is absent from production consumers’ validators; its commits are invisible to production.
2. Winner selection. The searcher scores candidates against realised refunds (Chapter 6’s tally::Refunds feeds into the outcome store). The policy picks a variant.
3. Candidate Config authorship. The searcher authors a new TDX-gated CandidateConfig embedding the winner’s decoding parameters, the retrained model digest, and the new image post- hash. The Config.content folds all of it; the resulting fingerprint is distinct from the predecessor’s.
4. ComputeRequest for the new image. Via the top-up path from inference — top-up loop. The Compute module matches the request to a provider carrying the candidate’s expected TDX Measurements.
5. Successor bootstrap. The provider starts the candidate image; its running Measurements match the expected set; the candidate binds against testnet-1a with its own validator and begins committing.
6. Retirement marker on the predecessor. The searcher’s existing organism commits a RetirementMarker pointing at the successor’s Config fingerprint. Consumers following the chain rebind to the successor at the next tick; consumers pinned to the old fingerprint see ConnectTimeout and consult the marker.
7. Atlas card update. The coalition’s Atlas module (when shipped) publishes the successor link on the predecessor’s MemberCard, so late- arriving consumers find the new searcher via the directory lookup.

No operator-side step is required for any of (1)–(7). The operator’s assent was captured once — when the operator chose to run the autonomous policy — and is not re-requested on each renewal.

Operator exit

The searcher’s operator retains one unconditional power: stop running the binary. Every autonomous renewal above happens only while the operator keeps the predecessor’s committee live long enough to commit the retirement marker. If the operator stops the binary cold:

• In-flight submissions land or fail on their own target blocks; the lattice does not care.
• Consumers bonded to the searcher’s Config eventually see ConnectTimeout without a retirement marker — a silent exit, in the vocabulary of ai/sustainability.md — threat model.
• The reputation organism scores the searcher’s last window as it normally would; the watchdog organism commits an AbandonmentReport once the subscription count drops below threshold.

This is the honest limit: Compute cannot compel provider capacity; consequently it cannot compel the searcher’s own operator to keep running either.

Chronicle heartbeat (optional)

For searchers that want their aliveness cryptographically anchored, searcher-α can ship the Chronicle basic service and commit a periodic heartbeat:

use coalition::chronicle::{
    ChronicleHandle, ChronicleKind, AgentHeartbeatBody,
};

async fn heartbeat_forever(
    chronicle: ChronicleHandle,
    searcher:  &Searcher<Submission>,
) -> anyhow::Result<()> {
    loop {
        let body = AgentHeartbeatBody {
            agent_id: SEARCHER_CFG.stable_id(),
            scope_digest: SEARCHER_CFG
                .content
                .scope_digest(),
            window: AlmanacRange {
                start: last_tick(),
                end:   searcher.current_tick(),
            },
            latest_commit: searcher
                .submissions
                .latest_evidence(),
        };
        chronicle.commit(
            ChronicleKind::Other("agent-heartbeat"),
            body,
        ).await?;
        tokio::time::sleep(HEARTBEAT_INTERVAL).await;
    }
}

This is pattern Z from ai/sustainability.md — anti-abandonment patterns applied one-for-one in the example.

Market-maker variant — differences at sustainability

• Fill-rate reputation, not accuracy reputation. The reputation organism for a market-maker scores fill-rate, quote-latency, and inventory- reconciliation accuracy, not bundle-level EV hit rate. The utility function in Config.content differs; the mechanism is identical.
• Shorter renewal cycles. Market-makers rebuild inventory parameters constantly; the staging → promote → publish cycle fires many times more often than a searcher’s. The Compute experiment budget is correspondingly larger (see inference market-maker note).
• Quote retirement cadence. A market-maker retirement marker chains through a stream of successor parameters rather than a single candidate-per-window. The marker primitive itself is unchanged.

Where Part II ends, Part III begins

Part III is the reference material an integrator, operator, or contributor consults when a specific question arises. If the reader is ready to stand up the searcher described across Part II, the entry points are:

• Part III — integrators quickstart — the canonical shape-1 path, which Part II extended into shape 2.
• Part III — operators quickstart — running the searcher’s committee, the Compute module’s committee, and any feed organisms.
• Part III — contributors topology-intro — commissioning a new composite organism (e.g., a shared reputation organism across multiple searchers) or a new coalition-scoped module.

Cross-references

• Part I — sustainability — self-replication and self-modification — the specification this chapter exhibits.
• Part I — emergent coordination — shared policy — the mechanism that makes the reputation-floor composition load-bearing.
• Part III — basic services — Chronicle
• zipnet book — the submission primitive the searcher’s bundles rely on.
• builder book — the lattice the searcher’s entire sustainability surface is bonded against.