Bombay Behavior

Bombay Behavior provides a pure, statically typed actor transition algebra and a catalogue of reusable actors. A behavior processes one communication at a time and returns explicit Actions: typed communications, staged fresh actor creations, and its next behavior or termination decision. Scheduling, transport, clocks, allocation, and effect execution remain interpreter responsibilities.

This guide has three documentation classes:

• Canonical contracts describe the current behavior algebra, application authoring syntax, composition laws, and interpreter obligations.
• Actor catalogue documents the current reusable atomic actors and their normalized aggregate laws.
• Engineering records preserve research, rejected alternatives, audit evidence, and implementation campaign decisions. They explain why the current design exists but are not an additional public API contract.

The generated API references are published alongside this guide:

• Behavior primitives
• Reusable behavior actors

When a historical engineering record conflicts with the crate API or a canonical contract, the current public types and canonical contract govern.

Actor transition algebra

This is the canonical semantic map for Bombay Behavior.

Laws and project constructions

The actor-model laws preserved here are:

1. an actor processes one accepted communication at a time;
2. a transition may communicate with known recipients, create fresh actors, and designate the behavior used for the next communication; and
3. a newly allocated actor address is fresh with respect to the actor configuration.

Bombay derives a concrete typed construction from those laws:

Behavior::transition(ActiveTurn, Behavior::Event)
    -> Result<Actions<Addr, Phase, Sends, Birth>, Error>

Actions is the only effect boundary. Typed send products, closed creation products, initialization effects, phases, explicit termination, structural event paths, creator-local child routing, and interpretation order are Bombay constructions and policies, not claims about the surface syntax of Agha's formal calculus.

Four orthogonal roles

A protocol is not a behavior. It has no state, initialization, internal event lanes, effects, errors, phases, or birth capabilities. A behavior is not a protocol supertrait: senders need only the destination's public signature, not proof of its current implementation.

A nominal actor may implement both traits and use Behavior::Protocol = Self. Transparent wrappers preserve the inner protocol while changing the concrete behavior and event/effect algebra.

InitializationTurn and ActiveTurn cannot be constructed directly by an application. The public initialize(&mut B) and delegate_transition(&mut B, event) functions are trusted composition and runtime ports: they can be called repeatedly, and the latter can run before initialization. The consuming behavior_actors::Activate::initialize path enforces one initialization for its owned definition and returns Active<B> for mailbox ingress. A runtime or wrapper using the raw ports must enforce the same lifecycle order itself.

Destination evidence

P is always canonical protocol identity. O is structural occurrence evidence used to navigate duplicate child declarations. It is not a key, address, or second identity.

The runtime selects exact message endpoints through RecipientAddress::Established<P>. Actor-hosting namespaces additionally select EndpointAddress::Installed<B>, which projects the endpoint and keeps matching B::Event authority. Generic application types and protocol owners do not implement key traits or carry runtime types. The inert endpoint family requires Clone, not Send. InterpretSends and concrete request interpretation require Send when an effect actually crosses an asynchronous executor boundary.

Fresh creation

CreateChild<A, C> stages a concrete child behavior, creator-local nonce, and CreationKind. Staging allocates nothing. The nonce cannot be converted to an address and proves neither identity nor freshness.

The interpreter performs, in order:

1. reserve an address fresh with respect to the actor configuration, without publishing a live endpoint;
2. run the child's pure definition initialization fold;
3. install the endpoint and commit the creator-local nonce binding;
4. interpret and settle all initialization effects; and
5. permit ordinary mailbox ingress only if initialization continues and its effects settle successfully.

Only the committed path may produce ChildCreationOutcome<C, Occurrence>::Established(CommittedChild<C, Occurrence>). A later named report may return EstablishedCreation<C, Occurrence>::Installed with the same committed product. Allocation rejection returns the complete staged creation before the initialization fold. Pure initialization rejection returns the current child and exact error; host rejection after that fold returns the current child and uninterpreted initialization Actions. A caught pure initialization panic returns the extant current child through InitializationPanicked, without claiming an initialization error or accepted actions. None of these outcomes commits a binding. Once committed, an initialization-effect failure belongs to the installed child's drain and cannot be reported as a creation rejection. An initialization Stop still settles its final actions and never enables ordinary ingress. A nonce collision is rejection, never replacement or overwrite.

These commit and settlement steps are Bombay policy, not Agha's allocation law. Agha et al.'s newadr and initbeh are separate model operations; Bombay packages fresh allocation, the pure fold, and establishment into one staged creation request.

CreationKind::ReplacementIncarnation records Behavior-authored provenance. It is still fresh allocation. A runtime may report a restart only after the corresponding replacement creation commits successfully.

Creation facts are indexed by canonical child protocol and structural occurrence—not by an entire parent behavior. A fact can be strengthened to EstablishedActor<RoleChild<Parent, Occurrence>> only at the topology boundary where ChildRole<Parent> genuinely proves the concrete installed behavior. This avoids forcing arbitrary consumers or wrappers to pretend to be actors.

Event and effect composition

EventLayer<Owned, Inner> forms a closed event sum. Here identifies the current owner and Inside<Path> identifies an inner owner. InjectEvent constructs exactly the selected lane; it never searches by payload type.

SendLayer<Owned, Inner> is the corresponding named effect product. SendsFor<Event> proves that every interpreter request returning to its emitter has a valid structural ingress. InterpretSends visits inner effects before wrapper-owned effects, preserving initialization and delegated transition order. Independent named lanes retain their own order; no global order is invented between unrelated lanes.

Composition must preserve these invariants:

• every accepted event produces one result;
• mapping sends preserves creations and the exact next verdict;
• mapping the next verdict preserves sends and creation order;
• wrapping cannot drop, duplicate, reinterpret, or consume an inner lane;
• duplicate structural occurrences remain distinct;
• established, child, and external destinations are not reindexed merely because the emitting behavior is wrapped; and
• controlled failure emits no partial effects.

Static interpretation

ActionItem fixes the outcome vocabulary of each emitted value. SendSettlements fixes the complete product shape independently of any runtime. InterpretItem and InterpretSends are the monomorphized runtime capabilities. Closed child sums use DispatchBirth and one EstablishChild<Occurrence, Child> implementation per concrete occurrence. Missing support fails to compile.

ChildOccurrenceProduct is the structural product needed by runtimes that retain creator-local state per direct child occurrence. Behavior owns the closed Behavior leaf / ChildChoice / Never recursion and supplies the same ChildHead / ChildTail<_> navigation evidence used by child creation. A runtime-owned ChildOccurrenceShape supplies only the storage constructor. This is a type-level derived construction, not an actor operation: it performs no transition, allocation, binding, lookup, or effect interpretation. Transitive descendants remain owned by the concrete child actors that may create them.

ResolveChildOccurrence<O> supplies the inverse static connection needed when an effect names O: the running emitter and occurrence determine one exact direct child behavior and structural position. Generated nominal roles are resolved through BehaviorBase only while protocol and birth topology remain identical; raw ChildHead/ChildTail<_> positions inspect the emitter's own closed birth node. Consequently a supervision wrapper that replaces a direct child with a proxy cannot silently reinterpret the base role. This is navigation evidence derived from Behavior, not a new identity or effect.

No core path uses trait objects, runtime protocol registries, reflection, downcasting, type-name dispatch, serialization, or unsafe type escape hatches.

Code map

• crates/behavior/src/transition.rs: protocol and behavior contracts
• crates/behavior/src/effects/: actions and static send interpretation
• crates/behavior/src/actor/addressing.rs: logical and established recipients
• crates/behavior/src/actor/creation.rs: staged creation and structural dispatch
• crates/actors/src/protocol/established.rs: exact creation, observation, and shutdown protocols
• crates/actors/src/requirements.rs: occurrence-preserving installation requirements

Bombay Behavior core type inventory

Scope

This document inventories the types exported at the root of the bombay-behavior crate (behavior in Rust source). The authority for the list is crates/behavior/src/lib.rs; semantic descriptions are taken from the defining modules in crates/behavior/src. It describes the current source surface, not a proposed redesign.

The inventory includes public traits, structs, enums, and type aliases. It also identifies the crate's public functions and #[behavior] macro because they construct or consume the types. It excludes private module items, test-only fixtures, and downstream types generated in a user's crate except for a separate description of the macro-generated family.

Some root exports are marked #[doc(hidden)]. They remain listed because they are publicly nameable implementation contracts, but ordinary behavior authors should not treat them as the preferred API.

Semantic center

The central relationship is:

Protocol = address namespace × public message type

Behavior = protocol
         × complete event algebra
         × send product
         × birth algebra
         × phase menu
         × controlled error

BehaviorActed<B>
    = Result<
          Actions<BehaviorAddr<B>, B::Ph, B::Sends, B::Birth>,
          B::Error,
      >

Actions = sends
        × ordered staged fresh creations
        × (Continue | Goto(phase) | Stop(Stopped))

Protocol is stable public communication identity. Behavior is the concrete stateful fold implementing that protocol. They are deliberately separate: recipients and deliveries do not recursively carry a destination behavior's sends, births, phases, or errors.

Actions is Bombay's typed realization of actor-transition effects. It is not described as a literal Agha effect triple: the Rust surface additionally owns typed send products, creator-local child routing, phases, controlled errors, termination, initialization effects, and Bombay interpretation ordering.

Protocol, behavior, and transition types

The associated type equation of Behavior is:

Behavior {
    Protocol: Protocol
    Event: UserEvent<Addr = BehaviorAddr<Self>,
                     Message = BehaviorMessage<Self>>
    Sends: SendEffects + SendsFor<Event>
    Ph
    Error
    Birth: BirthMode
}

Next-state and action types

Actions constructors (cont, stop, goto, send, and create) construct values only. They do not interpret sends, allocate actors, change runtime state, or perform lifecycle work.

Addressing and installed-capability types

The capability strength increases from logical naming to installed evidence:

Recipient<P>
    logical protocol destination

EstablishedRecipient<P>
    exact installed endpoint for P

EstablishedActor<B>
    exact installed endpoint for B::Protocol
    + static proof of concrete behavior B

None of these values has an ambient send, shutdown, allocation, or lookup method. Effects cross explicit interpreter traits.

Event and ingress types

Here and Inside<Path> are structural proof types, not runtime routing addresses. Ordinary composed templates should prefer semantic EventIngress<Source, Input> implementations so callers do not count wrapper depth.

Send products and interpretation types

Send-product algebra

The crate supplies SendEffects/interpretation implementations for selected Vec<T> lanes, including logical deliveries, established deliveries, creator-local child deliveries and inputs, and Vec<Never>. A general Vec<T> is a send value container, but only statically supported effect kinds receive interpreter meaning.

Interpreter capabilities

These are statically dispatched interpreter obligations. A composite send product cannot silently omit a lane: the concrete interpreter must implement every required capability or fail to compile. Source custody uses the same declared order, but returns after one successful admission so the runtime can process that input and all transitive effects before offering the next one.

Staged creation and lifecycle result types

Creation values and outcomes

Creation is staged, not performed by CreateChild. Behavior issues a CreationId and emits the child in the same transition. Exact correlation is the static child occurrence together with that ID. Independent layers may use equal numeric IDs for distinct occurrences; reuse within one occurrence remains invalid. The interpreter privately selects routes for the complete Creations batch before it hosts any child. A creation becomes established only after fresh allocation, initialization, installation, commit, and binding. Behavior never constructs or stores a runtime route.

Heterogeneous creation products

Each Children::child or Children::create call adds one new structural child occurrence, so conversion into Creations is total. Equal IDs in distinct occurrences remain distinct correlations. Runtime route exhaustion returns the entire batch through ChildNamespaceExhausted.

Closed birth and topology type algebra

Birth capability and child sums

ChildChoice is a creation-only sum, not a message envelope, behavior trait object, registry, or runtime dispatcher.

Nominal child roles and occurrence resolution

Nominal roles distinguish duplicate occurrences even when they contain the same child behavior. A role and its structural position are topology evidence, not protocol identity, actor identity, or runtime lookup keys.

Interpreter dispatch and child occurrence products

These types let an interpreter prove support for every child alternative at compile time. They do not perform runtime protocol lookup or erase the child behavior type.

Protocol and host projections

Protocol products preserve repeated occurrences. They are static evidence and perform no allocation, hosting, normalization, or runtime lookup.

Finite sequence observation

The Behavior crate exposes no mailbox reducer or finite-stream result. Its contract ends at one initialization or event transition and the resulting Actions. Runtime scheduling belongs to Bombay. Repository tests use behavior_testkit::drive, whose Trace preserves the final active behavior, ordered sends and creations, initialization-inclusive transition count, pending mailbox suffix, and an exhaustive DriveDisposition distinguishing a drained mailbox from BehaviorStopped(Stopped).

Public companion operations

For an actor named Actor, the macro may generate these concrete types when the corresponding declarations exist:

ActorSends
ActorSends<Field>                 one uninhabited selector per send lane
ActorActions                     fluent action-extension trait
ActorChildren                    closed ChildChoice alias
ActorChildren<Field>             one nominal role type per child declaration
ActorChild                       namespace containing role values

The exact generated Rust names preserve the actor and authored field names. The macro does not create actors, interpret effects, introduce a dynamic envelope, or grant capabilities absent from the handwritten core types.

Boundary summary

The crate intentionally stops at the pure algebra and minimal typed interpreter contracts:

• Behavior consumes one event and returns Actions.
• Actions owns sends, staged fresh creations, and next behavior or stop.
• event, send, and birth products are concrete closed sums/products;
• recipients distinguish logical identity from exact installed capability;
• creation IDs remain creator-local correlation rather than actor identity;
• interpreter traits realize typed effects without dynamic dispatch; and
• reducers observe folds without becoming a scheduler or runtime.

Scheduling, mailbox transport, clocks, endpoint allocation, installation, effect settlement, and actor execution remain interpreter responsibilities.

Nominal Behavior attribute

#[behavior::behavior(...)] is the single generated authoring path. It preserves an ordinary inherent impl and emits the adjacent nominal Protocol, pure Behavior, optional named send product, and optional closed child product that a careful user could write by hand.

use behavior::{Actions, BehaviorActed, Delivery, MailAddr};

struct QueryPoolProtocol;
struct QueryStarter;

#[behavior::behavior(
    addr = MailAddr,
    message = behavior::Never,
    sends = {
        query_pool: Vec<Delivery<QueryPoolProtocol>>,
    },
)]
impl QueryStarter {
    fn init(&mut self) -> BehaviorActed<Self> {
        Ok(Actions::cont().send_query_pool(/* typed delivery */))
    }

    fn receive(&mut self, _: MailAddr, message: behavior::Never) -> BehaviorActed<Self> {
        match message {}
    }
}

addr and message are required because they establish public protocol identity. The other declarations are capability-denying defaults:

• omitted sends means NoSends;
• omitted births means NoBirths; and
• omitted error means Never.

Those defaults do not infer or grant an effect. Code that tries to send, create, or return an error absent from the declaration fails to type-check. An advanced author may still supply an existing concrete sends or birth type instead of a generated { ... } product; this preserves handwritten catalogue products without adding another macro path.

Named send products

For an actor System, sends = { workers: Vec<Delivery<Workers>> } generates:

• the nominal SystemSends product with a named workers field;
• the uninhabited lane selector SystemSendsWorkers;
• the SystemActions extension trait, with a fluent send_workers method;
• SendEffects, preserving each field independently in declaration order;
• SendInput<_, SystemSendsWorkers>, used through SendEffects::send;
• SendsFor<Event>, requiring every field to be lawful for the complete event; and
• InterpretSends, requiring and visiting every field in declaration order.

Two fields with identical product and payload types still have different lane selector types. No recursive position, type-name search, runtime registry, or catch-all effect value is generated. An interpreter missing any constituent delivery or request implementation fails its InterpretSends bound.

Generated fluent methods reuse the same Actions value and SendInput proof: they append exactly once to their named lane while preserving existing sends, creation order, and Continue, Goto, or Stop. They do not interpret an effect or introduce a second effect representation. Existing concrete send products remain directly constructible for advanced composition code.

Closed birth products

For an actor System, this declaration:

births = {
    workers: Workers,
    query_reply: ManagedQueryReply,
    query_starter: ManagedQueryStarter,
},
creation_settlements = return_to_creator,

generates SystemChildren as the exact recursive ChildChoice produced by calling Children::child_at in that declaration order. The generated behavior's birth capability is Births<SystemChildren>. The field labels record semantic roles. It also generates SystemChildrenRoutes, with one nominally distinct typed route per role. The same route stages that role's creation and constructs ChildDelivery<Child::Protocol, Role> or ObserveEstablishedCreation<Child, Role>, so dependent effects do not repeat an untyped nonce. Values and nonces remain explicitly authored.

These names extend the macro's existing generated namespace: SystemChild, SystemChildren, SystemChildrenRoutes, and one SystemChildrenRole marker for each field (for example, SystemChildrenWorkers). As with SystemSends and its lane selectors, callers must leave those actor-prefixed names to the macro. Using the same child behavior in two fields still produces two incompatible role types; sharing a protocol cannot accidentally exchange their routes.

The same declaration also generates the SystemChild selector namespace. Its inhabited values, such as SystemChild::Workers, implement ChildRole<System, Child = Workers>. Each role also carries a structural ChildHead/ChildTail<_> position proving where that exact behavior occurs in SystemChildren, and implements ChildOccurrence<System> for the sealed running-emitter resolver. This is the Behavior-owned proof consumed by static application topology and existing heterogeneous effect products:

Application::new(System::new())
    .child(SystemChild::Workers, workers)
    .child(SystemChild::Queries, queries)

The selector contains no nonce and performs no creation. SystemChildrenRoutes remains the separate creator-local routing product used when the parent stages creation and local dependent effects.

A route is routing intent only. It is not an actor identity, proof of freshness, or successful installation fact.

Generated and handwritten child products share the same sealed occurrence product. A static runtime may implement ChildOccurrenceShape once to project any SystemChildren into its own occurrence-preserving direct-child storage. The macro emits no runtime storage or shape implementation, and equal child types at two named roles still receive distinct structural positions.

Every real birth declaration must state who owns its completed creation settlements. creation_settlements = return_to_creator makes the generated event type CreationEvent<Addr, SystemChildren, Message> and requires an authored transition with this shape:

fn creations_settled(
    &mut self,
    settlements: behavior::CreationsSettled<behavior::MailAddr, SystemChildren>,
) -> behavior::BehaviorActed<Self> {
    // Decide from the exact accepted or rejected creation settlements.
}

Use creation_settlements = retain_for_retirement when the actor has no lawful transition for those runtime results. Its birth capability becomes RetirementBirths<SystemChildren>; the interpreter retains the exact settlement as terminal source custody rather than dropping it or manufacturing a no-op callback. Omitting births, or explicitly declaring NoBirths, needs no settlement policy because no creation request can exist.

ResolveChildOccurrence<Role> maps such a generated role to the exact child and position of the concrete behavior currently being interpreted. It follows BehaviorBase through wrappers only when they preserve both the canonical protocol and complete birth algebra. Wrappers that rewrite child topology do not inherit the base role; their own ChildHead/ChildTail<_> positions remain available. The mapping is sealed and type-level, not generated runtime code.

This is Bombay's staged creation policy: Children builds typed CreateChild requests, and the interpreter must commit them before dependent same-action sends and interpreter requests. The macro does not allocate, establish, replace, choose nonces, or infer lifecycle provenance. DispatchBirth still requires one concrete EstablishChild<Occurrence, Child> implementation for every alternative. The position distinguishes duplicate occurrences without making the role a protocol identity or forcing the parent type onto ordinary creation creation-result consumers.

Exact initialization and transition results

An optional inherent init(&mut self) -> BehaviorActed<Self> becomes the initialization fold. If it is absent, initialization returns the explicit empty Actions::cont(). The required receive(&mut self, from, message) -> BehaviorActed<Self> becomes the user transition fold. Rust checks both method results against the generated complete Actions<Addr, Never, Sends, Birth> and declared error type.

The macro generates no runtime context, constructor, scheduler, mailbox, executor, interpreter, or template policy. Initialization and receive bodies remain application-authored pure folds.

Why one attribute

Rust attribute macros transform an attributed item and their output is unhygienic. The implementation therefore resolves absolute paths through the direct bombay-behavior dependency or the bombay-rs facade, including Cargo renames. See the Rust Reference on procedural macros.

Serde-style stacked helper attributes are formally supported for derive macros, which can register inert helpers. An impl-level attribute macro has no equivalent helper-registration mechanism. Keeping sends, births, and errors as named sections of the one owning #[behavior] invocation avoids expansion order as an API constraint and keeps one coherent generated fold.

This construction is Bombay policy, not an actor-model primitive. Actions remains Bombay's typed realization of communications, fresh actor creation, and the next behavior or termination.

Behavior layer laws

This document is the acceptance contract for every same-actor behavior composition in Bombay. It is deliberately a semantic review rule, not another Rust trait hierarchy.

BehaviorLayer<B> has one narrow job: construct a fully concrete output behavior from B without forcing a generic owner to name that output type. The trait does not make an output lawful merely because the associated type implements Behavior. The concrete output behavior owns and must prove the event, effect, initialization, error, birth, and lifecycle transformation described below.

Provenance of the laws

Agha's actor calculus supplies the foundational boundary: an actor processes a communication, may send communications, create actors, and designate its next behavior. Actor configurations compose through their explicit receptionist and external-name interfaces. Agha does not specify Bombay's same-mailbox Rust wrapper order, typed event sums, typed effect products, initialization fold, controlled errors, shutdown protocol, or structural child occurrences.

Consequently:

• single-communication processing, actor-owned behavior change, messaging to known actors, and fresh actor creation are actor-model laws;
• Behavior, Actions, EventLayer, SendLayer, initialization ordering, creator-local child routing, and structural occurrences are derived Bombay constructions; and
• wrapper precedence, error policy, shutdown policy, buffering, retries, and lifecycle reactions are deliberate Bombay policy choices owned by concrete behaviors.

References:

• Gul Agha et al., A Foundation for Actor Computation.
• Gul Agha, Actors: A Model of Concurrent Computation in Distributed Systems.

Construction is not transition composition

For a layer value L and behavior B:

L.layer(B) -> Output

is construction only. It must not initialize an actor, process an event, allocate an address, interpret an effect, or acquire a runtime capability. Output: Behavior defines the operational composition.

The blanket Fn(B) -> Output implementation exists only so ordinary concrete constructors and closures can be reused by topology owners. It is not evidence that two actor laws have been composed. A catalogue migration is complete only when the resulting concrete behavior satisfies every applicable law below and the former bespoke implementation has been deleted.

Do not add associated types, marker types, *Layer configuration wrappers, or aliases merely to make a generic call nameable. A new concrete wrapper is admissible only when it owns a distinct state or event/effect transformation.

Enforcement hierarchy

No single checker can establish these laws. The repository uses four complementary levels, in this order:

1. this semantic contract decides what the behavior must mean;
2. concrete Rust sums, products, capabilities, and compile-fail tests make representable invariants static;
3. compiler and Clippy hard failures reject unsafe code, suspicious constructs, ignored must_use results, mutation hidden in debug assertions, placeholders, and unexplained lint suppressions; and
4. pure-fold, model, exhaustive, property, fuzz, and interpreter-path tests establish the observable transition laws.

Broad style, complexity, and performance lint groups are review inputs rather than repository gates. They must not compel aliases, wrappers, boxing, helper traits, or reordered branches that obscure the actor algebra. Conversely, a lint suppression is not evidence that a semantic law holds. Clippy cannot prove effect conservation, error atomicity, lifecycle authority, initialization order, or higher-order reuse; those require the types and independent tests above.

L1: stable public capability

A transparent layer preserves B::Protocol exactly. A layer may change the public protocol only when protocol adaptation is its documented semantic law. Changing the internal event algebra, send product, child topology, error, phase, or state representation does not by itself create a new public destination identity.

The address namespace is preserved. A logical recipient, established recipient, creator-local child route, and established parent relationship keep their original routing intent through composition. A layer must not replace one with another to satisfy a bound.

L2: closed and single-owned event algebra

The output event is the exhaustive sum of its owned inputs and the preserved inner event algebra.

• Every accepted event has exactly one semantic owner.
• An inner event is injected once and delegated once.
• An owned event is either handled by the layer or deliberately transformed into one exact inner event.
• Equal payload representations from different sources or child occurrences remain distinguishable by their semantic source.
• No implementation searches by payload type, wrapper depth, type name, or a runtime registry.
• Adding an unrelated outer layer cannot change which existing law owns an input.

Public domain messages and private system inputs are members of the same closed Behavior::Event sum, but only the domain-message lane belongs to Behavior::Protocol.

Two ingress traits that differ only because Rust cannot prove their blanket implementations disjoint do not establish two semantic input laws. Such a split must be redesigned around explicit event ownership rather than exposed as architecture.

L3: one deterministic fold

One output event produces one Result<Actions, Error>. A layer does not run an interpreter, spawn work, call a clock, or perform another actor turn.

For a delegated event, the inner fold is invoked exactly once. For an owned event, the layer's documented transition is invoked exactly once. If an owned transition also induces an inner transition, the order and combined state commit are part of that layer's law and must be tested as one atomic fold.

Construction layers may be nested:

b.layer(first).layer(second)

Nesting is observationally associative with the equivalent composed closure: it must not change event ownership or action order merely because the caller grouped construction differently. This is observational equivalence, not Rust type equality.

L4: effect conservation

The output Actions product retains every inner effect and every layer-owned effect in semantically named lanes.

• Inner sends are not dropped, duplicated, consumed, or reinterpreted.
• The order within each inner lane is unchanged.
• Layer-owned sends occupy an owned lane; positional .inner.inner access is not a public semantic interface.
• Mapping sends preserves creations and the exact next-behavior verdict.
• Mapping the verdict preserves sends and creation order.
• A wrapper may consume an inner effect only when effect interception is its explicitly documented law and the replacement outcome is complete and observable.

The normal structural interpretation order is inner effects before outer-owned effects. A different order requires a named product, a stated reason, and complete order tests; it cannot arise accidentally from field layout.

L5: initialization conservation

Construction performs no initialization. Output initialization invokes the inner initialization fold exactly once unless construction or outer validation rejects before an actor definition exists.

For successful transparent composition:

1. inner initialization effects retain their exact values and order;
2. outer initialization effects are added in the layer's named send and birth lanes;
3. the declared structural order is inner before outer; and
4. the combined initialization become decision is explicit.

If initialization fails, no partial Actions exists. Validation or staged state changes performed before delegation must not leave the output in a partially initialized state.

Every pair of initialization-owning layers must be tested in both wrapper orders. Commutativity must never be assumed.

L6: controlled-error atomicity

An output error is a truthful exhaustive sum of inner failures and failures owned by the layer. It must retain the rejected input and any other owned value needed for recovery.

• Delegated errors preserve the inner cause without reclassification.
• Returning Err emits no partial effects.
• State needed by a retry remains unchanged unless the documented error law says ownership was consumed.
• A layer cannot mutate one submachine and then discover that another submachine rejects the same transition.
• Expected availability, capacity, overlap, stale-input, and shutdown outcomes do not become opaque actor crashes after mailbox admission. They are successful typed responses or reports when a customer can recover.

Compiler difficulty coordinating two mutable folds is evidence that their joint transition has not yet been modeled atomically; it is not permission to add a wrapper or weaken an error bound.

L7: birth conservation and freshness

A transparent layer preserves the complete inner birth algebra. A topology-owning layer appends its children as distinct structural occurrences.

• Inner creations retain order, concrete child behavior, nonce, and CreationKind.
• An inner child is never reinterpreted as a layer-owned child.
• Duplicate protocols remain distinct occurrences.
• A nonce remains correlation data, not an address or freshness proof.
• Same-action creation dependencies retain Bombay's creation-before-send interpretation policy.
• Replacement provenance is carried explicitly and cannot be inferred from address or sequence reuse.

A layer that changes topology must expose the changed birth algebra. It may not claim transparent topology merely so an old role or interpreter continues to compile.

L8: next behavior and lifecycle authority

The inner Continue, phase change, or termination verdict is preserved unless the layer owns a documented lifecycle law that changes it.

Exactly one layer owns each lifecycle fact. Observation, shutdown, replacement, timeout, retry, and termination facts retain their source and generation. Duplicate, stale, contradictory, and late facts have exhaustive outcomes. Shutdown is defined in every intermediate state.

An outer lifecycle layer may suppress an inner verdict only when its state sum explicitly represents why and what later event completes the decision. It may not use a boolean, inferred ordering, or a later cleanup branch to repair a temporarily invalid combination.

Wrapper order is policy. For example, StopOnShutdown<Stash<B>> and Stash<StopOnShutdown<B>> are not presumed equivalent; each applicable order must either have a documented law and tests or be statically unavailable.

L9: higher-order reuse

A higher-order actor may retain a separate implementation only for a genuinely joint law that cannot be expressed by composing existing concrete behaviors. The review must name the correlated state and prove why separate actors or ordinary same-actor layers would alter the semantics.

It is not sufficient that two implementations call the same private helper. If a higher-order template merely selects, parameterizes, or translates an existing behavior, it must be ordinary typed composition and the duplicate fold must be deleted.

Examples of required review:

• keyed affinity should be a layer over the ordinary pool unless key binding is inseparable from the pool's assignment/termination commit;
• fixed supervision may own one shared fleet state machine, but pools must not copy its restart, installation, or shutdown transitions; and
• a queue inside a pool is reusable only when its ownership, admission, completion, and interruption laws are actually the same—not merely because both use FIFO storage.

L10: static metadata follows the real algebra

Protocol hosting, interpreter obligations, and birth requirements are structural projections of the concrete output behavior. They must not be owner-authored duplicate lists, runtime registries, or aliases that repeat an already inferable composed type.

Static proof traits may expose an associated product when a generic framework must consume the product. Such a trait is metadata, not an operational layer, and its tests must use the real owner/interpreter path rather than a synthetic lookalike proof.

Required evidence

A concrete layer is not accepted by a compile-only example. Its evidence must cover every applicable item:

1. construction without naming the output behavior type;
2. complete initialization Actions and order;
3. every owned event and a delegated inner event;
4. complete sends, births, and next verdict;
5. inner and owned controlled errors with state conservation;
6. both relevant wrapper orders;
7. duplicate, stale, contradictory, and shutdown lifecycle facts;
8. a complete outer interpreter path for every new effect capability;
9. an independent model or exhaustive trace for stateful laws; and
10. restoration or simulation of the original defect proving that the regression fails for the intended reason.

Assertions observe a completed transition. They never perform the transition, move required state, or call a required function inside the assertion.

Rejection checklist

Reject a proposed layer or helper if any answer is “no”:

1. Does it own a distinct state or event/effect transformation?
2. Is every event owned exactly once?
3. Are inner effects, births, errors, and verdicts conserved?
4. Is initialization order explicit?
5. Is failure atomic across every coordinated state machine?
6. Does it work through every relevant existing wrapper order?
7. Does it delete more bespoke caller machinery than it adds?
8. Can a user construct the composition without naming its output type?
9. Do tests exercise the public behavior law rather than its helper types?

A compiler error is diagnostic evidence for this review. Passing the compiler is the final representation check, not the design criterion.

Established capabilities

This document defines the production contract for runtime-issued exact actor capabilities. It does not claim that a downstream runtime has already adopted the contract.

The shared TerminalOutcome preserves the distinct execution cause Crash::CapabilityFailed when live execution acquires a capability task failure as its primary stop cause. It differs from a Behavior failure, affine Environment failure, actor-task panic and owner cancellation. Bombay owns detection, retirement, joining and full recoverable result custody; reusable actor templates preserve the supplied cause and apply their explicit policies. An operation failure discovered after an actor has completed remains a coexisting full-result fact and does not rewrite that actor's terminal outcome. A returned domain rejection is interpreted by its owning policy and is not automatically this crash cause. Cancellation selected first remains the primary cause even if a capability failure is also available; the full runtime result retains that failure.

Semantic classification

Actor-model laws:

• actors may communicate only through acquaintances they possess;
• actor names may be communicated; and
• creation allocates a fresh actor name.

Derived Bombay constructions:

• protocol-indexed endpoint families selected by a runtime-owned address type;
• opaque inert recipient capabilities;
• structural child occurrences and named effect products; and
• distinct protocol and concrete-behavior capability strengths.

Deliberate Bombay policies:

• a behavior stages creation with a CreationId that is non-reused within one statically declared child occurrence before allocation;
• all creations in one Actions value commit before dependent sends or interpreter requests from that value;
• successful creation reports an exact installed concrete actor;
• observation and orderly shutdown have explicit correlation identities and complete accepted/rejected fact algebras; and
• public interpretation traits are power-user authority boundaries.

Capability ladder

logical name                     exact protocol endpoint

Recipient<P>                    EstablishedRecipient<P>
    │ address lookup                 │ endpoint transferred directly
    ▼                                ▼
Delivery<P>                     EstablishedDelivery<P>

CreateChild<A, C> --commit--> CommittedChild<C, O>
          │                        │ ID, kind, occurrence, actor
          │                        ▼
          └───────────────> EstablishedCreation<C, O>
                                   │ Installed or Rejected
                                   ▼
                            EstablishedActor<C>

Recipient<P> is a typed logical name. It remains necessary where a stable name, external address, discovery result, or transport address is the intended semantics. Resolving it to a live endpoint is runtime work.

EstablishedRecipient<P> is an inert capability for one exact protocol endpoint. Its representation is <P::Addr as RecipientAddress>::Established<P>. It exposes no endpoint accessor and no direct send method. Transfer occurs through the public InterpretEstablished<P> boundary, so this is a power-user API boundary, not exclusive runtime authority. It does not prove which behavior is installed.

EstablishedActor<B> retains the runtime-owned Installed<B> value. That value projects the exact protocol endpoint and carries lifecycle authority for the same installed B. Its public constructor accepts only this one installed value. Message-only consumers may project an EstablishedRecipient<B::Protocol>; that projection cannot recreate the stronger actor. Generic orderly shutdown transfers the full B value and typed ingress without address lookup.

Why the address owns both capability families

An address used only for exact messages implements RecipientAddress. An actor-hosting namespace implements EndpointAddress, which supplies both projections:

impl EndpointAddress for RuntimeAddr {
    type Established<P> = RuntimeEndpoint<P>
    where
        P: Protocol<Addr = Self>;

    type Installed<B> = RuntimeInstalled<B>
    where
        B: Behavior<Protocol: Protocol<Addr = Self>>;

    fn recipient<B>(installed: &Self::Installed<B>) -> RuntimeEndpoint<B::Protocol>
    where
        B: Behavior<Protocol: Protocol<Addr = Self>>,
    {
        installed.recipient()
    }
}

This preserves static dispatch without imposing an associated endpoint or key on every domain protocol. Each concrete P, including a generic instantiation, produces a distinct EstablishedRecipient<P> capability type. The runtime may reuse one message endpoint representation across protocols; Installed<B> remains indexed by the concrete behavior because two behaviors can share P while accepting different events. There is no hashing, TypeId, dynamic dispatch, erased storage, or manually authored protocol key.

The associated endpoint must be Clone, because an established recipient is transferable acquaintance evidence. It is deliberately not unconditionally Send. Local interpreters may use closure-owned or otherwise thread-local endpoints. InterpretSends requires the complete concrete delivery or request to be Send when an asynchronous interpreter moves it, which naturally requires both the endpoint and P::Msg to be sendable on that path. This keeps executor policy out of inert capability construction and avoids propagating a false P::Msg: Send obligation through local creation, observation, and shutdown facts.

MailAddr intentionally implements only Address. It is a neutral logical address used by pure examples and tests, not a commitment to a runtime endpoint representation.

Creation transaction

CreateChild<A, C> owns one creator-issued CreationId, concrete child C, and explicit birth or replacement intent. The runtime interprets the ordered creation batch and each routed child as a transaction:

prepare one route for every creation without partial consumption
    -> allocate fresh address
    -> initialize child
    -> interpret initialization actions
    -> install exact endpoint and matching B::Event control
    -> commit creator-local (protocol occurrence, CreationId) binding
    -> issue EstablishedActor<B> and publish CommittedChild<B, O>

Route preparation rejection returns the complete untouched batch with ChildNamespaceExhausted. After routing commits, any failed child step publishes a rejected creation result and commits no binding. The owning ChildCreationOutcome settlement separately retains the current child and exact initialization value. The child rejection sum is:

• Allocation(Exhausted | AddressAlreadyClaimed);
• InitializationFailed; or
• EnvironmentFailed.

The allocator's fresh address is independent of CreationId. Address has no derivation operation. A CreationSequence retained by one child occurrence makes reuse within that occurrence unrepresentable. Independent occurrences may issue equal numeric IDs because the occurrence is part of every binding. Stable identity and replacement are higher-level constructions; replacement never means overwriting an address.

A static runtime can derive its creator-local binding product with ChildOccurrenceProduct and a runtime-owned ChildOccurrenceShape. The sealed product retains each direct behavior leaf together with its existing structural occurrence; the runtime decides what endpoint and nonce storage that leaf contains. It adds no runtime value or capability to Behavior, and it does not flatten descendant actors into the current creator's namespace.

Effects retain their nominal occurrence rather than the running wrapper type. ResolveChildOccurrence<O> maps that occurrence back to the exact direct child and position for the concrete emitter. Generated roles pass transparently through wrappers only when Behavior::Protocol and Behavior::Birth are both unchanged. Raw structural positions always refer to the emitter's current birth node, including a topology-changing wrapper's proxy child. No endpoint, binding, or runtime lookup is performed by this type-level resolution.

ChildCreationOutcome<C, O>::Established directly owns CommittedChild<C, O>: ID, CreationKind, occurrence, and exact actor. It cannot nest a rejected EstablishedCreation. The later EstablishedCreation<C, O> report uses the same committed product on success and a typed CreationRejection without authority on failure. The parent behavior is absent from the report type; C is the actual child behavior, not a protocol-only guess reconstructed after the fact.

Same-action local delivery

ChildDelivery<P, O> carries only the child protocol, structural occurrence, nonce, and message. The active parent instance supplies the creator namespace as interpreter context. The interpreter resolves its committed local binding; it does not derive an address or consult an application-wide protocol table.

If the corresponding creation was rejected or no binding exists, delivery must fail through the interpreter's typed error. It may not be silently dropped, redirected, or resolved to an older incarnation.

Exact observation

ObserveEstablishedCreation<C, O> requests the committed result of a staged creation. It returns EstablishedCreation<C, O> to the emitting behavior.

ObserveEstablished::new(id, recipient) constructs one affine whole request with a freshly allocated private correlation. Construct the request outside every Behavior fold, then transfer it into the owning Actions lane; a Behavior may own or emit that prepared request, but does not issue fresh request identity during its fold. The observer-local numeric ObservationId selects a registration slot, not cancellation authority. A never-accepted whole original returned by rejection may be serially retried with its original correlation. New construction always issues a new private correlation, even for the same id and endpoint. Acceptance consumes the original, including when later Started publication fails; it never reconstructs a rejected Observe request after commitment.

ObservationAuthority<P> owns one protocol-indexed permission to attempt cancellation of an exact accepted relationship. It is affine, not a claim that the observed actor or membership is still live. The advanced interpreter consumes the complete Observe request when issuing the original authority, commits its same identity in its sole membership owner, and only then publishes Started. Public interpretation and issuance remain trusted advanced-host boundaries; the type system does not prove that a custom host actually committed membership.

ObservationRelationship<P> is cloneable nonauthorizing identity. It owns one strong Arc<ObservationId> and an invariant protocol brand; the numeric ID is derived from that allocation. Its read-only identity may be compared with a runtime-owned membership value. It cannot be publicly reconstructed, rebranded, or converted back into cancellation permission. Each new request owns fresh identity even when its numeric slot is reused; acceptance transfers that same original identity into the committed relationship.

CancelObservation::new(authority) consumes the exact protocol-matched grant. The request owns that grant until successful cancellation consumes it into a nonauthorizing receipt, or rejection returns the whole original request. Retrying that rejected cancellation retains the same relationship, not a fresh Observe attempt. EstablishedObservation<P> reports exactly:

• Started { authority };
• Stopped { relationship, outcome, at };
• Cancelled { relationship };
• ObserveRejected { request, reason }; or
• CancelRejected { request, reason }.

Stopped carries no actionable permission. Every rejected Observe or Cancel retains its complete original request. Duplicate live numeric slots reject an Observe with IdAlreadyBound; a missing exact relationship rejects a Cancel with NotObserved, including when another relationship now occupies that ID.

The interpreter serializes completion's irrevocable decision to admit a Stopped fact and exact-member removal against cancellation. Cancellation winning that cut publishes Cancelled and permits no later Stopped. Completion winning the cut publishes Stopped and returns a later Cancel as NotObserved. If conversion occurs outside the membership guard, NotObserved may arrive before Stopped; this does not turn a cancellation rejection into an observation terminal fact. Retirement takes the same notification-admission owner before draining control. An already acquired converted event that cannot be admitted remains an original returned event in the existing task hierarchy.

The exact monitor owns one target control sum, emits its original Observe once, and consumes Started only when its request correlation matches. Its cancellation transfer must be returned in the aggregate's typed Actions lane. A rejected cancellation coexists with eventual Stopped and remains consumingly recoverable; its arrival does not suppress the terminal reaction. Monitor into_parts and the target's consuming rejection methods preserve all original current values on the wrong extraction kind. StopOnShutdown::into_inner consumes that wrapper without inventing mutable active-actor authority.

Legacy address-based ObservePeer<A> remains a different operation. It asks a runtime to select an incarnation by logical address and therefore still needs name-resolution policy. It must not be described as equivalent to exact capability observation. Its total action settlement accepts with unit after the relationship is established, or returns the complete request with PeerObservationRejection::UnknownAddress when neither a live incarnation nor authoritative retained termination can be selected. It has no prerequisite; missing interpreter support is corruption rather than unknown-address rejection.

Exact orderly shutdown

ShutdownEstablished<B, TargetPath> combines:

• EstablishedActor<B>;
• an observer-local ShutdownId; and
• Ingress<ShutdownRequested, TargetPath> proving where shutdown enters B::Event.

The interpreter receives the exact installed actor and typed ingress. The request therefore remains an explicit event/effect transformation, not an ambient mailbox or runtime shutdown side channel. Immediate resolution is either Accepted or a typed AlreadyStopping/AlreadyStopped rejection. Later termination remains a separate observation fact.

ShutdownEstablished is an ActionItem under the repository's single total settlement law. Acceptance consumes the request and leaves its ShutdownId. Either lawful rejection returns the complete original request and exact actor capability. InterpretEstablishedShutdown can return only Result<(), ShutdownRejection>; it no longer selects an arbitrary output type. The request retains its original capability until acceptance and supplies a clone to the concrete admission port so rejection remains ownership-complete.

Runtime obligations

A conforming interpreter needs only capabilities justified by the values it drives:

• one concrete message endpoint family and, for actor-hosting namespaces, one concrete installed B family with matching control;
• fresh allocation independent of occurrence-local creation IDs;
• creator-instance protocol-occurrence/CreationId bindings for local child effects, which may be derived statically from the sealed direct-child occurrence product;
• exact endpoint delivery, observation, and typed shutdown interpretation;
• logical-address resolution only for retained Recipient<P> paths; and
• creation-before-dependent-effects ordering.

This contract can remove application-wide per-protocol actor spaces from exact internal paths. It does not make logical address resolution disappear where Recipient<P> is intentionally used.

Composition invariants

• P remains the only protocol identity.
• Structural occurrences are navigation evidence only.
• Wrapping an emitter does not reindex an established or child destination.
• Rejected creation carries no endpoint capability.
• Exact capabilities are transferred only through Actions and explicit interpretation boundaries; they perform no ambient effect themselves.
• Creation, observation, and shutdown correlation IDs are not actor identity.
• No wrapper or domain generic is forced to implement Behavior unless an operation genuinely requires its concrete event or birth algebra.

Behavior adapter contract

An adapter drives one concrete B: Behavior. It owns execution and resource capabilities while the behavior owns state and semantic decisions.

Universal execution law

For each actor incarnation an adapter must:

1. consume B through initialize exactly once;
2. completely interpret initialization Actions before accepting mailbox events;
3. process at most one accepted B::Event at a time;
4. call transition exactly once for that event;
5. if the fold succeeds, interpret the returned Actions exactly once; and
6. commit its Continue, Goto, or Stop verdict exactly once.

A controlled fold error commits no partial actions. Cancellation or adapter failure must not manufacture a successful semantic fact.

Static boundary

The adapter is monomorphized over the complete behavior and its capabilities:

B: Behavior
B::Sends: InterpretSends<Adapter, B::Event, Here>
B::Birth::Child: DispatchBirth<B::Protocol::Addr, Adapter>

The concrete bounds vary with the host design, but every lane and child alternative must have a compile-time implementation. A universal driver may be generic; it may not erase events, effects, endpoints, futures, or child types to achieve universality. EndpointAddress itself does not require every endpoint to be Send. A thread-safe driver instead requires Send on the concrete Actions, request, event, endpoint, or future that it actually moves across its asynchronous boundary.

Actions commitment

For one successful Actions value, the adapter interprets:

1. creations in vector order, reserving a fresh unpublished address, running each child's pure initialization fold, then privately committing its host, exact endpoint, and creator-local binding when those steps succeed;
2. each committed child's initialization effects once before public publication or ordinary ingress;
3. every named sends lane in its structural InterpretSends order; and
4. the next-behavior or termination verdict.

All creation attempts precede sends and interpreter requests from the same action. This is a Bombay policy that makes create-then-send and create-then-observe deterministic. It is not a general actor-model ordering guarantee between independent actors.

Within SendLayer, inner effects are interpreted before wrapper-owned effects. Within a vector lane, values retain vector order. The algebra deliberately does not invent an order between independent product lanes beyond the product's own InterpretSends implementation.

An expected rejection retains its complete request and does not suppress independent later effects. Interpreter corruption retains the settled prefix, faulting value, and untouched suffix. Neither outcome can be reinterpreted as successful readiness, restart, or observation. A child whose private host was already committed remains an established birth even when its initialization effects later fail; it drains without public publication.

Fresh creation

CreateChild<A, C> contains a CreationId that is non-reused within its exact static child occurrence, a concrete child, and CreationKind. The adapter must not derive an address from the creation ID. Equal numeric IDs belonging to different occurrences remain different correlations.

For each ordered creation batch and routed request it must:

• prepare every required runtime route without partially consuming the batch;
• allocate an address fresh with respect to the actor configuration;
• initialize the concrete child exactly once;
• install a private runtime host, exact endpoint for C::Protocol, and matching C::Event control authority;
• atomically commit the creator-local protocol-occurrence/CreationId binding;
• report EstablishedCreation<C, Occurrence>::Installed after that commitment, without claiming initialization-effect success; and
• interpret the child's initialization actions once, then make a continuing successful child publicly resolvable before ordinary ingress.

Failure before host commitment publishes no capability. Failure after private commitment preserves the established birth and its exact action settlement but does not publish the endpoint to logical resolution. After ownership transfer, InitializationRejected returns the current child and exact error, while InitializationPanicked returns the extant current child after a caught pure initialization panic, and HostRejected returns the current child, uninterpreted initialization actions, and matching CreationRejection. Before transfer, rejection returns the original creation batch with ChildNamespaceExhausted. An allocation collision is CreationRejection::Allocation(AddressAlreadyClaimed) when the selected allocator rejects it; it can never mean replacement.

DispatchBirth recursively selects the concrete child. One EstablishChild<Occurrence, C> implementation is required per structural occurrence. Position is interpreter navigation evidence, not hosting identity.

When the adapter retains exact child bindings, it may derive their complete direct-child product through ChildOccurrenceProduct. Behavior owns and seals the leaf, ChildChoice, and Never recursion; the adapter's ChildOccurrenceShape chooses only its storage constructor. The product is compile-time structure and performs none of the creation transaction above. Each installed child derives its own product from its own Behavior::Birth, so creator namespaces are not flattened or shared.

When an effect carries a nominal occurrence, require Emitter: ResolveChildOccurrence<Occurrence> and select the mapper-owned slot with its associated Position. This sealed projection accepts generated roles, raw ChildHead/ChildTail<_> paths, and genuinely transparent wrappers. It rejects inherited roles when a wrapper changes protocol or birth topology; an adapter must not repair that mismatch with a registry or runtime search.

Destination interpretation

The three delivery paths have different obligations:

The adapter must preserve P statically throughout. It may not coalesce two protocols merely because their addresses or message layouts match.

EndpointAddress lets the runtime's own address newtype select the endpoint family. InterpretEstablished, InterpretEstablishedDelivery, and the exact observation/shutdown interpreter traits are public power-user boundaries. They do not grant endpoint access outside the explicit transfer call, but they are not sealed as exclusive runtime authority.

Event injection

Interpreter-originated facts return through their declared ReturnsToEmitter<Input, Path>. The adapter retains the corresponding Ingress<Input, Path> or equivalent static constructor and enqueues exactly the root B::Event it produces.

Ancestor reports instead carry their destination ingress in the request and declare NoReturnToEmitter. For ReportShutdownPlan<P, Path>, the adapter calls into_event and enqueues that exact root event. It must not deliver the plan to the emitting inner lane, mutate the coordinator directly, or treat the request as successful installation before the coordinator consumes the event.

It must not inspect payload types to find a lane. Repeated fact types at different wrapper depths are distinct because their structural paths are distinct.

Observation

Exact observation uses ObservationId as observer-local relationship correlation and the supplied endpoint as incarnation identity. The adapter must return a complete EstablishedObservation<P> fact for start, cancel, rejection, or eventual stop. Duplicate live IDs and cancellation of a missing relationship are explicit rejections.

Address-based ObservePeer<A> remains separate. A missing live address is not proof that the requested incarnation stopped. Without a selected live incarnation or authoritative retained terminal fact, the adapter returns its own error rather than fabricating PeerStopped.

Orderly shutdown

ShutdownEstablished<B, Path> supplies an exact endpoint and a typed Ingress<ShutdownRequested, Path>. The adapter injects that event through the normal mailbox boundary. It returns EstablishedShutdownResolved<P>::Accepted only when the request is admitted, or the precise rejection otherwise.

The same attempt returns the generic action settlement: accepted leaves the exact ShutdownId, while AlreadyStopping or AlreadyStopped returns the complete ShutdownEstablished request. The concrete shutdown port returns only Result<(), ShutdownRejection> and cannot substitute another settlement shape.

Acceptance is not termination. Eventual termination is reported through the observation relationship.

Environment and liveness

Clock reads, timer queues, bounded-mailbox waiting, task scheduling, endpoint storage, networking, persistence, and operating-system failures are adapter concerns. They must enter or leave the fold only through declared typed events, effects, and errors.

Backpressure may delay a concrete interpretation future. The adapter must not silently drop or reorder accepted effects. Fairness, scheduling policy, and resource limits are runtime policy and should be documented by the runtime, not presented as laws of this crate.

Conformance checklist

• initialization once and before mailbox events;
• one event at a time and one fold per accepted event;
• creations before dependent sends/requests;
• fresh allocation independent of nonce;
• rejected creation commits no binding or endpoint;
• static interpretation for every effect and child occurrence;
• exact endpoints bypass logical-name resolution;
• all returning facts use their declared structural ingress;
• ancestor reports use only the explicit ingress capability carried by the request;
• no erased envelopes, registries, downcasts, or hidden side effects; and
• no success, restart, stop, or observation fact is inferred from failed mechanics.

Exact observation ownership

The exact observation interpreter consumes the whole ObserveEstablished<P> or CancelObservation<P> request. It must preserve that original on rejection, commit the issued exact relationship before publishing Started, and consume a successful cancellation grant into its nonauthorizing relationship receipt. Stopped retains exact relationship, outcome and notification timestamp without retaining cancellation permission. Completion decision and cancellation share one membership owner; a reused numeric ID cannot authorize an old grant. A custom interpreter is a trusted issuance boundary, not a compiler-proven registration service. See Established capabilities for requests constructed outside folds, original input emission, serial never-accepted retry, both legal control arrival orders, and retirement admission custody.

Actor composition

bombay-behavior-actors exposes concrete actor folds and typed event/effect transformations. Applications connect those actors with ordinary typed composition. A constructor recipe is not a separate actor template when it only selects policy values, forwards to another constructor, or hides a nested type.

These compositions are derived Bombay constructions. They preserve the pure behavior boundary: one typed input produces complete Actions and a next behavior decision, while the interpreter alone realizes delivery, creation, observation, scheduling, and shutdown effects.

The composition map

There are two orthogonal ways to compose Behavior Actors. They may be used together, but they do not mean the same thing.

LogicalHostRequirements separately derives the ordered product of every intentional logical Delivery<P> in the root and its transitive births, including interpreter requests that carry a logical recipient. It excludes established-incarnation delivery and creator-local child effects while retaining repeated protocol occurrences. A runtime may recursively require its own static Hosts<P> proof for that product; the projection creates no host and performs no lookup.

Same-mailbox layers

A layer constructs a new concrete behavior around one existing behavior. Both participate in one mailbox fold. Put the domain state machine at the center and add only transformations that own a distinct event/effect law:

StopOnShutdown                         root lifecycle transformation
└── ReceiveTimeout                     activity/timer transformation
    └── Stash                          bounded hold/replay transformation
        └── DomainBehavior             application transition law

Callers compose at the value level; Rust infers the full nested type:

let behavior = domain
    .layer(|inner| Stash::new(inner, |_, message| admission(message)))
    .layer(|inner| ReceiveTimeout::new(inner, timer, idle, on_idle))
    .layer(StopOnShutdown::new);

BehaviorLayer itself performs no actor effect. Each concrete transformation still owns and documents its event routing, initialization order, sends product, failure, and terminal decision. Reordering layers can therefore change the program and must be chosen from those laws, not from type convenience.

Actor-to-actor topology

Independent actors keep independent mailboxes. They compose through typed routes and explicit ownership, not by flattening their protocols into one envelope. Atomic actors have two intentionally different worker relationships:

FixedSupervisor ─┐
                  ├─> StableProxy ─> worker
DynamicSupervisor┘

FifoPool  ────────> direct worker
KeyedPool ────────> direct worker

The supervisors reuse the one stable-service and worker-replacement law owned by StableProxy. Pools own assignment, completion, recovery, and worker retirement directly; they contain no supervisor or stable proxy. A Router, queue, workflow, or domain actor remains a peer whose own transition law is connected through a typed transferable capability.

The short responsibility map is atomic-actor-architecture.md. The sole application-facing construction and worker-authoring syntax is atomic-actor-devx.md; this composition guide does not repeat either specification.

Choose the owner of the law

The catalogue is a vocabulary of state-transition laws, not a list of stacks that must always be used together:

If two laws belong to different actors, connect them with DeliveryRoute. If one law transforms the same mailbox fold, construct it with Behavior::layer. If neither is true, the application is defining a new topology or a genuinely new transition law; hiding that fact in a generic wrapper would be incorrect.

Application routing and atomic actors

FixedSupervisor owns declared-roster recovery and DynamicSupervisor owns bounded keyed service membership. Neither also owns application command selection. Both rely on StableProxy for the stable service protocol and worker replacement, so application clients receive only the service capability—not a worker route or supervisor control capability.

A pool is different: it accepts customer jobs and owns direct assignment to its workers. It never exposes those worker routes. FIFO owns one global admission order; keyed pooling owns per-role queues and future-admission affinity. Their complete differences are owned by the two pool documents, not by a selector mode in this guide.

When an application command selects a worker, that selection is application state-transition policy. Keep it in the application behavior and emit a typed delivery to the chosen stable service, or place a concrete routing actor beside the supervisor and give it those capabilities. The supervisor remains responsible for recovery and stable service ownership; the router remains responsible for command admission and destination selection. This composition makes both protocols and both rejection laws visible to Rust.

Router is deliberately unicast and transfers ownership of a command to one selected route; it does not require the command to be Clone. Use Topic or PubSub when fan-out and its explicit cloning cost are the intended law.

Bombay application provisioning

Bombay must distinguish two creation owners:

• Root::Birth contains only children the root behavior can itself create and correlate with creator-issued CreationId values.
• Application contains peers provisioned by the application declaration.

An application child must therefore stop appearing in the root's births = { ... } declaration merely to make it runnable. That old arrangement forces the declaration to name the child's fully composed type before Rust can infer it. It is the source of aliases such as ManagedTask = StopOnShutdown<Task<...>>.

The application declaration should instead store each semantic slot and child value in its own heterogeneous product. Its private application-child owner keeps one sequence for those declarations and lowers the resulting values through the existing Children product. That sequence is independent of the root's creation state; equal numeric IDs remain distinct because root and application children occupy different static occurrences. Bombay selects runtime routes only when it interprets that creation batch. The public spelling contains values, not nested type declarations:

struct Tasks;
struct Events;

let application = Application::new(root)
    .child(Tasks, WorkQueue::new(worker).stop_on_shutdown())
    .child(
        Events,
        Topic::<MailAddr, Event, Recipient<EventSink>>::new()
            .stop_on_shutdown(),
    );

Tasks and Events are nominal application roles, not aliases for actor types. The expression passed to each child call determines the concrete child type. Each call returns the next inferred application-product type, so neither the composed child types nor the final Application<...> type is written by the caller. A zero-state generic actor such as an empty Topic still needs enough protocol arguments to determine its law; that is real protocol information, not a mechanical nesting alias.

Internally, Bombay needs one private application-child product with an associated Product: ChildProduct<MailAddr>. It should return Children<MailAddr, Product> after issuing IDs from the application-child sequence. The running application then uses exactly these Behavior projections:

type RootNode<R> = <<R as Behavior>::Birth as BirthMode>::Child;
type AppNode<L> = <<L as StageApplicationChildren>::Product
    as ChildProduct<MailAddr>>::Choice;
type RunningNode<R, L> =
    <RootNode<R> as BirthNodeAppend<AppNode<L>>>::Output;

impl<R, L, Routes> Behavior for RunningApplication<R, L, Routes>
where
    R: Behavior<Protocol: Protocol<Addr = MailAddr>> + BehaviorBase,
    L: StageApplicationChildren<Routes>,
    RootNode<R>: BirthNodeAppend<AppNode<L>>,
{
    type Birth = Births<RunningNode<R, L>>;

    // init:
    // 1. initialize R;
    // 2. issue one ID per application-child occurrence;
    // 3. lower L through Children::into_creates;
    // 4. call BirthNodeAppend::append_creations(root, application);
    // 5. rebuild Actions with the original sends and become decision.

    // transition:
    // delegate to R, then call append_creations(root_creates, Vec::new()).
}

BirthNodeAppend keeps RootNode<R> as an exact structural prefix. Existing root roles therefore retain the same child and position after application peers are appended. It also preserves every child value, creation ID, CreationKind, and within-lane order, with root creations before application creations. It does not allocate, install, or validate address freshness. Bombay still owns runtime route selection and must surface initialization-twice or child-product rejection as a typed private running-application error rather than panic.

This lets Bombay delete its root-shaped vacant-slot machinery: RuntimeApplicationTopology, EmptyApplicationTopology, VacantChild, OccupiedChild, AvailableApplicationRole, FillApplicationRoleAt, and InjectApplicationChildAt. A smaller role-indexed application product remains because it owns a genuine law absent from Children: semantic naming, deferred creation-ID issuance, and construction of runtime child handles.

The runtime must derive installation storage from the running application's combined birth algebra, not from Root::Birth. Consequently BirthProtocols automatically includes the root, genuine root children, application peers, and every transitive birth. Intentional logical destinations remain concrete in the composed send products. Behavior does not fabricate a completeness proof by asking the application to repeat those destinations in metadata, and Bombay must not add a protocol registry to compensate.

Unicast and broadcast in Bombay

Router is only unicast. Use RoundRobin, LeastLoaded, ConsistentHash, or RendezvousHash; each successful route transfers one owned message to at most one member. Bombay must remove stale Router<Broadcast> examples and imports, not recreate a broadcast strategy or compatibility wrapper.

Fan-out is the distinct Topic/PubSub state-transition law:

• Topic<A, P, Route> owns one insertion-ordered membership snapshot; TopicMessage::Publish(P) sends a clone to every member.
• PubSub<A, K, P, Route> additionally owns keyed topic introduction, known-empty retention, and per-topic membership; PubSubMessage::Publish { topic, value } fans out within one key.

Choose Route truthfully. EstablishedRecipient<P> broadcasts to exact installed incarnations and adds no logical-host requirement. Recipient<P> broadcasts to intentional logical identities, so the application topology must install that concrete protocol. For stable replaceable workers, subscribe the logical stable protocol, not a stale exact worker incarnation. Different destination protocols remain different actors and are connected with typed MessageAdapters; Topic never erases them into a common envelope.

Root shutdown

Use StopOnShutdown<B> when a shutdown request means that this actor stops directly. Use FinalizeOnShutdown<B> when shutdown must run one typed finalizer and preserve all of its sends, creations, and terminal decision. If shutdown must first be delegated to a coordinator, place that coordinator at the root; no guardian alias or builder is required.

These transformations compose like every other wrapper:

let direct = StopOnShutdown::new(application);
let finalizing = FinalizeOnShutdown::new(application, finalize);
let coordinated = ShutdownCoordinator::new(application, plan);

The choice is deliberate Bombay policy. It is not automatic discovery of a nested shutdown handler.

Plans derived from committed children

ShutdownCoordinator and HeterogeneousShutdownCoordinator own the distinct homogeneous and heterogeneous ordered-shutdown folds. A topology-owning application that cannot construct its plan until children commit records those committed EstablishedChild capabilities in its own state. Once complete, it emits ReportShutdownPlan::new(plan) in its ordinary Actions send product. The interpreter returns the corresponding typed InstallShutdownPlan<P> event to the coordinator.

The topology owner must preserve the following policy:

• only a successfully committed creation contributes a child target;
• rejection remains a typed application transition failure;
• every declared role contributes exactly once;
• an early shutdown request remains pending until installation; and
• a plan installs at most once.

This is ordinary actor communication between two concrete folds. A generic child-plan wrapper cannot own these laws because it does not own the application's topology or role state.

Observation

Watch<B> is the recurring logical-name observation transformation. It continues observing later incarnations of the same logical peer. TerminationMonitor owns a correlated, exact-once observation lifecycle and consumes its terminal relationship. Exact-incarnation monitoring uses that same monitor law with an established target and an ordinary typed reaction.

Those recurrence laws are different, so they remain separate folds. Target aliases and established-watch wrappers add no law and are unnecessary.

Pools and shutdown products

FifoPool and KeyedPool each implement their public transition law directly. They may reuse private data helpers, but neither delegates its Behavior fold to a hidden generic actor engine. FIFO assignment and persistent key affinity have different state transitions.

Likewise, homogeneous and heterogeneous shutdown coordinators retain separate folds. Their phase products select different concrete child effect lanes, so a generic execution engine would hide the very distinction the public types are meant to prove.

Audit record

The complete catalogue classification and change ledger are in Actor-template composition audit. The broader capability and adversarial-test record remains in Behavior Actors template-law audit.

External actor-system interface

This note records the intended public boundary between a Bombay actor system and every external consumer: HTTP handlers, command-line programs, tests, embedded callers, and future authenticated transports. It is an architecture decision, not a claim that the downstream Bombay runtime already implements the complete contract.

Decision

Bombay should expose one transport-neutral, statically typed actor interface:

ActorInterface<Api>

Api is an application-defined named product of actor capabilities exported to the environment. The interface can also establish a real external actor/customer with a fresh typed address, an exact reply capability, and one affine receive authority.

Conceptually:

struct Api {
    orders: EstablishedRecipient<Orders>,
    discovery: EstablishedRecipient<ServiceDiscovery>,
}

let interface: ActorInterface<Api> = application.interface();
let mut caller = interface.external::<OrderReplies>()?;

caller
    .send(
        &interface.api().orders,
        OrderCommand::Get {
            reply_to: caller.recipient(),
        },
    )
    .await?;

let reply = caller.receive().await?;

The names above are illustrative. The semantic contract, rather than a particular spelling, is the decision.

The interface is not the actor runtime. Scheduling, mailbox interpretation, allocation, transport, topology ownership, and lifecycle control remain private runtime responsibilities. In particular, an untrusted external consumer does not receive the complete application topology or root shutdown authority merely because it can communicate with exported actors.

Source classification

Actor-model law

An actor configuration exposes receptionists: internal actor names known to the environment. It may also know external actors: actor names outside the configuration. Communication can expand these sets by transferring actor names. This is the actor-model basis for an explicit interface formed from exported actor capabilities and real external customer endpoints.

Primary sources:

• Gul Agha et al., A Foundation for Actor Computation.
• Gul Agha, Actors: A Model of Concurrent Computation in Distributed Systems.

The actor model does not require a global application router, a service registry, a public/private modifier on behavior types, or a generic ask operation.

Derived Bombay construction

• Api is a closed, statically typed product that names the initial receptionist set.
• An external actor owns a fresh address, a cloneable exact send capability, and an affine receiver.
• A request carries its reply capability explicitly. User::from records the truthful origin of the communication; it is not implicitly the reply protocol.
• Logical and exact destinations remain distinct. A stable logical name may be appropriate for discovery, proxies, or transport. An exact recipient identifies one installed incarnation and must never retarget.
• Discovery is an ordinary typed actor protocol that can return additional actor capabilities. It is not privileged runtime lookup.

Deliberate Bombay policy

• Application composition explicitly chooses the initial exports. Root is not automatically public, and declared children are not automatically public.
• HTTP, CLI, tests, embedded integrations, and future transport gateways use the same interface contract.
• A future Zenoh/KERI boundary authenticates an external identity and decides which typed interface or capabilities it may receive. Authentication, serialization, and transport do not enter the Behavior algebra.
• Lifecycle ownership and the external communication interface are separate capabilities.

Visibility law

Bombay does not need a PublicActor behavior marker or inferred visibility. The same behavior may be public in one application and private in another.

An internal actor is externally reachable exactly when:

1. its capability occurs in the initial Api receptionist product; or
2. an already reachable actor later sends its capability to an external actor.

An actor that has not crossed that boundary remains private because the external party cannot name it. Discovery changes reachability only by returning a typed capability through ordinary actor communication.

Discovery

Registry and Resolver already supply the basic reusable discovery construction. No new Behavior Actors template and no new Behavior Core algebra are required.

Passing only a discovery receptionist to a particular boundary is a valid application policy when discovery is intentionally the sole bootstrap capability. It is not a universal actor-system rule. Another application may export several static receptionists, only its root protocol, or no discovery actor at all.

A heterogeneous global registry would require erasure or a closed application-specific protocol product. Bombay must not add an untyped global envelope, runtime protocol registry, Any, or string-based lookup to simulate heterogeneous discovery.

Request and reply

Actor-native request/reply is customer passing: the request contains a typed reply capability. A truthful external caller therefore needs a real endpoint that an internal actor can retain and use. Fabricating the target address as the sender, using an unclaimed raw address, or treating User::from as an implicit reply destination violates this contract.

The fundamental interface operation is external actor creation plus typed send and receive. A generic ask convenience may be derived later, but only after Bombay defines:

• timeout ownership;
• cancellation and overlap;
• whether the reply actor remains live after caller cancellation;
• late-reply handling;
• correlation and stale-reply behavior; and
• the typed result when an exact late delivery is rejected.

This is not cosmetic. In the current exact-delivery runtime contract, sending to a closed exact endpoint is an interpretation failure. Closing a temporary reply port on timeout could therefore make a correct but late reply fail the replying actor's action. Bombay must choose and test that policy explicitly rather than silently adopting dead letters or dropping the message.

Behavior Actors support

The catalogue audit classified every stored or received recipient by semantic role. All arbitrary customer/reply destinations are now parameterized by the sealed DeliveryRoute construction, which projects Protocol and Sends, instead of being hard-coded as Recipient<Reply>:

DeliveryRoute projects the protocol and concrete sends product from the route itself. Stateful templates such as dynamic supervision therefore cannot pair a retained route with an unrelated nominal reply protocol.

Creator-local child communication is not a transferable DeliveryRoute. Behavior retains a creator-issued CreationId; Bombay privately maps that ID and the statically selected child occurrence to its runtime route.

Registry membership, configured downstream destinations, worker completion targets, stable proxy identity, and transport names remain logical where that is their actual domain. The route migration changes only customer-passing seams. Compile-contract tests instantiate every such template with exact and mixed routes, while interpreter tests prove that a mixed lane neither converts capabilities nor reorders deliveries.

The shutdown coordinators also support creation-dependent topology. They may start in AwaitingPlan. The child composition constructs the plan only after every configured creation commits and emits ReportShutdownPlan through its returned Actions. The report's final destination is inferred from the complete static actor composition; application code supplies neither a path nor a route. Interpretation enqueues exactly one InstallShutdownPlan event for the owning coordinator. An earlier shutdown request remains retained until that event is folded. Homogeneous and heterogeneous plans are different event types and cannot be substituted. This is explicit Bombay lifecycle policy, not a new actor-model primitive.

Both additions live wholly in Behavior Actors and use existing Core events, effect products, exact recipients, child routes, and composition paths. No new Behavior Core algebra is required.

Rejected designs

The following alternatives fail the intended laws:

Required runtime work

The downstream Bombay runtime should implement this contract holistically:

1. establish a fresh external actor endpoint with truthful typed origin;
2. expose a named application-specific receptionist product;
3. retain cloneable send capability and affine receive authority;
4. keep exact recipients incarnation-bound and return the original message on admission rejection;
5. separate the client interface from topology and lifecycle ownership;
6. adapt HTTP, CLI, tests, and later transport gateways to this same boundary;
7. preserve accepted-prefix draining and deterministic endpoint closure; and
8. keep raw runtime address and mailbox representations private.

The complete composition must prove that a protocol mismatch cannot compile, receive authority cannot be cloned, private topology cannot be acquired from the client interface, a stale exact endpoint cannot retarget, and capability transfer can deliberately expand the reachable receptionist set.

Audit hypotheses

The architecture audit produced the following verdicts:

1. A central application router is not the actor interface.
2. Discovery is not universally the sole boundary.
3. Publicness cannot be inferred from names or topology.
4. Publicness is not a property of a reusable behavior type.
5. The initial interface is an explicit typed receptionist product.
6. Capability transfer may expand the reachable interface.
7. An external caller must own a real endpoint and truthful origin.
8. A fabricated or unclaimed origin is invalid.
9. User::from is provenance, not an implicit reply protocol.
10. Requests carry reply capabilities explicitly.
11. Receive authority is affine.
12. Send capability is transferable and cloneable where its endpoint permits.
13. An exact capability never retargets to a later incarnation.
14. Exact admission rejection preserves the rejected message.
15. A logical reply route is not universally sufficient.
16. DeliveryRoute supplies the existing static logical/exact abstraction.
17. The public interface must not expose the complete topology.
18. The public interface must not imply lifecycle authority.
19. Generic ask requires a separate explicit lifecycle policy.
20. The interface is transport-neutral and exposes no raw mailbox address.

These conclusions require no new actor template and no new Behavior Core algebra. The Behavior Actors route-capability and late shutdown-plan work is complete; the explicit unified interface itself remains downstream runtime work.

Atomic runtime interpretation and settlement

Status: H02 static representation proven; H07 has lowered total item, heterogeneous creation, and complete Actions settlement into Behavior; H10 fixes each named settlement product independently of the runtime; H03 records the required Bombay terminal-custody contract. Bombay will change to implement this architecture; its present interfaces do not constrain the atomic design. This document is the sole normative owner of generic action settlement, creation dependency ordering, initialization settlement, terminal custody, residual retirement, and the Bombay Engine integration requirement.

Ownership

Actions is Bombay's typed realization of actor transition effects: communications, staged fresh actor creation, and the next behavior or termination decision. It is not literally Agha's effect triple: typed products, termination, initialization, creator-local routing, and interpretation order include derived constructions and Bombay policy.

Behavior owns only pure static products. Bombay interprets concrete capabilities and owns runtime custody. Neither aggregate transitions nor generic Behavior machinery may contain tasks, clocks, channels, address spaces, observation publishers, callbacks, or runtime handles.

Total item law

For each declared item, interpretation produces exactly one outcome:

Accepted { receipt-or-promised-success }
Rejected { complete-original-item, exact-reason }
Blocked { complete-untouched-item, exact-prerequisite }

Blocked means a declared dependency did not commit; it is not a generic failure or a reason to suppress independent siblings. A corrupt interpreter result retains the recorded accepted/rejected prefix, the exact faulting item, and the complete unattempted heterogeneous remainder.

The product law is total and static:

• lanes and items are interpreted in their declared stable order;
• rejection does not short-circuit independent later items;
• every accepted item is consumed and leaves only its specified receipt;
• every rejected item returns its complete original value;
• dependency-blocked items remain untouched with the exact prerequisite;
• no positional traversal, runtime graph, erased envelope, callback, or per-template settlement adapter is permitted; and
• a stopping actor is not required to receive its own settlement.

Any generic Behavior representation must prove this law through two unrelated catalogue templates and two wrapper orders without placeholders before catalogue migration begins.

Each action item fixes its accepted receipt, rejection, and prerequisite types. SendSettlements projects a concrete sends product to one complete settlement product without naming a runtime, root event, or structural path. InterpretSends may decide only the attempted outcomes within that fixed product. A stopping aggregate can therefore retain one typed settlement value without coupling its state to Bombay or adding a template-specific adapter.

The H02 non-production model satisfies that representation gate with a recursive heterogeneous product and the existing SendLayer inner-to-outer order. It preserves complete values after rejection/blocking, attempts independent later items, retains exact prefix/fault/remainder at every product position, and rejects a deliberate short-circuit trace. This proves stable-Rust realizability, not production implementation or Bombay custody.

Creation dependencies

Actor-model creation requires fresh allocation. A creating Behavior issues one checked CreationId, non-reused within the exact statically declared child occurrence, and emits the complete child in the existing creation leg. The occurrence and ID together are creator-visible correlation, not an address, runtime route, actor identity, or establishment capability. Independent pure layers do not share an ID issuer; equal numeric IDs in distinct occurrences are lawful. The interpreter commits a successful fresh creation before same-action communications or observations that name that occurrence and ID. This ordering is Bombay policy.

Creations owns one ordered creation batch. Bombay accepts that whole batch for routing or returns it unchanged with ChildNamespaceExhausted; it may not consume only a prefix. On acceptance Bombay privately pairs every request with one route from the current creator namespace, then the generic creation interpreter attempts each routed request independently in declared order. An expected child-establishment rejection does not suppress later creations or independent sends. Interpreter corruption retains the completed prefix and the exact routed remainder.

Behavior exposes no ChildRoute and never constructs an Address::Nonce. Bombay owns the private mapping from exact typed child occurrence plus CreationId to its runtime route. Child communications, lifecycle requests, reports, and creation prerequisites travel through that typed occurrence and carry its ID; runtime code resolves the pair to a route. An ID from one occurrence cannot satisfy another occurrence even when their numeric values are equal. A rejected routed creation remains in runtime settlement custody with its child, ID, kind, and selected route. Retirement transfers unresolved batches and routed creations through the same parent-to-root custody path as every other affine runtime value.

After a complete interpretation, one typed CreationsSettled input returns the entire creation leg to a live creator. The batch remains the ownership and ordering unit; templates do not rebuild a per-child settlement join. NoBirths requires no custody port. If creator admission is closed, the unchanged batch continues through parent-to-root custody.

There is no separate route request, result, aggregate waiting phase, or ReturnToEmitter continuation. Route preparation is the first generic step of interpreting the one creation leg through the unchanged Driver. It creates no mailbox, task, registry, callback, or lifecycle service.

An establishment attempt that accepts ownership of a child definition returns an authoritative ChildCreationOutcome<C, Occurrence>. Established owns the exact capability. InitializationRejected returns the current child and exact initialization error. InitializationPanicked returns the extant current child after a caught pure fold panic, without claiming a typed initialization error or actions. HostRejected returns the current child, uninterpreted initialization actions, and exact reason. These are semantic creation rejections, not interpreter corruption, and none reconstructs the pre-initialization child. Rejection or corruption before ownership transfer instead returns the complete original CreateChild through ItemSettlement.

A behavior declares that request through exactly one of two domain operations: CreateChild::birth or CreateChild::replacement. CreationKind remains authoritative carried provenance for interpreters and typed results; it is not a third, context-free application constructor. Closed child-product composition may reconstruct the same request internally while preserving its owned kind.

Semantic creation rejection blocks only operations whose typed prerequisite is the uncommitted child binding. After creation commits, rejection of one observation blocks only operations that depend on that observation; lawful child delivery, input, shutdown, termination observation, and unrelated observations remain independently eligible. The dependency relation is expressed by the concrete child-operation item type and its InterpretItem::Prerequisite: ObserveCreation, ObserveEstablishedCreation, ObserveChild, ChildDelivery, ChildInput, and ShutdownChild are the only current same-action child families. The runtime transaction retains their typed resolution by exact child protocol, occurrence, and CreationId. ObserveCreation<P, Occurrence> returns CreationResolved<P::Addr>; it does not erase P to its address. No general dependency graph, lane index, or wrapper position is consulted.

A route collision can only falsify Bombay's accepted batch-preparation receipt; it is interpreter corruption, never replacement. Namespace exhaustion rejects the untouched batch before route transfer. Replacement provenance is explicit typed semantic data and never inferred from address reuse, route reuse, or sequence arithmetic.

Initialization and activation order

Initialization is part of the Behavior contract. Its actions are interpreted before ordinary mailbox ingress and compose with wrapper initialization in one defined order:

fresh address reservation, no live endpoint
  -> pure definition initialization fold
  -> endpoint installation and creator-local binding commit
  -> total initialization-action interpretation
  -> initialization settlement and residual custody
  -> activation authorization and attempt, where required
  -> exact readiness or failure fact, where required
  -> ordinary ingress only after a continuing, successfully settled initialization

Initialization may stop with final actions. Accepted initialization effects are settled before ordinary ingress, even when the resulting actor is stopping. Activation capacity is actor-side admission before an action is emitted; it is not relabelled as an interpreter rejection afterward.

Reservation rejection retains the complete staged creation without running the fold. Pure initialization rejection retains the current child and exact error. Host rejection after the fold retains the current child and uninterpreted initialization Actions. After installation commits, an effect rejection or interpreter fault belongs to the installed child's drain and cannot be recast as a creation rejection. A stopped initialization settles its final actions without permitting ordinary ingress. Fresh allocation is the actor-model requirement; this packaging and ordering are Bombay policy.

Exact Bombay changes for worker initialization and activation

Bombay must keep the installed child closed to ordinary traffic and retain its complete initialization-action settlement in the existing child lifecycle host. The settlement never moves into StableProxy state or a supervisor report. After ChildCreationOutcome::Established, an atomic owner retains its non-cloneable worker state and emits InitializeWorker<W, P>. That request contains only a cloneable exact worker target, opaque worker and initialization correlations, and the moved activation plan. It does not move the aggregate's worker, name the worker's action product, or search by runtime type.

The request is an ordinary ActionItem with accepted unit and uninhabited capability rejection or prerequisite. Bombay interprets it by locating the already existing child host through the supplied established target. Missing support is interpreter corruption, not an invented runtime rejection. The host calls InitializeWorker::resolve with exactly one WorkerInitializationOutcome::ReadyForActivation | EffectsRejected | Stopped result, which reunites that result with the affine plan as WorkerInitializationReport. The request and result run inside the unchanged Driver and retirement barrier.

Bombay's local environment must interpret that request through its exact installed-child capability. Acceptance transfers the request to the already existing child lifecycle host; it is therefore a non-rejecting local custody operation. Missing typed support is interpreter corruption and retains the complete request. It is not an expected mailbox, observer, or capacity rejection. When initialization settles, the host returns exactly one Tier-1 WorkerInitializationReport input:

ReadyForActivation { worker evidence, original plan, one activation permit }
EffectsRejected {
    worker evidence,
    original plan,
    failure: EffectsRejected | InterpreterCorrupt
}
Stopped { worker evidence, original plan, exact stop }

The host derives failure by inspecting the complete settlement's SettlementStatus without consuming that settlement. Accepted selects the Initialized alternative and cannot inhabit WorkerInitializationFailure. Expected capability rejection or dependency blocking selects EffectsRejected; interpreter corruption or an unattempted suffix selects InterpreterCorrupt. The exact settlement remains attached to the concrete worker environment. StableProxy drains the worker and reports only this semantic classification, its activation plan, and the exact worker result.

A foreign worker or initialization correlation returns the complete request and report unchanged. Failed creator admission follows RecoverEvent and the existing parent-to-root custody path. No template-specific Bombay conversion, second mailbox, or detached task is allowed.

If StableProxy admission closes, Bombay retains the complete WorkerInitializationReport input, including the activation plan, beside the worker environment's exact action settlement. Parent retirement transfer moves both values outward as one statically typed residual. This is not a lookup token and does not require StableProxy to reopen or consume its own settlement.

On Initialized, the aggregate consumes the permit and plan with a fresh activation attempt and exact worker target into BeginActivation<W, P>. Activation capacity is checked by the aggregate before this request exists. It is never reported as an interpreter rejection.

The selected Communication control capability has one rejection: ControlClosed, which returns the complete submitted value. Consequently the activation-start action has exactly one expected rejection, OwnerStopped, and that rejection retains the complete BeginActivation. Mailbox fullness, observer capacity, generic host failure, and activation capacity are not members of this sum.

ActivationPlan::activate(self) is a statically dispatched future. After accepting the request, Bombay must enqueue the matching Started input to the owner before polling the plan. It then retains the typed JoinHandle<WorkerActivation<W, P>> in the existing local environment, polls it with the existing input schedule, and returns the matching ready or rejected input through the unchanged Driver. Only an accepted request's consumed plan may produce readiness.

The H22 production contract realizes that shape without a task in Behavior. ActivationPermit retains the exact established worker target already supplied to the initialization host. BeginActivation::new therefore accepts only the returned plan and permit; no caller can substitute another same-protocol worker. A private activation correlation is reserved one-to-one from the permit's non-reused worker attempt. BeginActivation::started produces the WorkerActivation value holding the matching started alternative. Consuming BeginActivation::activate moves the plan exactly once to a WorkerActivation holding either readiness or rejection. The public runtime values expose consuming projections, not constructors for their private alternatives.

Bombay must own activation work in one statically typed task product within the actor's existing environment. Completed results return through the actor's ordinary typed system-input admission. Unfinished work and completed results whose owner admission has closed transfer through the existing retirement barrier to the root custodian. The task product retains its concrete output; it must not reduce it to JoinHandle<()>, abort and discard it, or detach it. This is Bombay runtime work, not a Behavior-side runtime. It introduces no second Driver, mailbox, erased output, or lifecycle service. Cancellation never claims physical cancellation unless the concrete plan provides it.

H14 supplies the generic ClassifySettlement projection over the complete H10 static settlement product. Bombay inspects SettlementStatus::Accepted, Rejected, or Corrupt without consuming or reconstructing that product and without template-specific traversal. Rejected includes both a capability rejection and a declared dependency block. Rejected or blocked effects take precedence over a simultaneous initialization stop; the unchanged next decision remains present in the complete settlement and the installed worker then drains normally. Corrupt includes an interpreter fault or any unattempted suffix and therefore enters the existing residual-custody path with the entire settlement.

ActionSettlements projects a concrete Actions type to this complete static settlement without naming an interpreter. BehaviorSettlements applies that projection to a concrete behavior without forcing lifecycle owners to restate the behavior's internal creation and send bounds. Lifecycle-host requests use the associated type when they must return a worker's initialization settlement; they do not restate the creation vector or send-product structure in each actor template. Both projections perform no interpretation and change no custody.

Named products interpret their fields in declared order. A corrupt earlier field retains the untouched later fields as unattempted; a lawful rejection does not stop independent later fields. The SendProduct derive and the #[behavior] generated products share the ordered traversal and source-custody generator while preserving their domain field names. The unused two-product tuple helper and the private Actors declarative macro were removed. Named products return complete named settlement shapes.

StableProxy's ProxyEffects declares worker observation, initialization, activation, shutdown, service delivery, owner outcome, and diagnostic lanes in that order. Runtime-local and structural-owner operations use the one InterpreterRequests product; service forwarding uses exact established delivery. A concrete compile witness proves the actual StableProxy::Sends implements InterpretSends, so no vector-only lane or template adapter remains. Creation is still interpreted first by Actions; therefore the observation's exact CreationCorrelation<WorkerProtocol, ChildHead> refers to that same action. Creation settlement and the later ChildStopped event are independent admissions. The proxy retains either arrival order explicitly and returns both values if creation rejection contradicts an already observed stop. Bombay must not serialize those admissions merely to simplify the aggregate.

Terminal custody

Every affine terminal settlement follows one ownership path:

child lifecycle host
  -> admitting parent
  -> next structural owner when parent admission is closed
  -> non-rejecting root custodian
  -> existing Engine retirement barrier

Closure returns the exact value; it never logs or discards it. Outward transfer does not reopen a stopped actor. The path uses the existing Driver and actor graph—no detached task, second mailbox, second lifecycle framework, or Behavior-side runtime is permitted.

Forced retirement transfers unresolved creations, initialization and activation settlements, assignment joins, customer outcomes, diagnostics, timers, shutdowns, and queued ingress as explicit residual ownership. Actor-graph retirement and external work are distinct; the root barrier cannot claim quiescence while externally owned terminal work remains unaccounted for.

An aggregate may retain its unresolved actor-owned values in a private terminal alternative of the final concrete behavior. Runtime work already accepted from that aggregate remains in the environment residual. Bombay transfers both products without inspecting, flattening, or reconstructing either one. This separation prevents a pool-specific residual lane while preserving the exact owner of every affine value.

FIFO and KeyedPool name the identical local stop cause once as ForcedRetirementCause: exhausted worker-shutdown identifiers, a deadline not scheduled with its complete interpreter result, or the exact elapsed deadline. The cause does not own a worker roster and does not perform transfer. Each aggregate retains its own unresolved workers; Bombay later moves the complete concrete behavior and environment residual together.

Exact concrete rejection vocabulary

Concrete reasons come from the selected locked dependency contracts:

• asynchronous Communication send waits for bounded capacity and rejects only with the closed complete payload; Full belongs to try_send;
• control send is unbounded and rejects only ControlClosed(complete_item);
• Address claim distinguishes AddressInUse and permanent registration-ID exhaustion;
• Observe distinguishes SubjectExists, UnknownSubject, and exact generation-checked retirement;
• Timers use exact branded schedule tokens and exact-current cancellation; and
• orderly shutdown distinguishes accepted, already stopping, and already stopped, with child absence separately reported as not established.

H23 places exact orderly shutdown on the same generic item settlement as every other action. Accepted exact shutdown leaves ShutdownId; either selected rejection returns the complete ShutdownEstablished request and its exact actor capability. The concrete endpoint port returns only Result<(), ShutdownRejection>. StableProxy can therefore use exact shutdown for post-commit worker drain without a proxy-specific adapter or weaker child route.

Generic settlement must not fabricate mailbox-full, observer-capacity, activation-capacity, or typed exhaustion variants unsupported by those APIs.

ObserveChild<P, Occurrence> names the concrete child protocol because its same-action dependency is the one existing CreationCorrelation<P, Occurrence>. The selected child-observation path clones the hosted exact termination observation after the typed child binding commits. It therefore has accepted unit, no capability rejection, and only the creation prerequisite; SubjectExists applies to subject registration and is not fabricated as a child-observation rejection. Equal address types do not make two child protocols substitutable.

H05 makes this boundary executable without adding runtime dependencies to Behavior. A research-local witness checks 13 exact facts against the selected Address 0.2.0, Communication 0.1.2, Timers 0.1.0, frozen Bombay Observe, and locked Behavior shutdown sources. Under Bombay's pinned Rust 1.96, the exact Address suite passes 14/14, the Timers suite passes 2/2, and Communication's library target builds (it has no library unit tests). These releases cannot be linked into the Rust-1.95 atomic experiment; that MSRV boundary is intentional evidence that concrete capability interpretation remains a Bombay concern.

Required Bombay target

The atomic architecture targets the following Bombay contract. Bombay's present method signatures are historical evidence only; they are not reasons to weaken, defer, or reshape the accepted actor laws.

Bombay must:

1. return or re-home the complete rejected parent event;
2. move the final concrete Behavior value into retirement ownership instead of dropping it after Step::Stop, Exhausted, or a Driver error;
3. return a typed residual from environment retirement;
4. carry the Behavior and environment residual through the existing Driver retirement barrier; and
5. deposit that one typed transfer at a non-rejecting root custodian before the barrier releases.

Typed application assembly

Bombay must also reverse its current root-first application construction order for actor templates whose required destinations are application-owned actors. The target order is:

declare application actors by semantic role
    -> install them through Bombay's existing runtime ownership
    -> obtain their typed logical or exact capabilities
    -> construct the pure root from those capabilities
    -> initialize and activate the root
    -> return the typed root and application lifecycle capabilities

The one-time root constructor belongs to Bombay application assembly. It is not a Behavior, is never retained by an atomic actor, performs no I/O, and cannot be invoked from a transition. Bombay remains the sole owner of address allocation, mailboxes, installation, activation, and startup rollback. If peer installation or root activation fails, Bombay retires every already installed application actor through the same retirement path and returns the exact startup failure.

Application code names semantic roles, concrete actor behaviors, and typed capabilities only. It does not name MailAddr, child-product positions, occurrence paths, generated type aliases, or final composed behavior types. Role selection must be inferred and statically checked; the public source shape must not expose the existing TopologyAt cursor or ApplicationRoute product. No registry, dynamic capability map, erased protocol, second mailbox, second Driver, or atomic-template-specific host is permitted.

H139 shows why returning only ApplicationHandle<Root::Protocol> after root activation is too late. A full Start message happens to infer every dynamic type from its payload. The lawful Stop { key } message does not name worker or activation types, so current stable Rust reports E0283 at Application::new. Adding a turbofish, alias, explicit root type, fabricated Recipient, or dummy worker field is rejected. The lifecycle actor's concrete DynamicLifecycle<Key, Worker, Plan> protocol must supply those types during role-first assembly instead.

This application-assembly change and the retirement-custody change are separate Bombay responsibilities. Either may be implemented first, but both must use the existing Driver and both must pass the final atomic integration probe.

H148 historically derived the target source equation independently of Bombay's current root-first API: typed lifecycle and diagnostic capabilities enter one pure root constructor, the six-policy dynamic(entries, activation, unexpected_exit, actor_drain, lifecycle, diagnostics) call infers its key, worker, and activation types. The real production construction test and five command paths now own that contract; H589 removes the superseded facsimile while retaining H148's compiler evidence in Git. Removing lifecycle provenance or delivering Stop without the typed supervisor capability produced E0277/E0308 or E0282. Bombay must change its assembly order to supply this context; Behavior Actors must not add an annotation, raw address, callback, or alternate constructor to compensate for the present runtime API.

This is the required Bombay architecture. A stopped aggregate can retain complete affine terminal values in its private final state, so returning only environment state would still lose ownership. Bombay changes to carry both the final concrete Behavior and the environment residual. Atomic implementation may target this contract before the upstream patch lands; it must not add a local workaround. Final end-to-end verification records the upstream revision that supplies these five links. H03 authorizes neither a Behavior-side custodian nor a second Driver, mailbox, task, or lifecycle service.

Bombay's application facade re-exports only the non-hidden semantic names listed by atomic-actor-devx.md. Interpreter code may import the doc-hidden associated request, event, effect, and settlement types through behavior_actors::atomic; none becomes a second application spelling.

Required Bombay implementation

Bombay must realize the target through its sole Driver path. No Bombay source is modified by this campaign, but upstream will make the following coherent replacement. Applying only a subset leaves affine values unowned.

crates/bombay/src/interpret.rs

1. Delete the InterpretationError<C, S> two-leg short-circuit sum. Expected capability rejection is data in ItemSettlement; it is no longer a commit error.
2. Implement the generic creation leg in two stages. First, one InterpretItem<Creations<CreateChild<BehaviorAddr<C>, C>>, ...> call either returns the complete batch untouched with ChildNamespaceExhausted or returns one ordered Creations<RoutedCreation<BehaviorAddr<C>, C>> value. Then EstablishChild<Occurrence, C> settles each routed child independently. Its output is fixed by the routed creation, not selected by Bombay. Established returns the exact established capability. InitializationRejected returns the current routed child and exact initialization error. InitializationPanicked returns the extant current routed child after a caught pure fold panic. HostRejected returns the current routed child, uninterpreted initialization Actions, and exact reason. Corruption retains the exact routed suffix through InterpreterFault.
3. Replace CommitActions::commit's creation for loop and subsequent InterpretSends::interpret(...).map_err(...) with exactly one actions.interpret::<_, B::Event, behavior::Here>(&mut self.capabilities) call. That call already owns creation-before-sends order, lawful continuation, heterogeneous residuals, and the exact become verdict.
4. Return the resulting ActionSettlement to the existing host settlement admission. Do not discard it after checking Complete, and do not convert Interpretation::Corrupt into an error lacking the settlement value.
5. Keep ActionInterpreter as the one concrete capability product used by the existing Engine Driver; add no loop, mailbox, task, registry, or adapter.

crates/bombay/src/application_runtime.rs

1. Delete the blanket SendInterpreter implementation and migrate every InterpretRequest, InterpretDelivery, InterpretEstablishedDelivery, InterpretChildDelivery, and InterpretChildInput implementation to the single static InterpretItem<Item, RootEvent, Path> ownership port. Runtime implementations do not select a settlement associated type; ActionItem and SendSettlements already fix the exact result vocabulary.

2. Each implementation must return its complete capability-specific sum:

   • async logical and exact delivery acceptance consumes the message and returns only its receipt; Unknown or Closed returns the original delivery and exact reason;
   • child delivery/input consults the exact occurrence binding. A rejected creation resolution produces Blocked { item, prerequisite }; genuine absence produces Rejected { item, MissingChild }; closed admission returns the original item;
   • timer scheduling uses only the selected Timers reason/token contract;
   • Observe uses only SubjectExists, UnknownSubject, and exact generation facts;
   • control ingress returns ControlClosed(complete event) instead of ignoring ControlSender::send;
   • child shutdown returns its exact accepted/already-stopping/not-established settlement and never reports success merely because a local fact was enqueued; and
   • ReportToParent<Report> returns the complete report when parent admission is closed.

3. Replace the legacy nonce-oriented CreationResults with a typed current-action prerequisite store keyed by the exact declared child occurrence plus CreationId. Beginning an action clears only the prior action transaction. Equal numeric runtime routes and distinct occurrences cannot satisfy each other's prerequisite.

4. Child hosting consumes RoutedCreation and returns ChildCreationOutcome<C, Occurrence> as its accepted receipt. Successful commit returns Established. A pure initialization error returns InitializationRejected with the routed child and exact error. A caught pure initialization panic returns InitializationPanicked with the extant current routed child. Allocation rejection occurs before initialization and returns the complete routed creation. Host rejection after initialization returns HostRejected with the routed child and still-uninterpreted initialization Actions. Post-commit initialization-action failure is not a creation rejection; it enters the created child's drain.

5. Remove every let _ = control.send(...) and equivalent ignored ControlSender result. Each becomes an owned item settlement or terminal residual.

crates/bombay/src/local.rs and crates/bombay/src/launch.rs

CommitActions must expose the complete action settlement rather than Result<(), E>. Initialization follows the same path as active turns. A child is not published live until its initialization ActionSettlement has been admitted or transferred; an initialization Step::Stop still settles its final actions. A post-commit corrupt or rejected initialization effect drains the installed incarnation and retains all residuals; it cannot be mapped back to CreationRejection or roll back an accepted prefix.

For every creating behavior, host settlement owns one generic creation-entry pass before ordinary ingress. In authored order it moves each entry into ChildCreationSettled<C, Occurrence> and attempts the statically declared creator system lane. This is one generic Births<C> capability, not an atomic template adapter. A live creator receives the exact ChildCreationOutcome, including the non-cloneable child and initialization value on rejection. If admission is closed, the control send returns the complete root event; RecoverEvent<ChildCreationSettled<C, Occurrence>, Path> recovers the exact product and the lifecycle host retains it. A stopping creator may transfer the entry directly without reopening its mailbox. NoBirths requires no settlement lane or placeholder event.

The same mechanism must work for a non-atomic creating catalogue template and for an atomic aggregate before Bombay accepts it. The Driver does not inspect a variant, runtime type, or positional index: the concrete environment is monomorphized over the creator event, child occurrence, and compile-time path. The result of each attempted admission is an admitted receipt or the complete still-host-owned creation product, never a discarded ControlSender result.

Source action results

Creation uses the one generic action-settlement path, not the source-result protocol used by emitted requests. The same Driver operation must also process request items whose exact interpretation result returns to the emitting actor. Stable-proxy owner operations and direct-pool assignments are the first two unrelated request consumers.

Behavior supplies only static declarations and owned values:

• the concrete action owns its accepted receipt, rejection, prerequisite, and source identity;
• the generic source-action product fixes every returned input as the exact SettledItem<Item, ItemSettlement<...>> and preserves authored order;
• ProxyOperation uses that exact result. Its accepted value is ProxyInputReceipt, containing the creator-local child route, exact proxy, and operation correlation; rejection retains the complete operation;
• AssignmentDelivery uses the same exact result. Its accepted value contains exact worker and assignment correlation; rejection retains the complete assignment delivery;
• PrepareWorkers uses the same start settlement for fixed supervision and direct-pool recovery. Its accepted value is an exact WorkerPreparationStarted receipt. The separately injected, later WorkerPreparation owns the source, ordered selected roles, complete prepared submissions or an exact worker/source rejection, and untouched suffix; and
• structural composition processes inner then owned lanes, matching the one declared interpretation order.

An action may not choose another result type or translate the generic alternatives. Such a hook is a per-template settlement adapter: it can duplicate the interpretation law and can silently discard the exact rejected or unattempted action. Domain-specific receipts remain lawful as the accepted type; later domain outcomes and application replies remain separate protocols.

Those declarations perform no delivery. Bombay must add one generic static operation over the settlement products returned by CommitActions. For each source result, that operation must:

1. retain ownership in the current actor host;
2. construct the statically selected current-actor system input;
3. submit it through the existing unbounded control capability;
4. remove it from host custody only after control admission succeeds;
5. recover the exact input from the returned closed-control event when admission fails; and
6. after the first closed admission, transfer the current value and every later value without trying to reopen the actor.

The Driver processes one admitted result turn and the complete transitive action chain it produces before offering the next result from the earlier product. Only after that chain is quiescent or transferred outward may it continue with the next ordinary User communication. This must be an iterative queue owned by the existing Driver; it is not a recursive call, detached task, second mailbox, or second actor loop. The ordering does not claim termination or fairness: an actor can continually produce more source results and starve ordinary traffic.

SourceSettlementCustody::offer_next_to_source is the static operation over a complete ActionSettlement. It visits creation before sends, preserves every named field and wrapper order, and returns SourceCustody::Admitted immediately after exactly one successful admission. Exhausted proves no source input remains; Closed returns the current input and untouched suffix in the exact residual product. The operation composes through every generated named sends product, catalogue-owned named product, and SendLayer without Bombay matching product fields, variants, or structural positions by hand. The generic source product supplies the exact input type once. Neither FixedSupervisor, DynamicSupervisor, FIFO pool, nor keyed pool supplies a runtime admission adapter.

Exact Bombay and Timers changes for scheduling

Timer scheduling follows the same total action law; it is not a FixedSupervisor exception. ScheduleAfter currently declares the later TimerElapsed input but has no ActionItem settlement. The present Bombay interpreter computes Instant::now().checked_add(after) and returns only unit or DeadlineOverflow. The selected bombay-timers 0.1.0 queue replaces an existing equal key and panics when its internal generation or insertion sequence exhausts. Those are current implementation constraints to replace, not the architecture.

Behavior Actors must give both scheduling requests ordinary total contracts:

ScheduleAfter:
  accepted = TimerScheduled { id, generation }
  rejected = DeadlineOverflow
           | QueueGenerationExhausted
           | QueueSequenceExhausted

ScheduleAt:
  accepted = TimerScheduled { id, generation }
  rejected = QueueGenerationExhausted
           | QueueSequenceExhausted

The two rejection sums remain distinct because an already absolute ScheduleAt cannot incur relative-deadline overflow. Adding an impossible alternative merely to share a type is prohibited. Generic ItemSettlement already returns the complete original request for every rejection and preserves independent later lanes. TimerScheduled is only the exact scheduling receipt; the eventual TimerElapsed remains a later typed input and must never be fabricated at acceptance.

Timers must change its existing queue operation to return a closed error before changing counters, current-key state, or heap ownership. Bombay maps those two queue errors without collapsing them, maps relative deadline overflow only for ScheduleAfter, and returns the exact TimerScheduled receipt after insertion. The current queue token remains Timers-owned scheduling authority; a Behavior does not receive or recreate it. Poison recovery, memory exhaustion, and polling are not new Behavior rejection alternatives.

FixedSupervisor privately selects a non-reused timer identity for each delayed recovery and carries an explicit generation. Two overlapping delayed recoveries therefore cannot use the same queue key, because the selected queue truthfully treats equal keys as replacement. Immediate recovery emits no schedule and owns no dummy timer. Recovery identity, timer identity, and release ordinal stay distinct values; none is inferred from another or from product position.

Bombay implements these as the same generic static InterpretItem operations used by unrelated timing templates. It must not inspect FixedSupervisor, introduce a schedule adapter, create another timer queue, or return unit after successful scheduling. Its Driver settles scheduling in the named action order, admits the exact settlement through the normal source-result operation, and retains it through the existing retirement product if actor admission closes.

Exact Bombay changes for atomic diagnostics

Behavior Actors supplies one shared DiagnosticAction<Route, Diagnostic> for the identical diagnostic law used by FixedSupervisor, DynamicSupervisor, FifoPool, and KeyedPool. The action is exactly:

Deliver { route, diagnostic }
| Terminal { diagnostic }

The route type selects the real rejection vocabulary statically: Recipient<P> uses LogicalDeliveryReason, EstablishedRecipient<P> uses ExactDeliveryReason, and the route-free Infallible alternative uses Never. Bombay must add ordinary InterpretItem implementations for these three concrete route families. It must not switch on a runtime protocol, erase the diagnostic, or add an aggregate-specific interpreter.

For Deliver, Bombay consumes the route and diagnostic through the existing logical or exact delivery capability. Accepted delivery returns DiagnosticAccepted::Delivered. Rejection returns the complete original DiagnosticAction and the exact selected delivery reason. Waiting for bounded Communication capacity is backpressure and is not a rejection variant.

For Terminal, Bombay performs no delivery and returns DiagnosticAccepted::Terminal(diagnostic). The complete diagnostic therefore remains inside the accepted action settlement owned by the current actor host. When source admission is closed or the source stops in the same transition, that settlement follows the normal child-to-parent-to-root custody path and ends at the non-rejecting root custodian. Terminal transfer is not a log call, detached task, second mailbox, or special Driver branch.

The first production consumer is FixedSupervisor's exact non-ready initial proxy transition. It emits DiagnosticAction::Terminal(FixedDiagnostic::ProxyOutcomeFailed(...)) together with Step::Stop. Bombay must settle the diagnostic before completing actor retirement, retain the complete role/outcome payload, and then transfer the remaining proxy child graph through the same retirement barrier. The aggregate does not serialize that payload, log it as a substitute for custody, or keep a second runtime coordination object.

The next production consumer is FixedSupervisor's committed-roster shutdown. Its final Step::Stop retains the complete private FixedShutdown state. That state includes ready workers and readiness values, locally cancelled initial inputs, exact initial-input settlements, completed initial outcomes, proxy-stop results, rejected proxy births, and any non-accepted shutdown operation reunited with an exact proxy exit. Bombay must move that concrete stopped supervisor value through the same retirement product. It must not inspect those private alternatives, convert retained values to logs, or require FixedSupervisor to publish a runtime-specific residual. A pending proxy creation remains an ordinary previously emitted creation action: Bombay returns its exact generic settlement. FixedSupervisor alone decides whether that means one newly committed proxy must be shut down, an exact creation rejection means absence, or wrong provenance must be returned unchanged. Recovery and deadline shutdown states target this same generic retirement contract; they do not justify a supervisor-specific Driver branch.

H119 realizes FixedSupervisor's deadline half. The first RetireActorGraphAfter shutdown emits one ordinary relative scheduling action. Its exact non-accepted result or its exact elapsed timer selects Step::Stop; the private deadline state retains that exact cause while FixedShutdown retains every unresolved member value. Bombay must therefore transfer the final concrete supervisor and the environment's residual actions together. It must not inspect the deadline state, synthesize per-member shutdown reports, or discard the supervisor after extracting Exit or unit. The same generic retirement product also covers an external worker-source operation that is still resolving when the deadline forces retirement.

Bombay's required change is deliberately ignorant of FixedSupervisor's private decomposition. FixedShutdown decides declaration-order roster completion, FixedShutdownMember owns one member's remaining startup values, and ProxyStoppingMember decides the exact shutdown-settlement/exit join. Bombay only executes typed actions, returns their complete settlements, observes exact child exit, and transfers the stopped concrete behavior to parent then root custody. No in-memory supervisor coordinator belongs in Bombay.

CommitActions must preserve these receipts with every other item settlement. ActiveEnvironment::retire, the Driver retirement barrier, and the root runner must return or retain the terminal diagnostic exactly as specified by the general custody changes in this document. A delivered diagnostic rejection is already terminal settlement and must never be reintroduced into the aggregate to emit a recursive diagnostic.

Exact Bombay change for keyed customer rejection

AA-40 requires more custody than an ordinary reply delivery for one case only: a synchronously rejected submission must preserve the original customer route inside the rejected action while a clone targets the KeyedOutcome::Rejected message. Behavior Actors represents that invariant with the CustomerDelivery<P> action item. The public KeyedOutcome remains free of an address generic, and neither the key nor payload is cloned.

Bombay must add one generic static InterpretItem<CustomerDelivery<P>, ..> implementation alongside its existing logical and established delivery implementations. It exhaustively handles the four concrete alternatives:

Logical { delivery }
Established { delivery }
RejectedLogical { delivery, customer }
RejectedEstablished { delivery, customer }

The ordinary alternatives delegate to the corresponding existing logical or established delivery capability. The rejected alternatives do the same while holding customer untouched. Acceptance consumes the complete action and returns unit, matching ordinary delivery. Logical rejection reconstructs the same CustomerDelivery with the returned Delivery, original customer, and ReplyDelivery::Logical(reason); exact rejection does the corresponding operation with EstablishedDelivery and ReplyDelivery::Established(reason). Interpreter corruption likewise returns the complete reconstructed action and exact fault. The uninhabited delivery prerequisite remains uninhabited.

This is one generic customer-action interpreter, not a KeyedPool branch or settlement adapter. It does not inspect keys, roles, outcomes, bindings, pool state, or aggregate type. Bounded Communication send capacity remains backpressure. When actor admission is closed, the complete returned CustomerDelivery travels in the existing environment residual and parent-to-root custody path; the Driver must not reopen the stopped pool or discard the original route. The research-local Bombay probe must cover logical acceptance, logical rejection, exact acceptance, exact rejection, and source retirement after rejection using the unchanged Engine Driver.

The operation returns a residual product. A residual owns every result not admitted to the source, including the current result at closure and the exact untouched suffix. That product joins the environment retirement value described below. Bombay may not map it to a log, unit, a generic error, or a recreated request. The root runner is the final non-rejecting owner.

This is the required upstream change. The atomic worktree does not modify Bombay production source and does not add an in-memory coordination object to StableProxy or either supervisor. H34 demonstrates the stable-Rust ownership shape with distinct proxy and assignment results in both wrapper orders; the real Driver and retirement proof remains a Bombay integration gate.

H38 adds one exact interpreter obligation. Bombay's environment statically implements PrepareWorkers for the application's concrete method-free WorkerSource<Role, Worker, Plan> declaration. It invokes that source outside Behavior. H45 requires that action to expose each selected application role only as &Role: it owns immutable private role names while the pending supervisor state retains every unique member-role authority. Bombay must neither request Role: Clone nor reconstruct a role from roster position. It returns the same source authority and role names with every completed result. WorkerPreparation contains three late domain outcomes: a complete non-empty sequence of prepared submissions, an exact prepared prefix plus worker rejection and untouched suffix, or source rejection before the first worker submission. Corrupt or unattempted starts remain generic settlement alternatives; source rejection after an accepted start is a late outcome. The action is handled by the same InterpretItem and source-admission machinery used for proxy operations, assignment delivery, and unrelated catalogue actions. Bombay adds no dynamic registry, callback inside the actor, factory actor mailbox, erased worker envelope, or FixedSupervisor Driver branch. The result enters the same generic source-admission queue and retirement product described above.

The concrete static interpreter consumes the request with start() and returns its exact receipt before awaiting the source. It injects the later WorkerPreparation through the typed control lane. The returned StartingWorkerPreparation advances the first attempt with accept(submission), reject(reason), or reject_source(reason). Acceptance returns ControlFlow::Continue(PendingWorkerPreparation) while a selected name remains and ControlFlow::Break(WorkerPreparation) only after the last one. The initial request alone implements the action traits; the pending value cannot be re-emitted as fresh work after it owns a prepared prefix. This progression is the arity proof: Bombay never supplies a role to an accepted result and performs no separate length validation. If the Driver retires during preparation, its actor-owned source task retains the StartingWorkerPreparation or PendingWorkerPreparation value until it can return a complete result through exact typed retirement custody.

Every request also carries one private non-reused preparation ticket. Bombay must preserve it by moving the request, start receipt, and later result through the typed event paths; it must not inspect, construct, compare, log, or reconstruct the ticket. Exact matching is FixedSupervisor policy.

If shutdown overlaps an emitted preparation, Bombay must not report actor retirement merely because ordinary mailbox admission is closing. The started progress cursor remains in the actor-owned source task until interpretation produces its complete result. Open control admission returns that result to the draining FixedSupervisor; closed control admission moves it into typed retirement custody. In neither case may Bombay cancel the request, recreate its source, call a FixedSupervisor-specific adapter, or treat successful preparation as permission to issue replacement work. The aggregate owns that late-result decision.

The clean-room FixedSupervisor now realizes its half of this contract. Its shutdown member retains the private preparation expectation beside the exact StableProxy drain, and the stopped aggregate retains the complete generic result after admission. Bombay must therefore preserve the final monomorphized FixedSupervisor value when interpreting Step::Stop; extracting only a unit exit status would lose the source, rejection, prepared submissions, or interpreter fault held there. The required Bombay change remains the generic Driver retirement product described below. It is not a FixedSupervisor branch and does not require Bombay to know PreparationExpectation.

The FixedSupervisor's concrete internal event includes the typed start settlement and separate late preparation result but does not constrain the worker source in its unrelated proxy variants. PrepareWorkers<Source, Role, Worker, Plan> is the static source selector because that action type uniquely identifies its associated result. The named sends product includes one worker_preparations source-action lane. The generic source-admission operation injects the start settlement through EventIngress and the later result through InjectEvent; the Driver must not pattern-match FixedSupervisor, special-case the lane, or add a callback. The declared fixed-supervisor lane order places worker preparation after proxy creation/observation work and before proxy input, scheduling, lifecycle, reply, and diagnostic work. A later production slice must compile this exact product before automatic recovery is claimed.

FixedSupervisor proxy operations independently use Here as their static same-actor source. Bombay therefore admits their exact generic ProxyOperation<Here, Worker, Plan> result through ordinary EventIngress; the operation does not use the aggregate event type as a recursive selector. The worker-preparation result remains a distinct input type for that same current actor, with no positional routing or runtime lookup. Bombay's static generic admission implementation selects the actor through the action/result type pair; it does not inspect the action value or infer a runtime destination.

Direct pools use this same interpreter operation for automatic recovery with a non-empty sequence containing exactly one semantic role. The pool retains the recovery decision and role authority while the action owns the source and role name. Bombay gains no pool branch: the same static request progression returns the source, name, and one WorkerSubmission or the exact rejection. Initial pool construction remains separate and may invoke its factory before a Behavior exists. A pool never stores or calls that factory from a transition.

Engine retirement and root custody

ActiveEnvironment::retire, the local inbox drain, Driver, run_with, and the application result must carry one typed retirement product through the existing barrier. That product owns both the final monomorphized Behavior and the environment residual; it does not inspect or erase the Behavior. Parent rejection transfers the complete terminal value outward. The application root owns a non-rejecting custodian and releases the barrier only after that product is empty. This is the H03 contract as completed by H28's final-Behavior link, not a new service: retirement remains part of the same Driver future.

Required upstream verification

• compile every concrete InterpretItem implementation without a universal error type;
• replay H07 rejection, blocking, corruption, and wrapper-order suites against ApplicationCapabilities;
• prove creation semantic rejection continues to an independent timer or delivery while only its exact child operation is blocked;
• prove two heterogeneous creation alternatives return branch-preserving receipts and exact rejected requests;
• prove ChildCreationSettled returns a non-cloneable child through one live creator and through closed creator admission into host custody, using the same generic code for an unrelated creating template;
• prove stopping initialization settles final actions before publication or retirement;
• inject control closure at every parent/root transfer and recover the exact value at the root custodian; and
• run the unchanged single Engine Driver through the retirement barrier with no detached work and no ignored must-use result.

Stable proxy

Status: feature-complete for the local aggregate. Initial start, readiness, exact pre-ready return, replacement, owner shutdown, complete local custody, independent models, compile contracts, and two stateful fuzz targets are implemented and verified. Parent-to-root terminal transfer remains assigned to Bombay and does not belong in this aggregate. Actor-graph deadline policy belongs to the owning supervisor, pool, or Bombay root, not StableProxy. The complete transition matrix is owned only by actor-laws/proxy.md.

Responsibility

StableProxy owns one stable service identity and at most one current worker. It owns initial worker start, replacement, unavailability, exact worker exit, creation, initialization, activation, worker return, and structural-owner outcomes and diagnostics.

It does not own restart strategy, restart budgets, fixed membership, dynamic membership, pool jobs, customer outcomes, or runtime execution. Its public service protocol is exactly the worker protocol. Start, replace, and shutdown control remain private to the structural owner.

Fresh worker creation is the actor-model law. Stable service identity across successive workers is a derived proxy construction. Creation-before-dependent- operation ordering, owner-only control, activation admission, and lifecycle publication are Bombay policies.

One aggregate, separated concerns

StableProxy<W, P> is the only Behavior in this family. Its six files have one domain owner each:

• mod.rs owns the aggregate, every state transition, construction, and the sole Behavior implementation;
• state.rs passively owns the complete current and terminal state sums;
• protocol.rs owns commands, events, outcomes, diagnostics, and returned terminal data;
• effects.rs owns the seven named action lanes and their declared order;
• operation.rs owns the parent request, receipt, rejection, and settlement contract;
• worker/mod.rs owns the proxy's pending and current worker values, creation correlation, and shutdown/stop correlation.

The shared atomic/worker/initialization.rs and atomic/worker/activation.rs modules own the worker-host request and result protocol used by every atomic aggregate. They are not StableProxy child files. The pending proxy worker stores only creation and activation values; the emitted CreateChild owns the concrete worker until settlement, so no worker type marker exists in proxy state.

The worker module is not another actor aggregate. The worker's own Behavior owns its domain decisions; this module stores only the parent proxy's exact typed authority and observations. No transition verb or arrival path owns a file, and mod.rs controls the public surface. Fixed and dynamic supervisors consume typed proxy outcomes and must not reproduce worker creation, forwarding, readiness, replacement, or return transitions. Direct pools own a different direct-worker lifecycle and never consume proxy state.

Mnesis core was inspected as a DDD structure reference. Its useful pattern here is a flat, concept-owned kernel with one aggregate root and passive state. Its AggregateRoot, command dispatch, event replay, versioning, and persistence do not belong in StableProxy: the existing Behavior contract already owns the pure actor transition, and adding Mnesis would create a second aggregate model.

Current state and action law

The implemented closed phases are:

Dormant
Starting {
    Creating { stopped: Option<exact stop> }
  | Initializing { stopped: Option<exact stop> }
  | Activating { progress: WaitingForStart | Running, stopped: Option<exact stop> }
  | ReturningWorker(WorkerStopping)
}
Ready
EmptyInitial | EmptyAfter
Replacing { ReturningPredecessor | SuccessorResultAwaitingShutdown }
ShuttingDownCreation | ShuttingDownInitialization | ShuttingDownActivation
ShuttingDownWorker | ShuttingDownReplacement
Stopped(complete private retirement values)

H77 corrects the initial literal state lowering. Creation, initialization, and activation remain different phases, but each owns the same exact current truth: the correlated stop is absent or has arrived once. One Option<ChildStopped<_>> directly represents that invariant; separate *AfterStop phase and result sums would store arrival history and duplicate transitions. Activation separately owns WaitingForStart | Running. Its stop presence remains visible to the exact readiness transition, so stop-before-ready still cannot publish availability. No phase is represented by coordinated flags or several correlated optional fields.

An accepted start issues one checked CreationId, enters Creating, and emits the complete worker submission in CreateChild in that same transition. The proxy does not wait for a route result and stores no runtime nonce. Bombay either routes the complete creation batch or returns it unchanged with ChildNamespaceExhausted; the proxy then returns the complete worker and activation policy through generic creation settlement. A foreign or stale creation result cannot replace the pending submission.

Every staged worker creation emits one exact ObserveChild request in the same Actions. A committed worker emits one InitializeWorker request. Successful initialization returns the original activation plan and one non-cloneable ActivationPermit; only those values can construct BeginActivation. Bombay admits Started before polling the plan. Only a matching Ready received after matching Started opens service routing.

Readiness arriving before Started is returned unchanged as a diagnostic. A foreign worker, initialization, activation, shutdown result, or worker stop is also returned unchanged and cannot advance state. WorkerAttempt carries opaque issued evidence; its ordinal is diagnostic data and cannot prove identity. Two proxies' first attempts therefore remain distinct. Address reuse, timing, and adjacency prove nothing.

Service input in Ready becomes one EstablishedDelivery to the exact current worker. Service input in every other phase becomes one Unavailable owner outcome containing the original sender and command.

An initialization-effects rejection, activation-start rejection, or accepted activation rejection begins exact orderly shutdown of the committed worker. For initialization, Bombay retains the complete concrete action settlement in the worker environment and returns only the closed WorkerInitializationFailure classification plus the affine activation plan. The proxy reports the terminal owner result only after both shutdown resolution and exact worker stop arrive. Either arrival order retains all proxy-owned values. If the worker stopped earlier, later initialization or activation input consumes the stored exact stop without reopening service. If readiness arrives first, the worker becomes ready and a later stop follows the ordinary ready-worker law; H77 deliberately preserves this ordering distinction.

WorkerStartResult has three decisions: creation rejected, worker ready, or committed worker unavailable. WorkerCreationRejection owns the exact pre-commit cause. ProxyDrain<W, P> owns the exact committed-worker cause and retained values. The outer result never repeats those nested causes as another alternative. Its ready and unavailable alternatives carry the opaque worker attempt, not a worker actor or route.

ProxyDrain<W, P> is a visible ownership result. Its six alternatives name current worker outcomes: initialization rejected, stopped, or completed after an observed stop; and activation start rejected, activation rejected, or activation completed after an observed stop. A rejection that may follow an emitted worker-shutdown request owns Option of its exact shutdown receipt. None means no request was emitted because the worker had already stopped; it does not encode which transition function ran. Initialization-returned and observer-returned stops remain separately owned because they are independent authorities. There is no duplicate cause, forwarding constructor, projection operation, string case label, runtime lookup, callback, or generic policy. It never owns the worker's complete initialization action settlement. That runtime value follows Bombay's typed environment-retirement path. This keeps proxy and supervisor types independent of the worker's concrete send and birth products without erasing or discarding them. The unexpected-initialization diagnostic owns the complete WorkerInitializationReport<W, P> directly. That typed input exposes no runtime action product in ordinary application syntax and needs no second custody wrapper.

H124 normalizes all unexpected worker inputs to the same ownership equation. Each ProxyDiagnostic alternative owns the complete returned input and the copyable current ProxyPhase. The exact expected creation, worker attempt, initialization, activation, or shutdown authority remains solely in proxy state. It is neither cloned into the diagnostic nor moved out while correct admission is still possible.

ProxyPhase reports the current proxy work, not private stored-stop presence. Creating remains Creating and initializing remains Initializing after an exact early worker stop. The stop still participates in the later transition; the public projection cannot inspect or authorize it.

Replacement first issues the successor's checked creation ID while retaining its complete CreateChild value. The exact predecessor remains owned, stable service admission closes, and the proxy requests exact predecessor shutdown. If the creation sequence is exhausted, the complete successor returns and the ready worker remains unchanged. The retained creation is emitted only after the exact predecessor stop arrives.

Predecessor stop and shutdown settlement form an order-independent join. If the stop arrives first, one successor creation is staged immediately and the exact pending shutdown correlation remains with the replacement. If shutdown settles first, the complete prepared successor remains local until stop. A successor that becomes ready before the late predecessor settlement is retained and is not published early. Replacement from EmptyAfter needs no predecessor return and still uses a fresh creation ID and the same WorkerStart transitions. Overlap returns the complete submitted successor.

WorkerStart and ProxyReplacement are separate private closed state values. The former retains only creation-through-readiness or pre-ready return; the latter retains only proxy replacement values and the predecessor/successor join. Neither advances itself: StableProxy admits each event, selects the next aggregate state, and returns the complete Actions. Bombay continues to own namespace binding, actor creation, task execution, delivery of typed results, and terminal custody. No OCC store, lock, allocator, runtime handle, or second lifecycle service exists in the aggregate.

Both components consume the same private WorkerStopping transition. It owns only the exact shutdown-result/stop reunion and returns every unrelated input unchanged. It owns no start, replacement, supervisor, pool, or runtime policy.

Owner shutdown is total in every implemented live phase. It closes stable service admission immediately, emits no ordinary owner result, and never emits the same worker shutdown twice. An uncreated successor is returned through the existing replacement-cancellation outcome and is never created. Pending creation still settles because its worker has already moved into the emitted action. Initialization and activation results remain owned but cannot publish readiness.

Initialization and activation each retain only their own exact unfinished work and worker-return values during owner shutdown. They share WorkerStopping for the shutdown-result/stop reunion, but no generic outer return product: an initializing worker has no pending domain value corresponding to activation's real waiting/running value. Introducing a unit or marker merely to share that outer product is forbidden. A ready successor waiting for its predecessor result is returned before the proxy stops. Both the predecessor result and successor departure remain owned regardless of arrival order. A rejected or already stopped successor waits only for the predecessor result.

Initialization represents its returned work directly as Option<WorkerInitializationRetirement> while the worker departs. There is no parallel pending/returned enum: absence is the pending condition and presence owns the one complete returned value. A duplicate remains outside that option and is returned complete through diagnostics.

A stopped initialization is one outcome. Its optional initialization_stop owns a second stop returned by the initializer only when the enclosing stopped worker already owns the independently observed stop. Absence means the initializer's stop is already the enclosing worker stop. There is no StoppedAfterObservation alternative because that would preserve arrival order instead of current ownership.

Once the worker has stopped, each shutdown join stores one current product: the worker, the exact stop, the initialization or activation value still being awaited or returned, and Option<EstablishedShutdownResolved<_>>. A receipt is present only when the proxy emitted and settled a shutdown request; it is absent when the worker had already stopped and no request was emitted. There are no separate AfterDeparture, AfterStop, or terminal *AfterStop alternatives. Those labels described arrival history and did not change any later decision.

ProxyRetirement is not an application API or runtime service. It is the final private state of the concrete stopped StableProxy. Bombay must move that whole behavior together with its environment residual through the existing Driver retirement barrier, as specified in atomic-runtime-settlement.md.

Total interpretation

Actions::creates owns worker creation. ProxyEffects declares these send lanes in stable order:

worker observations
worker initializations
worker activations
worker shutdowns
worker deliveries
owner outcomes
diagnostics

Every runtime-local or structural-owner lane uses the one InterpreterRequests product. Worker service uses EstablishedDelivery. Actions still interprets child creation before these sends. A compile witness requires the concrete StableProxy::Sends, not a homogeneous stand-in, to implement the generic total interpretation contract.

The operation module also owns the crate-private receipt correlation evidence. Its tests prove that receipt consumption returns one affine operation id while the established proxy capability remains repeatable. FixedSupervisor has no parallel receipt model or fixture module.

No proxy-specific interpreter adapter exists. Corruption retains the committed prefix and exact untouched suffix under atomic-runtime-settlement.md.

Bombay realization

Bombay owns concrete child hosts, initialization action settlements, activation work, task retention, mailboxes, observation, and retirement. The exact single-Driver changes required for initialization, activation, parent/root custody, and retirement residuals are normative in atomic-runtime-settlement.md. Bombay production remains read-only in this campaign; no Behavior-side runtime substitute is permitted.

Verification and external integration

The local aggregate is feature-complete. Current verification supplies exhaustive small shutdown interleavings, independent models, generated longer sequences, two stateful fuzz targets, optimized replay, compile denials, and affine drop witnesses. The ready-worker target exercises exact and foreign shutdown inputs; the replacement target exercises overlap, cancellation, successor creation, and both predecessor-return orders. They share only the identical four-state worker-return join.

Bombay must supply the documented parent-to-root custody contract. The atomic implementation targets that contract without adding a Behavior-side runtime. This external integration requirement prevents a whole-system completion claim; it does not reopen StableProxy's locally owned transitions. The repository-wide gates are owned by atomic-actor-verification.md.

There is one canonical construction path described in atomic-actor-devx.md. No legacy With* wrapper, structural route, compatibility alias, public nonce, readiness flag, erased callback, or application-authored final behavior type may return.

StableProxy deliberately has no ActorDrainPolicy and schedules no deadline. The AA-01 law leaves deadline expiry and forced actor-graph retirement outside its implementation evidence. FixedSupervisor, DynamicSupervisor, FifoPool, and KeyedPool own their aggregate shutdown policies; Bombay root custody owns the remaining runtime transfer. Adding a proxy timer lane would take on another aggregate's responsibility and is prohibited.

Fixed supervisor

Status: active. The current implementation covers construction, startup, coordinated recovery, diagnostics, lifecycle publication, management queries, shutdown, and forced retirement. Four stateful fuzz targets cover shutdown, recovery, delayed release, and three-role recovery correlation. Remaining owner-partitioned viable mutation review, the local closure audit, the final repository gates, and Bombay root custody remain open.

The complete transition matrix is owned by actor-laws/fixed-supervisor.md. This document maps that law to the current Bombay Behavior design without repeating the matrix or its research history.

Responsibility

FixedSupervisor owns:

• one non-empty ordered roster of unique application roles;
• one StableProxy for each role;
• each role's current membership and worker status;
• activation capacity across unresolved proxy operations;
• OneForOne, OneForAll, and RestForOne recovery selection;
• restart eligibility, limits, release timing, and recovery correlation;
• topology-failure disposition;
• optional lifecycle publication;
• operational diagnostics;
• status and capability queries; and
• complete actor-graph retirement.

It does not create or replace workers directly. StableProxy owns worker startup, replacement, service forwarding, and worker shutdown. The supervisor coordinates several stable proxies without copying that law.

It is neither a dynamic membership supervisor nor a pool. Its roster never gains a role after construction, contains no customer job, and is not selected by a mode flag shared with another aggregate.

Construction

fixed(...) is the sole construction path. Applications provide:

• a function that prepares the initial WorkerSubmission for each role;
• validated OrderedRoles;
• ActivationPolicy;
• Recovery;
• FailureReaction;
• ActorDrainPolicy; and
• DiagnosticDisposition.

Lifecycle publication is the builder's only optional transformation. Every semantic policy is explicit; no no-op recipient or placeholder callback is required.

The initial worker function runs only while the builder prepares the roster. It is not stored in the resulting behavior and cannot run during a transition. Automatic recovery instead emits one typed PrepareWorkers action. Its exact settlement returns the worker source, prepared submissions, rejection, and untouched role names without an application callback inside the actor.

Construction either returns one supervisor owning every prepared role and submission, or returns FixedConstructionRejected. Its workers value is the shared InitialWorkerRejection: the function, accepted prefix, rejected role and reason, and unexamined suffix. The shared representation is owned by atomic-actor-architecture.md; this document owns only fixed-supervisor construction policy. A duplicate role is rejected by OrderedRoles before the supervisor exists.

Roster ownership

The roster preserves declaration order. Each role has one immutable roster position used only when the law observes order. The position is not an address, actor identity, or public path.

A role is owned by either an independent member or one admitted recovery. An admitted recovery owns a non-empty unique set of participating members and the stable position of its trigger. A member cannot occur in two recoveries. When a member returns to service it can leave the recovery independently; the recovery retires after its final participant leaves.

The current roster uses its existing ordered collections to answer selection, authorization, query, and shutdown-order questions. It does not keep parallel membership tables or before/after history.

Startup and activation capacity

Initialization emits one fresh StableProxy creation and one observation request for every declared role. Creation results are accepted only for the expected creation ID and kind. A rejected creation leaves that role without a proxy; a foreign or stale result is returned unchanged.

ActivationPolicy limits unresolved proxy operations, not actor count. The supervisor authorizes waiting roles in declaration order while capacity exists. An exact accepted proxy-operation settlement is required before the matching proxy outcome is admissible. Capacity is released when the admitted outcome resolves, even if another member value still awaits its matching stop.

A ready outcome makes the member available through its stable proxy. A failed startup follows the configured diagnostic disposition and topology reaction. Stopping the complete supervisor reuses ordinary supervisor shutdown; retiring one member reuses that member's exact proxy retirement.

Worker-stop classification and recovery selection

Recovery policy classifies an exact worker stop:

• Temporary never starts automatic recovery;
• Transient recovers only after an abnormal stop; and
• Permanent recovers after every exact stop.

An ineligible stop leaves the member empty. An eligible stop selects members by strategy:

• OneForOne selects only the stopped role;
• OneForAll selects the complete eligible roster; and
• RestForOne selects the stopped role and eligible roles declared after it.

Normal or abnormal classification is derived from the exact owned worker stop at this decision. The accepted stop does not retain a second classification that could disagree with the terminal outcome.

Selection is all-or-nothing. If a required role cannot participate, the unchanged roster is restored and the configured topology response is applied. Disjoint recoveries may coexist, but their role sets may not overlap.

One accepted selection moves the sole WorkerSource into one PrepareWorkers action. The supervisor retains the exact recovery correlation and cannot issue replacement work until the source result returns. The action's accepted start receipt establishes only that source work began. A later prepared result pairs each selected role with exactly one WorkerSubmission in declaration order. Worker or source rejection is a late typed result; interpreter corruption and no-attempt return the original request in the start settlement.

The worker source has one private custody sum: it is available to the supervisor, owned by one emitted worker preparation, or retained as that complete returned preparation while the supervisor retires. There is no parallel optional return field. A shutdown return changes custody only; it cannot reopen recovery or issue another preparation.

Restart admission and release

Returned prepared workers are not yet authorized replacements. In the same actor transition that accepts the exact preparation result, the supervisor carries every prepared worker directly into one restart-admission transaction. It does not store a separately observable prepared roster phase. The transaction combines:

• its checked lifetime recovery count;
• the inclusive restart window and maximum;
• checked release calculation;
• one non-reused recovery ID; and
• for delayed release, one non-reused timer ID and generation.

RestartLimit owns the inclusive window and maximum. RestartRelease owns the release calculation.

The transaction commits all of those values together or returns them unchanged. It cannot partially spend a count, history entry, recovery ID, or timer key. Its six denial alternatives are stored once in RecoveryDenialReason; recovery admission moves that value and the complete triggering worker stop into RecoveryDenied, which exposes both by reference without rebuilding a parallel diagnostic sum. Denied prepared workers remain in the topology response selected by FailureReaction; admitted workers become one durable recovery batch. Timer schedule rejection does not use this stop transfer: its diagnostic owns the rejected timer request while topology retains the worker stop.

The requested replacement count retains the native non-empty roster cardinality. Only an accepted budget charge is narrowed to the configured u32 limit, so an oversized coordinated recovery is reported as an unchanged restart-limit denial rather than internal corruption.

Release policies are:

• immediate;
• constant delay;
• linear delay, initial × ordinal; and
• exponential delay, initial × 2^(ordinal - 1).

Arithmetic is checked before applying the configured maximum. Overflow is a typed denial, never saturation or panic. Delayed release emits the generic ScheduleAfter action. Only its exact accepted timer may later authorize the recovery; rejected, stale, foreign, early, or duplicate timer inputs cannot.

Replacement progress

Each participating member keeps its stable proxy and one current replacement product. That product owns:

• the previous worker attempt and readiness;
• the exact predecessor stop, if it has arrived; and
• the current proxy response: input pending, outcome pending, returned outcome, or rejected input.

The exact input settlement, predecessor stop, and proxy outcome update only their corresponding value. The accepted input settlement must precede the proxy outcome. After that admission, predecessor stop and proxy outcome may arrive in either order and produce the same restart. Duplicate, stale, early, or foreign inputs return unchanged.

Successful readiness returns the member to service and publishes lifecycle events in semantic order. Input rejection or proxy failure preserves the complete diagnostic payload and enters member retirement or supervisor shutdown according to policy. The next waiting member may use released activation capacity even while an earlier predecessor stop remains outstanding.

Diagnostics and lifecycle publication

DiagnosticDisposition has two exhaustive choices:

• DeliverTo attempts one typed diagnostic delivery; or
• Terminate transfers the diagnostic with the stopped behavior.

FixedDiagnostic distinguishes startup failure, proxy-input rejection, worker preparation failure, restart denial, restart scheduling failure, unavailable service work, and unexpected typed input. Unexpected input retains the complete input while the unchanged supervisor retains every expected correlation. Terminal startup failure likewise leaves every unrelated roster member inside the stopped supervisor; only Bombay's generic retirement transfer may move that remaining ownership outward.

A preparation failure is valid for every recovery strategy and selected roster size. Non-trigger participants return to their exact prior member states; the trigger remains stopped. The diagnostic retains the prepared prefix, exact rejection or interpreter disposition, and untouched suffix, while the supervisor separately retains the reusable worker source and applies FailureReaction.

FailureReaction is independent of diagnostic delivery:

• RetireMember removes only the unavailable role; or
• StopSupervisor retires the complete supervisor.

Optional FixedLifecycle publication reports started and restarted workers, ineligible and admitted worker stops, unavailable service commands, and member retirement. When no lifecycle recipient is configured, no lifecycle value is constructed. Lifecycle publication never replaces the operational diagnostic that owns a failure cause.

Management protocol

The public FixedCommand protocol contains:

• Status, returning every member status in declaration order;
• Capability, returning the stable service capability for one role or the exact unavailable/unknown-role result; and
• Shutdown.

Queries do not copy or change roster ownership. They remain admissible while the supervisor is operating or draining. Only a ready member yields a service capability; startup, empty, recovering, stopping, and retired members return the corresponding UnavailablePhase.

Service commands use the stable proxy. If the proxy has no ready worker, the supervisor accepts the exact returned command only while that proxy is still a live member. The command is then moved to either the configured lifecycle publication or WorkerUnavailable diagnostic. It is never stored as roster state.

Shutdown and retirement

The first shutdown closes recovery admission and projects every live member in declaration order. It emits at most one shutdown operation for each live stable proxy. Repeated shutdown emits none.

Each proxy retirement is a commutative join of its exact shutdown-operation result and exact proxy exit. Either may arrive first; neither alone retires the member. A rejected operation remains complete. A member already stopping is adopted without issuing a duplicate operation.

Other work already outside the actor remains required during shutdown:

• proxy creation results;
• initial and replacement proxy-operation settlements;
• proxy outcomes and worker stops;
• worker-preparation start settlements and later source results; and
• restart-schedule settlements and exact elapsed timers.

Late results may restore custody or finish retirement but may not reopen recovery or issue replacement work.

WaitForActorGraph waits for every owned proxy to retire. RetireActorGraphAfter also emits one exact deadline schedule. Its accepted timer, or an exact schedule rejection/no-attempt/corruption, selects forced retirement while preserving the complete unresolved supervisor and exact cause. Foreign, stale, early, and duplicate deadline inputs return unchanged.

The stopped value retains every worker, submission, operation, result, stop, timer request, and diagnostic still owned by the supervisor. Logging is not custody, and Behavior does not spawn a task to dispose of those values. Because retirement consumes or drops that complete value instead of inspecting each private field in the producing crate, the corresponding fields carry checked dead-code expectations. Replacing them with unit is forbidden by the drop-count ownership regressions.

Bombay collaboration

Behavior owns the pure transition and complete Actions. Bombay must:

1. interpret the named action lanes in declared order;
2. return every exact accepted, rejected, blocked, corrupt, or unattempted item;
3. admit initialization actions before ordinary ingress;
4. move the complete stopped supervisor into parent/root retirement custody;
5. keep accepting settlements through that retirement path without reopening the stopped actor; and
6. use the existing Engine driver and retirement barrier.

The required Bombay change is specified in atomic-runtime-settlement.md. It is an upstream composition requirement, not permission to add a FixedSupervisor-specific driver, detached task, mailbox, settlement adapter, or callback.

Canonical construction and application syntax are owned by atomic-actor-devx.md. Verification ownership is mapped in atomic-actor-verification.md.

Dynamic supervisor

Status: feature-complete locally. DynamicSupervisor implements bounded keyed services, all five management commands, replacement, unexpected worker exit, lifecycle and diagnostic publication, shutdown, and forced retirement. Focused unit and model evidence plus four stateful fuzz targets cover cancellation, transferred cancellation, shutdown, and unexpected exit. Three viable mutation partitions have no survivors, direct construction inference and authority forgery have compile contracts, and the obsolete legacy supervision corpus is gone. Final fresh campaign audits and Bombay root custody remain open.

The complete transition law and exhaustive input matrix have one owner: actor-laws/dynamic-supervisor.md. This document is the shorter component guide.

Responsibility

DynamicSupervisor owns a bounded keyed service table; a fresh non-reused generation for every accepted start or semantic rebind; start, replace, stop, query, and cancel commands; exact operation correlation and affine cancellation authority; overlap rejection; lifecycle and diagnostic publication; unexpected worker-exit policy; capacity release; and complete shutdown or forced retirement.

It delegates stable forwarding and worker replacement to the single StableProxy implementation. It owns no fixed roster, coordinated restart strategy, restart budget, worker factory, pool queue, customer outcome, runtime task, mailbox, address allocation, or actor loop. It is not a configurable FixedSupervisor.

Fresh proxy and worker allocation follows the actor-model freshness law. The keyed table, generation policy, operation correlations, phase-sensitive cancellation, bounded terminal-operation retention, and durable lifecycle reporting are Bombay policies.

Construction

The canonical constructor is:

dynamic(
    entries,
    activation,
    unexpected_exit,
    actor_drain,
    lifecycle,
    diagnostics,
)

entries is a validated EntryCapacity; activation is a validated ActivationPolicy. Both have checked constructors from usize, return ZeroCapacity for zero, and cannot be exchanged accidentally. Every other argument is a distinct required policy or typed capability. There is no default, callback, marker, empty route, structural path, application alias, or public proxy factory.

The complete application syntax and public products are owned by atomic-actor-devx.md.

Commands and outcomes

The application protocol has exactly five commands:

• Start admits a new key and complete worker submission;
• Replace changes the worker behind an existing stable service;
• Stop drains and removes one ready, empty, creating, or waiting service;
• Query returns the current public service projection; and
• Cancel uses the exact affine authority returned by an accepted start or replacement.

Start and replace share WorkerChangeReceipt and WorkerChangeRejection<Reason> because their accepted and rejected ownership is identical; their reason sums remain distinct. Stop, query, and cancellation keep their own result sums because their outcomes and retained values differ. DynamicLifecycle owns durable later outcomes. DynamicDiagnostic owns malformed, stale, contradictory, or rejected runtime input according to the configured disposition.

If global shutdown arrives while proxy creation is unresolved, the entry keeps one of two private current phases: supervisor shutdown, or drain of an already admitted explicit Stop. Both are publicly Draining, but later creation settlement preserves their different terminal lifecycle outcomes. No optional stop marker or repeated operation correlation encodes that distinction.

Service and cancellation rules

An accepted start reserves one fresh entry generation, proxy creation ID, ordered management operation, and cancellation authority before committing the entry. The management-operation order also determines which waiting service receives the next activation authorization. The table itself is the source of that ordering and capacity use; there is no second queue or occupancy flag. The affine cancellation authority owns the key and this globally non-reused operation. Entry generation remains lifecycle identity rather than a duplicate cancellation coordinate.

Cancellation returns a worker submission only while the supervisor still owns it locally. After transfer to the proxy, cancellation is logical: the worker is not reconstructed or returned, and a later successful proxy report cannot publish Started or Replaced. The supervisor retains the exact worker result, proxy-shutdown result, and proxy exit until all three resolve. Only then does it publish OperationCancelled and EntryRetired(Cancellation), remove the entry, and release entry capacity. Private proxy-input custody names input rejection and a later proxy report as distinct terminal outcomes; rejection is never encoded as an absent report. Cancellation completion constructs the ordered OperationCancelled then EntryRetired(Cancellation) pair as one closed domain operation; callers cannot select another retirement cause or omit either message. The aggregate selects the exact entry once from the creation carried by the proxy input result; retirement custody does not accept or repeat that correlation. Arrival order does not change the result.

One matching terminal cancellation record is retained until the next accepted change. This makes immediate replay truthful without an unbounded history. Once the entry retires or its key is rebound, the old authority is stale. A rebound key always receives a fresh generation.

Replacement does not copy StableProxy's predecessor-drain logic. StableProxy reports replacement only after its own predecessor has drained. The supervisor validates that report against the retained current service and stores the exact successor or typed unavailability outcome.

Explicit stop and automatic unexpected-exit retirement remain different operations. Its terminal failure is one shutdown-settlement reason together with zero or one exact proxy stop. Those values are independent: the reason is reported unchanged, while stop absence permits restoration and stop presence requires retirement. The representation stores neither arrival order nor four copies of the same optional stop. Stale, duplicate, foreign, wrong-generation, and wrong-operation inputs return or diagnose their complete values without mutating the current entry. Proxy input and exit select their exact entry once; phase transitions do not repeat that same creation comparison or expose an unreachable second wrong-proxy failure.

Shutdown

Global shutdown arrives through the existing typed ShutdownRequested control event; it is not a sixth application command. The supervisor closes new mutations, converts every retained entry exactly once, preserves each unfinished worker change, and drains according to ActorDrainPolicy.

WaitForActorGraph waits for every entry. RetireActorGraphAfter schedules one deadline and stops after its exact timer or scheduling rejection while retaining the unresolved supervisor state for runtime custody. Behavior Actors creates no second Driver, mailbox, task, registry, or shutdown service.

Bombay collaboration

Bombay must assemble applications role-first: establish lifecycle and diagnostic actors, supply their typed capabilities to one pure root construction, and only then activate the root. DynamicSupervisor stores those capabilities; it never looks them up or creates them through an application callback.

Bombay must also carry stopped-child output through parent admission to a non-rejecting root custodian and its existing retirement barrier. The required Engine and custody changes are specified in atomic-runtime-settlement.md. They are runtime composition work, not DynamicSupervisor behavior or a reason to adapt this aggregate to Bombay's current limitations.

Verification

Current evidence covers admission and overlap, cancellation replay and stale authority, pre- and post-transfer cancellation, all six worker/shutdown/exit orders, retained capacity, fresh same-key reuse, replacement, explicit stop, unexpected exit, repeated shutdown, forced residual transfer, and complete named action lanes. Four dedicated fuzz targets each pass 4,096-input replays in development and optimized profiles. Direct real construction infers without a final aggregate type, and compile-fail contracts reject duplicated or forged cancellation authority. Same-signature foreign authority remains AA-20's runtime-stale case rather than a fabricated compiler-only owner brand. The verification plan and remaining whole-catalogue gates are owned by atomic-actor-verification.md.

FIFO pool

Status: feature-complete for the local aggregate; final whole-catalogue audits and Bombay root custody remain. Ordered dispatch, assignment reunion, direct-worker start/activation, recovery eligibility, role retirement, and dispatch shutdown custody have focused models and production tests. Complete worker-source settlement, immediate and delayed replacement release, restart-limit denial, topology disposition, and exact restart schedule/timer correlation now have focused production tests. Exact operating stops before readiness and their returned initialization/activation values now have focused production tests without another worker state machine. Standalone pre-ready failures now stop their installed worker and wait for the exact shutdown/exit reunion before recovery. Late activation results during drain advance only the exact existing progress and never restore eligibility. Restart schedules outside the actor remain pending through drain; accepted restart timers transfer their cancelled replacement immediately. Orderly retirement releases the drained roster, while forced retirement retains the unchanged unresolved roster and exact cause in the final concrete behavior. Generated operating and FIFO-only fuzz evidence now exist. The canonical worker and direct-construction compile contract, two actual timer-wrapper orders, six focused compile denials, and result-type inversion are retained. The warning-custody audit, complete viable mutation audit, and replacement performance baseline are retained. The complete FIFO suite passes 90/90 in debug and optimized modes. Its 305-candidate mutation run has 118 caught, 187 unviable, zero surviving, and zero timed-out candidates without exclusions. The optimized canonical fixture sustains a median 2,732,844 complete assignment cycles/s across five 100,000-cycle runs; this is pure aggregate throughput, not mailbox or Engine throughput. Bombay owns the documented terminal-custody change. The complete transition law is owned only by actor-laws/fifo-pool.md.

A test-only independent customer desk now compares the production aggregate's public customer actions after every input in all 24 permutations of assignment delivery acceptance, completion, exact worker exit, and shutdown. Its oldest-observation queue independently predicts first-terminal precedence, route and payload custody, shutdown return, and terminal uniqueness. It reads no private aggregate state. Recovery and full-drain sequence parity are closed by the direct independent comparisons below. An independent recovery desk also matches all 20 combinations of operating or shutdown ownership, both topology reactions, and every preparation outcome. An independent retirement desk matches every ordering of one ready worker's stop, shutdown return, deadline rejection, accepted scheduling, and exact deadline firing. It proves normal role release and forced role retention without reading private pool state. A generated queue desk additionally compares 192 shrinkable scripts of up to 128 repeated submissions, delivery acceptances, and completions against the real aggregate after every applicable input. Its sole VecDeque predicts bounded admission and oldest-first dispatch without reading private pool state; a newest-first inversion fails on the exact next payload. The FIFO-only fuzz target retains the real emitted assignment plus concrete stale and foreign inputs. It discovered and now preserves both exact worker-stop orders in which accepted or rejected delivery settlement reunites the final assignment prerequisite. Three named seeds, 5,000 development runs, and 5,000 optimized runs preserve terminal uniqueness and every unrelated action lane without importing a private pool phase.

Responsibility

FifoPool owns direct worker incarnations, one bounded global backlog, immutable admission order, direct assignment authority, completion correlation, worker interruption, at-least-once retry or exact failure return, direct-worker restart policy, exactly one terminal customer outcome per accepted job, and complete shutdown extraction and drain.

It contains no stable proxy or hidden supervisor. It owns no key, binding, per-role queue, affinity selector, or keyed management operation. It is not a mode of KeyedPool.

Collaboration and policy

Fresh worker allocation is the actor-model law. FIFO admission, circular idle selection, immutable retry ordering, interruption disposition, restart policy, and terminal customer custody are Bombay pool constructions. Assignment and direct-worker lifecycle values may be shared with KeyedPool only after the same law suite passes both consumers without modes, ignored outcomes, or weaker errors.

The pool retains the canonical customer obligation and route. A worker receives only a moved assignment containing execution payload and affine completion authority. Delivery settlement, completion, and exact worker exit form the four-way order-independent join owned by the aggregate; a generic settlement lane cannot replace it.

A queued obligation stores only its immutable admission order and an optional assigned role. The role remains necessary for a later assigned-job return. The event that caused retry does not remain in queue state because worker exit and rejected delivery have identical future behavior. Forced-retirement and emitted diagnostic payloads are different: they remain complete affine custody until Bombay or the selected diagnostic route accepts them.

Exact worker shutdown reuses the generic protocol described in atomic-runtime-settlement.md: the lifecycle host retains the complete ActionItemResult<ShutdownEstablished<...>>, while the pool later receives only EstablishedShutdownResolved<P> and the exact ChildStopped input. Direct-worker state must not duplicate the emitted request or import StableProxy's private worker state.

The initial factory is consumed only while constructing the all-or-none roster. Its rejection is the shared InitialWorkerRejection described in atomic-actor-architecture.md, embedded in FifoConstructionRejected beside FIFO policy. Automatic recovery never calls that closure inside Behavior; permanent and transient recovery emit the generic typed worker-source request for one role, which Bombay executes and settles outside the actor. Temporary recovery has no source. One shared worker classification defines normal and abnormal stops for both fixed supervision and FIFO. FIFO then owns the closed decision to prepare, wait while its single affine source is in use, retire the role, or stop the pool. A second simultaneous eligible stop cannot duplicate the source and waits in declaration order. FIFO still owns budget, timing, and topology disposition. An exact preparation start receipt records that the source has begun; it does not assert a prepared worker. The later successful, worker-rejected, or source-rejected result returns the affine source exactly once. A corrupt or unattempted start returns the original request. Under RetireRole, that source immediately serves the first waiting role before ordinary dispatch; under StopPool, ordinary shutdown drains surviving workers. Delayed restart release admits only its exact schedule result and timer once. When an exact temporary worker stop becomes actionable, RetireRole removes that role from future dispatch, fills any surviving ready worker from the same ordered backlog, and returns the remaining backlog only when no serviceable or recoverable role remains. StopPool enters the ordinary pool shutdown path and requests shutdown only from workers that have not already stopped. A temporary worker never occupies recovery state.

An exact initialization or activation failure without a prior stop does not retire an installed worker by assertion. The pool transfers the complete returned failure through diagnostics, requests exact worker shutdown, and reuses the same Stopping shutdown/exit reunion as rejected assignment delivery. Activation failure releases its occupied capacity and admits the next waiting role in declaration order. Recovery begins only after both shutdown settlement and exact worker exit arrive.

Once pool shutdown begins, an activation already dispatched remains correlated until its exact result returns. Exact Started advances that worker from dispatched to activating. Duplicate or foreign starts are diagnostic-only. A later readiness or rejection retires the activation progress into diagnostics; it cannot make the worker idle, assign queued work, or start recovery. The same worker remains in the ordinary exact shutdown/exit reunion.

FIFO and KeyedPool implement that retirement equation once in the direct-worker model. Retirement stores Option<WorkerStartupCustody>: an inhabited value is the exact activation plan, initialization attempt, activation permit, activation start, or activation still owned locally; absence means no startup value remains. It does not use service readiness to stand for absence. The shared transition admits only exact initialization and activation inputs and returns complete foreign, duplicate, rejected, or late values for aggregate diagnostics. Queue, customer, binding, recovery, deadline, and final actor policy remain outside it.

A worker creation emitted before shutdown remains admissible during drain. If the exact actor is established after admission closes, FIFO starts no worker initialization or activation work: it emits one exact shutdown and holds the activation value in the drain member until exact stop. If that stop was already observed, FIFO retires the member immediately and transfers the activation to diagnostic custody. Rejected creation transfers the returned worker, activation, and any prior stop together. Foreign or reversed creation results leave every pending member unchanged.

An emitted worker-preparation request remains pending after shutdown even when all direct workers have retired. Its exact start settlement and, if started, later source result have distinct correlation phases. Only its private exact ticket can release that drain member. The late successful, worker-rejected, or source-rejected result restores the affine source when valid and transfers every cancelled submission, rejection, and stopped-worker value to diagnostics. It cannot create a replacement or emit a restart schedule. A foreign return leaves the member unchanged, and normal pool retirement waits for the exact return. Corrupt or unattempted starts return the original request before source work begins.

An emitted restart schedule likewise remains pending until its exact accepted, rejected, corrupt, or unattempted return. Shutdown then transfers the stopped worker, uncommitted replacement, and schedule return to diagnostics without creating another worker. A foreign schedule cannot release that custody. Once Timers accepts the schedule, Timers alone owns whether an elapsed event will be published; pool shutdown immediately transfers the cancelled replacement and does not wait for that event. Any later elapsed event is stale input. Worker restart and actor-drain schedules use distinct identities and cannot settle one another.

Normal retirement is the payload-free Stopped alternative; it retains no role or shutdown history. Shutdown-identifier exhaustion, an exact returned deadline schedule, or exact deadline firing instead enters the private ForcedRetirement alternative. That alternative owns the unchanged ordered drain roster and the exact cause. It does not reinterpret unresolved worker creation, activation, assignment, recovery, or shutdown values as completed. Bombay moves the whole final concrete behavior together with its environment residual through the existing Driver retirement barrier. FIFO adds no residual action lane, runtime adapter, actor loop, or task. Work still outside the actor, including an accepted activation or worker-source request, remains in Bombay's environment residual rather than being duplicated inside the pool.

Realization gate

Canonical construction, submission, outcomes, and the required assignment.complete(result) worker expression are owned by atomic-actor-devx.md. The implementation must prove capacity zero/full boundaries, FIFO fill, multiple interrupted reinsertion, every assignment join order, authority reunion, duplicate/stale/foreign completion, recovery, complete shutdown, and exactly one terminal outcome.

No supervisor, proxy, generic pool engine, selector placeholder, structural parent route, named interpreter send lane, helper type alias, or alternate pool spelling may survive. Repository-wide verification status and remaining gates are owned by atomic-actor-verification.md.

Keyed pool

Status: feature-complete locally. The aggregate implementation and both bounded independent models are executable. Separate retained stateful targets isolate binding management from assignment/retirement custody. The assignment/quarantine partition has all 18 viable candidates caught, including exact nonzero-role completion selection; the binding value/table partition has all 22 viable candidates caught, including public evidence privacy and exact caller request identity. The recovery partition has all 13 viable candidates caught, including exact delayed recovery of a nonzero role through preparation, scheduling, and timer release. The binding and recovery partitions retain 49 and twelve compiler-unviable substitutions as inventory only. The shutdown partition has both viable candidates caught; thirteen compiler-unviable defaults remain inventory only. The complete fresh 232-candidate owner inventory is classified: all 72 executable candidates are caught and 160 compiler-unviable substitutions remain inventory only. Final campaign audits and Bombay root custody remain open.

Production includes canonical construction, pre-ready admission, generation-exact binding management, exact successful direct-worker startup, role-local dispatch, both accepted-delivery/completion orders, foreign completion rejection, exact busy-worker interruption, permanent role extraction, rejected-delivery authority reunion, worker quarantine, direct worker preparation, immediate and delayed replacement release, exact restart schedule/timer correlation, and shutdown custody for creating, initializing, waiting for activation capacity, activating, ready, busy, quarantined, waiting for the recovery source, preparing, scheduling a restart, and waiting for its timer. An unused activation plan remains in the terminal diagnostic action until the interpreter settles that action; it is not destroyed when the worker exits. Forced retirement retains the unchanged unresolved worker roster and exact cause in the final concrete behavior; a non-cloneable pending worker value proves that custody survives Step::Stop. Generic settlement and FIFO's complete direct-worker consumer are retained, and Bombay owns the documented transfer of final behavior and actions through its retirement barrier. The private diagnostic-cause sum carries a checked dead-code expectation because the selected custodian receives it intact; KeyedPool does not expose lifecycle internals merely to make the producer inspect them. The complete transition law is owned only by actor-laws/keyed-pool.md.

Responsibility

KeyedPool owns direct workers, one bounded queue per semantic role, stable future-admission affinity, bounded bindings, non-reused binding generations, exact generation-or-current-absence management expectations, rebalance/unbind, assignment and completion, permanent role retirement/binding removal, exactly one terminal customer outcome per accepted job, and complete shutdown drain.

It has no global FIFO queue, circular selector, stable proxy, or supervisor. It is neither a wrapper nor mode of FifoPool.

Collaboration and policy

Fresh worker allocation is the actor-model law. Concrete key selection, binding capacity, fresh global generation, same-role rebalance semantics, immutable admitted affinity, per-role admission, and automatic binding extraction are deliberate keyed-pool policies.

The binding table solely owns each retained key. Accepted work retains only opaque generation/role evidence and its immutable admitted role. Unbind or rebalance affects future admission; it cannot retarget queued, assigned, or retried work. Permanent role unavailability removes every binding and returns all role-owned work in one transition. Temporary recovery retains bindings.

The initial factory is construction-only. KeyedConstructionRejected embeds the shared InitialWorkerRejection described in atomic-actor-architecture.md beside keyed policy. Permanent and transient recovery use the same generic one-role worker-source request as FIFO and fixed supervision; Bombay executes it outside Behavior, while KeyedPool owns eligibility, budget, timing, binding consequences, and topology disposition. Temporary recovery has no worker source.

FIFO and KeyedPool use one passive direct-worker component for successful child creation, initialization, activation admission, and readiness. That component cannot inspect a queue or binding and cannot emit Actions. KeyedPool alone selects the correlated role, applies the global activation capacity, and drains only that role's oldest queued job when its worker becomes ready. Creation identity and lifecycle kind are selected once by the shared ordered mapping; the member transition does not repeat that correlation test.

They also use one direct-worker retirement transition. Its Option<WorkerStartupCustody> owns only a concrete startup value still local to the pool; absence means none remains. An exact stopped initialization joins the authoritative worker stop with shutdown and returns the unused activation plan. An exact activation Started receipt advances the retained attempt without a diagnostic; a later terminal or duplicate activation remains complete for the owning pool's diagnostics. This component chooses no binding, queue, customer, deadline, recovery, or final actor outcome.

FIFO and KeyedPool now also consume the same private AssignedJob join. A completion received before its delivery receipt remains attached to the assignment; the exact receipt releases one customer completion. When the receipt arrives first, the exact completion releases that outcome directly. Worker identity alone is insufficient: the completion authority must identify the retained assignment. An exact worker stop applies the configured interruption policy once. If retry is selected but recovery retires the role, the job remains an assigned obligation and is returned as RolePermanentlyUnavailable; it is never reclassified as queued. Role retirement extracts that role's queue and every binding in the same aggregate transition.

FIFO and KeyedPool also use one private ForcedRetirementCause: exhausted worker-shutdown identifiers, a deadline that was not scheduled with its complete interpreter result, or the exact elapsed deadline. Each pool still owns its own unresolved workers, customer extraction, and terminal transition; there is no common pool or retirement engine.

FIFO and KeyedPool consume the same exact preparation start settlement and later source-result law. The shared worker value correlates the exact preparation request through both phases, retains the stopped worker and complete replacement submission, and changes from waiting for schedule acceptance to waiting for the exact timer. It cannot choose a role, touch a queue or binding, apply a failure policy, emit an action, or create a worker. KeyedPool alone serializes its affine recovery source, applies restart limits and release timing, returns work, removes bindings when a role becomes permanently unavailable, and selects role retirement or pool shutdown.

Rejected delivery returns the complete assignment to the shared authority reunion. An exact return restores the existing customer obligation to its original role queue at its immutable admission order, then quarantines that worker. The role remains unavailable until both the shutdown response and the exact worker exit arrive in either order. Only then may recovery or permanent role retirement begin. A returned assignment that contradicts an already received completion returns the customer obligation once, preserves both contradictory inputs in diagnostics, and drains the pool.

The independent keyed_model checks two keys/roles, zero and one capacities, all eligibility classes, exact management expectations, immutable affinity, every delivery/completion/stop permutation, retry order, retirement, shutdown, 22,621 bounded prefixes, and five deliberate inversions in debug and optimized builds. The production keyed_binding_sequences fuzz target separately drives only management commands through the real aggregate. Its scenario stores one absent-or-bound value, issued and stale generations, and one foreign generation; it owns no assignment, customer, or worker-retirement state. Five thousand development and five thousand optimized inputs preserve same-role stability, role-changing and post-unbind freshness, exact stale rejection, and foreign generation rejection.

The separate keyed_assignment_sequences target begins with one ready worker and one accepted binding, then drives accepted or rejected delivery, completion, exact and foreign stops, shutdown settlement, and replay. Five thousand development and five thousand optimized sequences preserve the original job, payload or result, role, generation, logical customer, and one terminal outcome. Its model retains the current post-stop phase because a late receipt can release terminal custody, and permits ReturnedQueued when rejected delivery restores an assignment to its admitted role immediately before that role retires. It delivers no input after Step::Stop, matching the interpreter lifecycle law.

Realization gate

Canonical construction, submission, management, outcomes, and worker completion syntax are owned by atomic-actor-devx.md. The exact production-source binding harness proves final-generation issuance, permanent exhaustion without wrap, complete rejected-key return, and preservation of an existing binding when rebinding cannot issue a generation. Real aggregate traces now cover shutdown from every reachable direct-worker and recovery phase, including activation-capacity and recovery-source waiters. A separate account-directory model now matches the production aggregate's automatic and explicit binding, capacity rejection and release, same-role preservation, cross-role generation, stale expectation, and unbind results without reading production state. The same independent customer-custody model now compares all 24 delivery-acceptance, completion, exact-exit, and shutdown orders against FIFO and KeyedPool. The keyed adapter also proves that every customer outcome retains the original binding generation and role. Recovery/shutdown parity is now closed by direct public traces: concurrent failures serialize the one recovery source in role order; every accepted, rejected, corrupt, or unattempted worker preparation and restart-schedule result returned after shutdown emits no new worker work; an accepted restart timer is cancelled; and accepted or rejected worker shutdown settlement reunites with the exact worker exit in either order. The separate workshop oracle checks the same ownership equations and explores 22,621 generated recovery/shutdown prefixes in debug and optimized builds. It uses no production state projection or second actor transition. Bombay's separately documented root transfer remains an upstream integration requirement.

No generic pool engine, optional key, selector mode, cloned key evidence, generation inference, permanent tombstone, stable proxy, structural completion route, helper alias, or compatibility spelling may enter the replacement. Repository-wide verification status and remaining gates are owned by atomic-actor-verification.md.

Normalized aggregate laws

These documents state the complete control states, retained data, transitions, outputs, rejections, and terminal paths for the five atomic actor aggregates. They are implementation-independent domain contracts. The adjacent catalogue documents map those laws onto Bombay's concrete typed behavior algebra.

Each law distinguishes actor-model requirements, derived library construction, and deliberate Bombay policy. Pseudocode identifiers describe semantic values; they are not additional exported Rust names.

Stable proxy falsification model

Status and authority

This document is the AA-01 independent semantic model for a stable worker proxy. It is a non-production falsification oracle. It does not define Rust types, a second behavior algebra, an interpreter contract, or evidence that a solution-matrix row is implemented. It is authoritative for the StableProxy behavior it covers. stable-proxy.md maps that behavior to the selected implementation, and atomic-runtime-settlement.md owns runtime interpretation and custody.

The actor-model law used here is fresh allocation: creating a replacement must establish a fresh actor rather than overwrite an existing address. Staged creator-local correlation, commit-before-dependent-effects ordering, exact installation, activation, owner-only control, and drain policy are Bombay derivations or policy choices. The stable public identity and replacement protocol are template laws.

Runtime route selection is owned normatively by docs/atomic-runtime-settlement.md. The proxy issues and stores only a CreationId; it never chooses or stores a runtime route before emitting CreateChild. Any older reservation label in the transition oracle denotes that creator-visible correlation before interpretation and routed evidence only inside the returned runtime settlement. It does not authorize a separate route request, waiting phase, public route, or combined value shared by proxy and Bombay.

Older shutdown labels that distinguish worker-return order describe semantic cases, not required Rust variants. Once the worker has stopped, the retained current product is the worker, exact stop, remaining initialization or activation value, and an optional exact shutdown receipt. Absence is lawful only when no shutdown request was emitted. H147 proves that separate AfterDeparture, AfterStop, and terminal *AfterStop Rust alternatives add arrival history without changing an accepted transition.

The model must falsify designs that make any of these claims false:

1. One proxy owns at most one installed worker incarnation.
2. A service command is sent only to the exact current incarnation in Ready.
3. Installation is not readiness.
4. Replacement drains the exact predecessor and creates a fresh successor.
5. Every accepted transition produces one next state and one complete named action product; no effect is ambient.
6. Shutdown closes admission and settles every definition, creation, initialization, activation, and incarnation the proxy still owns.
7. Stale, duplicate, foreign, and contradictory facts cannot advance state.

“Atomic” below means one local Behavior fold commits a state and its complete Actions. It does not claim atomic delivery, creation, or cross-actor work.

Semantic values

The following names are model vocabulary, not proposed public Rust names.

BirthKind =
    Initial
  | Replacement { replaces: WorkerIncarnation }

BirthAttempt = the fresh, non-reused CreationId issued by the proxy
RoutedBirth = interpreter-private { attempt: BirthAttempt, route }
WorkerRecipient = proxy-private routable capability for one committed worker birth
WorkerIncarnationEvidence = opaque non-routable provenance for that birth
WorkerIncarnation = private { recipient: WorkerRecipient, evidence: WorkerIncarnationEvidence }
InitSettlement = complete initialization effects retained by the lifecycle host
InitAttempt = exact correlation for host-owned initialization work
ActivationPlan = the concrete work required before the worker may be ready
ActivationPermit = a one-shot capability issued only after successful initialization
ActivationAttempt = a fresh, non-reused correlation for one consumed permit and plan

ActivationPhase =
    AwaitingStartSettlement
  | InFlight

DrainCompletion =
    ReturnToEmpty
  | StopProxy

ActivationFailure =
    StartRejected { request, reason }
  | Rejected { rejection }

WorkerInitializationFailure = EffectsRejected | InterpreterCorrupt
InitFailure = { failure: WorkerInitializationFailure, activation }

ExitEvidence =
    FromInitialization {
        observation, stop
    }
  | FromObserver {
        observation, stop
    }

ExitSettlement =
    Observed { evidence: ExitEvidence }
  | Transferred {
        observation, worker: WorkerIncarnation, reason
    }

WorkerDrain =
    Exited { exit: ExitSettlement }
  | Transferred { residual }

PreReadyStop =
    DuringInit {
        activation,
        exit: ExitSettlement
    }
  | InitializedAfterExit {
        permit, activation,
        exit: ExitSettlement
    }
  | ReadyAfterExit {
        attempt, proof,
        exit: ExitSettlement
    }

BirthDrainResult =
    FoldRejected {
        creation, error, definition_and_plan
    }
  | HostRejected {
        creation, rejection, prepared_init, activation
    }
  | Contradiction { facts }

InitDrainWork =
    Initialized { permit, activation }
  | Rejected { rejection, activation }

InitDrainResult =
    WorkAndExit {
        work: InitDrainWork,
        exit: ExitSettlement
    }
  | FailureAndExit {
        failure: InitFailure,
        exit: ExitSettlement
    }
  | StoppedDuringInit {
        activation,
        exit: ExitSettlement
    }
  | Transferred {
        phase: InitDrainPhase,
        residual
    }

InitDrainPhase =
    AwaitingBoth { attempt: InitAttempt }
  | InitSettled {
        work: InitDrainWork
    }
  | ExitObserved {
        attempt: InitAttempt,
        exit: ExitSettlement
    }

ActivationDrainResult =
    StartRejected { request, reason }
  | ReadyAfterCancel { proof }
  | RejectedAfterCancel { rejection }

ActivationDrainPhase =
    AwaitingBoth { phase: ActivationPhase }
  | ActivationSettled { result: ActivationDrainResult }
  | ExitObserved {
        phase: ActivationPhase,
        exit: ExitSettlement
    }

An attempt is neither an address nor proof of freshness. A creation becomes an installed incarnation only when the interpreter commits fresh host ownership. All correlation values are exact and non-reused. Two proxies issuing their first worker attempt must still produce unequal evidence; a local ordinal is diagnostic data, not identity. Sequence arithmetic, address reuse, timing, or adjacency cannot manufacture provenance.

The proxy never publishes WorkerRecipient or the private WorkerIncarnation product. It alone routes service through worker.recipient. Parent outcomes project only WorkerIncarnationEvidence; the stable proxy remains the sole externally routable service capability.

Every payload in this model is complete and owned. Field names therefore use domain words such as worker, request, rejection, stop, and exit without repeating complete_ or structural implementation phrases.

Complete state sum

Each variant owns exactly the values listed. kind is the closed BirthKind sum, not an optional predecessor.

Dormant
    no installation has ever been attempted

Creating {
    kind, reservation: ChildReservation,
    stopped: Option<ExitSettlement>
}
    one complete worker definition and activation plan have moved into the
    staged creation action and its unresolved settlement; `stopped` is exactly
    absence or one authoritative pre-birth stop

Initializing {
    kind, worker: WorkerIncarnation, attempt: InitAttempt,
    stopped: Option<ExitSettlement>
}
    installation committed; the lifecycle host owns unresolved initialization
    settlement and the activation plan under this exact correlation; the proxy
    retains at most one already-arrived exact stop

Activating {
    kind, worker: WorkerIncarnation,
    attempt: ActivationAttempt, phase: ActivationPhase,
    stopped: Option<ExitSettlement>
}
    one exact permit and plan were consumed by one `BeginActivation` action;
    stop absence/presence remains current input to the readiness decision

Ready { worker: WorkerIncarnation }
    the one routable exact current worker

EmptyInitial
    the initial operation failed before installation committed

EmptyAfter { previous: WorkerIncarnation }
    a previously installed incarnation is terminally settled

StoppingForReplacement {
    current: WorkerIncarnation,
    next: ChildReservation,
    replacement
}
    the predecessor is being drained; the successor definition has not moved
    into creation yet

DrainingCreation { kind, reservation: ChildReservation }
    shutdown owns an unresolved creation settlement

DrainingCreationAfterExit {
    kind, reservation: ChildReservation,
    exit: ExitSettlement
}
    shutdown owns creation settlement and already has the pre-birth exit

DrainingInitFailure {
    kind, worker: WorkerIncarnation, failure: InitFailure,
    completion: DrainCompletion
}

DrainingInit {
    kind, worker: WorkerIncarnation, phase: InitDrainPhase
}

DrainingActivationFailure {
    kind, worker: WorkerIncarnation, attempt: ActivationAttempt,
    failure: ActivationFailure, completion: DrainCompletion
}

DrainingActivation {
    kind, worker: WorkerIncarnation, attempt: ActivationAttempt,
    phase: ActivationDrainPhase
}

DrainingWorker { worker: WorkerIncarnation }
    one shutdown/worker-exit observation remains unresolved

Stopped
    terminal; no mailbox event is admitted

EmptyInitial and EmptyAfter are distinct because only the latter has replacement provenance. The drain variants contain closed work/cause and join sums; they do not coordinate optional fields, cross-product flags, or already-settled live combinations.

At most one of Initializing, Activating, Ready, StoppingForReplacement, DrainingInit*, DrainingActivation*, or DrainingWorker can exist, proving the installed-incarnation bound structurally. Creating and DrainingCreation* own no installed capability.

The only empty-state projections are explicit:

PreBirthEmpty(Initial) = EmptyInitial
PreBirthEmpty(Replacement { replaces }) = EmptyAfter { previous: replaces }
PostBirthEmpty(worker) = EmptyAfter { previous: worker }

Therefore an initial attempt that committed an incarnation and then stopped or failed cannot return to EmptyInitial.

Complete input sum

There are three ingress lanes. They are distinct protocols, even where the table presents them together.

Public service input

Service { sender, command }

Private owner control input

InstallInitial { definition, activation }
Replace { definition, activation }
Shutdown

Only the established structural owner can construct the control capability. Clients can construct only the worker's concrete service protocol.

Lifecycle facts

BirthResult =
    FoldRejected { reservation, definition_and_plan, error }
  | HostRejected {
        reservation, behavior, init_actions, activation, reason
    }
  | Committed {
        reservation, worker: WorkerIncarnation, init: InitAttempt
    }

InitResult =
    Initialized {
        worker: WorkerIncarnation, init: InitAttempt,
        permit: ActivationPermit, activation: ActivationPlan
    }
  | EffectsRejected {
        worker: WorkerIncarnation, init: InitAttempt,
        failure: WorkerInitializationFailure, activation: ActivationPlan
    }
  | Stopped {
        worker: WorkerIncarnation, init: InitAttempt,
        activation: ActivationPlan,
        exit: ExitEvidence
    }

ActivationStartResult =
    Accepted { worker: WorkerIncarnation, attempt: ActivationAttempt }
  | Rejected {
        worker: WorkerIncarnation, attempt: ActivationAttempt,
        request, reason
    }

ActivationResult =
    Ready { worker: WorkerIncarnation, attempt: ActivationAttempt, proof }
  | Rejected { worker: WorkerIncarnation, attempt: ActivationAttempt, rejection }
  | ReadyAfterCancel { worker: WorkerIncarnation, attempt: ActivationAttempt, proof }
  | RejectedAfterCancel {
        worker: WorkerIncarnation, attempt: ActivationAttempt, rejection
    }

WorkerExit =
    BeforeBirth {
        reservation: ChildReservation,
        evidence: ExitEvidence
    }
  | AfterBirth {
        worker: WorkerIncarnation,
        evidence: ExitEvidence
    }

ProxyDiagnostic =
    UnexpectedWorkerReservation { phase, result: ReservationResult }
  | UnexpectedWorkerStart { phase, worker: WorkerStart }
  | UnexpectedWorkerStop { phase, stopped: WorkerStop }
  | UnexpectedWorkerInitialization { phase, initialization: WorkerInitialization }
  | UnexpectedWorkerActivation { phase, activation: WorkerActivation }
  | UnexpectedWorkerShutdown { phase, shutdown: WorkerShutdown }

Each alternative owns the complete unexpected input. phase is observable status data, not correlation authority. The exact expected reservation, worker, attempt, or shutdown token remains solely in the unchanged proxy state. Requiring the diagnostic to own that token as well would either duplicate an affine authority or make unchanged-state preservation impossible in safe Rust.

The split between activation start settlement and later activation result is intentional. A typed Ready value injected by a test is only model input. It is not implementation evidence.

Delivery rejection for service sends, parent reports, worker shutdowns, and logical cancellation remains lifecycle-host settlement rather than proxy mailbox input. Those settlements are still mandatory and must be witnessed in AA-06; excluding them from this input sum does not discard them or make the proxy their universal rejection owner.

The proxy's normal template report remains the solution's four-variant sum:

ParentReport =
    InitialInstallation { outcome: InstallationOutcome }
  | Replacement { outcome: ReplacementOutcome }
  | WorkerStopped { stop }
  | Unavailable { sender, phase, command }

InstallationOutcome =
    Rejected { definition_and_plan, phase, reason }
  | Resolved { result: WorkerStartResult }

ReplacementOutcome =
    Rejected { definition_and_plan, phase, reason }
  | CancelledBeforeBirth {
        replaces: WorkerIncarnationEvidence,
        replacement,
        reason: Shutdown
    }
  | Resolved {
        replaces: WorkerIncarnationEvidence, result: WorkerStartResult
    }

WorkerStartResult =
    CreationRejected {
        rejection: WorkerCreationRejection,
        activation,
        stopped: None | ExactWorkerStop
    }
  | Ready { attempt: WorkerAttempt, readiness }
  | Unavailable { attempt: WorkerAttempt, drain: WorkerDrain }

WorkerCreationRejection is the sole owner of the exact pre-commit cause and returned worker value. WorkerDrain is the sole owner of the exact committed worker failure cause and every proxy-held affine value. WorkerStartResult classifies only the three decisions its consumer makes; it does not repeat either nested cause as another outer alternative. stopped is present on a creation rejection only when the proxy had already accepted the exact stop.

Every attempt and replaces field in ParentReport is opaque evidence. A WorkerStopped report likewise contains terminal provenance and no WorkerRecipient. The owner can correlate lifecycle without acquiring a delivery route around the stable proxy.

Control rejection and contradiction are nested outcomes, not additional top-level parent-report variants. Shutdown completes through behavior termination and lifecycle-host settlement; it is not a fifth parent report. An owner never rebuilds one atomic outcome by joining several lower-level reports.

ProxyDiagnostic is deliberately not smuggled into that sum. It travels on the separate model-required diagnostics lane to the established owner. This is part of the recorded product disagreement and must be reconciled before production authority changes.

For non-shutdown operations, the atomic parent outcome carries every proxy-owned leftover. A creation rejection carries the complete creation rejection, activation plan, and any already accepted exact stop. An unavailable committed worker carries one WorkerDrain, whose exhaustive alternative owns the exact initialization, activation, early-stop, shutdown, and stop values. The lifecycle host separately retains the complete concrete action settlement in the worker environment. That settlement follows the one runtime retirement path; it is not a second Behavior outcome channel.

During shutdown there is deliberately no parent report. The lifecycle host receives BirthDrainResult for a pre-birth behavior/host rejection or contradiction. After commit it receives exactly one InitDrainResult: completed initialization work plus exact exit settlement, a stop produced by initialization with the unstarted plan, or a forced transfer containing the complete unresolved join and residual ownership. These are the only initialization-leftover alternatives; none may be dropped or reconstructed. This enriches the solution's abbreviated nested outcomes only inside the non-production oracle and remains an AA-06 runtime proof obligation.

Initialization and activation share only WorkerStopping, whose shutdown-result/stop law is identical. Their outer shutdown state is not one generic product: initialization has no pending domain value, whereas activation owns a real waiting-for-start or running value. A unit, marker, ignored field, or fabricated initialization token may not be introduced to make those shapes appear substitutable. Each concrete state must store only the exact work and worker-return values that remain current.

For initialization, the current work value is exactly Option<WorkerInitializationRetirement>: absence means the result has not returned; presence owns the complete result while worker departure remains unfinished. A second result cannot replace the first and is returned complete. No separate pending/returned initialization sum is lawful. Its stopped outcome owns Option<initialization stop> rather than an arrival-order alternative: presence retains the initializer's independently returned stop when the enclosing worker already owns the observed stop; absence means the initializer stop occupies that enclosing worker slot.

WorkerExit::BeforeBirth is admissible only in a state that owns the same ChildReservation. AfterBirth is admissible only in a state that owns its worker incarnation. The attempt and creator-local route are reserved, stored, emitted, compared, and retired as one private product. No field is inferred from the other; no optional field, address inference, or timing decides which provenance is present.

The lifecycle host, not Initializing, owns the linear InitSettlement and ActivationPlan while initialization work is unresolved. The proxy owns only InitAttempt. A matching InitResult transfers the exact permit/plan, failure-classification/plan, or stopped/plan product back once while the host retains the complete rejected or corrupt settlement for retirement. This is an intentional falsification-model clarification of the solution's shorthand Initializing { initialization_settlement, activation_plan }; AA-02 and AA-06 must prove a concrete locked-boundary realization before that shorthand can become Rust state.

Authorized readiness chain

Readiness is valid only if all of this chain is realized through the locked Behavior -> Actions boundary:

1. Fresh creation commits one exact installed incarnation, closed to service.
2. Initialization actions settle successfully for that incarnation.
3. Settlement issues the one-shot ActivationPermit tied to that incarnation.
4. The proxy reserves a fresh ActivationAttempt and, in the same fold, consumes the permit and concrete plan into an explicit BeginActivation action.
5. The activation interpreter accepts or rejects that complete action. If accepted, it—not a test harness or arbitrary client—owns the in-flight work and the unique authority able to produce the result.
6. Only Ready { worker, attempt, proof } from that accepted work can enter Ready.
7. Rejection, stop, cancellation, a foreign incarnation, a wrong attempt, a duplicate, or a late result cannot publish readiness.

Who produces Ready: the concrete immediate or asynchronous activation interpreter designated by the consumed permit and plan. Who authorizes it: the exact one-shot permit obtained from successful initialization settlement. What starts asynchronous work: the real BeginActivation item in Actions. What correlates it: both exact incarnation and fresh activation attempt. Who owns it while in flight: the lifecycle host's exact activation settlement record, while the proxy owns the corresponding semantic waiting state.

The concrete capability representation and interpreter integration remain open for AA-03 and AA-06. If they cannot be expressed without changing locked foundations, that is a falsification result. This section must not be replaced by a helper that mints Ready directly.

Required falsification-model effect product

The governing solution currently names these six proxy lanes:

worker_deliveries
worker_creations
worker_creation_observations
worker_stop_observations
worker_shutdowns
parent_reports

That product is insufficient for this model because the proxy itself emits two activation operations and must continue after rejecting lifecycle facts. The minimum model product therefore adds three concrete typed send lanes:

activation_begin_requests: BeginActivation
activation_cancel_requests: CancelActivation
diagnostics: ProxyDiagnostic

The resulting nine-lane product is a non-production falsification requirement, not an amendment to design authority. It records a focused disagreement with the solution's six-lane product. AA-03 may not implement activation until the solution, matrix, retained-core decision, and research audit are reconciled or an existing named lane is proven to own the same exact operation without reinterpretation.

The fold returns the real Actions, including its next behavior or termination decision. That decision is not an extra effect lane. Initialization settlement remains an interpreter/lifecycle-host responsibility and is not an ambient behavior effect.

An emitted item transfers its complete value to action settlement. State retains only correlation and ownership that legitimately coexist with the emitted item. Creations still precede dependent observations and sends. The relative order of the independent named send lanes remains an interpreter obligation; AA-06 must prove the selected order rather than infer it from product position.

Creation must commit before same-action sends or observations that depend on the new child. Initialization settlement precedes BeginActivation. Replacement shutdown precedes successor creation because the successor definition remains in StoppingForReplacement until the predecessor's exact worker exit. No row emits both service delivery and unavailability.

Ownership table

Transition notation

The total matrix uses these cells:

• I0: accept initial install; reserve one fresh attempt/route product, enter Creating(Initial), and emit one fresh creation plus its observation.
• R0: accept replacement from Ready; reserve the complete successor attempt/route product before emitting one exact predecessor shutdown, then enter StoppingForReplacement retaining the complete successor.
• R1: accept replacement from EmptyAfter; reserve the complete successor product and enter Creating(Replacement { replaces }) and emit creation.
• C-: reject control with the complete submitted definition/plan and current phase. Repeated shutdown is handled by S= instead.
• D+: deliver the untouched command once to the exact Ready incarnation.
• U: emit one Unavailable report with untouched sender, command, and phase.
• S0: close immediately, settle any control outcome, and enter Stopped.
• S1: close admission and enter the corresponding drain variant without duplicating an already-emitted action.
• S=: shutdown is already in progress; remain in the same drain state and emit no duplicate child shutdown or cancellation.
• BR, IR, AS, AR, WE: apply the matching-result rules below.
• F-: keep the same semantic state and emit exactly one ProxyDiagnostic on diagnostics; every other action lane is empty and the next decision is Continue.
• NA: the event is not admitted because Stopped is terminal. Late settlements are owned by the lifecycle host, not a stopped mailbox.

All BR, IR, AS, AR, and WE cells mean “matching exact correlation only”; every mismatch is F-.

F- is a continuing diagnostic law, not Behavior::Error. The concrete diagnostic alternative names the unexpected input kind, retains the complete original input, and carries the current observable proxy phase. It does not copy the proxy's expected correlation authority out of unchanged state. Creating and initializing each have one public phase; their privately retained optional stop is ownership needed by the later result, not another public work phase. If diagnostic delivery is rejected, the lifecycle host settles that complete action directly and does not recursively send another diagnostic.

Reservation of both attempt and route is a pure, fallible precondition of I0, R0, and R1. A collision or exhaustion of either component returns the complete input through the appropriate nested InstallationOutcome::Rejected or ReplacementOutcome::Rejected and leaves the state unchanged. It never emits creation and never replaces an existing binding.

Total state/event matrix

The matrix is exhaustive over the complete input categories. Nested outcome rules below make each matching cell exhaustive over its result sum.

Shutdown expansion (S0, S1, and S=)

• Dormant, EmptyInitial, and EmptyAfter own no unresolved child work; they return the terminal behavior decision and transfer shutdown settlement to the lifecycle host (S0); no parent report is fabricated.
• Creating with no stop becomes DrainingCreation; with a stop it becomes DrainingCreationAfterExit. The already-transferred creation is not reconstructed or physically cancelled.
• Initializing with no stop becomes DrainingInit(AwaitingBoth) and initiates exact worker drain. With a stop it uses ExitObserved and emits no duplicate worker shutdown.
• Activating becomes DrainingActivation, preserving its ActivationPhase in AwaitingBoth when no stop is present, logically closes readiness publication, and emits the exact cancellation/drain actions. With a stop it preserves the exit in ExitObserved and emits no duplicate worker shutdown.
• Ready becomes DrainingWorker and emits one exact worker shutdown plus its worker-exit observation.
• StoppingForReplacement settles the still-local replacement definition as a nested ReplacementOutcome::CancelledBeforeBirth, becomes DrainingWorker for the predecessor, and does not create the successor.
• Shutdown in DrainingInitFailure or DrainingActivationFailure changes DrainCompletion from ReturnToEmpty to StopProxy. It does not lose the complete failure and emits no duplicate child drain (S1). If the completion is already StopProxy, shutdown is S=.
• All shutdown-owned drain states use S=. They retain their exact state and emit no duplicate cancellation, shutdown, or observation.

Matching-result rules

Birth result (BR)

• In Creating without a stop, FoldRejected or HostRejected emits the corresponding complete initial/replacement outcome and enters EmptyInitial for Initial or EmptyAfter { previous: replaces } for Replacement. Committed enters Initializing with the exact initialization correlation while the lifecycle host retains the linear settlement and plan.
• In Creating with a stop, rejection produces one Contradiction containing both complete authoritative inputs, then enters the pre-commit empty state. Commit enters Initializing carrying that stop; it cannot publish readiness.
• In DrainingCreation, rejection settles shutdown and enters Stopped. FoldRejected and HostRejected transfer their complete values through the corresponding BirthDrainResult variant. Commit enters DrainingInit(AwaitingBoth); exact initialization and terminal ownership must both settle.
• In DrainingCreationAfterExit, rejection produces the complete contradiction, transfers it as BirthDrainResult::Contradiction, and enters Stopped. Commit enters DrainingInit with the retained exit in ExitObserved.

No creation rejection can coexist with a successful birth report. A committed creation is never reclassified as rejected because later initialization fails.

Init result (IR)

• In Initializing without a stop, only a result matching both worker and InitAttempt is admissible. Initialized reserves a fresh activation attempt and, in the same fold, emits the exact BeginActivation action and enters Activating with AwaitingStartSettlement. EffectsRejected enters DrainingInitFailure with both proxy-owned values returned by the result—the closed failure classification and still-unstarted activation plan—then initiates exact drain. Stopped settles its returned plan as never activated and satisfies the outstanding stop observation with that same authoritative result. Its exit field must be ExitEvidence::FromInitialization. It emits StoppedBeforeReady carrying PreReadyStop::DuringInit plus the corresponding ExitSettlement::Observed, then enters EmptyAfter { previous: worker }.
• In Initializing with a stop, every outcome settles initialization without beginning activation. Only the exact initialization attempt is admissible. Initialized emits PreReadyStop::InitializedAfterExit carrying its returned permit/plan and the already-satisfied worker-exit observation. Stopped reconciles its exact stop with the stored exit and requires exit = ExitEvidence::FromObserver, then emits DuringInit with the corresponding Observed settlement; it does not settle the observation twice. EffectsRejected combines its failure classification and returned plan with the same exit settlement. The lifecycle host retains the complete action settlement. None can emit Ready; all enter EmptyAfter { previous: worker }.
• DrainingInitFailure already owns a settled rejection. It waits only for the exact worker exit. With ReturnToEmpty, it emits one InitEffectsRejected parent outcome carrying the failure classification, unstarted plan, and exit settlement. With StopProxy, it transfers exactly InitDrainResult::FailureAndExit instead. Shutdown changes only that completion and never discards either value.
• In DrainingInit, an exact init result changes AwaitingBoth to InitSettled and stores one exhaustive InitDrainWork, including the permit/plan or failure-classification/plan pair. From ExitObserved, the same result closes the join by transferring WorkAndExit to the lifecycle host and enters Stopped. InitResult::Stopped closes directly as StoppedDuringInit: from AwaitingBoth it satisfies and retires the exact outstanding observation with the same authoritative stop; from ExitObserved it reconciles the already-satisfied observation and does not settle it twice. A separate worker exit changes AwaitingBoth to ExitObserved, or closes InitSettled as WorkAndExit. A foreign correlation emits ProxyDiagnostic; two authoritative inputs with the same correlation but conflicting stop data emit the atomic Contradiction retaining both. No live state represents both obligations settled.

The exact host ordering used to interpret and settle initialization actions is an open foundational realization. These rules state the ownership constraint; they do not claim that AA-01 implements it.

Activation start (AS) and result (AR)

• In Activating(AwaitingStartSettlement) without a stop, exact start acceptance changes only phase to InFlight; the host then owns work and result authority. Exact start rejection enters DrainingActivationFailure with the complete unaccepted request and initiates exact drain.
• An activation result is authorized only in Activating(InFlight). Exact Ready enters Ready and emits the initial/replacement readiness outcome. Exact rejection enters DrainingActivationFailure, retains the complete rejection, and initiates exact drain. A result received before start acceptance is F-; the activation interpreter must causally publish acceptance before releasing its result authority. Cancellation-qualified results in a non-cancelling state are F- and cannot be reinterpreted.
• In Activating with a stop, exact start acceptance changes phase to InFlight; exact start rejection emits its complete atomic outcome with the retained stop. An authorized exact result in InFlight emits PreReadyStop::ReadyAfterExit for Ready, carrying the attempt, authority proof, and worker-exit settlement. A rejection emits the complete activation-rejection outcome with the same exit settlement. Every case enters EmptyAfter { previous: worker }; none publishes readiness.
• DrainingActivationFailure already owns a settled activation failure. It waits only for the exact worker exit, then emits the complete failure outcome. Shutdown changes its drain completion to Stopped without discarding failure provenance.
• In DrainingActivation, matching start acceptance changes the activation phase inside AwaitingBoth or ExitObserved from AwaitingStartSettlement to InFlight. Matching start rejection changes AwaitingBoth to ActivationSettled, or closes ExitObserved and stops. An exact late result from InFlight follows the same two transitions. Neither ordinary Ready racing with cancellation nor ReadyAfterCancel is published. A result before start acceptance is F- under the causal interpreter policy; a result after ActivationSettled is a duplicate. Ordinary Ready/Rejected racing the logical close are normalized into the corresponding after-cancel settlement without publishing availability. An exact stop changes AwaitingBoth to ExitObserved, or closes ActivationSettled and stops. No live state represents both obligations settled.

The causal acceptance-before-result rule is an explicit Bombay interpreter policy and an AA-06 proof obligation, not a general actor-model guarantee. If the real boundary cannot enforce it, AA-03 must replace ActivationPhase with a truthful closed out-of-order join before production code exists.

Worker exit (WE)

• Creating with no stop accepts only BeforeBirth with its child reservation, stores that exact stop, and still waits for the creation result to decide whether a birth committed. DrainingCreation similarly becomes DrainingCreationAfterExit.
• Every WorkerExit must carry ExitEvidence::FromObserver; initialization exit evidence provenance on this ingress is wrong-kind and follows F-. An accepted exit is stored or emitted only after wrapping that delivered value in ExitSettlement::Observed.
• Initializing and Activating with no stop accept only AfterBirth with their worker incarnation and store that exact stop. A second stop is F-.
• Ready emits one complete WorkerStopped report and enters EmptyAfter { previous: worker }.
• StoppingForReplacement emits the predecessor stop report and, in the same fold, transfers the retained successor through the already-reserved complete attempt/route product into the fresh creation action, entering Creating(Replacement { replaces }) with that same reservation.
• In any DrainingInit*, DrainingActivation*, or DrainingWorker state, only AfterBirth with the owned worker incarnation can advance. It either completes the failure drain, records ExitObserved, or closes a shutdown join whose work is already settled. A second stop is F-. Final outcome waits for any still-owned settlement.
• DrainingWorker consumes the exact stop, returns the behavior's terminal decision, and transfers final shutdown settlement to the lifecycle host. It emits no invented parent-report variant.

Overlap, stale input, and outcome laws

• A second install or an install after Dormant is a typed rejection that returns its complete definition and plan.
• A replacement is accepted only in Ready or EmptyAfter. Every overlap returns the complete submitted successor.
• Every non-ready service command produces exactly one complete Unavailable report. No retry or implicit replay is promised.
• A lifecycle fact can advance only the state owning its exact worker and attempt and expecting that fact kind. Wrong-kind facts are not reinterpreted.
• Duplicate stop, creation, initialization, activation-start, activation result, and readiness inputs preserve proxy state and emit exactly one closed ProxyDiagnostic retaining the complete input.
• Parent-report delivery rejection never rewinds the transition. The lifecycle host settles the complete rejected report.
• A pre-readiness failure after committed installation is not reported as final until the exact incarnation and all transferred initialization or activation work are settled or transferred to terminal residual ownership.

First-slice non-features and proof obligations

AA-01 intentionally does not provide:

• Rust proxy types, a fold, an executable local algebra, or test helpers;
• the real initialization fold/settlement implementation and its exact host ordering;
• a selected Rust representation for ActivationPermit, result authority, out-of-order activation joins, or asynchronous work;
• accepted and rejected interpreter traces;
• delivery settlement/rejection realization for service or parent reports;
• deadline expiry, forced retirement, root residual settlement, or leak-free late-work ownership;
• wrapper composition or initialization-order proof;
• catalogue parity, builder syntax, compiler/DevX acceptance, or migration;
• edits to the locked kernel, legacy actors, macros, testkit, or interpreters.

Consequently this document is ready only to guide AA-02’s focused failing regressions and to be compared against production authority. It is not implementation evidence. “Ready for comparison and policy enrichment” later requires real Behavior/Actions integration, accepted and rejected interpreter traces, applicable catalogue parity, wrapper-composition proof, complete shutdown/residual ownership, and compiler and DevX acceptance.

If AA-02 through AA-06 cannot realize any table cell through the locked boundary, the experiment records that focused counterexample. It must not invent a parallel actor contract or silently weaken the table.

Fixed-supervisor falsification model

Status and authority

This document is the AA-10 independent semantic model for one fixed supervisor. It is a non-production falsification oracle. It does not select Rust types, define another behavior algebra, implement a supervisor, or mark a row in docs/engineering/atomic-actor-solution.md implemented. That document remains the production design authority.

AA-10 is blocked, not complete. The state and transition oracle requires typed child terminal/drain settlement to return an emitted install or replacement when the proxy terminates without its normal outcome, but the locked boundary has no implementation witness for that transfer yet.

Fresh allocation is the actor-model law used here: every stable proxy and every worker incarnation behind it is freshly established rather than written over an existing address. Creator-local child reservations, commit before dependent effects, exact installed capabilities, action settlement, activation authorization, and actor-graph drain are Bombay derivations or policy choices. Ordered semantic roles, stable proxies, recovery policy, and fixed-topology failure reaction are template laws.

Runtime route selection is owned normatively by docs/atomic-runtime-settlement.md. The supervisor issues and stores only a CreationId for each proxy creation; it never chooses or stores a runtime route before emitting CreateChild. Any older reservation label below denotes that creator-visible correlation before interpretation and routed evidence only in the returned runtime settlement. It does not authorize a separate route request, waiting state, or public route.

The model must falsify designs that make any of these claims false:

1. The roster is non-empty, ordered, and contains each semantic role once.
2. Each live role owns at most one exact stable proxy.
3. The supervisor consumes one atomic proxy outcome; it never reconstructs worker creation, initialization, activation, or readiness.
4. A role is advertised ready only after its exact proxy reports a successful initial or replacement outcome.
5. The configured positive activation bound limits unresolved proxy install/replace operations across the complete supervisor.
6. A recovery admission is selected from one immutable roster snapshot. The membership partition, prepared replacements, fallible correlations, and budget charge commit in one fold; failure before that fold changes none of them. Later cross-actor realization resolves each admitted participant independently.
7. Recovery timing, readiness, and activation authorization are independent prerequisites joined without flags.
8. Stale, duplicate, foreign, wrong-kind, and contradictory facts cannot advance a member or charge recovery twice.
9. Query is a total projection and cannot mutate topology, budget, recovery, authorization, or lifecycle ownership.
10. Shutdown closes recovery and drains every owned or still-creating proxy exactly once while leaving unrelated application children untouched.
11. Every accepted input produces one next state and one complete named action product. No effect is ambient.

“Atomic” means one local Behavior fold commits one supervisor state and its complete Actions. It does not claim atomic delivery, creation, or work across actors.

Model vocabulary

The following names describe the oracle. They are not proposed public Rust names.

Role = one semantic member label, unique inside this supervisor
RoleOrder = the declaration order retained for the supervisor lifetime

ProxyBirthAttempt = fresh non-reused CreationId issued by the supervisor
RoutedProxyBirth = interpreter-private { attempt: ProxyBirthAttempt, route }
ExactProxy = externally routable exact capability for one committed stable proxy
WorkerAttempt = opaque non-routable evidence for one started worker

OperationKind =
    Initial
  | Replacement { recovery: RecoveryTicket, replaces: WorkerAttempt }

OperationTicket = one affine ID paired with one private supervisor witness

ProxyControl =
    Start { definition, activation }
  | Replace { definition, activation }

OperationInput = {
    ticket: OperationTicket,
    kind: OperationKind,
    control: ProxyControl,
}

RecoveryTicket = fresh non-reused correlation for one complete recovery decision
RecoveryOrdinal = checked one-based lifetime recovery count of the triggering role
TimerCorrelation = { timer, generation }

RecoveryParticipant =
    Stopped {
        previous: WorkerAttempt,
        stop,
    }
  | Online { current: WorkerAttempt }
  | AwaitingInitial { phase: InitialPhase }

FailureReaction = RetireMember | StopSupervisor

ActorDrainPolicy =
    WaitForActorGraph
  | RetireActorGraphAfter { deadline }

DiagnosticDisposition =
    DeliverTo { route }
  | Terminate

LifecyclePublication =
    NotPublished
  | Published { route }

An attempt, ticket, timer generation, role, or child route is correlation, not actor identity or evidence of fresh allocation. Only committed creation yields an exact installed proxy. Sequence arithmetic, address reuse, timing, or adjacency cannot manufacture provenance.

Every payload named below is complete and owned. A state may retain an exact correlation after its value has moved into an action, but it cannot retain a second ownership claim on the moved value.

WorkerIncarnationEvidence is correlation and lifecycle provenance, not a recipient or transferable delivery capability. The proxy alone retains the routable worker capability. The only service capability the supervisor may publish or return is ProxyIncarnation, preserving the stable proxy as the one public communication path for the role.

OperationKind is supervisor settlement metadata. Only the matching concrete ProxyControl value is delivered to AA-01's private control protocol; the fixed supervisor does not widen the proxy message with its recovery ticket. The action settlement owns the metadata and control as one staged source-side product so rejection can return both without asking the proxy to echo either.

Construction domain

Worker-preparation correction

The original draft stored one callable factory and instructed the recovery transition to invoke it. That representation is rejected: application execution is not part of a pure Behavior transition. A callable used to prepare the initial roster is consumed before the supervisor exists and is not stored in the successful behavior.

Automatic recovery instead emits one typed batch worker-preparation action. Its accepted start settlement proves only that source work began. Its later typed result must return the complete worker-source authority, the ordered selected immutable role names, every WorkerSubmission, any exact rejection, and every untouched role name. Bombay interprets the statically selected capability; FixedSupervisor owns selection and the later state change. No callback, registry, erased response, or runtime lookup exists in Behavior.

H38 selects the typed batch action rather than a mandatory factory actor. The actor alternative adds a delivery settlement and later reply join; delivery acceptance cannot mean workers were prepared. The action uses H35 source settlement directly. Bombay will implement its exact static interpreter and retirement transfer through the required generic runtime contract. The atomic implementation targets that contract and does not wait for the present Bombay API shape. The old callable instruction below is not an alternate accepted path.

The source contract is a method-free static declaration over the concrete role, worker, and activation-plan types. One non-empty action owns the complete selected immutable-name batch; it never owns the unique member-role authorities, which remain in the pending recovery. Bombay observes each name only as &Role. Its late result is exactly a complete prepared group, the prepared prefix plus a worker rejection and untouched suffix, or a source rejection before the first submission. Corruption and no-attempt remain generic start settlement alternatives; FixedSupervisor must not repeat them in another sum.

One complete definition contains:

FixedDefinition = {
    initial_factory: ConstructionOnly,
    roles: OrderedNonEmptyUnique<Role>,
    activation,
    activation_limit: PositiveMaximum,
    recovery: {
        eligibility,
        worker_source: OnlyWhenAutomatic,
        strategy,
        budget,
        timing,
    },
    failure_reaction: FailureReaction,
    actor_drain: ActorDrainPolicy,
    diagnostics: DiagnosticDisposition,
    lifecycle: LifecyclePublication,
}

Duplicate roles, an empty roster, invalid timing, a non-positive activation limit, and a rejected initial factory call are construction failures. The initial factory prepares every initial definition before the supervisor exists or any initialization action is emitted. A failure returns all still-owned inputs and identifies the exact role; it cannot leave a partially constructed behavior. Success drops the callable before producing the behavior.

Replacement definitions arrive only through the typed batch action above. A closed heterogeneous worker sum is valid only when every variant exposes one common concrete public protocol. Different public protocols are different supervisors, not one erased envelope.

The canonical recovery value is constructed as Recovery::permanent(source, strategy, limit, release), Recovery::transient(source, strategy, limit, release), or Recovery::temporary(). The first two variants own the concrete source that crosses the worker-preparation action. The temporary alternative has no source, strategy, limit, or release field and requires no placeholder or annotation.

Lifecycle publication is genuinely optional. NotPublished constructs no event and requires no dummy route. Diagnostics remain mandatory through the independent DeliverTo | Terminate choice.

Every selected route retains its concrete logical, established, or mixed capability form and its corresponding static hosting obligations. The model does not normalize those routes into one runtime-selected envelope.

AA-10 deliberately selects no builder, typestate marker, callback, trait, or finished behavior spelling.

Normalized supervisor state

SupervisorState =
    Operating {
        definition,
        fleet: FixedFleet,
        budget: BudgetState,
    }
  | Draining {
        definition,
        fleet: DrainingFleet,
        budget: BudgetState,
        deadline: DeadlinePhase,
    }
  | Stopped

FixedFleet is one order-preserving partition of the declared roles. Each role has exactly one topology authority, held either by an independent Member or by one participant in exactly one RecoveryBatch. The immutable role value is allocated once. Lifecycle events, diagnostics, and an emitted worker-preparation action may retain read-only role names, but those names cannot select, move, recover, or retire a member. The application-facing values expose &Role, not the private shared representation. RecoveryBatch and its participants are one dependent semantic value: there is no separately mutable member map plus batch map whose flags may disagree. A later Rust experiment must find a concrete representation that preserves this equation.

The configured activation maximum is immutable. Occupancy is not a second counter: every occupied slot is owned by exactly one initial operation or one replacement whose input or proxy outcome is still pending. An exact proxy outcome releases the slot even when the predecessor stop is still outstanding. Capacity is the count of those exact unresolved operations. Waiting roles are discovered from RoleOrder, so a separate queue cannot disagree with member state.

The budget stores only committed evidence inside its active inclusive window. It is bounded by the configured maximum; a maximum of zero stores no admitted charge and denies every otherwise eligible decision.

Complete independent-member sum

Member =
    CreatingProxy {
        role,
        reservation: ProxyReservation,
        initial: OperationInput,
    }

  | CreatingProxyAfterExit {
        role,
        reservation: ProxyReservation,
        initial: OperationInput,
        exit,
    }

  | Starting {
        role,
        proxy: ProxyIncarnation,
        phase: InitialPhase,
    }

  | Online {
        role,
        proxy: ProxyIncarnation,
        worker: WorkerIncarnationEvidence,
    }

  | Empty {
        role,
        proxy: ProxyIncarnation,
        previous: WorkerIncarnationEvidence,
        cause,
    }

  | Stopping {
        role,
        proxy: ProxyIncarnation,
        cause,
        phase: ProxyStopPhase,
    }

  | Retired {
        role,
        cause,
    }

InitialPhase =
    WaitingForAuthorization { input: OperationInput }
  | Dispatched {
        ticket: OperationTicket,
        settlement: InputSettlementCorrelation,
    }
  | AwaitingOutcome { ticket: OperationTicket }

ProxyStopPhase =
    ShutdownDispatched { settlement: ShutdownSettlementCorrelation }
  | AwaitingExit
  | Rejected { rejection }

Starting owns no worker incarnation. Its unresolved operation kind is always Initial. Empty is possible only after one installed worker has stopped or a replacement attempt against such a predecessor has failed. Failure before any worker installation is irrecoverable for the current proxy contract and therefore enters Stopping or whole-supervisor drain; it cannot manufacture an Empty predecessor.

Stopping preserves a rejected shutdown reason while still waiting for exact proxy exit. Rejection is not reclassified as a successful stop. Under RetireActorGraphAfter, the deadline may transfer the remaining ownership to the lifecycle host; under WaitForActorGraph, the member can wait forever.

The accepted-stop carrier owns the unchanged other members and one complete stopped member. Recovery eligibility borrows the stopped member's terminal outcome when choosing policy; it does not store a second normal/abnormal label beside the outcome that already determines it.

Recovery partition

An admitted recovery batch owns all selected member-role authorities as one value. Its preparation action may temporarily own read-only names for those same roles, never another topology authority:

RecoveryBatch = {
    ticket: RecoveryTicket,
    trigger: RosterPosition,
    release: RestartReleaseState,
    members: Vec<RecoveryMember>,
}

RestartReleaseState =
    Ready
  | Scheduling { correlation: TimerCorrelation, request_settlement }
  | Waiting { correlation: TimerCorrelation }

RecoveryMember =
    Waiting { participant, prepared_replacement }
  | Replacing { participant_identity, replacement: WorkerReplacement }

WorkerReplacement = {
    previous_worker,
    readiness,
    stopped: None | Some { complete_stop },
    response: ReplacementResponse,
}

ReplacementResponse =
    InputPending { witness }
  | OutcomePending { operation }
  | OutcomeReturned { complete_outcome }
  | InputRejected { complete_settlement }

RosterPosition is assigned once at roster construction and moves with the unique member authority. Admission proves that members is non-empty, contains each selected position once, and contains trigger. OneForOne selects one position, OneForAll selects every eligible position, and RestForOne selects the trigger position and its eligible suffix. Physical collection placement is not declaration order.

The trigger position remains after that participant returns independently. A return removes exactly one position from members and restores one independent roster owner; the recovery retires only when members becomes empty. This is the same one-collection ownership equation as H32/H32r. It needs neither a parallel recovery table nor a split recovery when a middle participant returns.

Every participant owns exactly one prepared replacement until it is emitted. After emission, WorkerReplacement stores two independent current values: the optional complete predecessor stop and the proxy operation's current response. An online participant has no stop; an already-stopped participant has one. The response changes from input pending to outcome pending only after the exact receipt, then to the complete returned outcome. Exact input rejection instead stores the complete settlement without erasing an already-owned stop. Operating recovery consumes a completed or rejected product immediately; shutdown may retain the same product while proxy retirement remains independent.

An AwaitingInitial subject owns the complete InitialPhase; the enclosing Waiting phase separately owns exactly one prepared replacement. It cannot issue replacement until the initial operation atomically reports a ready worker, providing the exact predecessor. Initial failure removes that participant through the configured topology-failure reaction; it never treats an initial-empty proxy as replaceable.

The stopped trigger begins with Some(complete_stop) and input pending; an online coordinated peer begins with no stop and input pending. A matching peer stop fills only the optional stop and cannot open another recovery decision. If the replacement outcome arrives first, OutcomeReturned retains it until the exact stop report or its typed delivery settlement closes the reunion. Thus stop and replacement outcome are order-independent and each is accepted once.

StableProxy and FixedSupervisor own different work here. StableProxy owns the worker shutdown-resolution and successor-start sequence and emits the exact predecessor WorkerStopped report before its later replacement outcome. FixedSupervisor owns admission of those two owner reports, lifecycle publication, recovery capacity, and the rule that replacement readiness is not published until both reports have been admitted. The supervisor never repeats StableProxy's worker-control sequence.

The triggering worker's stop classification is consumed when recovery disposition is chosen; its immutable roster position remains as the recovery's trigger identity. RecoveryOrdinal is consumed when the release is calculated. The committed budget charge remains solely in BudgetState, where the next admission needs it. None is copied into RecoveryBatch. Immediate release and an accepted exact timer both produce RestartReleaseState::Ready; their arrival history cannot change a later decision. Schedule rejection transfers the exact rejected request directly into the configured failure reaction and therefore is not a stored release phase.

Readiness is derived from the participant's current worker ownership, timing from the batch's current RestartReleaseState, and authorization from current activation occupancy. There is no stored cross-product of these prerequisites. The transition that sees all three immediately emits the replacement input and stores one WorkerReplacement with exact stop absence or presence and InputPending; a ready-to-issue phase is never committed between turns.

Recovery batches may overlap in time only when their selected role sets are disjoint. Exact recovery tickets distinguish them. A role already in any batch, stopping, retired, or awaiting an admitted replacement is not selectable by another batch.

Complete input sum

Inputs arrive through distinct concrete protocol lanes.

Management input

Management =
    QueryStatus { reply_to }
  | QueryCapability { role, reply_to }
  | Shutdown

Query routes are temporary reply capabilities. They never become durable lifecycle or diagnostic owners.

Stable-proxy lifecycle input

ProxyBirthResult =
    FoldRejected { reservation, proxy_definition, error }
  | HostRejected { reservation, proxy, init_actions, reason }
  | Committed { reservation, proxy: ProxyIncarnation }

ProxyInputResult = ActionItemResult<
    ProxyOperation,
    ProxyInputReceipt { proxy: ProxyIncarnation, ticket: OperationTicket },
    ProxyInputRejection,
    Never,
>

ProxyReport =
    InitialInstallation { outcome }
  | Replacement { outcome }
  | WorkerStopped { stop, observed_at }
  | Unavailable { sender, phase, command }

ProxyExit =
    BeforeBirth { reservation: ProxyReservation, exit }
  | AfterBirth { proxy: ProxyIncarnation, exit }

ProxyShutdownSettlement =
    Accepted { proxy: ProxyIncarnation, correlation }
  | Rejected { proxy: ProxyIncarnation, correlation, request, reason }

The generic result owns whether interpretation was attempted. Acceptance owns only the receipt promised by the request. Rejection and corruption return the complete ProxyOperation; an unattempted result retains it unchanged. There is no supervisor-specific result sum or conversion seam.

ProxyReport is always accompanied by its exact child-source capability. The source capability, expected pending operation kind, and the replacement outcome's nested exact replaces: WorkerIncarnationEvidence together provide report correlation. That evidence must equal the participant's retained prior evidence. An initial operation occurs at most once for one exact proxy, and each later replacement names a fresh predecessor, so a delayed earlier report cannot satisfy a later pending operation. The supervisor does not add its operation or recovery ticket to AA-01's flat four-variant proxy report. Install/replace settlement is discharged before a later report from that input, so Dispatched -> AwaitingOutcome -> report is a causal Bombay interpreter policy, not an inference from arrival timing.

Recovery and drain input

RestartScheduleSettlement =
    Accepted { recovery: RecoveryTicket, timer: TimerCorrelation }
  | Rejected {
        recovery: RecoveryTicket,
        timer: TimerCorrelation,
        request,
        reason,
    }

RestartElapsed = { recovery: RecoveryTicket, timer: TimerCorrelation, observed_at }

DrainDeadlineSettlement =
    Accepted { timer: TimerCorrelation }
  | Rejected { timer: TimerCorrelation, request, reason }

DrainDeadline = { timer: TimerCorrelation, observed_at }

ActionSettlement = one closed lane-specific accepted, rejected, or
not-attempted settlement from the current action product

Workers and callers cannot author observed_at. The interpreter's monotonic clock supplies it with the authoritative stop or timer fact. A regressing clock fact is a typed rejection and cannot prune future evidence.

Unexpected input

UnexpectedInput = { input: FixedSupervisorEvent }

A mismatched input moves complete into one diagnostic outcome. The exact expected route, proxy, operation, recovery, or timer authority remains solely in current supervisor state. Copying it into the diagnostic would duplicate admission authority; moving it would contradict unchanged-state preservation. The unexpected input is not dropped, reinterpreted, or converted into Behavior::Error merely because it was unexpected.

Public projections

Status is a total read-only projection in declaration order:

MemberStatus =
    CreatingProxy
  | WaitingForActivationAuthorization
  | AwaitingProxyOutcome
  | Ready { proxy: ProxyIncarnation }
  | Empty
  | Recovering
  | Stopping
  | Retired

CapabilityResult =
    Ready { role, proxy: ProxyIncarnation }
  | Unavailable { role, phase }
  | UnknownRole { submitted_role }

The projections are exact:

The supervisor never reports proxy-private worker-creation, initialization, or activation phases. Query emits one management reply and leaves the complete state byte-for-byte semantically unchanged. Reply rejection belongs to action settlement and cannot mutate the snapshot that was already produced.

Production witness H121 realizes this table directly from the current roster owners. It sorts status by immutable roster position and scans capability by borrowed role equality. Logical and exact reply routes select two named lanes in the ordinary action product; no copied roster, lookup table, query actor, or template-specific interpreter exists.

Production witness H123 realizes the exact initial-failure StopSupervisor row through the ordinary FixedShutdown transition. It emits one failure diagnostic, stops only committed proxies, retains pending proxy creations, and makes repeated shutdown idempotent. It adds no alternate drain state or response product.

Lifecycle and diagnostic values

LifecycleEvent =
    Started { role, proxy: ProxyIncarnation }
  | Restarted {
        role,
        proxy: ProxyIncarnation,
        recovery: RecoveryTicket,
    }
  | WorkerStopped { role, stop, disposition }
  | Unavailable { role, sender, phase, command }
  | MemberRetired { role }

RecoveryDisposition =
    Ineligible
  | Admitted { recovery: RecoveryTicket }

RecoveryDenialReason =
    RecoveryTicketsExhausted
  | RestartTimersExhausted
  | RestartLimitReached { active, requested, maximum }
  | ClockRegressed { previous, observed }
  | RecoveryCountExhausted { admitted }
  | ReleaseCalculationFailed { reason }

OperationalDiagnostic =
    WorkerPreparationFailed {
        trigger,
        prepared,
        reason,
        remaining,
    }
  | RecoveryDenied { trigger, stop, reason: RecoveryDenialReason }
  | ProxyCreationRejected { role, rejection }
  | ProxyInputRejected { role, input, reason }
  | ProxyOutcomeFailed { role, outcome }
  | ProxyDied { role, exit }
  | ProxyShutdownRejected { role, proxy, request, reason }
  | UnexpectedInput { input: FixedSupervisorEvent }
  | ForcedRetirement { role, residual, cause }

FactoryRejected is construction custody, not an operational diagnostic: the construction-only callable is consumed before a successful Behavior exists. WorkerPreparationFailed is emitted only after an operating recovery action returns its source. It retains the prepared prefix and untouched roles but not the reusable source authority.

Started and Restarted exist only after the exact atomic proxy-ready outcome. They expose the stable proxy capability and no worker recipient or worker evidence. Committed proxy creation, accepted proxy input, and a worker creation fact hidden inside the proxy cannot fabricate either event. The supervisor retains WorkerIncarnationEvidence privately for correlation. A replacement failure is never Restarted.

MemberRetired reports the durable topology change and carries only the role. The exact operational diagnostic emitted before the configured failure reaction is the sole owner of why retirement began. Repeating a summarized cause in the lifecycle value would create a second authority; labeling shutdown or deadline arrival as that cause would retain transition history rather than current topology. Forced actor-graph retirement remains a distinct runtime-custody diagnostic and does not fabricate MemberRetired.

RecoveryDenied is the sole observable owner of both the triggering stop and the exact denial reason. Repeating the reason in lifecycle output would create a second semantic cause. A rejected recovery therefore constructs no WorkerStopped lifecycle event: lifecycle owns ineligible and admitted stops; the operational diagnostic owns rejected recovery.

The Rust realization uses this one RecoveryDenialReason sum in restart admission and stores that same value with the complete triggering worker stop in RecoveryDenied. Public inspection borrows both values; a second private six-way sum or variant-for-variant diagnostic conversion is not part of the law. The post-denial topology retains a stop-less trigger and the unissued prepared workers separately. A later restart-schedule rejection is different: its diagnostic owns the rejected timer request, so topology continues to own the worker stop. Both paths use the same topology reaction only after that ownership distinction has been made.

If lifecycle publication is NotPublished, lifecycle events are not built and no discard operation occurs. Diagnostics always follow the selected disposition. DeliverTo emits one delivery; rejection becomes one terminal UndeliverableDiagnostic. Terminate emits the diagnostic directly to terminal settlement and selects Stop after preserving every other action in the turn. Neither path recursively diagnoses diagnostic rejection.

Required semantic action product

The governing solution names these fixed-supervisor lanes:

proxy_creations
proxy_creation_observations
proxy_stop_observations
proxy_install_inputs
proxy_replacement_inputs
proxy_shutdowns
worker_preparations
restart_schedules
lifecycle_events
management_replies
terminal_diagnostics
delivery_rejections

This is the semantic lane inventory, not a second interpretation-order specification. The generic ordering rule is owned by atomic-runtime-settlement.md: among the currently retained fixed-supervisor lanes, worker preparation precedes proxy operations, which precede restart scheduling, lifecycle publication, management replies, and diagnostics. Adding a missing lane must preserve that relative order and the creation-dependency rules above.

The oracle requires those operations plus a truthful representation of a route-delivered operational diagnostic. terminal_diagnostics can represent Terminate but cannot by itself represent DeliverTo(route), and lifecycle_events cannot own diagnostics because lifecycle publication is optional. Until an existing concrete product is proven to carry both choices without reinterpretation, the minimum model product treats this as one closed semantic lane:

diagnostics =
    Deliver { route, diagnostic }
  | Terminal { diagnostic }

delivery_rejections denotes the closed interpreter settlement product, not a catch-all message envelope. An input rejected by the supervisor becomes an OperationalDiagnostic::UnexpectedInput; rejection of an emitted action arrives through its lane-specific settlement. These are different laws.

This diagnostic-product mismatch is a falsification finding, not a production API amendment. A later executable task must reconcile the solution, matrix, retained-core decision, and research audit before adding a production lane.

The fold still returns the real Actions with its next behavior or terminal decision. Creation commits before same-action observations or proxy input. Within one recovery release, replacement inputs are emitted in declaration order. Diagnostics are emitted before a terminal verdict in the same action. The interpreter order and every accepted, rejected, or not-attempted settlement remain focused proof obligations.

Ownership table

Transition notation

The matrices use these cells:

• Q: emit the total status or capability reply and preserve state.
• S0: close admission, cancel un-emitted recovery work, and enter one drain.
• S=: shutdown is already active; preserve the drain and emit no duplicate shutdown or deadline request.
• PB, PE, IS, PR, PS, RS, TF, DDS, DF, SET: apply the matching proxy-birth, proxy-exit, input-settlement, proxy-report, proxy-shutdown, restart-schedule, timer, drain-deadline-schedule, deadline, or lane-settlement rule.
• F-: preserve the semantic state and emit exactly one complete unexpected-input diagnostic through the configured disposition.
• NA: Stopped admits no mailbox input; late settlement belongs to the surviving lifecycle host.

All runtime-input cells require exact expected source, kind, operation, and correlation for admission. Every mismatch is F-. F- continues only under successful diagnostic delivery. Terminate or an undeliverable diagnostic preserves other actions and selects terminal settlement as specified above.

Total supervisor-mode matrix

Queries remain available during orderly drain and show Stopping or Retired. DrainDeadline* in Operating and a recovery timer with no exact batch are F-. Late recovery facts during Draining settle or diagnose the cancelled exact batch but cannot emit a replacement.

Total operating-member matrix

Nested phase rules below exhaust each non-empty cell. The five Needs* row labels are readable projections of WorkerReplacement's stop/response product, not five separately stored Rust alternatives.

The exact proxy source is checked before report kind. A report from another owned role is foreign to this member and cannot be redirected by equal payload shape. An unowned application child never enters this matrix.

Initialization and proxy creation

Initialization reserves every ProxyReservation and pairs one affine initial OperationTicket with one private witness per role in declaration order before emitting the first creation. Each retained initial OperationInput owns that ticket. Pair allocation is fresh by construction: another reservation cannot collide with it, and process-wide allocation failure is not relabelled as a supervisor rejection. If any proxy-route reservation rejects, every locally paired operation is retired, the complete ordered initial set is returned, and no proxy creation, observation, input, or partial fleet is emitted. Otherwise one creation bundle per role contains:

1. the fresh stable-proxy creation;
2. exact creation observation;
3. exact established-capability observation; and
4. exact termination observation.

This is a Bombay staged-creation policy and a future real-boundary proof obligation, not a general actor-model guarantee.

An emitted proxy operation retains its private witness only until one exact settlement is admitted. Admission consumes the witness's correlation authority. An accepted settlement retains the operation ID only when a later exact proxy outcome requires it; a rejected, corrupt, or unattempted settlement already owns the complete operation and ID. Retaining the consumed witness beside that settlement would store arrival history rather than current authority. Foreign settlement admission returns the witness and complete settlement unchanged. Roster search attempts this affine admission in declaration order and restores every declined member to the same position without allocation or a separate owner query.

For an exact ProxyBirthResult:

• Committed enters Starting(WaitingForAuthorization) with the exact proxy and retained initial input. It does not consume activation capacity merely because the proxy exists.
• FoldRejected or HostRejected retains the complete initial input and applies the configured topology-failure reaction. RetireMember enters Retired because no proxy exists. StopSupervisor starts global drain.
• In CreatingProxyAfterExit, rejection plus authoritative exit is one contradiction retaining both facts. Commit proves an installed but already terminal proxy and retires that role or begins whole-supervisor drain; it never sends the initial input.

An exact ProxyExit::BeforeBirth changes CreatingProxy to CreatingProxyAfterExit. An AfterBirth exit for the exact live proxy is handled by the stable-proxy-death reaction. RetireMember preserves the exact cause and removes only that role from live topology; StopSupervisor begins global drain. No worker failure is inferred from proxy death.

If proxy exit races an emitted initial or replacement operation, the exit atomically transfers that operation's input/report settlement to the surviving lifecycle host and releases its activation slot by transfer, not by pretending an atomic proxy outcome arrived. The affected participant leaves its recovery batch. The complete exit moves into the ProxyDied diagnostic settlement; the retired member retains only exact terminal correlation. Any later proxy report or rejected-report settlement meets that same host-owned exit and is returned as one contradiction retaining both facts. The actor does not clone the exit into state or forget the pending operation merely to retire quickly.

This host-transfer equation is required for totality but remains an open shared-settlement realization. An executable prototype must prove that the locked interpreter can perform the transfer; otherwise the focused finding is recorded rather than replaced by a mailbox flag.

After every transition that releases activation capacity, the supervisor scans waiting roles in declaration order. It reserves at most the remaining positive capacity and emits each eligible initial or replacement input in that same order. Reservation and emission are one commit.

Initial operation settlement and outcome

Authorization changes:

Starting(WaitingForAuthorization { input: { ticket, kind, control } })
    -> Starting(Dispatched { ticket, settlement })
       + proxy_install_inputs(control)
         whose source settlement owns { ticket, kind, control }

The complete input leaves state. The fold consumes its already-reserved ticket; authorization never performs a new fallible correlation allocation. Exact settlement then follows:

• Accepted changes Dispatched to AwaitingOutcome; the operation ticket remains occupied.
• Rejected releases the ticket and returns the exact input. It emits one ProxyInputRejected diagnostic and applies the configured failure reaction. There is no automatic retry.
• A proxy outcome before accepted settlement is F-; the interpreter must discharge install settlement before making the later child report admissible.

In AwaitingOutcome, an exact InitialInstallation result releases the operation ticket:

• Ready { worker } stores that opaque evidence in Online and, when selected, emits Started { role, proxy }.
• Any complete non-ready result is retained inside ProxyOutcomeFailed, then applies RetireMember by draining the still-live proxy or begins whole-supervisor drain. It never emits Started.

An Unavailable report from the exact owned proxy is expected in every live non-retired member phase. It is relayed as one lifecycle event when publication is selected, preserving role, sender, proxy phase, and command. Without lifecycle publication, the same complete value is an operational diagnostic; it is never discarded. This is a deliberate model policy required to preserve the command obligation when no lifecycle consumer exists.

Recovery admission

Only an exact WorkerStopped from Online can trigger automatic recovery. It first produces the semantic Empty subject, then evaluates one transaction from the pre-transition fleet snapshot:

1. classify the complete stop as normal or abnormal;
2. apply permanent, transient, or temporary eligibility;
3. select one-for-one, one-for-all, or rest-for-one roles in declaration order;
4. reject every role already recovering, stopping, retired, or owned by an admitted replacement;
5. include an initially unresolved role required by a coordinated strategy as AwaitingInitial rather than pretending it is ready;
6. reserve one exact batch-preparation correlation, emit the typed ordered worker-preparation action, and enter the pending preparation phase;
7. join its exact source settlement, retaining the source authority, every prepared submission, every selected role, and any rejection;
8. reserve the recovery ticket, one operation ticket per selected replacement, and every fallible timer correlation;
9. prune budget evidence at the interpreter-authored stop time using an inclusive window;
10. reject clock regression explicitly;
11. validate the complete multi-role budget charge;
12. compute the checked one-based delay from the triggering role's next admitted RecoveryOrdinal; and
13. commit the membership partition, prepared ownership, exact correlations, budget charge, and resulting actions in one transition.

Steps 1–5 are pure local preparation. Step 6 commits only the pending preparation phase and its action. Steps 8–13 occur only after the exact batch settlement succeeds. Failure changes no peer, emits no replacement, and charges no budget. The trigger's authoritative stop has still occurred; the configured failure reaction applies to that exact now-empty role.

Every selected replacement receives one new affine operation pair before the recovery commits. A pair cannot equal another live or retired pair. The complete ordered candidate set therefore has no operation-allocation rejection case; worker preparation, recovery/timer correlation, budget, and checked release remain the fallible pre-commit decisions.

The delay ordinal is deliberately the triggering role's admitted recovery ordinal. Selected peers do not combine their unrelated history into one delay. This fills a policy choice left implicit by the governing documents and must be compared before production work.

No source selects a reset rule. Bombay therefore preserves the triggering role's lifetime admitted count and advances it with checked arithmetic. Exhaustion is RecoveryCountExhausted { trigger, admitted }; it does not wrap, saturate, panic, reset implicitly, or masquerade as delay arithmetic overflow. This is a deliberate Bombay representation policy, not an actor-model guarantee.

Eligibility is total:

Ineligible termination is not topology failure. The exact role remains Empty behind its live stable proxy and no recovery budget is charged. This is the AA-10 policy selected for the feature catalogue's previously open “retires or leaves empty” choice. It allows status to distinguish an intact but unavailable role from a lost proxy. Only explicit proxy/topology failure uses FailureReaction.

When lifecycle publication is configured, the exact ineligible stop moves into the role's WorkerStopped { disposition: Ineligible } event. The durable Empty role then owns no second stop. When publication is omitted, no lifecycle event is constructed and the explicit omission policy discharges the already classified stop. Empty retains no historical report merely for a later shutdown. Ineligibility is not an operational failure and therefore does not manufacture a diagnostic merely to dispose of the stop.

Selection is total:

• one-for-one selects the triggering role;
• one-for-all selects every restartable role in the immutable snapshot;
• rest-for-one selects the trigger and every restartable role declared after it;
• an online peer contributes its exact current worker;
• the trigger contributes its exact stopped predecessor;
• an initial operation that was already admitted may contribute one AwaitingInitial participant;
• every other unresolved or terminal role is not restartable.

If a coordinated strategy requires an inadmissible role rather than one of the explicitly supported awaiting-initial phases, admission rejects the complete decision. It never silently shrinks the selected set.

Factory rejection identifies its role and returns every prepared peer definition. Budget denial reports active attempts, requested replacement count, and maximum. A maximum of zero denies every non-empty decision. Each admission appends one charge whose replacements equals participant count to the supervisor's BudgetState; the sum of active charge counts never exceeds the maximum. RecoveryBatch does not duplicate that evidence.

Recovery prerequisite transitions

Immediate timing starts in Ready. Delayed timing emits one exact schedule request for the batch. Schedule acceptance changes Scheduling to Waiting; rejection applies the topology-failure reaction to the trigger and returns every still-unemitted replacement. An exact timer input changes Waiting to Ready once. Stale, duplicate, wrong-generation, foreign, early, or regressing timer inputs are F-.

Replacement issue requires these three current truths:

• its exact predecessor/readiness prerequisite is satisfied;
• its batch release is Ready; and
• activation capacity is currently available.

Readiness and timing remain satisfied in their owning participant and release state. Capacity is derived afresh and is consumed only in the transition that issues the input, so no stored phase claims a slot before issuance. That transition consumes the prepared input's already-reserved OperationTicket, emits the complete replacement input, and stores NeedsReceipt for a stopped participant or NeedsReceiptAndStop for an online participant. No fallible correlation allocation remains after batch admission. A batch may issue several newly eligible participants in one turn only up to available capacity, in declaration order.

An AwaitingInitial participant continues to process its exact InitialPhase:

• accepted input settlement advances normally;
• a ready initial outcome emits Started, supplies the exact predecessor, satisfies readiness, and may issue replacement in the same fold;
• rejected input or non-ready atomic outcome cannot satisfy readiness. The participant leaves the batch and applies topology failure for that role;
• the remaining admitted participants continue. Already emitted replacements are not rolled back, because atomicity governed admission, not cross-actor completion.

The recovery batch retires only after every participant has left through a ready replacement, typed failure reaction, shutdown transfer, or forced retirement. Its ticket is never reused.

Replacement settlement and outcome

For an exact NeedsReceiptAndStop or NeedsReceipt participant:

• accepted settlement changes only the remaining requirements and retains its occupied operation ticket;
• rejected settlement releases the ticket, retains the complete input in one diagnostic, and applies topology failure to that role without retry.

An exact WorkerStopped for the owned predecessor is accepted in NeedsReceiptAndStop, NeedsStopAndOutcome, or NeedsStop. It removes only the stop requirement, may emit the optional lifecycle event, and never opens or charges another recovery decision. A duplicate or stop for another worker is F-.

For an exact NeedsStopAndOutcome or NeedsOutcome participant:

• every exact replacement outcome releases the activation ticket immediately;
• if worker stop is already owned, Replacement::Ready { worker } leaves the recovery batch, enters Online, and optionally emits one Restarted carrying the exact proxy and recovery ticket;
• if worker stop is still required, the complete result enters NeedsStop; readiness is not externally published until the matching stop report or its typed delivery settlement closes the join;
• after the join closes, every rejection, activation failure, pre-ready stop, or contradiction applies topology failure and never emits Restarted;
• an initial-installation report is wrong-kind even if its nested payload has the same worker type.

An exact WorkerStopped in NeedsStop closes the reunion and applies the retained outcome once. Rejection of the stop report delivery closes the same semantic join through lane settlement while preserving the rejected report with the lifecycle host; it cannot fabricate a successful stop event.

Operating recovery consumes a terminal WorkerReplacement immediately through one exhaustive replacement disposition. A ready outcome plus the exact stop is Restarted; a non-ready outcome plus the exact stop is ProxyFailed; an input rejection is InputRejected; every other current combination remains Waiting. This disposition is a transition result, never another stored member phase. It retains complete stop, outcome, or rejected-input ownership and chooses no diagnostic disposition, topology reaction, lifecycle route, or action. Shutdown retains the unchanged WorkerReplacement instead: retirement requires both proxy retirement and return of the emitted replacement input or outcome.

The transient terminal values preserve ownership explicitly. Restarted and ProxyFailed carry StoppedWorker { readiness, stop }; InputRejected carries RejectedReplacement { previous, readiness, stopped, operation, returned_worker }. The aggregate then consumes those values once. Success moves the successor's attempt/readiness into Online; predecessor readiness is discharged only after the exact stop has joined. Failure moves predecessor attempt/readiness into the selected member-retirement or supervisor-drain reaction. When lifecycle publication is configured, the exact stop moves into WorkerStopped; otherwise a failed replacement retains it with retirement ownership. There is no separate stop-presence flag or duplicated stop claim.

For successful replacement with lifecycle publication, WorkerStopped precedes Restarted in the declared lifecycle lane. Omitted publication constructs no lifecycle value. Input rejection and non-ready proxy outcome construct exactly one complete operational diagnostic and apply the configured topology reaction; neither can fabricate Restarted. Removing a terminal participant releases its operation occupancy and allows the existing declaration-order authorization transition to consider the next waiting participant in the same turn.

An exact spontaneous WorkerStopped opens a new recovery only in Online. While RecoveryMember::Waiting still owns an online participant, its first exact stop changes that participant to stopped and does not open another batch. A second stop while the member is empty or recovering is stale unless it is the one explicit replacement reunion above. A stop of an unrelated peer that remains independent and online may trigger its own disjoint batch.

Failure reaction

Every topology failure first constructs one exact diagnostic. Then:

• RetireMember asks the exact live proxy to stop and enters Stopping; if no proxy was committed or it already exited, the member enters Retired directly. Shutdown settlement and exact proxy exit form one order-independent join. Accepted settlement retires its receipt; non-accepted settlement remains complete in the retired member after exact exit. Unrelated roles and disjoint recovery batches remain live.
• StopSupervisor begins the same global drain as management shutdown after preserving the diagnostic in that action.

Factory rejection, budget denial, checked-delay failure, schedule rejection, proxy creation rejection, proxy input rejection, failed atomic proxy outcome, and stable-proxy death enter this equation. Ineligibility does not.

If diagnostic disposition is Terminate, it dominates RetireMember: the diagnostic action selects terminal settlement and the lifecycle host owns the remaining fleet drain. This is not silently converted into the configured topology reaction. A production realization must reconcile the actor's immediate stop verdict with exact child ownership before claiming this path is implemented.

Shutdown normalization

The first Shutdown atomically:

1. closes management mutation and recovery admission;
2. logically cancels every un-emitted prepared initial/replacement input;
3. preserves emitted input settlement and atomic-outcome ownership;
4. cancels delayed recovery batches so no later timer can issue work;
5. transforms every member into one exhaustive drain member;
6. emits at most one shutdown request for every exact installed proxy;
7. retains every pending proxy creation until it resolves; and
8. for deadline policy, reserves and emits one exact drain timer.

The drain partition is:

DrainMember =
    ResolvingProxyBirth {
        role,
        reservation: ProxyReservation,
        retained_initial,
        prior_exit: NoExit | Exited { exit },
    }

  | DrainingProxy {
        role,
        proxy: ProxyIncarnation,
        outstanding: ProxyOutstanding,
        phase: ProxyStopPhase,
    }

  | Drained {
        role,
        result: Graceful | Absent | Forced { residual },
    }

ProxyOutstanding =
    Idle
  | InitialWaiting { input: OperationInput }
  | InitialEmitted { ticket, settlement_or_outcome }
  | RecoveryWaiting { recovery, prepared }
  | ReplacementEmitted { recovery, ticket, settlement_or_outcome }

These variants own the complete values that were local at shutdown. There is no pending flag and no attempt to reconstruct an emitted input. Recovery batches dissolve into their per-proxy outstanding ownership plus cancelled timer settlement.

For ResolvingProxyBirth, exact rejection enters Drained(Absent) and creates no proxy. Exact commit emits one shutdown for the installed proxy and enters DrainingProxy. Commit after an authoritative pre-birth exit records a contradiction and counts the already terminal proxy drained; it cannot send to the dead proxy.

For DrainingProxy, shutdown settlement rejection stores the complete request and reason in ProxyStopPhase::Rejected while the exact exit observation remains live. It does not count as drained. An exact proxy exit consumes every outstanding operation through the child's typed drain settlement, preserves its complete result with the lifecycle host, and enters Drained(Graceful). The normal proxy report lane is not required to fabricate an initial or replacement outcome during child shutdown.

This exact child-drain settlement is a model requirement exposed by AA-01 and remains an open real-boundary proof obligation. If the interpreter cannot return emitted install/replacement ownership when the child suppresses normal parent reports during shutdown, later prototype work must record the focused kernel gap rather than drop the operation ticket.

Repeated shutdown is S=. It emits no duplicate proxy shutdown or deadline. Late restart timers and schedule settlements can settle cancelled requests but cannot restore a RecoveryBatch or emit replacement.

Deadline drain

DeadlinePhase =
    WaitingWithoutDeadline
  | Scheduling { timer, settlement }
  | Waiting { timer }
  | Fired { timer, observed_at }

WaitForActorGraph uses WaitingWithoutDeadline and may wait indefinitely. RetireActorGraphAfter uses exact interpreter-authored monotonic time. Wrong, duplicate, stale, early, or regressing deadline facts are F-.

Exact deadline-schedule acceptance changes Scheduling to Waiting. Exact rejection cannot silently weaken RetireActorGraphAfter into an unbounded wait. In the rejecting fold, every unresolved member moves to Drained(Forced { residual }); the residual preserves the complete rejected request, timer correlation, capability reason, and every other outstanding ownership claim. The rejection is the forced-retirement cause and transfers directly to the surviving lifecycle host. Any operational diagnostic follows the selected disposition independently; its delivery cannot gate or undo the forced transfer.

When the exact deadline fires, the aggregate atomically selects forced retirement for every unresolved DrainMember. Its terminal ownership must contain the role, proxy or reservation, current semantic phase, every outstanding operation/timer/action settlement, and cause. The implementation may project this as Drained(Forced { residual }) per member or retain the complete stopped supervisor plus its exact deadline cause; it must not store both. Ownership transfers to the surviving lifecycle host. No accepted shutdown, proxy exit, worker readiness, successful restart, or normal lifecycle event is fabricated.

The supervisor selects normal actor termination only when every member is Drained and every action in the final transition has a settlement owner. A forced actor-graph summary is not the application result: the live root remains in residual settlement until late activation, proxy, and delivery ownership resolves.

Unrelated application children and application births never enter DrainingFleet, are never queried, and are never stopped by this actor.

Stale, overlap, and contradiction laws

• A proxy birth or exit advances only the role owning its exact reservation or installed capability.
• An install/replacement settlement advances only its exact role, proxy, operation ticket, and expected dispatched phase.
• An atomic proxy report advances only the exact child source and expected operation kind. Nested payload similarity cannot substitute for kind.
• A duplicate report after its operation ticket released is rejected and cannot release another slot.
• A worker stop outside Online cannot start recovery.
• One role cannot join two recovery batches. Overlap rejects the new complete decision before factory results, budget, or peers commit.
• A timer fact advances only its exact recovery ticket and timer generation.
• Proxy creation rejection plus authoritative exit is a contradiction retaining both facts. Commit plus prior exit retires the exact dead proxy.
• A report claiming readiness from a proxy already authoritatively stopped is a contradiction, never a transient Started/Restarted.
• A delivery rejection cannot roll back an already committed member or budget transition. Its lane-specific payload moves to settlement.
• Diagnostic delivery rejection is terminal and non-recursive.
• No stale or contradictory input is consumed merely to make a later fact easier to accept.

Feature-catalogue trace

Every family remains a model claim, not implementation or verification status. Open shared settlement, diagnostic, activation, terminal-lift, and deadline mechanisms keep their dependent production coverage rows open.

Independent-model obligations

AA-10 defines the oracle structure for later tests. The executable model must not copy the implementation branch structure. It should use independent vocabulary such as roster cells, admitted recovery batches, occupied permits, and drain obligations, then compare complete traces.

At minimum later tasks must cover:

• empty and duplicate-role construction rejection;
• initial proxy creation in declaration order and partial-preparation failure;
• proxy exit before/after birth resolution;
• positive activation bounds of one and two with declaration-order release;
• foreign, duplicate, and stale initial or replacement operation IDs, including proof that every new operation pair differs from every earlier pair;
• accepted and rejected install settlement before atomic proxy outcome;
• total query projections in every member phase;
• lifecycle and capability projections that expose only the stable proxy as a service capability;
• permanent/transient/temporary eligibility for normal and abnormal stops;
• one-for-one, one-for-all, and rest-for-one selection from immutable snapshots;
• unresolved-initial participants and overlapping failure rejection;
• zero budget, inclusive window boundary, pruning, multi-role atomic charge, and clock regression;
• immediate, constant, linear, and exponential timing, checked overflow, and all eight readiness/timer/authorization gates;
• factory rejection at every selected position with no peer mutation;
• stale/duplicate/foreign report, timer, exit, and settlement facts;
• lifecycle omitted versus delivered and both diagnostic dispositions;
• shutdown from every member phase, creation/exit ordering, rejected child shutdown, rejected deadline scheduling, late timers, and forced residual transfer; and
• complete named actions and accepted/rejected interpreter settlement.

First-slice non-features and open findings

AA-10 intentionally does not provide:

• Rust supervisor, fleet, recovery, builder, protocol, event, or effect types;
• an executable fold or independent model implementation;
• a shared recovery framework or reuse of dynamic-supervisor/pool state;
• proxy-private worker creation, initialization, activation, or worker routing;
• an interpreter for activation capacity, delivery settlement, timers, diagnostics, deadlines, or residual root ownership;
• wrapper-composition, initialization-order, compiler/DevX, or migration proof;
• a capability-safe heterogeneous public-protocol supervisor; or
• edits to the locked kernel, legacy actors, macros, testkit, or runtime.

The model records four findings requiring later comparison:

1. the governing documents leave ineligible fixed members “retired or empty” without a selected construction policy; this oracle deliberately leaves an intact live proxy Empty;
2. delayed coordinated recovery does not state which member history determines its one-based delay; this oracle uses the triggering role's admitted recovery ordinal;
3. the named fixed-supervisor effect product has terminal diagnostics but no explicit route-delivered diagnostic operation even though lifecycle publication is optional; and
4. normal proxy death or shutdown with an emitted install/replace operation requires a typed child terminal/drain settlement that returns outstanding ownership even when no normal proxy outcome can reach the supervisor.

These are falsification results, not changes to production authority. Before an executable task relies on any new mechanism, the solution, matrix, retained-core decision, and research audit must be reconciled together or the existing real boundary must be proven to express the same law unchanged.

This blocked specification may be compared with the independent dynamic supervisor, FIFO pool, and keyed pool models, but no comparison may treat its child-terminal settlement requirement as implemented or extract machinery from that assumption. It does not make AA-11 eligible: executable fixed supervision depends on AA-07's completed proxy boundary audit and eventual AA-10 closure.

Dynamic-supervisor falsification model

Status and authority

This document is the AA-20 independent semantic model for one dynamic supervisor. It is a non-production falsification oracle. It does not select Rust types, define another behavior algebra, implement a supervisor, or mark a production coverage row implemented. docs/engineering/atomic-actor-solution.md remains the production design authority.

Fresh allocation is the actor-model law used here: every accepted entry owns a fresh stable proxy, and every worker behind that proxy is a fresh actor. Creator-local creation correlations, exact capability settlement, operation tokens, generation-safe key reuse, activation authorization, and actor-graph drain are Bombay derivations or policy choices. Bounded keyed membership, explicit management operations, one durable lifecycle owner, unexpected-exit handling, and phase-sensitive cancellation are dynamic-supervisor template laws.

Runtime route selection is owned normatively by docs/atomic-runtime-settlement.md. An accepted start issues and stores one CreationId for its proxy; it never chooses or stores a runtime route before emitting CreateChild. The generic creation settlement returns that exact correlation and every rejected value. There is no separate route request, waiting state, public route, or dynamic-supervisor-specific creation result.

The model is deliberately not a fixed supervisor with an optional role list. It contains no worker factory, fixed roster, restart eligibility, restart strategy, restart budget, or backoff policy.

The model must falsify designs that make any of these claims false:

1. The configured positive entry limit bounds every retained entry, including entries still creating, cancelling, draining, or retiring.
2. A semantic key is management identity only. It is never converted into a proxy route, nonce, incarnation, or proof of freshness.
3. Every accepted start reserves one fresh entry generation, proxy creation ID, cancel authority, and initial-operation correlation before commitment.
4. Admission and realization are distinct. StartAccepted and ReplaceAccepted never claim readiness.
5. The stable proxy is the only externally routable service capability. Worker incarnation evidence is opaque and non-routable.
6. At most one management mutation owns an entry at a time. Every submitted worker definition is either locally owned, transferred once, returned once, or held by exact settlement ownership.
7. Request reply routes are temporary. One mandatory durable lifecycle route owns later realization, unavailability, cancellation completion, and retirement facts.
8. Cancellation is exact and phase-sensitive. It cannot claim that emitted creation, delivery, initialization, or activation work was physically cancelled.
9. Removing an entry releases capacity only after every exact outstanding fact and action settlement transfers or resolves. Reusing its key receives a fresh generation and fresh proxy creation ID.
10. Stale, duplicate, foreign, wrong-generation, wrong-operation, wrong-kind, and contradictory inputs cannot mutate a current entry.
11. Query is a total read-only semantic projection and never exposes private definitions, routes, tokens, or proxy-private phases.
12. Global shutdown closes mutation and drains every retained or still-creating entry exactly once while preserving request, lifecycle, diagnostic, and residual ownership.
13. Every accepted input produces one next state and one complete named action product. No effect is ambient.

“Atomic” means one local Behavior fold commits one supervisor state and its complete Actions. It does not claim atomic delivery, creation, cancellation, or work across actors.

Model vocabulary

The following names describe the oracle. They are not proposed public Rust names.

Key = application-authored semantic management key
EntryGeneration = fresh non-reused supervisor correlation for one accepted key use
EntryIdentity = { key, generation: EntryGeneration }

ProxyBirthAttempt = fresh non-reused CreationId issued by the supervisor
RoutedCreation = the existing interpreter-private route selected for that CreationId
ProxyIncarnation = externally routable exact capability for one committed stable proxy

WorkerIncarnationEvidence = opaque non-routable provenance for one installed worker
WorkerSubmission = complete owned worker definition and activation work for one attempt

OperationKind = Start | Replace
OperationCorrelation = fresh non-reused checked operation identity and admission order
CancelAuthority = opaque caller-held capability for one OperationCorrelation
OperationEvidence = opaque non-cancelling projection used in durable events
ProxyOperationWitness = private affine authority retained before one emitted
    proxy input settles
ProxyOperationId = opaque affine correlation returned only after that exact
    proxy input is accepted

PreparedProxyInput =
    Initial { worker: WorkerSubmission }
  | Replacement { worker: WorkerSubmission }

DefinitionOwnership = Present { worker: WorkerSubmission } | Transferred

StopCorrelation = fresh non-reused correlation for one explicit entry stop
ShutdownCorrelation = structural exact { EntryIdentity, ProxyIncarnation }
DeadlineCorrelation = { timer, generation }

Key, EntryGeneration, operation correlations, proxy-operation IDs, attempts, timer generations, and child routes are correlation—not actor identity. Only a committed creation yields ProxyIncarnation. Sequence arithmetic, address reuse, key equality, timing, or adjacency cannot manufacture provenance.

The proxy alone retains its routable worker recipient. The dynamic supervisor retains only WorkerIncarnationEvidence for exact replacement and stop correlation. Status, capabilities, request replies, and lifecycle events never grant a route around the stable proxy.

Every checked sequence has an explicit exhaustion outcome and never wraps. Collision against retained state is a controlled contradiction, not an invented result of the opaque StableProxy operation pair. Failed correlation issue returns every still-owned input and commits no entry, operation, activation occupancy, or action.

Construction domain

One complete construction contains:

DynamicDefinition = {
    entry_limit: PositiveMaximum,
    activation: ActivationContract,
    activation_limit: PositiveMaximum,
    unexpected_exit: KeepEmpty | Retire,
    actor_drain: ActorDrainPolicy,
    lifecycle: DurableLifecycleRoute,
    diagnostics: DeliverTo { route } | Terminate,
}

The durable lifecycle route is mandatory and selected once. It preserves its concrete logical, established, or mixed capability form and static hosting obligations. No request route can replace it. Diagnostics are independently mandatory through either a concrete route or terminal settlement.

ActivationContract is the selected static interpretation law. Each WorkerSubmission is the complete owned per-attempt definition and activation work after that law is applied. The fold never reconstructs, looks up, or clones an affine activation plan after admission.

A zero entry limit, zero activation limit, invalid deadline, or missing policy is a construction failure. There is no fixed factory, worker roster, recovery policy, callback, no-op route, default unexpected-exit behavior, or public structural path.

A closed heterogeneous worker sum is valid only when every variant exposes one common concrete public service protocol. Different public protocols require different dynamic supervisors; the model never erases them into one envelope.

AA-20 selects no builder, typestate spelling, public enum names, or macro.

Supervisor state

SupervisorState =
    Operating {
        definition,
        entries: BoundedEntryTable,
        allocators,
    }
  | Draining {
        definition,
        entries: BoundedDrainTable,
        deadline: DeadlinePhase,
        allocators,
    }
  | Stopped

BoundedEntryTable contains at most entry_limit entries. Every key occurs at most once. Every entry stores its exact generation and proxy creation ID or exact proxy; the table does not derive either from the key.

The table need not retain declaration order. Activation fairness is explicit: each waiting start or replacement already stores its ordered OperationCorrelation, and newly available capacity issues the lowest outstanding operation first. There is no separately mutable queue whose contents can disagree with entry phases.

Activation occupancy is derived from exact dispatched or awaiting proxy-input states. A prepared but un-emitted input owns its complete worker submission but does not occupy activation capacity. Reserving capacity, forming the infallible proxy-operation pair, and emitting the prepared input are one transition.

Transaction-local start preparation

Start preparation is not a stored entry phase:

PreparedStart = {
    identity: EntryIdentity,
    creation: CreationId,
    operation: OperationCorrelation,
    cancel: CancelAuthority,
    input: PreparedProxyInput,
}

PreparedReplace = {
    identity: EntryIdentity,
    proxy: ProxyIncarnation,
    base: ReplaceBase,
    operation: OperationCorrelation,
    cancel: CancelAuthority,
    input: PreparedProxyInput,
}

For one Start, the supervisor checks shutdown, duplicate key, and table capacity; then fallibly reserves every field above before committing anything. Failure returns the complete worker and an exact reason. Success commits Entry::Starting(CreatingProxy) and emits the acceptance reply, fresh empty proxy creation, exact creation observation, and exact proxy-exit observation in one action.

There is therefore no observable stored Reserved phase between acceptance and creation emission. A future executable design that introduces such a phase must identify the real intervening settlement or prerequisite. A label that is only a transient local preparation value must not appear in public query.

Operating entry sum

Every retained entry is exactly one of:

Entry =
    Starting(StartEntry)
  | Ready(ReadyEntry)
  | Empty(EmptyEntry)
  | Replacing(ReplaceEntry)
  | Stopping(StopEntry)
  | Cancelling(CancelEntry)
  | Retiring(RetireEntry)

No entry has pending, ready, cancelled, stopping, or retired flags.

Start entry

StartEntry =
    CreatingProxy {
        identity,
        creation: CreationId,
        operation,
        input: PreparedProxyInput,
    }
  | WaitingForAuthorization {
        identity,
        proxy: ProxyIncarnation,
        operation,
        input: PreparedProxyInput,
    }
  | AwaitingInputReceipt {
        identity,
        proxy: ProxyIncarnation,
        operation,
        witness: ProxyOperationWitness,
    }
  | AwaitingOutcome {
        identity,
        proxy: ProxyIncarnation,
        operation,
        proxy_input: ProxyOperationId,
    }

CreatingProxy and WaitingForAuthorization own the worker inside the prepared input. AwaitingInputReceipt retains only correlation; the input has moved to source-side delivery settlement. AwaitingOutcome exists only after exact input acceptance.

Available entries

ReadyEntry = {
    identity,
    proxy: ProxyIncarnation,
    worker: WorkerIncarnationEvidence,
    last_operation: TerminalOperation,
}

EmptyEntry = {
    identity,
    proxy: ProxyIncarnation,
    previous: WorkerIncarnationEvidence,
    cause,
    last_operation: TerminalOperation,
}

TerminalOperation =
    Committed { operation: OperationCorrelation, kind: OperationKind }
  | Cancelled { operation: OperationCorrelation, kind: OperationKind }
  | None

At most one terminal operation is retained per entry. It makes an immediate matching repeated cancel truthful without an unbounded operation-history table. Accepting the next start/replace mutation retires the prior terminal record; older authorities then produce CancellationReceipt::Stale. This is a deliberate bounded-retention policy, not an actor-model rule.

Replacement entry

ReplaceBase =
    WasReady { worker: WorkerIncarnationEvidence }
  | WasEmpty { previous: WorkerIncarnationEvidence, cause }

ReplaceEntry =
    WaitingForAuthorization {
        identity,
        proxy,
        base: ReplaceBase,
        operation,
        input: PreparedProxyInput,
    }
  | AwaitingInputReceipt {
        identity,
        proxy,
        base: ReplaceBase,
        operation,
        witness,
    }
  | AwaitingOutcome {
        identity,
        proxy,
        base: ReplaceBase,
        operation,
        proxy_input,
    }

StableProxy is the sole owner of predecessor drain. It does not publish a replacement outcome until its internal predecessor shutdown/exit reunion has closed, and its owner never reconstructs that outcome from lower-level worker events. DynamicSupervisor therefore owns no predecessor-stop phase. The replacement outcome's nested replaces evidence must equal the retained base; that validation is the supervisor's only predecessor responsibility after input transfer.

Explicit stop entry

StopOrigin =
    Available { prior: ReadyEntry | EmptyEntry }
  | Starting { phase: StartOutstanding }

StopEntry =
    WaitingForProxyBirth {
        identity,
        creation: CreationId,
        stop: StopCorrelation,
        start_outstanding,
    }
  | ShutdownDispatched {
        identity,
        proxy,
        stop,
        origin: StopOrigin,
        shutdown: ShutdownCorrelation,
        settlement,
    }
  | AwaitingProxyExit {
        identity,
        proxy,
        stop,
        origin: StopOrigin,
        shutdown: ShutdownCorrelation,
    }
  | ExitBeforeShutdownSettlement {
        identity,
        proxy,
        stop,
        origin: StopOrigin,
        exit,
        shutdown: ShutdownCorrelation,
    }

Stop during a pending start is accepted and waits for exact proxy creation. It is not operation-token cancellation: it closes the complete entry by key, reports stop admission to its caller, and transfers the interrupted start obligation to the durable lifecycle owner. Stop during replacement or cancellation is rejected as unavailable and does not steal that operation.

Cancellation entry

CancelKind = Start | Replace { base: ReplaceBase }

CancelEntry =
    AwaitingProxyBirth {
        identity,
        creation: CreationId,
        operation,
        kind: Start,
        definition_disposition: ReturnedToCancelReply,
    }
  | DrainingProxy {
        identity,
        proxy,
        operation,
        kind: CancelKind,
        outstanding: CancelOutstanding,
        shutdown: ProxyStopPhase,
    }

CancelOutstanding =
    NoTransferredInput
  | InputSettlement { witness: ProxyOperationWitness, settlement }
  | ProxyOutcome { proxy_input: ProxyOperationId }
  | OutcomeBeforeExit { outcome }

ProxyStopPhase =
    NotEmitted
  | ShutdownDispatched { shutdown, settlement }
  | AwaitingExit { shutdown }
  | Rejected { shutdown, request, reason }
  | ExitObserved { exit }

StartOutstanding =
    DefinitionLocal { operation, input }
  | InputEmitted { operation, witness: ProxyOperationWitness, settlement_or_outcome }

RetireOutstanding =
    Idle
  | Start { outstanding: StartOutstanding }
  | Replace { operation, base, witness: ProxyOperationWitness, settlement_or_outcome }
  | Cancellation { operation, outstanding: CancelOutstanding }
  | Stop { stop, settlement_or_exit }

Cancellation before proxy-input emission returns the complete submitted worker through CancellationReceipt::Returned. If proxy creation is already in flight, the entry still waits for its exact result; a late committed proxy is drained.

Cancellation after input emission returns CancellationReceipt::Pending. It never returns the worker, even if later delivery rejection transfers that input to the lifecycle host. A late ready result is retained only for drain and never emits Started or Replaced.

Retirement entry

RetireCause =
    UnexpectedWorkerExit
  | StableProxyExit
  | StartFailed
  | ReplacementFailedAfterTopologyLoss
  | Cancellation
  | Stop
  | DiagnosticTermination

RetireEntry = {
    identity,
    proxy: NoProxy | Pending(CreationId) | Exact(ProxyIncarnation),
    cause: RetireCause,
    outstanding: RetireOutstanding,
    shutdown: ProxyStopPhase,
}

An entry is removed only when outstanding is empty and its proxy is rejected before birth or authoritatively exited. Removal is a state transition, not a permanent tombstone.

Public command sum

Management =
    Start { key, worker, reply_to }
  | Replace { key, worker, reply_to }
  | Stop { key, reply_to }
  | Query { key, reply_to }
  | Cancel { authority: CancelAuthority, reply_to }

Here worker means the complete WorkerSubmission, not merely the inner behavior after its activation work has been separated. A future Rust surface may infer and hide that product, but its ownership cannot disappear.

AA-20 omits a separate Retire command. For a ready or empty entry, explicit Stop already drains the stable proxy and releases the key after exact exit. Retirement after unexpected exit is policy-driven and automatic. Adding Retire without another state-transition law would create two public ways to perform the same operation.

Every request route is used once for its immediate reply and then moves to action settlement. It is never stored as the durable lifecycle owner. A CancelAuthority is returned in every cancel reply (or its rejected-delivery settlement), so the supervisor never retains or clones that affine authority.

Request receipts

WorkerChangeReceipt = { key, cancel: CancelAuthority }
WorkerChangeRejection<Reason> = { key, worker, reason: Reason }

Start result =
    Result<WorkerChangeReceipt, WorkerChangeRejection<StartRejection>>

Replace result =
    Result<WorkerChangeReceipt, WorkerChangeRejection<ReplaceRejection>>

Stop result = Result<Key, StopRejection<Key>>

CancellationReceipt =
    Returned { authority, worker }
  | Pending { authority, phase }
  | Committed { authority, resulting_phase }
  | Cancelled { authority }
  | Stale { authority }
  | Draining { authority }

QueryReply = Unknown { key } | Known { key, phase }

Start rejection reasons include AlreadyExists, AtCapacity, ShuttingDown, entry-generation exhaustion, management-operation exhaustion, and proxy-creation exhaustion. Replace rejection includes unknown, unavailable, shutting down, and management-operation exhaustion. Every rejection owns the complete submitted worker. Stop rejection includes unknown, unavailable, already stopping, shutting down, and stop-correlation exhaustion or collision; no stop state or shutdown action is committed when that reservation fails.

Public query projection

PublicPhase =
    CreatingProxy
  | WaitingForActivationAuthorization
  | AwaitingProxyOutcome
  | Ready { proxy: ProxyIncarnation }
  | Empty
  | Stopping
  | Replacing
  | Cancelling
  | Draining
  | Retiring

Query is a byte-for-byte semantic no-op on entry state, allocator state, capacity, and activation occupancy. It exposes no worker definition, child route, entry generation, proxy-operation correlation, cancel authority, proxy-private installation phase, or worker recipient. Delayed lifecycle events retain the opaque entry generation because they cross key reuse; an immediate query does not expose bookkeeping its caller cannot use. During global shutdown it projects the drain phase. Absence is Unknown, not an Option combined with flags.

Durable lifecycle and diagnostic values

DynamicLifecycle =
    Started { identity, operation: OperationEvidence, proxy: ProxyIncarnation }
  | StartFailed {
        identity, operation: OperationEvidence,
        definition: DefinitionOwnership, reason,
    }
  | Replaced { identity, operation: OperationEvidence, proxy: ProxyIncarnation }
  | ReplacementFailed {
        identity, operation: OperationEvidence,
        definition: DefinitionOwnership, reason,
    }
  | StopFinished {
        identity,
        proxy,
        result: Result<ProxyExit, StopFailure>,
    }
  | UnexpectedWorkerStopped {
        identity, observed_at, disposition: KeptEmpty | Retiring,
    }
  | OperationCancelled { identity, operation: OperationEvidence, kind, result }
  | WorkerChangeInterrupted {
        identity,
        operation: OperationEvidence,
        interruption:
            ExplicitStop { stop: OperationEvidence }
          | SupervisorShutdown { change: Start | Replacement },
        definition: DefinitionOwnership,
    }
  | CommandUnavailable { identity, sender, proxy_phase, command }
  | EntryRetired { identity, cause }

DynamicDiagnostic =
    CorrelationReservationRejected { key, operation_kind, reason }
  | ProxyCreationRejected { identity, rejection }
  | ProxyInputRejected { identity, operation, input, reason }
  | ProxyOutcomeFailed { identity, operation, outcome }
  | ProxyShutdownRejected { identity, proxy, request, reason }
  | StableProxyDied { identity, proxy, exit }
  | RejectedLifecycleFact { rejected }
  | ForcedRetirement { identity, residual, cause }

Lifecycle events never expose a routable worker recipient. Exact predecessor evidence from a worker-stop report moves into the entry; the durable event gets the disjoint observation time and semantic disposition. Service capability publication is limited to the stable proxy. A failure or interruption carries a still-local worker definition as Present; after proxy-input emission it says Transferred and the exact input settlement remains the sole owner. Every event delivery has exact settlement ownership; delivery rejection cannot roll back admission or realization.

When one transition emits both lifecycle and diagnostic values, the exact source payload moves to only one of them. The other receives an explicit semantic classification or a disjoint field projection. The model never clones an affine rejection, exit, worker definition, command, or incarnation fact merely to satisfy two consumers.

Diagnostics follow DeliverTo(route) | Terminate. Diagnostic delivery rejection is terminal and non-recursive. Lifecycle and diagnostics are independent lanes: neither substitutes for the other. Terminate transfers the diagnostic and every still-live entry obligation to the surviving lifecycle host and enters the same global drain equation; it does not drop the diagnostic or continue an ordinary entry-local transition.

Stable-proxy input sum

ProxyCreationResult = the generic CreationsSettled result for the exact
    CreationId and StableProxy creation

ProxyInputResult = ActionItemResult<
    ProxyOperation,
    ProxyInputReceipt { creation, proxy, operation: ProxyOperationId },
    ProxyInputRejection,
    Never,
>

ProxyReport =
    Initial { outcome }
  | Replacement { outcome }
  | WorkerStopped { stop, observed_at }
  | Unavailable { sender, phase, command }

ProxyExit = { identity, proxy, exit }

ProxyShutdownSettlement =
    Accepted { identity, proxy, shutdown }
  | Rejected { identity, proxy, shutdown, request, reason }

The generic result owns whether interpretation was attempted. Acceptance owns only the receipt promised by the request. Rejection and corruption return the complete ProxyOperation; an unattempted result retains it unchanged. There is no supervisor-specific result sum or conversion seam.

Every proxy report is accompanied by its exact child-source capability. The entry generation, exact source, expected operation kind, and replacement outcome's nested replaces evidence form complete correlation. The supervisor does not widen AA-01's proxy protocol with its cancel authority.

The source carried by a proxy input result or proxy exit selects its entry once before the phase matrix. A source that selects no entry is returned as rejected input. After selection, the phase checks only its distinct operation or worker evidence; it does not compare the selecting source with itself again or invent a second phase-local wrong-source outcome.

Required semantic action product

The minimum model product is:

proxy_creations
proxy_creation_observations
proxy_stop_observations
proxy_initial_inputs
proxy_replacement_inputs
proxy_shutdowns
management_replies
lifecycle_events
diagnostics = Deliver { route, diagnostic } | Terminal { diagnostic }
deadline_schedules
rejected_inputs
delivery_settlements

All operations are named semantic lanes. No positional traversal, nested .inner, runtime registry, dynamic envelope, callback, or direct effect occurs inside the fold. The actual production product may use existing lower-order lanes only if it proves this complete observable algebra without reinterpretation.

Ownership table

Management-command matrix

During global drain, every mutation rejects with ShuttingDown; Cancel returns CancellationReceipt::Draining; Query remains total.

Lifecycle-fact matrix

Notation:

• A accepts the exact fact and performs the named phase transition;
• J accepts one side of an order-independent join;
• D settles only the matching drain obligation;
• F preserves state and emits one complete rejected-fact diagnostic.

Exact entry generation and proxy source are checked before this table. A fact that fails either check is always F.

WorkerStopped while replacement still waits for authorization changes a WasReady base into the exact empty predecessor; it does not open an unexpected-exit policy decision or a second operation because the accepted replacement already owns the service mutation. For WasEmpty, another stop is F. After replacement input transfer, StableProxy consumes predecessor stop privately and emits only the completed replacement outcome. A later WorkerStopped report can describe only the successor selected by that completed outcome and is processed after the replacement result.

Stopping accepts proxy birth only when its origin still owns the matching pending proxy creation. Input and outcome values in stopping/cancelling/ retiring states never publish success; they settle exact outstanding ownership through the drain equation.

Start transitions

Successful preparation commits the entry before emitting StartAccepted and the proxy creation bundle. Acceptance delivery rejection cannot unreserve the entry or recover the worker; the durable lifecycle owner remains authoritative for later realization.

The entry retains only OperationCorrelation. CancelAuthority moves to the request reply action and then to its delivery settlement; the supervisor never stores or clones the caller's cancellation capability. A later Cancel returns that authority to the fold, which privately projects the matching correlation.

Exact proxy rejection removes the entry after preserving StartFailed with the still-local definition as Present and all creation settlement. Exact proxy commit stores ProxyIncarnation and either:

• waits with the complete prepared input when activation capacity is full; or
• consumes the lowest waiting OperationCorrelation, forms the infallible ProxyOperationWitness/ProxyOperationId pair, emits the initial input, and enters AwaitingInputReceipt in the same transition.

Input settlement acceptance enters AwaitingOutcome. Rejection releases activation occupancy, marks the durable StartFailed definition Transferred, preserves the complete input in diagnostic settlement, drains the empty stable proxy, and never retries automatically.

An exact initial Ready outcome releases occupancy, enters Ready, stores the opaque worker evidence privately, and emits exactly one durable Started with the stable proxy. Any non-ready outcome emits StartFailed and retires/drains the proxy. A report before accepted input settlement is rejected; the interpreter must discharge source settlement before later child report admission.

After every occupancy release, waiting starts/replacements issue in increasing OperationCorrelation up to the positive limit.

Replace transitions

Replace is admissible only from Ready or Empty. Before acceptance, the supervisor constructs one complete transaction-local PreparedReplace, reserving its operation/cancel pair. A failure returns the complete replacement and leaves the base entry unchanged. Success moves the cancel authority into the acceptance action and every other field into Replacing::WaitingForAuthorization; no partial replacement phase is committed.

While waiting for authorization, cancellation returns the replacement and restores the exact base with a bounded Cancelled terminal record. Authorization forms the infallible proxy-operation pair and moves the replacement input to settlement.

Input rejection restores the base, emits one durable ReplacementFailed with definition Transferred, and preserves the complete input through diagnostic settlement. Input acceptance enters AwaitingOutcome.

StableProxy joins the ready predecessor's exact stop with successor work before publishing one replacement outcome; an empty proxy has no predecessor drain. DynamicSupervisor consumes that one completed outcome. A ready result enters Ready with fresh worker evidence and emits one Replaced after validating the nested replaces evidence against the retained base. A pre-birth failure enters Empty with the validated replaces evidence; a post-birth failure enters Empty with the successor attempt returned by StableProxy. Both emit ReplacementFailed. This is the same EmptyAfter projection owned by AA-01; the supervisor does not infer which worker the proxy now names. It never reports success or returns an already-transferred worker definition.

Cancellation after emission suppresses both outcomes, drains the exact proxy, and eventually emits OperationCancelled to the durable lifecycle owner. It cannot revive the predecessor or pretend the proxy stopped creating work.

Stop, unexpected exit, and unavailability

Stop accepts a ready, empty, or still-starting entry. Its immediate reply describes admission only. The durable lifecycle owner receives completion or runtime rejection.

Before StopAccepted, the fold fallibly reserves StopCorrelation. For a committed proxy, the exact shutdown correlation is then formed totally from the retained entry identity and proxy capability, and one shutdown is emitted. Settlement rejection preserves the request and reason. If the proxy is otherwise live, a stop-originating ready/empty entry is restored only when no authoritative exit has arrived; a failed StopFinished is durable realization, not an admission rejection. If exit and settlement arrive in the other order, the closed join preserves both and never resurrects the entry.

For a still-creating proxy, stop retains the creation result obligation. Exact creation rejection removes the entry. Exact commit emits one shutdown. Any locally owned initial definition transfers to the durable WorkerChangeInterrupted { interruption: ExplicitStop } outcome. An already-emitted input resolves first: rejection moves the complete returned input to diagnostic custody, while acceptance requires the exact late proxy result in the same lifecycle value. No Transferred label substitutes for an owned worker value.

An exact spontaneous worker stop from Ready first makes the entry unavailable and emits UnexpectedWorkerStopped. KeepEmpty enters Empty and continues to consume capacity. Retire enters Retiring, shuts down the stable proxy, and releases capacity only after exact drain. Neither policy restarts a worker.

Stable-proxy death in any phase retires that exact entry generation. It settles the active operation through typed host transfer, emits the corresponding lifecycle failure and diagnostic, and cannot affect another entry or later use of the same key.

Every exact Unavailable report is delivered once to the mandatory durable lifecycle route with key, generation, sender, phase, and command intact. It is valid during starting, ready, empty, replacing, stopping, cancelling, and draining. Foreign or stale source capability is a diagnostic, not a fold error that loses the command.

Cancellation and bounded token retention

Cancel first selects the semantic key and matches the checked, supervisor-global operation carried by its opaque authority. Operations never wrap or reuse, so entry generation is not a second cancellation coordinate; it remains the durable identity of the retained entry and its lifecycle messages.

• A matching locally owned definition returns once.
• A matching transferred definition returns CancellationReceipt::Pending and moves the entry into exact drain.
• A matching active cancellation returns CancellationReceipt::Cancelled.
• A matching most-recent committed record returns CancellationReceipt::Committed.
• A matching most-recent cancelled record returns CancellationReceipt::Cancelled.
• An older, removed-generation, foreign, or never-issued authority returns CancellationReceipt::Stale without mutation.
• Global drain returns CancellationReceipt::Draining.

The model retains no unbounded operation history. When a new operation is accepted, the prior terminal record retires. This bounded policy must be documented in any public cancellation contract; indefinite Committed answers would require a growing tombstone set or an impermissible provenance inference from sequence arithmetic.

Entry retirement and key reuse

Capacity counts every retained entry, including cancelling and retiring ones. An entry is removed only after:

1. pending proxy creation resolves;
2. every emitted proxy input settles or transfers;
3. every proxy-private activation outcome resolves or transfers;
4. exact proxy shutdown/exit resolves or transfers;
5. lifecycle, diagnostic, and rejected-delivery ownership has a host; and
6. forced-retirement residual ownership, if any, moves to the surviving root.

Removal retains no key tombstone. A later Start for the same key reserves a fresh supervisor-global EntryGeneration, proxy creation ID, and operation. Because child routes and generations are never reused, a late fact from an old entry cannot match the new entry. It is returned complete as a stale diagnostic.

Allocator exhaustion rejects future starts with their workers intact. It does not justify reuse of an old generation or child route.

Global shutdown normalization

The first global shutdown atomically:

1. closes start, replace, and stop admission;
2. makes cancel report CancellationReceipt::Draining while query remains available;
3. transfers every locally owned start/replacement definition to one durable WorkerChangeInterrupted { interruption: SupervisorShutdown { change } } outcome and retains already-emitted definitions through their exact input settlement or proxy outcome;
4. preserves every emitted creation, proxy-input settlement, and atomic proxy outcome obligation;
5. transforms every retained entry into one exhaustive drain entry;
6. emits at most one shutdown for every committed live proxy;
7. retains every pending proxy creation until exact commit/rejection; and
8. reserves and emits one exact deadline request when selected.

DrainEntry =
    ResolvingProxyCreation { identity, creation: CreationId, local_values }
  | DrainingProxy {
        identity,
        proxy,
        outstanding: EntryOutstanding,
        shutdown: ProxyStopPhase,
    }
  | Drained { identity, result: Graceful | Absent | Forced { residual } }

EntryOutstanding =
    Idle
  | StartWaiting { operation, input }
  | StartEmitted { operation, witness: ProxyOperationWitness, settlement_or_outcome }
  | ReplaceWaiting { operation, base, input }
  | ReplaceEmitted { operation, base, witness: ProxyOperationWitness, settlement_or_outcome }
  | ExplicitStop { stop, settlement_or_exit }
  | Cancellation { operation, outstanding }
  | Retirement { cause, outstanding }

Repeated shutdown is idempotent. Late creation, proxy report, input settlement, shutdown settlement, and proxy exit can settle only their exact drain entry. They cannot restore mutation or emit Started/Replaced.

Exact proxy exit consumes every outstanding operation through the same typed child terminal/drain settlement required by AA-01 and AA-10. If the runtime cannot return emitted input ownership when normal proxy reports are suppressed during shutdown, that is a shared real-boundary blocker; the model does not replace it with flags, abort, logging, or dropped values.

Deadline drain

DeadlinePhase =
    WaitingWithoutDeadline
  | Scheduling { correlation, settlement }
  | Waiting { correlation }
  | Fired { correlation, observed_at }

WaitForActorGraph may wait indefinitely and owns no timer. RetireActorGraphAfter reserves one exact correlation. Reservation failure or schedule rejection immediately forces every unresolved entry into Drained(Forced { residual }) with that exact rejection as cause; it never degrades into unbounded waiting.

When the exact deadline fires, every unresolved entry transfers its complete phase, proxy or creation ID, operation, local values, and action settlements to the surviving lifecycle host. No accepted stop, ready worker, successful replacement, or normal exit is fabricated. The root remains live until residual external work settles.

The supervisor selects normal termination only when every entry is drained and every final action has a settlement owner.

Stale, overlap, and contradiction laws

• A management key alone never matches a lifecycle fact.
• A proxy creation or exit advances only its exact entry generation and creation ID or exact capability.
• A proxy-input settlement advances only its exact generation, source, ProxyOperationWitness, operation kind, and dispatched phase.
• An initial outcome cannot satisfy replacement, and replacement cannot satisfy initial.
• Replacement outcome evidence must name the exact retained predecessor.
• A duplicate report cannot release another activation slot.
• A cancel authority cannot cancel another operation on the same key.
• An old-generation fact cannot advance a reused key.
• A stop correlation cannot consume a replacement or cancellation settlement.
• A delivery rejection cannot roll back an already committed state transition.
• Contradictory authoritative facts retain both sides and transfer to diagnostics.
• Diagnostic rejection is terminal and never recursively diagnoses itself.

Every rejected fact preserves the semantic entry state and emits one complete RejectedLifecycleFact through the configured diagnostic disposition.

Feature-catalogue trace

Every row remains a model claim, not implementation status.

Independent-model obligations

The later executable oracle must use independent vocabulary and compare complete traces. At minimum it must cover:

• zero/invalid construction limits and missing mandatory policies;
• start at capacity, duplicate key, and every correlation reservation failure;
• proxy creation commit/rejection/exit orderings;
• activation limits one and two with operation-order issuance;
• accepted/rejected proxy-input settlement before atomic outcome;
• start cancellation in every phase, including late commit/readiness;
• replace from ready and empty, including StableProxy's internal predecessor stop/outcome orders and the supervisor's single completed result;
• replacement cancellation before and after definition transfer;
• stop during pending start, ready, empty, replacement, and cancellation;
• unexpected worker exit under both policies;
• total query projection in every operating and draining phase;
• operation-token replay, bounded terminal retention, and old-token staleness;
• remove/reuse of one key with a fresh generation and late old facts;
• foreign/duplicate/wrong-kind/wrong-source lifecycle facts;
• request, lifecycle, diagnostic, and shutdown delivery rejection;
• shutdown from every entry phase, pending creation, late ready, and repeated shutdown;
• deadline reservation failure, schedule rejection, exact firing, and residual root settlement; and
• complete named actions for every accepted/rejected transition.

Falsification findings and comparison obligations

AA-20 records these findings for governing-document reconciliation:

1. The clean-room task text called durable lifecycle ownership optional, while the feature, solution, and DevX contracts make one durable route mandatory. This model follows the governing mandatory law.
2. The solution/type inventory list a public Retire command, but the feature law already makes Stop release ready/empty entries and automatically removes fully retired entries. No distinct Retire transition remains; retaining both would violate the one-operation/one-spelling DevX target.
3. The solution/query vocabulary stores and exposes Reserved, but successful preparation and proxy creation emission are one fold. Without a real intervening settlement, Reserved is transaction-local and not queryable.
4. The cancellation contract did not bound how long terminal operation tokens remain recognizable. This model retains only the active or most recent terminal operation per entry; older tokens return CancellationReceipt::Stale.
5. The stop requirements both restrict admission to available/empty and require stop during pending start to wait for creation. This model selects the latter explicit race law and accepts stop during Starting.
6. The governing dynamic action product omits explicit route-delivered diagnostic, deadline, fact-rejection, and child-terminal settlement operations required by its own laws. Activation remains proxy-private; the supervisor authorizes it by emitting the opaque proxy input, not through a second activation lane.
7. The current production template conflates key with child nonce, retains the start reply route as lifecycle owner, exposes Option<phase>, has no entry limit/generation/cancellation/deadline law, and reconstructs worker progress instead of consuming AA-01's atomic proxy outcome. It is comparison evidence, not an implementation candidate for this model.
8. Governing dynamic syntax supplies worker per operation while construction selects activation, but it does not state where a possibly affine concrete activation plan is materialized or returned. This model treats worker as the complete WorkerSubmission once the static activation contract is applied. An executable design must infer and hide that composition without cloning, reconstructing, or asking users to spell the product.

These findings do not authorize production surface. The solution, feature catalogue, type inventory, coverage matrix, DevX contract, retained-core decision, and research audit must be reconciled before an executable task relies on a changed law.

This specification is ready to compare with the FIFO and keyed-pool models. It does not make AA-21 eligible: executable dynamic supervision still depends on AA-07's completed proxy and interpreter boundary audit.

FIFO-pool falsification model

Status and authority

This document is the AA-30 independent semantic model for one FIFO worker pool. It is a non-production falsification oracle. It does not select Rust types, define another behavior algebra, implement a pool, or mark a production coverage row implemented. docs/engineering/atomic-actor-solution.md remains the production design authority.

The actor-model laws used here are isolated processing of one communication, communications to known recipients, fresh actor creation, and explicit next behavior. The pool itself, direct worker ownership, FIFO admission, bounded backlog, circular worker selection, activation authorization, recovery, at-least-once retry, opaque completion authority, action settlement, and actor-graph drain are derived constructions or deliberate Bombay policies. Neither Agha's actor model nor message-arrival indeterminacy supplies FIFO pool semantics.

The model is deliberately not a supervisor containing a work queue. It reuses policy values where their meanings are identical, but it contains no stable proxy, supervisor member state, proxy operation, public worker capability, nested supervisor behavior, keyed affinity, or redispatched supervisor event.

Runtime route selection is owned normatively by docs/atomic-runtime-settlement.md. The pool issues and stores only a CreationId for each direct worker creation; it never chooses or stores a runtime route before emitting CreateChild. Any older reservation label below denotes that creator-visible correlation before interpretation and routed evidence only in the returned runtime settlement. It does not authorize a separate route request, waiting state, or public route.

AA-30 is exercised by the clean-room FifoPool aggregate and independent customer, recovery, retirement, and queue models. H04b proves typed assignment completion lowering and H02 implements total action settlement. H03 assigns terminal lifecycle custody to Bombay through the documented upstream contract; that Engine/root integration remains an upstream gate rather than a FIFO aggregate gap. Legacy WorkerPool tests remain historical characterization evidence, not an architecture or independent model.

The model must falsify designs that make any of these claims false:

1. The roster is non-empty, ordered, and contains each semantic worker role once.
2. Every installed or replacement worker is a freshly created actor. A role, route, attempt, or sequence value is not actor identity.
3. The stable pool actor is the only public service capability. Exact worker capabilities remain pool-private.
4. The pool directly owns worker creation, initialization, activation, readiness, recovery, and drain. No nested proxy or supervisor owns them.
5. Every accepted job has exactly one authoritative customer obligation and is either queued, assigned, or being terminally settled—never two of them.
6. Backlog capacity counts queued jobs only. Zero capacity permits immediate assignment and rejects waiting ownership.
7. Every worker has at most one assignment. Only an exact ready incarnation is eligible.
8. No queued job coexists with an eligible idle worker after a completed fold.
9. Jobs leave the queue in admission order. Worker choice starts at one circular declaration-order cursor and advances after each assignment.
10. A completion must match its opaque authority, assignment, creator-local child nonce, private worker-birth evidence, role, and active phase. It resolves one customer outcome.
11. A matching worker stop resolves its active assignment once before recovery. Retry is at-least-once execution and preserves FIFO admission order.
12. Assignment delivery, completion, and worker stop may arrive in any order. Their join cannot duplicate a retry, terminal customer outcome, or recovery decision.
13. Irrecoverable topology loss cannot strand accepted queued or assigned work.
14. Shutdown closes admission, returns every queued and assigned job once, disables dispatch/retry, and drains every owned or still-creating worker.
15. Stale, duplicate, foreign, wrong-worker-birth, and contradictory facts preserve current ownership and have an explicit diagnostic disposition.
16. Every accepted input produces one next state and one complete named action product. No effect is ambient.

“Atomic” means one local Behavior fold commits one pool state and its complete Actions. It does not claim atomic delivery, creation, execution, recovery, or customer observation across actors.

Model vocabulary

The following names describe the oracle. They are not proposed public Rust names.

Role = one semantic worker label, unique inside this pool
RoleOrder = immutable declaration order retained for the pool lifetime

WorkerBirthAttempt = fresh non-reused CreationId issued by the pool
RoutedWorkerBirth = interpreter-private { attempt: WorkerBirthAttempt, route }
WorkerBirthEvidence = opaque non-routable evidence for one committed birth
WorkerRecipient = pool-private exact routable capability for one committed worker
WorkerIncarnation = { recipient: WorkerRecipient, evidence: WorkerBirthEvidence }

BirthKind = Initial | Replacement { recovery: RecoveryTicket, replaces: WorkerBirthEvidence }
WorkerSubmission = complete owned worker definition and activation work

RequestCorrelation = caller-authored opaque submission correlation, echoed only
JobId = fresh non-reused customer-visible correlation issued by the pool
AdmissionOrdinal = fresh non-reused private total order for one accepted job
AssignmentId = fresh non-reused private correlation for one dispatch attempt
CompletionAuthority = opaque affine authority bound to AssignmentId and WorkerBirthEvidence
CompletionCorrelation = pool-retained non-authorizing half of that exact authority
CompletionEvidence = consumed CompletionAuthority paired with one result
DispatchCorrelation = {
    assignment: AssignmentId,
    retained: CompletionCorrelation,
    authority: CompletionAuthority,
}

RecoveryTicket = fresh non-reused correlation for one role recovery
RecoveryOrdinal = one-based admitted recovery count for that role
TimerCorrelation = { timer, generation }
ActivationTicket = fresh non-reused correlation occupying one authorization slot
ShutdownCorrelation = exact { role, WorkerIncarnation }

A child route, role, attempt, job, admission ordinal, assignment, recovery ticket, timer, or activation ticket is correlation, not actor identity. Only committed fresh creation yields WorkerIncarnation. Its recipient is routable only inside the pool's effects and lifecycle state; customers and worker messages never receive it as a service capability.

CompletionAuthority has no public constructor or inspectable fields. It is the affine authority half of one freshly issued pair; the pool retains the non-authorizing CompletionCorrelation half. The worker can only consume its half with the assignment to form assignment.complete(result). The resulting completion chooses no customer, pool address, role, parent path, send lane, or inspectable worker evidence. The current ChildReport boundary attaches only the creator-local child nonce, not an exact WorkerIncarnation. Exact completion matching therefore combines that nonce with the authority's opaque WorkerBirthEvidence; retained comparison evidence cannot manufacture a completion. A concrete lowering of that private evidence remains a blocker rather than an interpreter assumption.

Every correlation allocator has one complete result:

Reservation<T> = Reserved(T) | Rejected(Exhausted | Collision { candidate: T })

A rejection never wraps, overwrites, or reuses a correlation. The transition rules below say whether it rejects an unaccepted submission, returns an accepted job, retires a worker attempt, or begins actor-graph failure. Merely declaring a value fresh is not a total allocation law.

Construction domain

One complete definition contains:

FifoPoolDefinition = {
    initial_factory,
    roles: NonEmptyOrderedUnique<Role>,
    activation: ActivationContract,
    activation_limit: PositiveMaximum,
    recovery: RecoveryPolicy,
    backlog_capacity: NonNegativeMaximum,
    interruption: Fail | Retry,
    distribution: FIFO,
    actor_drain: ActorDrainPolicy,
    diagnostics: DeliverTo { route } | Terminate,
}

RecoveryPolicy contains eligibility, the typed worker source required by permanent or transient recovery, restart budget and inclusive window, immediate or checked delayed timing, and RetireRole | StopPool topology failure. Temporary recovery contains no worker source. Recovery is always one role at a time; a FIFO pool has no one-for-all or rest-for-one strategy.

ActorDrainPolicy is exactly:

WaitForActorGraph
RetireActorGraphAfter { deadline }

Construction fails for an empty roster, duplicate role, zero activation limit, invalid deadline, missing policy, or worker protocol that cannot accept the exact assignment product. FIFO construction has no selector or placeholder selector.

Before the pool exists, the initial factory is invoked for every role in declaration order and every worker reservation is fallibly prepared. If one factory or reservation fails, the construction error owns every already prepared definition and correlation; no partial fleet, budget charge, activation occupancy, or Actions commits. This is a Bombay all-or-none initial-preparation policy. Later creation and activation realization resolve independently for each committed role.

The worker sum may be heterogeneous only when every variant accepts one common concrete assignment protocol and produces one common concrete result type. Static closed sums are allowed; erasure and runtime registries are not.

AA-30 selects no builder spelling, typestate, public identifier representation, trait, wrapper, alias, or macro.

Pool state

FifoPoolState =
    Operating {
        definition,
        members: OrderedMemberMap,
        backlog: Fifo<QueuedJob>,
        cursor: RoleCursor,
        activation: ActivationCapacity,
        budget: RestartBudget,
        allocators,
    }
  | Draining {
        definition,
        members: OrderedDrainMap,
        deadline: DeadlinePhase,
        allocators,
    }
  | Stopped

The Rust aggregate also has Constructed, which owns the prepared worker roster before its one initialization transition, and ForcedRetirement, which owns unresolved retiring workers plus the exact shutdown-ID or deadline failure after a terminal transition. The sketch above describes the operating law; those two additional source states preserve initialization rejection and terminal custody. A real interpreter still has to prove transfer of the ForcedRetirement value to the parent or root custodian.

OrderedMemberMap has exactly one member for each declared role. Roles are never inserted, removed, or reordered. Retired remains as a terminal cell so cursor order and late-fact classification do not depend on sequence arithmetic.

The backlog owns jobs in original admission order. backlog_capacity is the new-admission waiting bound: a submission may queue only while the current backlog length is below it. An interrupted already-accepted assignment under Retry may re-enter even when that admission bound is full. Reinsertion is by its immutable AdmissionOrdinal, before every later-admitted queued job and after every earlier-admitted queued job; it is not unconditional front insertion. The absolute queue bound is therefore backlog_capacity + roles.len(), because each role can contribute at most its one formerly active assignment. There is no unbounded overflow and no second in-flight map: a live assignment is owned by its exact member.

RoleCursor denotes the first declaration-order position inspected for the next assignment. Selection wraps once, skips non-idle and retired roles, and chooses the first exact Idle. After assignment to role r, the cursor moves to the declaration-order successor of r; retirement never compacts or reorders the ring.

ActivationCapacity is derived from member states containing an occupied ActivationTicket. A declaration-order queue is derived from members waiting for authorization; correlated flags or a second occupancy counter are forbidden.

Customer ownership sums

CustomerObligation = {
    job: JobId,
    admitted_at: AdmissionOrdinal,
    customer: CustomerRoute,
    retained_payload,
}

QueuedJob = {
    obligation: CustomerObligation,
    assigned_role: None | Some(Role),
}

AssignedJob = {
    obligation: CustomerObligation,
    assignment: AssignmentId,
    completion: CompletionCorrelation,
    worker: WorkerIncarnation,
    role: Role,
}

AssignmentCommand = {
    execution_payload,
    completion: CompletionAuthority,
}

The queue owns QueuedJob. One busy member owns AssignedJob. The worker owns only the moved AssignmentCommand; it never owns the customer route or the canonical customer obligation.

Both Fail and Retry require a retained canonical payload while a cloned execution payload is sent to the worker. Clone preparation occurs before the candidate transition commits. If application cloning unwinds, no next state or Actions exists; the model does not promise to reconstruct a value already moved into a panicking fold.

The customer protocol is one closed sum:

AdmissionOutcome =
    Accepted { request: RequestCorrelation, job: JobId }
  | Rejected { request: RequestCorrelation, payload, reason: AdmissionRejection }

TerminalCustomerOutcome =
    Completed { job: JobId, role: Role, result }
  | ReturnedQueued { job: JobId, payload, reason: QueuedReturnReason }
  | ReturnedAssigned { job: JobId, role: Role, payload, reason: AssignedReturnReason }

RequestCorrelation is supplied by the caller and echoed unchanged in both admission outcomes. The pool neither allocates it nor trusts it as internal job identity; customers using one route can still distinguish concurrent requests. Admission commit moves it into the emitted Accepted; it is not retained in the accepted job. Rejection moves it into Rejected. If either delivery rejects, the lifecycle host owns that complete outcome. Accepted and Rejected are admission outcomes. The other three are the only terminal outcomes. A rejected submission was never accepted. A terminal outcome removes its obligation from actor state when the delivery attempt is emitted; rejected outcome delivery transfers that exact complete value to the lifecycle host and never reconstructs an active job.

Complete member sum

Member =
    Creating {
        role,
        reservation: WorkerReservation,
        kind: BirthKind,
        prior_stop: NoStop | StoppedBeforeBirth { stop },
    }

  | Initializing {
        role,
        worker: WorkerIncarnation,
        kind: BirthKind,
        init_attempt: InitAttempt,
    }

  | WaitingForActivationAuthorization {
        role,
        worker: WorkerIncarnation,
        kind: BirthKind,
        activation_permit,
        activation_plan,
    }

  | ActivationDispatched {
        role,
        worker: WorkerIncarnation,
        kind: BirthKind,
        ticket: ActivationTicket,
        begin_attempt: ActivationAttempt,
    }

  | Activating {
        role,
        worker: WorkerIncarnation,
        kind: BirthKind,
        ticket: ActivationTicket,
        activation_attempt,
    }

  | DrainingPreReady {
        role,
        worker: WorkerIncarnation,
        outstanding: PreReadyOutstanding,
        cause: PreReadyDrainCause,
        after_drain: Recover { stop } | Retire { reason },
    }

  | Idle {
        role,
        worker: WorkerIncarnation,
    }

  | Busy {
        role,
        worker: WorkerIncarnation,
        job: AssignedJob,
        join: AssignmentJoin,
    }

  | Recovering {
        role,
        predecessor: WorkerIncarnation,
        stop,
        recovery: RecoveryPhase,
    }

  | Stopping {
        role,
        worker: WorkerIncarnation,
        outstanding: StopOutstanding,
        after_stop: Retire { reason } | StopPool { reason },
    }

  | Retired {
        role,
        reason,
    }

AssignmentJoin is the exhaustive delivery/completion/stop join:

AssignmentJoin =
    AwaitingDeliveryAndTerminal { delivery: AssignmentDeliveryAttempt }
  | DeliveryAcceptedAwaitingTerminal
  | CompletionBeforeDelivery {
        delivery: AssignmentDeliveryAttempt,
        completion: CompletionEvidence,
        later_stop: NoStop | Stopped { stop },
    }
  | StopBeforeDelivery {
        delivery: AssignmentDeliveryAttempt,
        stop,
        later_completion: NoCompletion | Completed { completion: CompletionEvidence },
    }

The delivery effect and lifecycle host own the moved AssignmentCommand while settlement is unresolved; actor state retains only AssignmentDeliveryAttempt and the non-authorizing completion half. CompletionBeforeDelivery owns the returned completion input, while StopBeforeDelivery owns the authoritative stop. They are disjoint, so no queue entry duplicates the stop. A completion after StopBeforeDelivery is retained for stale or contradictory settlement; a stop after CompletionBeforeDelivery is retained in later_stop for one recovery after completion settles. Shutdown transfers any unresolved join intact.

The lifecycle host—not Initializing—owns the linear initialization settlement and activation plan while initialization is unresolved. Actor state retains only InitAttempt. An exact InitResult later transfers either the activation permit and plan, the rejected settlement and plan, or the stopped plan back once. ActivationDispatched likewise retains correlation while the host owns the moved begin request. These are the same ownership laws as AA-01, applied directly rather than by reusing proxy state.

PreReadyOutstanding, StopOutstanding, and every recovery variant own complete exact values rather than booleans. A definition or activation plan is either local, moved into an action settlement, or transferred to the lifecycle host—never reconstructed.

Recovery phase

RecoveryPhase =
    Scheduling {
        recovery: RecoveryTicket,
        timer: TimerCorrelation,
        prepared: PreparedReplacement,
        schedule_attempt: RestartScheduleAttempt,
    }
  | WaitingForTimer {
        recovery: RecoveryTicket,
        timer: TimerCorrelation,
        prepared: PreparedReplacement,
    }
  | ReadyToCreate {
        recovery: RecoveryTicket,
        prepared: PreparedReplacement,
    }

PreparedReplacement owns a fresh worker definition, fresh WorkerReservation, checked delay evidence, and one budget charge. Emitting the creation moves the member to Creating; no recovery phase and creating phase own the definition simultaneously.

Recovery eligibility is total:

One matching stop can admit at most one recovery. Preparation invokes the factory, reserves the recovery and worker-birth correlations, prunes budget at the interpreter-authored monotonic stop time using an inclusive window, validates the charge, and computes checked timing before commit. Any failure commits no recovery, timer, creation, or budget charge; it applies the selected topology-failure reaction to the already stopped role.

Immediate timing enters ReadyToCreate. Delayed timing enters Scheduling. Exact schedule acceptance enters WaitingForTimer; exact rejection applies topology failure and returns the complete prepared replacement to lifecycle settlement. An exact timer moves to ReadyToCreate and emits creation in that same fold. Stale or duplicate schedule/timer facts cannot create another worker.

Complete input sum

FifoPoolInput =
    Submit { request: RequestCorrelation, payload, customer: CustomerRoute }
  | Shutdown

  | WorkerBirthResolved(WorkerBirthResolution)
  | InitializationSettled(InitializationSettlement)
  | ActivationBeginSettled(ActivationBeginSettlement)
  | WorkerReady(WorkerReadyFact)
  | WorkerStopped(WorkerStopFact)

  | AssignmentSettled(AssignmentSettlement)
  | WorkerCompleted { child: ChildRouteNonce, completion: CompletionEvidence }

  | RestartScheduleSettled(RestartScheduleSettlement)
  | RestartTimerElapsed(RestartTimerFact)
  | WorkerShutdownSettled(WorkerShutdownSettlement)

  | DrainDeadlineSettled(DeadlineScheduleSettlement)
  | DrainDeadlineElapsed(DeadlineFact)

Every fact carries exact role, reservation or incarnation, operation kind, and correlation required by its transition. A payload match without exact source and phase is never sufficient.

WorkerBirthResolution is:

Committed {
    role,
    reservation: WorkerReservation,
    worker: WorkerIncarnation,
    init_attempt: InitAttempt,
}
Rejected {
    role,
    reservation: WorkerReservation,
    returned_submission: WorkerSubmission,
    reason,
}

Successful installation is authoritative before worker initialization effects are interpreted. Initialization settlement and later activation are separate facts; commit cannot be rolled back because one later effect rejects.

InitializationSettlement is one host-authored result:

ReadyForActivation {
    role, worker, init_attempt,
    permit: ActivationPermit,
    plan: ActivationPlan,
}
Rejected {
    role, worker, init_attempt,
    rejected_settlement,
    plan: ActivationPlan,
    reason,
}
Stopped {
    role, worker, init_attempt,
    stop,
    plan: ActivationPlan,
}

The actor never stores the unresolved settlement or plan. Only this exact result moves the lawful next values into actor state or drain ownership.

AssignmentSettlement is attached to the creator-local child nonce:

Accepted { child: ChildRouteNonce, assignment }
Rejected {
    child: ChildRouteNonce,
    assignment,
    returned: AssignmentCommand,
    reason,
}

Rejection proves only that this delivery was not accepted. It is not fabricated worker termination. Before the pool resolves the job, AuthorityReunion consumes the returned command's affine authority together with the exact retained CompletionCorrelation:

AuthorityReunion =
    Cancelled { assignment, worker_birth: WorkerBirthEvidence }
  | Mismatch { retained, returned_authority }

Cancelled proves that neither half remains live. Mismatch transfers both complete values to terminal settlement and cannot requeue, complete, or reuse the assignment. After successful reunion the pool safely requeues the proven- unaccepted job, quarantines and drains the exact worker, and applies recovery only after exact terminal or forced transfer.

Required semantic action product

The pool fold's minimum model product is:

FifoPoolActions = {
    worker_creations: [CreateWorker { reservation, submission }],
    worker_creation_observations: [ObserveWorkerCreation { reservation }],
    worker_stop_observations: [ObserveWorkerStop { child: ChildRouteNonce }],
    activation_begins: [BeginWorkerActivation { child, attempt, permit, plan }],
    activation_cancellations: [CancelWorkerActivation { child, attempt }],
    worker_assignments: [DeliverAssignment { child, assignment, command }],
    worker_shutdowns: [ShutdownWorker { child, correlation }],
    restart_schedules: [ScheduleRestart { recovery, timer, deadline }],
    deadline_schedules: [ScheduleDrainDeadline { timer, deadline }],
    admission_deliveries: [DeliverAdmission { route, outcome }],
    terminal_customer_deliveries: [DeliverCustomerTerminal { route, outcome }],
    diagnostic_deliveries: [DeliverDiagnostic { route, diagnostic }],
    terminal_diagnostic_transfers: [TransferTerminalDiagnostic { diagnostic }],
    rejected_fact_transfers: [TransferRejectedFact { fact, reason }],
    forced_drain_transfers: [TransferDrainResidual { residual, cause }],
}

WorkerCompletionActions = {
    parent_completion_reports: [ReportCompletionToParent {
        authority: CompletionEvidence,
    }],
}

The heterogeneous product has one closed owned-operation view for ordered application and rejection ownership:

OwnedOperation =
    CreateWorker { reservation, submission }
  | ObserveWorkerCreation { reservation }
  | ObserveWorkerStop { child: ChildRouteNonce }
  | BeginWorkerActivation { child, attempt, permit, plan }
  | CancelWorkerActivation { child, attempt }
  | DeliverAssignment { child, assignment, command }
  | ShutdownWorker { child, correlation }
  | ScheduleRestart { recovery, timer, deadline }
  | ScheduleDrainDeadline { timer, deadline }
  | DeliverAdmission { route, outcome }
  | DeliverCustomerTerminal { route, outcome }
  | DeliverDiagnostic { route, diagnostic }
  | TransferTerminalDiagnostic { diagnostic }
  | TransferRejectedFact { fact, reason }
  | TransferDrainResidual { residual, cause }
  | ReportCompletionToParent { authority: CompletionEvidence }

AppliedOperation =
    WorkerCreationSubmitted { reservation }
  | WorkerCreationObservationStarted { reservation }
  | WorkerStopObservationStarted { child }
  | WorkerActivationBeginDelivered { child, attempt }
  | WorkerActivationCancelDelivered { child, attempt }
  | AssignmentDelivered { child, assignment }
  | WorkerShutdownDelivered { child, correlation }
  | RestartScheduleSubmitted { recovery, timer }
  | DrainDeadlineScheduleSubmitted { timer }
  | AdmissionDelivered { request }
  | CustomerTerminalDelivered { job }
  | DiagnosticDelivered { diagnostic_correlation }
  | TerminalDiagnosticTransferred { diagnostic }
  | RejectedFactTransferred { fact, reason }
  | DrainResidualTransferred { residual, cause }
  | ParentCompletionReported { child, completion_correlation }

AppliedOperation records exactly which owned operation crossed the runtime boundary without pretending that creation, observation, scheduling, worker execution, or customer receipt has already completed. Their later domain facts remain distinct inputs. Each applied variant carries the correlation needed to match that later fact; where the draft vocabulary does not yet define a diagnostic correlation, that missing allocator is part of the lowering blocker, not permission to use a generic label.

Because the locked Environment::apply is ordered but non-transactional, one action application reports a closed prefix result:

ActionBatchSettlement =
    Complete { applied: [AppliedOperation] }
  | Partial {
        applied_prefix: [AppliedOperation],
        rejected: { operation: OwnedOperation, reason },
        not_attempted_suffix: [OwnedOperation],
    }

OwnedOperation is the exact flattened sum of FifoPoolActions and WorkerCompletionActions; it is not an erased envelope. Partial owns the rejected operation and returns every unattempted payload to the lifecycle host in authored order. A rejected ReportCompletionToParent therefore returns the complete CompletionEvidence through rejected.operation; no separate generic parent-rejection label is needed. The current runtime supplies neither this complete prefix result nor the rejected parent operation: local parent reporting discards a closed-parent send rejection. Both are explicit AA-30 blockers.

These are named semantic operations. No positional .inner traversal, proxy lane, supervisor report, runtime registry, callback, channel, untyped envelope, or ambient effect occurs inside the fold. A production representation may reuse existing concrete lower-order products only after proving that it preserves every lane, source, ordering, and rejection owner.

Initialization creation is interpreted before dependent observations. For one fold, admission outcomes precede assignments, terminal customer outcomes precede successor assignments, and diagnostics precede a terminal verdict. These interpretation orders are explicit Bombay policies, not general actor- model ordering guarantees.

Ownership table

Transition notation

• AD: submission admission and immediate assignment/queue/rejection.
• WB: worker birth resolution.
• IN: initialization settlement.
• AZ: activation authorization release.
• AS: activation-begin settlement.
• WR: exact readiness.
• WS: exact worker stop.
• DS: assignment delivery settlement.
• CP: exact completion.
• RS / RT: restart schedule settlement / timer fact.
• S0: first shutdown normalization.
• S=: repeated shutdown, no duplicate effects.
• WD: worker drain settlement or exit.
• DDS / DF: drain-deadline schedule settlement / exact deadline.
• F-: preserve semantic ownership and emit one complete rejected-fact diagnostic through the configured disposition.
• NA: Stopped accepts no actor input; late settlements belong to the surviving lifecycle host.

All cells below assume exact creator-local nonce, private worker-birth evidence, role, kind, correlation, and phase. Any mismatch is F-.

Total pool-mode matrix

Submission during drain emits Rejected { request, payload, ShuttingDown }; the customer route and payload never enter pool ownership.

Total operating-member matrix

Creating may observe an exact stop before its birth observation because child report and creation-observation paths have no global arrival order. It stores that one stop. Later commit joins the exact incarnation and resolves it without advertising readiness; later creation rejection plus prior authoritative stop is a contradiction retaining both facts.

Initialization and activation

Initialization emits every preflighted worker creation in declaration order. Each member enters Creating before the action is exposed. Creation rejection retires or stops the pool according to topology failure and never reports a successful birth.

Creation commit enters Initializing { init_attempt }; the lifecycle host retains the unresolved initialization settlement and activation plan. Exact ReadyForActivation transfers its permit and plan into WaitingForActivationAuthorization. Rejected or Stopped transfers its complete plan into DrainingPreReady; neither rolls back the committed worker or begins recovery while an installed actor remains owned.

After every transition that releases activation capacity, AZ scans waiting roles in declaration order. Reserving an ActivationTicket, changing the member to ActivationDispatched, and emitting BeginActivation are one fold. Ticket exhaustion/collision enters DrainingPreReady with complete activation ownership; it cannot leave a silent installed worker waiting forever.

The model accepts begin settlement in either order with worker stop and forced drain; no synchronous interpreter guarantee is assumed. Acceptance enters Activating. Rejection enters DrainingPreReady and returns the complete activation request through exact settlement. Exact Ready releases its ticket and invokes the same fill_fifo transition used after completion and retry. If backlog is non-empty, the member becomes Busy directly; it never transiently commits Idle.

Stop or forced transfer in any occupied activation phase releases exactly one ticket. Late readiness after stop is stale and never restores eligibility.

Admission

Submit { request, payload, customer } evaluates one transaction:

1. reject ShuttingDown or NoRecoverableWorkers before allocation;
2. inspect worker availability and queue occupancy; when no Idle member exists and the new-admission bound is full, reject BacklogFull before allocation;
3. reserve one fresh accepted-job pair { JobId, AdmissionOrdinal }; pair exhaustion/collision rejects with JobCorrelationUnavailable and retires every candidate;
4. if an Idle member exists, reserve one fresh DispatchCorrelation; rejection emits DispatchCorrelationUnavailable and does not fall back to queue admission;
5. prepare the retained execution clone and exact assignment action; unwind produces no transition;
6. commit Busy, advance the cursor, emit Accepted { request, job }, then emit the assignment; or
7. when step 2 proved queue capacity, append the obligation with NeverAssigned in AdmissionOrdinal order and emit Accepted { request, job }.

These branches are disjoint. Full/unserviceable rejection performs no internal allocation; job-pair rejection and immediate-dispatch rejection return the original request, route, and payload; no preparation failure silently queues a job or leaves it accepted without an owner. Every candidate from an uncommitted attempt is retired and never reused.

The Accepted delivery attempt does not gate assignment or queue ownership. Its rejection transfers the complete admission outcome to the lifecycle host; it cannot roll the job back or become its terminal outcome.

FIFO fill and correlation failure

fill_fifo is a pure finite transition applied after readiness, completion, retry insertion, assignment return, or member retirement:

1. maintain the queue sorted by immutable AdmissionOrdinal; a newly retried job is inserted after all smaller ordinals and before all larger ordinals;
2. while both the queue and an exact Idle member exist, inspect the smallest ordinal and the first idle role at or after the cursor;
3. prepare its execution clone and reserve a fresh assignment/completion pair;
4. on success, remove that head, commit the member to Busy, advance the cursor, and append one assignment action;
5. on correlation exhaustion/collision, remove that head and emit exactly one terminal outcome selected by its origin—ReturnedQueued for NeverAssigned, or ReturnedAssigned for Retried—then continue; and
6. on no idle member or empty queue, stop.

Returning a job on correlation failure is necessary because leaving it at the head beside an idle worker would violate the maintained invariant and could wait forever after permanent exhaustion. A clone unwind produces no fold and therefore does not run step 5.

After every committed operating transition:

backlog.is_empty() OR no member is Idle

Assignment settlement and completion

Delivery settlement, completion report, and worker stop have no assumed cross-path order. AssignmentJoin consumes them as follows:

• AwaitingDeliveryAndTerminal + Accepted becomes DeliveryAcceptedAwaitingTerminal.
• AwaitingDeliveryAndTerminal + completion becomes CompletionBeforeDelivery; no customer outcome is emitted yet.
• AwaitingDeliveryAndTerminal + stop becomes StopBeforeDelivery; no interruption outcome or recovery is admitted until delivery settles.
• CompletionBeforeDelivery + stop retains that stop in later_stop.
• StopBeforeDelivery + completion retains the completion in later_completion; stop remains the winning terminal ordering.
• CompletionBeforeDelivery + Accepted resolves Completed, then evaluates its retained later stop once when present.
• StopBeforeDelivery + Accepted applies Fail | Retry once, diagnoses any retained later completion as stale, then evaluates recovery once.
• Any exact Rejected settlement first attempts affine AuthorityReunion. With no retained completion it safely reinserts the proven-unaccepted job by AdmissionOrdinal with its prior assigned role, quarantines the worker, and evaluates any retained stop once. If a completion is already retained, the claimed returned authority contradicts its prior consumption; the fold emits ReturnedAssigned { ContradictoryAssignmentSettlement }, transfers both facts terminally, and begins whole-pool drain.

No branch relies on synchronous settlement. The customer obligation remains in the exact Busy join until one settlement branch selects its disposition. Wrong assignment, child nonce, worker-birth evidence, or phase is F-.

A completion matches the current assignment only when its creator-local child nonce, opaque WorkerBirthEvidence, assignment correlation, and retained non-authorizing half all agree. It never relies on the interpreter attaching an exact incarnation capability. A matching completion after accepted delivery:

1. removes the active correlation;
2. consumes the canonical obligation;
3. emits Completed once;
4. makes the exact member available;
5. runs fill_fifo in the same fold; and
6. commits Idle only if no queued job can be dispatched.

A duplicate, cross-worker, old-birth, unknown-authority, or wrong-phase completion preserves all current state and emits the complete result as a stale operational diagnostic. It never selects a customer route from a tombstone.

Interruption and recovery

An exact stop of Idle makes the role unavailable and evaluates recovery. An exact stop after accepted delivery removes the active completion correlation:

• Fail emits ReturnedAssigned { WorkerStopped } once;
• Retry retains the canonical obligation and reinserts it by immutable AdmissionOrdinal with its prior assigned role; the next dispatch reserves fresh authority only when an exact idle worker is available; and
• dispatch-correlation rejection for that retried head emits ReturnedAssigned { RetryPreparationRejected } once.

Ordered reinsertion handles multiple interrupted workers: if A was admitted before B, stopping A then B still produces [A, B], not [B, A]. Retry is not a new admission: it may exceed the new-admission backlog limit, but the complete queue remains bounded by backlog_capacity + roles.len(). fill_fifo may assign the job to a different exact idle role in the same fold. Because the prior worker may have executed before stopping, this is explicitly at-least-once execution.

The queue retains only the immutable ordinal and whether the obligation was previously assigned to one role. Worker exit and rejected delivery have identical future ordering, dispatch, shutdown, and customer-outcome semantics, so retaining which event caused reinsertion would store history rather than current queue truth. The authoritative stop remains solely in AssignmentJoin until recovery consumes it, then in Recovering; it is never copied into the queued job. Duplicate stop during recovery is F-.

After assignment resolution, recovery eligibility and preparation run from the exact stop. Eligible recovery emits the same typed non-empty worker-source request used by fixed supervision, selecting this one role. Bombay interprets that request outside Behavior and returns its complete generic settlement; the pool owns what the returned submission or rejection means. Worker-source failure, budget denial, clock regression, checked delay overflow, recovery/birth correlation rejection, creation rejection, or schedule rejection applies RetireRole | StopPool. RetireRole runs fill_fifo across surviving members. If no live or recoverable member remains, every queued job receives ReturnedQueued { NoRecoverableWorkers } in FIFO order. StopPool enters the ordinary shutdown normalization rather than dropping jobs through a terminal error.

Shutdown normalization

The first Shutdown atomically:

1. closes admission;
2. removes every queued obligation in FIFO order and emits one ReturnedQueued { PoolShutdown } for each;
3. removes every assigned correlation and emits one ReturnedAssigned { PoolShutdown } for each;
4. disables retry, recovery admission, readiness publication, and successor dispatch;
5. cancels un-emitted prepared replacement and restart-timer ownership;
6. transforms every member into one exhaustive drain member;
7. emits at most one exact shutdown request per committed worker;
8. retains every pending worker creation until commit or rejection; and
9. for deadline policy, reserves and emits one exact drain timer.

The drain sum is:

DrainMember =
    ResolvingCreation {
        role,
        worker,
        activation,
        creation_kind,
        stop: None | Some,
    }
  | Worker {
        role,
        actor,
        work: Created { activation }
            | Initializing
            | WaitingForActivation
            | ActivationDispatched
            | Activating
            | Idle,
        shutdown: NotRequested | Waiting { request, stop },
    }
  | AwaitingWorkerPreparation { role, request }
  | AwaitingRestartSchedule { role, request }
  | Drained { role }

The worker work sum owns actor-side correlations for unresolved initialization, activation, assignment, and shutdown operations; the lifecycle host owns their moved requests and linear values. Customer ownership has already moved to terminal customer outcomes; a late completion is stale diagnostic data and cannot be retained as another job.

Creation rejection enters Drained. An exact creation accepted during drain starts no initialization or activation work. Without a prior stop it emits one shutdown and enters Worker { work: Created { activation }, ... }; the activation value stays local until exact stop transfers it to diagnostic custody. With a prior exact stop, the worker is already retired and the activation transfers immediately. A foreign or reversed result changes no member. Shutdown rejection remains in the existing request/stop reunion while exact stop observation is still possible; rejection alone never completes the drain.

An exact worker stop consumes every matching outstanding child-side settlement, preserves complete unresolved values with the lifecycle host, and enters Drained(Graceful). Repeated shutdown is S=. Late restart, readiness, assignment, and completion facts settle or diagnose their exact cancelled ownership and can never reopen admission or dispatch.

Deadline drain

DeadlinePhase =
    WaitingWithoutDeadline
  | Scheduling { timer: TimerCorrelation, attempt: DeadlineScheduleAttempt }
  | Waiting { timer: TimerCorrelation }
  | Fired { timer: TimerCorrelation, observed_at }

WaitForActorGraph may wait indefinitely. RetireActorGraphAfter uses exact interpreter-authored monotonic time. Deadline correlation reservation failure cannot silently weaken it to unbounded waiting: the rejecting shutdown fold immediately transfers every unresolved member as forced-retirement custody.

Exact schedule acceptance enters Waiting. Exact schedule rejection also forces every unresolved member in that same fold. The residual preserves the complete timer request, rejection reason, worker or birth ownership, and every outstanding action settlement. Exact deadline firing performs the same forced transfer with the deadline fact as cause.

Forced transfer does not fabricate worker stop, assignment acceptance, completion, successful creation, recovery, or customer delivery. The stable root remains alive in lifecycle-host settlement until every transferred external obligation is resolved.

The pool selects normal actor termination only when every member is Drained and every action in the final turn has an exact settlement owner. Unrelated application children never enter this drain.

Stale, overlap, and contradiction laws

• A role alone never identifies a worker fact.
• Birth resolution advances only its exact role, reservation, attempt, and expected birth kind.
• Initialization, activation, and readiness advance only their exact installed incarnation and expected phase.
• Assignment settlement advances only its exact child nonce, private birth evidence, assignment, and AssignmentJoin variant.
• Completion advances only the exact active accepted assignment and consumed opaque authority.
• A completion carrying old worker-birth evidence cannot release a new worker birth's job.
• Stop is consumed once by the exact member or drain state. It cannot admit a second recovery or interruption.
• A recovery schedule or timer advances only its exact recovery and timer generation.
• A delivery rejection cannot roll back already committed job, budget, cursor, or worker state; its complete payload moves to settlement.
• Customer-outcome rejection cannot recreate a queue entry or assignment.
• Contradictory authoritative facts preserve both facts for diagnostic or residual settlement.
• Diagnostic rejection is terminal and non-recursive.

Every rejected fact preserves current semantic ownership and emits one complete RejectedPoolFact through the selected diagnostic disposition.

Feature-catalogue trace

Every row remains a model claim, not implementation status.

Independent-model obligations

The later executable model must use independent vocabulary such as worker cells, one queue, one accepted-job ledger, and one cursor. It must not copy these production-oriented phase names or the eventual implementation branches.

At minimum it must cover:

• empty/duplicate construction, missing policy, zero activation limit, and factory/reservation failure at every role with no partial fleet;
• worker birth commit/rejection and stop-before-birth in both orders;
• initialization and activation acceptance/rejection, limits one and two, and declaration-order authorization;
• readiness with empty and non-empty backlog and no intermediate idle state;
• capacity zero, exact capacity, backlog full, shutdown admission, and no recoverable worker;
• job, assignment, completion, recovery, activation, birth, and timer exhaustion/collision transitions;
• cursor wrap, retired-role skipping, multiple idle workers, and FIFO batches;
• completion followed by successor dispatch in one complete action;
• duplicate, cross-worker, old-worker-birth, wrong-token, and unknown-token completion with result preservation;
• assignment settlement before stop, stop before settlement, and replay of each side;
• completion-before-stop and stop-before-completion under Fail and Retry;
• ordered reinsertion for two or more interrupted workers and immediate reassignment to another idle worker;
• permanent/transient/temporary recovery for normal and abnormal stop, budget boundaries, checked timing, schedule rejection, and restart exhaustion;
• role retirement with surviving capacity and complete stranded-job return;
• admission, customer outcome, assignment, diagnostic, creation, activation, timer, and shutdown delivery rejection;
• shutdown from every member phase, every queued/assigned cardinality, pending birth, pending assignment join, repeated shutdown, and late completion;
• deadline reservation failure, schedule rejection, exact firing, and forced lifecycle-host residual transfer; and
• complete named actions for every accepted and rejected transition.

Properties after every generated step must include:

accepted_jobs = queued_jobs + assigned_jobs + terminally_settling_jobs
queued_jobs <= backlog_capacity + worker_roles
new submission queues only when queued_jobs < backlog_capacity
queued admission ordinals are strictly increasing
each worker has at most one assigned job
each job has at most one terminal customer outcome
backlog.is_empty() OR no worker is Idle
cursor is one position in the immutable declaration-order ring
active completion correlations are unique
retired correlations are never reissued

Falsification findings and comparison obligations

AA-30 records these findings for governing-document reconciliation:

1. Unconditional retry-front insertion reverses two interrupted jobs when stop order differs from admission order. The corrected queue stores immutable AdmissionOrdinal and reinserts by that order.
2. The initial draft stored linear initialization settlement and activation plan in actor state. The corrected model follows AA-01: the lifecycle host owns them while actor state retains only InitAttempt.
3. The initial draft rejected completion before assignment settlement while accepting stop in that order, despite no locked causal guarantee. The corrected AssignmentJoin exhausts settlement, completion, and stop order.
4. ChildReport attaches only a creator-local nonce. The corrected completion law combines that nonce with opaque authority-carried WorkerBirthEvidence; it does not claim an interpreter-attached exact incarnation.
5. The initial retry queue copied the authoritative stop fact. Corrected queue provenance owns only admission ordinal, prior role, and semantic interruption class; the join/recovery path owns the stop once.
6. Rejected assignment delivery returns the affine authority. Corrected AuthorityReunion consumes returned authority and retained non-authorizing evidence exactly once before safe reinsertion.
7. The initial admission outcomes could not correlate concurrent requests on one customer route. Both corrected variants echo caller RequestCorrelation, distinct from pool-issued JobId.
8. The initial admission algorithm allocated before full-backlog rejection and allowed queue fallback to overlap preparation failure. Corrected branches classify first, allocate only for an admissible candidate, and give every preparation failure one typed rejection.
9. Generic settlement labels hid payload ownership and the locked runtime's non-transactional apply/closed-parent-report loss. The corrected model names every operation, exact settlement, applied prefix, rejected operation, and owned unattempted suffix. Concrete lowering remains blocked.
10. Recovery reuses fixed-supervisor policy values but not state; its selected topology failure is RetireRole | StopPool. Backlog capacity bounds new admission while retry preserves the finite absolute capacity + roles queue bound.
11. The current production pool contains stable proxies and a nested fleet ownership fold, exposes assignment/job identifiers to workers, and lacks the selected activation/opaque-authority/deadline laws. It is comparison evidence, not an implementation candidate. Its 550 green tests do not validate this oracle, and the current independent FIFO property model has one worker, so it cannot expose the two-worker retry-order counterexample.

These are falsification findings, not production API amendments. Before an executable task relies on any selected mechanism, the feature catalogue, solution, inventory, retained-core decision, research audit, and interpreter boundary must be reconciled together or the existing concrete boundary must be proved to express the same law unchanged.

First-slice non-features and blocker

AA-30 intentionally provides no:

• Rust pool, worker, job, assignment, completion, recovery, builder, protocol, event, effect, or error type;
• executable fold, model test, property, fuzz target, or benchmark;
• proxy, supervisor, keyed-affinity, shared recovery engine, or nested pool;
• interpreter for creation, activation, assignment, customer delivery, diagnostics, deadlines, or residual root ownership;
• wrapper-composition, initialization-order, compiler/DevX, or migration proof; or
• change to the locked kernel, actors, macros, testkit, runtime, examples, or public API.

The semantic document is complete enough for bounded comparison, but AA-30 is [!], not complete as an executable aggregate prerequisite. H04b proves that assignment.complete(result) lowers one unforgeable private parent completion without exposing a path or customer capability. H02 owns exact report and prefix/suffix action settlement. H03 records the required Bombay custody path; that upstream runtime work is not implemented in this repository. A clean-room FIFO model must still execute the independent-model obligations above before production can cite AA-30 as executable evidence. AA-40 may compare this law, but neither aggregate may extract shared production machinery before the same suite passes both real consumers.

Keyed-pool falsification model

Status and authority

This document is the AA-40 independent semantic model for one keyed worker pool. It is a non-production falsification oracle. It does not select Rust types, define another behavior algebra, implement a pool, or mark a production coverage row implemented. For the clean-room campaign this document owns the keyed aggregate law; lower-authority solution and synthesis documents must be corrected when they disagree. Rust representation remains separately unselected.

The semantic state, input, action, admission, assignment, retirement, and drain sums are complete in this revision. The independent bounded oracles in src/keyed_model.rs and its keyed/recovery.rs child pass in debug and optimized builds. They separately explore 22,621 binding/assignment prefixes and 22,621 recovery/shutdown prefixes. The first rejects deliberate generation reuse, stale mutation, accepted-work retargeting, cross-role queue consumption, and duplicate terminal outcomes. The second rejects candidate loss and worker restart after shutdown while checking one exact worker source, restart schedule, timer, and worker-shutdown owner after every prefix. AA-30 now supplies the first real assignment-authority consumer, and docs/atomic-runtime-settlement.md owns the retained total interpretation and terminal-custody contracts. This oracle does not duplicate either implementation.

The actor-model laws used here are isolated processing of one communication, communications to known recipients, fresh actor creation, and explicit next behavior. Direct worker ownership, key selection, affinity, bounded per-role backlogs, bounded binding retention, generation-safe reuse, opaque completion authority, recovery, action settlement, and actor-graph drain are derived constructions or deliberate Bombay policies. The actor model does not supply keyed-pool semantics.

The keyed pool is one independent aggregate transition. It is not a FIFO-pool wrapper, supervisor, stable proxy, nested behavior, or specialization that stores or forwards another template's state. It may compare AA-30's recorded value laws, but it owns distinct member, partition, binding, management, and transition sums. It may reuse only the separately proven direct-worker and assignment laws; it never depends on FIFO aggregate state.

Runtime route selection is owned normatively by docs/atomic-runtime-settlement.md. The pool issues and stores only a CreationId for each direct worker creation; it never chooses or stores a runtime route before emitting CreateChild. Any older reservation label below denotes that creator-visible correlation before interpretation and routed evidence only in the returned runtime settlement. It does not authorize a separate route request, waiting state, or public route.

The clean-room crates/actors keyed pool is subordinate implementation evidence against this model, never authority for it. It owns direct workers, bounded generation-safe bindings, Unbind, typed management outcomes, and per-role backlogs. Any implementation that instead nests a WorkerPool, routes through stable-proxy nonces, retains unbounded generationless bindings, omits typed management, or admits work to a stopping role is the obsolete architecture falsified by this model; it is not a parallel keyed-pool design.

The model must falsify designs that make any of these claims false:

1. The worker roster is non-empty, ordered, and contains each semantic role once.
2. Every installed or replacement worker is freshly created. Role, key, binding generation, route, and correlation are not actor identity.
3. One submitted key is separate from its owned payload and is evaluated by one concrete selector only when no binding is retained.
4. A binding proposed by admission commits if and only if the same transition accepts the submitted customer obligation. An explicit management rebalance may instead bind an absent key without submitting work.
5. Binding capacity and per-role backlog capacity are distinct bounds. Zero backlog capacity lawfully permits immediate assignment only.
6. Every accepted job permanently retains its admitted role. Rebalance, unbind, retry, and worker replacement cannot retarget it.
7. Work for one role never consumes another role's backlog capacity or idle worker.
8. Every live member phase projects to exactly one of AssignableNow, BacklogAdmissible, or Unavailable, without a wildcard or inferred readiness.
9. No serviceable queued job for a role coexists with that role in eligible idle state after a completed transition.
10. Each role has at most one active assignment. Completion matches opaque authority, exact worker-birth evidence, retained role, and active phase.
11. Rebalance and unbind change future admission only. Every accepted queued or assigned job retains its original role and single customer obligation. Every management mutation is guarded by an exact absence or generation expectation.
12. Reusing an unbound key receives a fresh opaque binding generation. Late management inputs for an absent or different generation cannot mutate it.
13. The transition that makes a role permanently unusable returns that role's queued and assigned work once, removes every retained binding to the role atomically, releases binding capacity, and diagnoses each removed key and generation. Temporary recovery retains bindings.
14. Shutdown closes admission, returns every accepted job from every role once, removes all bindings, and drains every owned or still-creating worker.
15. Stale, duplicate, foreign, wrong-role, wrong-generation, wrong-worker- birth, and contradictory inputs preserve current ownership and have an explicit diagnostic disposition.
16. Every accepted input produces one next state and one complete named action product. No effect is ambient.

“Atomic” means one local Behavior transition commits one keyed-pool state and its complete Actions. It does not claim atomic delivery, creation, worker execution, external activation, or customer observation across actors.

Model vocabulary

The following names are oracle vocabulary, not proposed public Rust names.

Role = one semantic worker label, unique inside this pool
RoleOrder = immutable declaration order retained for the pool lifetime

Key = caller-supplied semantic affinity key
BindingGeneration = fresh opaque non-reused correlation
Binding = { key: Key, generation: BindingGeneration, role: Role }
AdmittedBindingEvidence = opaque copyable { generation: BindingGeneration, role: Role }

WorkerBirthAttempt = fresh non-reused CreationId issued by the pool
RoutedWorkerBirth = interpreter-private { attempt: WorkerBirthAttempt, route }
WorkerBirthEvidence = opaque non-routable evidence for one committed birth
WorkerRecipient = pool-private routable capability for one committed worker
CurrentWorker = { recipient: WorkerRecipient, evidence: WorkerBirthEvidence }

RequestCorrelation = caller-authored opaque submission correlation, echoed only
JobId = fresh non-reused customer-visible correlation issued by the pool
AdmissionOrdinal = fresh non-reused private total order for one accepted job
AssignmentId = fresh non-reused private correlation for one dispatch attempt
CompletionAuthority = opaque affine authority bound to assignment and worker birth
CompletionCorrelation = pool-retained non-authorizing half of that authority

ManagementRequest = fresh caller-visible correlation
BindingExpectation = Absent | Exact(BindingGeneration)
RebalanceCommand = {
    request: ManagementRequest,
    key: Key,
    expected: BindingExpectation,
    target: Role,
    reply: ManagementRoute,
}
UnbindCommand = {
    request: ManagementRequest,
    key: Key,
    expected: BindingExpectation,
    reply: ManagementRoute,
}
ManagementCommand = Rebalance(RebalanceCommand) | Unbind(UnbindCommand)
RecoveryTicket = fresh non-reused correlation for one role recovery
ActivationTicket = fresh non-reused authorization occupancy correlation

BindingGeneration, like every other correlation above, is not an actor identity. It is allocated freshly for a newly committed binding rather than derived from a per-key counter. Removing a binding therefore leaves no permanent key tombstone. A later use of the same key obtains a fresh generation from the fallible allocator.

Binding is the sole pool owner of its retained Key. A job accepted through that binding receives only AdmittedBindingEvidence; it does not clone, own, or keep the key. Multiple jobs may copy the non-authorizing evidence without creating a binding, changing affinity, or extending binding retention. A rejected admission or management command returns its one complete owned key.

The selector is one concrete statically known function Fn(&Key) -> Role. It cannot select an address, nonce, worker birth, customer route, assignment lane, or behavior implementation. Its output is validated against the immutable semantic roster. It is evaluated at most once for one unbound submission and is not evaluated for an already-bound key.

Every correlation allocator is total:

Reservation<T> = Reserved(T) | Rejected(Exhausted | Collision { candidate: T })

Rejection never wraps, overwrites, reuses, or guesses a correlation. A later transition table must name the complete owner returned by every allocation failure before this model can be complete.

Construction domain

KeyedPoolDefinition = {
    initial_factory,
    roles: NonEmptyOrderedUnique<Role>,
    selector: one concrete Fn(&Key) -> Role,
    activation: ActivationContract,
    activation_limit: PositiveMaximum,
    recovery: RecoveryPolicy,
    backlog_capacity_per_role: NonNegativeMaximum,
    binding_capacity: PositiveMaximum,
    interruption: Fail | Retry,
    actor_drain: ActorDrainPolicy,
    diagnostics: DeliverTo { route } | Terminate,
}

ActorDrainPolicy =
    WaitForActorGraph
  | RetireActorGraphAfter { deadline }

Construction fails for an empty or duplicate roster, zero activation limit, zero binding capacity, invalid drain deadline, missing selector or policy, or a worker protocol that cannot accept the exact assignment product. Backlog capacity is non-negative because zero is immediate-assignment-only. There is no global backlog capacity and no FIFO placeholder selector.

The worker sum may be heterogeneous only when every variant accepts one common concrete assignment protocol and produces one common concrete result type. Static closed sums are allowed; erasure, a runtime registry, and downcasting are not.

AA-40 selects no builder spelling, typestate, public identifier representation, trait, wrapper, alias, or macro.

Top-level ownership state

KeyedPoolState =
    Operating {
        definition,
        roles: OrderedRoleTable,
        bindings: BoundedBindingMap,
        activation: ActivationCapacity,
        budget: RestartBudget,
        allocators,
    }
  | Draining {
        definition,
        roles: OrderedDrainRoleTable,
        bindings: DrainingBindingMap,
        deadline: DeadlinePhase,
        allocators,
    }
  | Stopped

The Rust aggregate also has Constructed, which owns the prepared worker roster before initialization, and ForcedRetirement, which owns unresolved retiring workers plus the exact shutdown-ID or deadline failure after a terminal transition. The sketch above describes the operating law; those two additional source states preserve initialization rejection and terminal custody. A real interpreter still has to prove transfer of the ForcedRetirement value to the parent or root custodian.

OrderedRoleTable has exactly one RoleCell for each declared role. One cell owns both that role's member phase and its FIFO queue; there is no separately mutable member map and partition map whose phases can disagree. Roles are never inserted, removed, compacted, or reordered. Retired membership remains a terminal role cell so late inputs and binding removal never depend on index arithmetic. Irrecoverable is a transition cause, not a second retained terminal phase.

BoundedBindingMap owns at most binding_capacity entries. It contains only currently retained bindings. Absence is not stored. Unbind and the transition committing permanent role unavailability delete entries and release capacity immediately. Queued and assigned work does not keep a binding entry alive; it owns admitted-binding evidence and its admission record independently.

Each role partition owns one FIFO queue with its own full backlog_capacity_per_role. A job admitted to role R can inhabit only R's queue or active assignment state. It cannot consume the queue budget of role S, even when S is idle. Retry reinserts within the same role by immutable admission ordinal rather than unconditional front insertion.

Accepted-work ownership

CustomerObligation = {
    job: JobId,
    admitted_at: AdmissionOrdinal,
    admitted_binding: AdmittedBindingEvidence,
    customer: CustomerRoute,
    retained_payload,
}

QueuedJob = {
    obligation: CustomerObligation,
    origin: NeverAssigned | Retried { interruption },
}

AssignedJob = {
    obligation: CustomerObligation,
    assignment: AssignmentId,
    completion: CompletionCorrelation,
    worker: CurrentWorker,
}

One accepted job has one authoritative CustomerObligation. It is owned by exactly one per-role queue, exact member assignment, or terminal settlement. The admitted-binding evidence is historical correlation data; it neither owns the key nor preserves or recreates a removed binding. The caller's RequestCorrelation is moved into the emitted Accepted admission outcome and is not retained in actor state. Retry may retain a canonical payload while an execution value has escaped to a worker, but that represents one semantic obligation and explicitly at-least-once execution, not exactly-once external side effects.

Total admission target eligibility

Admission never asks whether a role is merely “alive” or “eventually ready.” It exhaustively projects the exact member phase:

AdmissionTargetEligibility =
    AssignableNow { current_worker }
  | BacklogAdmissible
  | Unavailable { reason }

AssignableNow = ReadyIdle

BacklogAdmissible =
    Prepared
  | Creating
  | Initializing
  | WaitingForActivationAuthorization
  | ActivationDispatched
  | Activating
  | ReadyBusy
  | RecoveryAdmitted
  | DrainingPreReady { after_drain: ResumeRecovery }

Unavailable =
    Stopping
  | Retired
  | DrainingPreReady { after_drain: Retire }
  | ShutdownOwned

The projection is a total match over the eventual complete keyed-member sum. DrainingPreReady is classified from its stored exhaustive disposition, not from a cause, timer, or inferred future. A new or existing binding can accept to BacklogAdmissible only when that role's queue has capacity.

For an unbound submission, selection, role validation, binding-generation reservation, job/ordinal reservation, capacity checks, and either immediate assignment preparation or queue insertion preparation all succeed before one binding and one customer obligation commit together. Any rejection returns the complete submission and retains neither proposed binding nor job. The detailed failure and transition sums are enumerated below.

Generation-safe management

Management target eligibility is a separate total projection because a rebalance admits no job and therefore asks neither immediate assignability nor queue capacity:

ManagementTargetEligibility =
    Bindable
  | Unavailable { reason }

Bindable =
    Prepared
  | Creating
  | Initializing
  | WaitingForActivationAuthorization
  | ActivationDispatched
  | Activating
  | ReadyIdle
  | ReadyBusy
  | RecoveryAdmitted
  | DrainingPreReady { after_drain: ResumeRecovery }

Unavailable =
    Stopping
  | Retired
  | DrainingPreReady { after_drain: Retire }
  | ShutdownOwned

An unknown role is UnknownTarget, not an eligibility member. An irrecoverable input synchronously chooses and commits a permanently unavailable member transition; it is never retained as a parallel member phase. Temporary RecoveryAdmitted and DrainingPreReady { ResumeRecovery } remain bindable and retain existing bindings. Entering terminal pre-ready drain, Stopping, Retired, or global shutdown ownership atomically extracts every binding for that role. Thus no permanently unusable role retains future-admission affinity.

The management protocol is exhaustive:

ManagementOutcome =
    BoundAbsent {
        request,
        current: AdmittedBindingEvidence,
    }
  | Rebalanced {
        request,
        prior: AdmittedBindingEvidence,
        current: AdmittedBindingEvidence,
    }
  | RebalanceUnchanged {
        request,
        current: AdmittedBindingEvidence,
    }
  | Unbound {
        request,
        removed: Binding,
    }
  | AlreadyUnbound {
        command: UnbindCommand,
    }
  | Rejected {
        command: ManagementCommand,
        reason:
            StaleExpectation { actual: Absent | Exact(BindingGeneration) }
          | UnknownTarget
          | TargetUnavailable
          | BindingCapacityExhausted
          | GenerationReservationRejected
          | ShuttingDown,
    }

Successful management outcomes need not echo a key: absent rebalance moves the command's key into Binding; successful existing rebalance retains the table's existing key; successful unbind returns the removed Binding and its key. Every rejected outcome returns the complete command unchanged.

ManagementRoute follows the same explicit capability-clone custody law as the customer route. The transition prepares one target clone before committing a rejected outcome so the original route can remain inside the returned command. A successful outcome consumes the command route as its delivery target and does not retain it. Rejected outcome delivery returns the target clone and the complete command, including the original route. This duplicates routable capability data only; request, key, expectation, and generation evidence remain single semantic values.

For a key absent from BoundedBindingMap:

For a key bound at exact generation g to role r:

Expectation comparison precedes target validation. No stale command can observe a later binding and then mutate it. Role-changing rebalance prepares the fresh generation before replacing the old binding, so allocation failure cannot leave an absent entry. Same-role rebalance deliberately preserves the generation: a management request that changes no affinity does not invalidate otherwise exact later inputs.

Complete role and worker sum

RoleCell = {
    role,
    member: KeyedMember,
    backlog: Fifo<QueuedJob>,
}

KeyedMember =
    Prepared { submission, reservation, kind }
  | Creating { reservation, kind, prior_stop }
  | Initializing { worker, kind, init_attempt }
  | WaitingForActivationAuthorization { worker, kind, permit, plan }
  | ActivationDispatched { worker, kind, ticket, begin_attempt }
  | Activating { worker, kind, ticket, activation_attempt }
  | DrainingPreReady { worker, outstanding, cause, after_drain }
  | Idle { worker }
  | Busy { worker, assigned: AssignedJob, join: AssignmentJoin }
  | Recovering { predecessor, stop, phase: RecoveryPhase }
  | Stopping { worker, outstanding, after_stop }
  | Retired { reason }

BirthKind = Initial | Replacement { recovery, replaces: WorkerBirthEvidence }
AfterPreReadyDrain = ResumeRecovery { stop } | Retire { reason }
AfterWorkerStop = Retire { reason } | StopPool { reason }

Each RoleCell owns at most one active assignment and one queue. Only Idle is assignable. A worker becoming ready first inspects its own role queue and commits directly to Busy when work exists; it commits Idle only when that queue is empty.

The direct-worker creation, initialization, activation, and exact-stop law is identical to AA-30: fresh creation commits before initialization settlement; the lifecycle host owns affine initialization and activation work while the actor retains exact correlations; readiness requires committed birth, successful initialization, accepted activation, and exact readiness proof; post-commit failure drains before recovery or retirement. This document uses that shared value law but does not embed FIFO aggregate state, cursor, or global queue behavior.

Activation occupancy is derived from ActivationDispatched and Activating. Waiting roles are released in immutable roster order. Reserving a ticket, moving permit and plan to the activation action, and storing the dispatched phase are one transition. Ticket failure drains the installed worker with the complete activation ownership; it never strands a silent worker.

Recovery sum

RecoveryPhase =
    Scheduling { recovery, timer, prepared, schedule_attempt }
  | WaitingForTimer { recovery, timer, prepared }
  | ReadyToCreate { recovery, prepared }

PreparedReplacement = {
    submission,
    reservation: WorkerReservation,
    checked_release,
    charge,
}

Recovery is one role at a time. It shares the complete Permanent | Transient | Temporary eligibility, inclusive monotonic restart limit, checked immediate or delayed release, and exact timer-correlation law with AA-30. It owns no fixed strategy and selects RetireRole | StopPool on topology failure. Permanent and transient recovery retain a typed worker source; temporary recovery retains no source. Eligible recovery selects one role through the same non-empty worker-source request as AA-30. Bombay executes the request outside Behavior; the keyed pool alone interprets the returned submission or rejection.

Temporary recovery preserves every binding to the role. A terminal recovery decision enters permanent role unavailability below. Factory, budget, clock, release, timer, reservation, creation, initialization, or activation failure cannot silently shrink ownership or fabricate a ready worker.

Admission protocol and outcomes

KeyedPoolInput =
    Submit { request, key, payload, customer }
  | Rebalance(RebalanceCommand)
  | Unbind(UnbindCommand)
  | Shutdown
  | WorkerBirthResolved(WorkerBirthResolution)
  | InitializationSettled(InitializationSettlement)
  | ActivationBeginSettled(ActivationBeginSettlement)
  | WorkerReady(WorkerReady)
  | WorkerStopped(WorkerStopped)
  | AssignmentSettled(AssignmentSettlement)
  | WorkerCompleted { child: ChildRouteNonce, completion: CompletionEvidence }
  | RestartScheduleSettled(RestartScheduleSettlement)
  | RestartTimerElapsed(RestartElapsed)
  | WorkerShutdownSettled(WorkerShutdownSettlement)
  | DrainDeadlineSettled(DeadlineScheduleSettlement)
  | DrainDeadlineElapsed(DrainDeadlineElapsed)

AdmissionOutcome =
    Accepted { request, job, binding: AdmittedBindingEvidence }
  | Rejected { request, key, payload, customer, reason }

AdmissionRejection =
    ShuttingDown
  | BindingCapacityReached
  | UnknownSelectedRole
  | RoleUnavailable
  | RoleBacklogFull
  | NoRecoverableWorkers
  | BindingGenerationUnavailable
  | JobCorrelationUnavailable
  | AssignmentCorrelationUnavailable

The customer route follows one explicit clone law. Before commit, the transition clones it once: the clone targets the admission outcome, while the original moves to the accepted CustomerObligation or the rejected outcome. Rejected delivery therefore returns a complete delivery containing the targeting clone and the original route. Payload, key, customer obligation, and completion authority are never cloned by this rule.

Admission is one transaction:

1. reject global shutdown or absence of every serviceable or recoverable role;
2. borrow the submitted key to search the binding table;
3. for an existing binding, bypass the selector and use its exact role and generation;
4. for an absent binding, invoke the selector exactly once, validate the role, check binding capacity, and reserve a fresh generation;
5. project the exact role phase to AssignableNow, BacklogAdmissible, or Unavailable and check only that role's queue capacity;
6. reserve fresh job and admission-ordinal correlations;
7. for immediate assignment, reserve the assignment/completion pair and prepare execution and customer-route clones; preparation failure does not fall back to queuing;
8. commit a proposed binding if and only if the same transition commits the customer obligation; and
9. emit acceptance followed by assignment, append to that role's queue, or return the complete unchanged submission through one rejection.

No Key: Clone law follows from this transition. An absent accepted key moves into Binding; an existing binding already owns its key and the submitted equal key is consumed by the accepted command. Rejection returns the submitted key. A concrete map representation may impose only the comparison or borrowing law actually needed; compiler convenience cannot strengthen it to cloning.

Zero per-role backlog capacity permits immediate assignment and rejects waiting ownership. A retry may temporarily make one role's queue length capacity + 1, because that role has at most one interrupted assignment. It is inserted by immutable AdmissionOrdinal, never at the unconditional front.

After every operating transition, independently for each role:

role.backlog.is_empty() OR role.member is not Idle

No fill operation can consume another role's queue or worker.

Assignment and completion law

The complete AssignmentJoin and affine AuthorityReunion law is identical to AA-30 and is applied inside one RoleCell:

AssignmentJoin =
    AwaitingDeliveryAndTerminal { delivery }
  | DeliveryAcceptedAwaitingTerminal
  | CompletionBeforeDelivery { delivery, completion, later_stop }
  | StopBeforeDelivery { delivery, stop, later_completion }

Delivery acceptance, rejection, completion, and exact worker stop are accepted in every runtime-permitted order. Completion matches only the child nonce, opaque worker-birth evidence, assignment, retained non-authorizing half, admitted role, exact worker birth, and active phase. Binding-table contents are not part of completion matching and cannot retarget accepted work.

Matching completion emits one Completed outcome and fills only the admitted role's oldest queue entry. Matching exit after accepted delivery applies Fail | Retry once; retry retains the admitted role and reinserts by ordinal in that same role. Assignment rejection must reunite the returned affine authority with the retained half before the proven-unaccepted job can requeue. Mismatch or a completion that already consumed the authority transfers both inputs terminally and begins whole-pool drain. Duplicate, stale, foreign, old-birth, or wrong-role completion preserves current ownership and transfers the complete result through diagnostics.

Exactly one terminal customer outcome exists for each accepted job:

TerminalCustomerOutcome =
    Completed { job, role, result }
  | ReturnedQueued { job, role, payload, reason }
  | ReturnedAssigned { job, role, payload, reason }

QueuedReturnReason =
    PoolShutdown
  | RolePermanentlyUnavailable
  | NoRecoverableWorkers
  | DispatchCorrelationUnavailable

AssignedReturnReason =
    PoolShutdown
  | RolePermanentlyUnavailable
  | WorkerStopped
  | AssignmentReturnedUnaccepted
  | RetryPreparationRejected
  | ContradictoryAssignmentSettlement

Removal from the queue or member precedes emission. Rejected customer delivery transfers the complete outcome outward and never recreates work.

Permanent role unavailability

Temporary recovery retains role bindings. The transition selecting permanent unavailability atomically creates one RoleRetirement:

RoleRetirement = {
    role,
    queued: [QueuedJob],
    assignment: NoAssignment | AssignmentDrain { assigned, join },
    bindings: [Binding],
    worker: WorkerDrain,
    cause,
}

In that transition:

1. admission and management projection for the role becomes unavailable;
2. every queued obligation is extracted in admission order and moved to one ReturnedQueued outcome;
3. an active assignment loses retry authority and moves with its complete join to terminal assignment settlement; it produces completion if completion had already lawfully won, otherwise exactly one ReturnedAssigned;
4. every binding whose role matches is removed from the table, releasing capacity immediately;
5. each complete removed Binding moves to one diagnostic containing its key, generation, role, and cause; and
6. the exact worker and all outstanding effects enter drain.

The table is the only key owner. Jobs retain only generation and role evidence, so binding extraction never needs to clone a key and never invalidates customer ownership. A rejected diagnostic transfers its complete removed binding to the lifecycle host; it cannot restore the table entry.

No later rebalance, unbind, completion, recovery, or worker-ready input can revive the retired role. Another role remains independently serviceable.

Required semantic action product

KeyedPoolActions = {
    worker_creations,
    worker_creation_observations,
    worker_stop_observations,
    activation_begins,
    activation_cancellations,
    role_assignments,
    worker_shutdowns,
    restart_schedules,
    deadline_schedules,
    admission_deliveries,
    management_deliveries,
    terminal_customer_deliveries,
    diagnostic_deliveries,
    terminal_diagnostic_transfers,
    rejected_input_transfers,
    forced_drain_transfers,
}

WorkerCompletionActions = {
    parent_completion_reports,
}

Each field is a concrete named typed lane, not a generic pool envelope or a flattened FIFO aggregate product. Generic item interpretation and settlement are owned only by atomic-runtime-settlement.md: accepted items leave their receipt, rejected items return the complete request, blocked items retain the exact prerequisite, independent later items continue, and corruption retains the committed prefix plus exact remainder. Creation is the prerequisite only for operations using its uncommitted child binding.

Interpretation order is creation before its exact dependents; management and admission outcomes before assignments they announce; terminal customer outcomes before successor assignments; per-role assignments in roster order when one transition releases several roles; and diagnostics before a terminal verdict. These are Bombay policies, not actor-model guarantees.

Total mode and member matrices

Every cell means exact role, reservation or worker birth, generation where applicable, operation kind, assignment, worker-birth evidence, and phase. Mismatch preserves state and moves the complete input to one non-recursive diagnostic. Management expectations are evaluated by their separate exhaustive tables above and never by this lifecycle matrix.

Shutdown normalization and drain

The first Shutdown atomically:

1. closes submission and management admission;
2. extracts and removes every binding, moving each complete key, generation, and role value to terminal custody or a selected binding-removal diagnostic;
3. extracts every per-role queue in role order and FIFO order and emits one ReturnedQueued { PoolShutdown } per obligation;
4. removes the customer right from every active assignment and emits exactly one ReturnedAssigned { PoolShutdown }; any retained completion becomes stale diagnostic ownership and the remaining affine delivery join moves to drain;
5. disables dispatch, retry, recovery admission, and readiness publication;
6. retains pending creation, initialization, activation, assignment, timer, and shutdown settlement ownership in one exact drain role;
7. emits at most one shutdown per committed direct worker; and
8. reserves and emits one exact deadline request for deadline policy.

DrainRole =
    ResolvingBirth { role, reservation, local_values, prior_stop }
  | DrainingWorker { role, worker, outstanding, stop_phase }
  | Drained { role, result: Absent | Graceful | Forced { residual } }

DeadlinePhase =
    WaitingWithoutDeadline
  | Scheduling { timer, attempt }
  | Waiting { timer }
  | Fired { timer, observed_at }

Repeated shutdown emits nothing twice. Birth rejection is Absent; birth commit is drained; commit plus prior authoritative stop is a contradiction, not readiness. Shutdown rejection retains the request and reason while exact stop observation remains live.

Deadline reservation or scheduling rejection cannot weaken the configured bound into an infinite wait. It transfers every unresolved role, binding removal, assignment join, child operation, timer, and external authority to Forced { residual }. Exact deadline firing does the same. It fabricates no stop, readiness, completion, acceptance, or recovery. The pool selects normal termination only when every role is drained and every final action has an exact settlement owner.

Stale, overlap, and conservation laws

• Key equality alone never matches a management input after generation changes.
• A role alone never identifies a worker or assignment input.
• Binding expectation comparison precedes target validation and mutation.
• Birth, initialization, activation, stop, recovery, assignment, and completion inputs advance only exact retained correlations and phases.
• Rebalance, unbind, recovery, replacement, and retry never retarget accepted work.
• One role cannot consume another role's queue capacity or idle worker.
• A removed binding generation is never reissued or inferred from arithmetic.
• Customer, management, diagnostic, and rejected-input delivery rejection never rolls back committed state and returns the complete value.
• Contradictory authoritative inputs retain both values in terminal custody.
• Diagnostic rejection is terminal and never recursively diagnosed.

After every generated step:

accepted obligations = queued + assigned + terminally settling
retained bindings <= binding capacity
each retained key has exactly one fresh generation and one role
each accepted job has one immutable admitted role
each role has at most one assignment
each job has at most one terminal customer outcome
each role queue is ordinal-ordered and <= backlog capacity + 1
role queue is empty OR its member is not Idle
permanently unavailable roles retain no binding

Feature trace and executable evidence

The independent keyed_model uses bins, leases, work slips, and service cells rather than these specification names. Its focused tests cover two roles and keys, zero and one capacity limits, every member eligibility, absent and exact expectations, same-role and cross-role rebalance, unbind and reuse, stale generations, permanent retirement, assignment delivery/completion/stop permutations, retry ordering, shutdown, and forced residuals. A depth-four enumeration checks the complete invariant set after all 22,621 prefixes. Its keyed/recovery.rs child uses a workshop, ordered bays, one recruiter, and a candidate-ownership map. A separate depth-four enumeration checks 22,621 recovery/shutdown prefixes, including concurrent stops, declaration-order source release, preparation returned during shutdown, all restart-schedule dispositions, accepted-timer cancellation, and both worker receipt/exit orders.

The inversion tests corrupt each of the seven named laws independently. The audit rejects generation reuse as GenerationReused, stale mutation as StaleMutation, accepted-work movement as QueueLocation, cross-role assignment as AssignmentRole, and double settlement as DuplicateTerminal.

AA-30's feature-complete production slice now supplies the first real opaque completion and affine-authority consumer. Generic total interpretation and terminal custody remain owned by docs/atomic-runtime-settlement.md. AA-40 is the retained keyed semantic oracle; production lowering must reuse those contracts rather than reopen or duplicate them.

The retained production startup checkpoint uses one passive direct-worker transition owner for both AA-30 and AA-40 successful creation, initialization, activation start, and readiness. AA-40 alone locates the role, applies activation capacity, and drains that role's queue. A Primary job queued before readiness is not consumed when Replica becomes ready; the deliberate cross-role inversion fails at that exact assertion. Foreign worker identity, wrong creation kind, foreign initialization, foreign activation, and duplicate activation start all retain the selected role and move the complete input to diagnostics. Assignment reunion, recovery, permanent role extraction, and shutdown now have clean-room production witnesses. Catalogue-wide compatibility, Bombay runtime lowering, and the final fixed-point audits remain open; this document does not claim those wider gates.

The production recovery suite also crosses shutdown after the exact restart schedule has been accepted and before its timer arrives. A drop-tracked worker submission remains owned by the terminal cancellation diagnostic until that action is released; shutdown emits no replacement creation and stops immediately. Deliberately dropping the submission during the shutdown transition fails at the ownership assertion.

Engineering records

These documents preserve the design campaign behind Bombay Behavior: research classification, candidate type inventories, acceptance targets, verification evidence, downstream-impact analysis, and audit results. They remain published for traceability, but they are not an additional public API surface.

The canonical contracts, actor catalogue, normalized aggregate laws, current crate documentation, and production types govern whenever terminology or an intermediate proposal in these records differs from the retained design.

The repository quality audit and checklist records the 2026-09-28 review of all workspace crates, verified gaps, and completion criteria for further simplification and testing work.

The interpreter ownership and startup PRD uses the current working code as its baseline. It specifies complete assignment and proxy rejection return, generic retained acceptance, coherent creation and initialization custody, and downstream interpreter acceptance tests. It also defines staged implementation gates before broader consolidation.

Repository quality audit and completion checklist

Audit date: 2026-09-28. Baseline: 435560ce7bea8ad3330ee2d42e5034f837a80602. Scope: all five workspace crates, their test and benchmark targets, the nested macro fixture and fuzz workspaces, public documentation, and verification gates.

The repository has a substantial typed algebra and meaningful adversarial tests. It also has gaps between its documented contracts, current composition surface, and what the tests prove. Address those gaps before expanding the catalogue. The best initial reductions are redundant test interfaces and dependencies, repeated effect-product machinery, and stale documentation. Aggregate state must be reduced only after proving that the removed distinction is unnecessary.

This is an audit and work list, not a claim that every branch is verified. All crates were inventoried; manual review covered public entry points, effect and creation interpretation, every actor family, representative transitions and test oracles, macros, and tooling. Source scans supplement that review. No line or branch coverage measurement, complete mutation campaign, or downstream Bombay Engine integration run was performed for this audit. Production code and existing tests were not changed at the audited baseline. Repairs made on the working branch are recorded below.

Inventory and interpretation of the evidence

Counts below are physical Rust lines, including comments and inline tests. They measure review surface, not essential complexity or production-only size. Integration counts include Rust support modules and macro fixture sources.

The fuzz manifest declares 21 binaries. Its target directory has 28 Rust files; the additional files include support modules and must not be counted as seven missing campaigns. The scheduled workflow currently lists all 21 binaries. There are also two benchmark programs and one core example.

Evidence labels used below:

• Confirmed: directly visible in source or reproduced by a focused probe.
• Coverage gap: the cited test or gate cannot establish the stated law; this does not by itself prove a production failure.
• Design candidate: a bounded investigation with explicit acceptance criteria; it is not authorization to introduce a new abstraction.

Priority: P1 affects contract correctness or trust in verification; P2 affects maintainability, developer experience, or breadth of evidence; P3 is supporting cleanup. Check an item only after its completion evidence is recorded against a revision.

Behavior release boundary

This branch completes and releases the five Behavior workspace crates. A17's production Bombay interpreter witness and the PRD's Bombay/Address runtime packages follow the Behavior release against immutable published versions. They remain open handoff obligations with their original acceptance criteria; their absence must not be described as a passing downstream test or silently used to change the Behavior algebra. Finish the Behavior-owned A12, A13, and A20 reviews and required Behavior gates before merging this branch to main. The release workflow creates its version PR after successful main CI, then publishes from the versioned main revision. Record those CI and publication outcomes separately from the later Bombay integration result.

P1 — close contract and verification gaps

• A01 — Reconcile creation, installation, and initialization ordering. Confirmed document conflict. docs/actor-transition-algebra.md, “Fresh creation,” orders initialization and its effects before installation. docs/atomic-runtime-settlement.md, “Initialization and activation order,” orders installation commit before the pure initialization fold, and describes InitializeWorker after ChildCreationOutcome::Established. actor/creation.rs::ChildCreationOutcome additionally represents initialization and host rejection before successful establishment. A runtime author cannot implement both descriptions as one unconditional order. Complete when: one normative contract distinguishes definition initialization, effect settlement, endpoint establishment, activation, and ordinary ingress; all canonical docs agree, and an interpreter trace proves the order plus each rejection and initialization-stop case. Any distinction between ordinary and atomic workers must be explicit and compositional. Classification: deliberate Bombay policy and derived composition, not a new actor-model guarantee. Resolve the law before changing production semantics.

• A02 — Support ordinary, unrenamed Cargo dependencies in both macros. Confirmed source defect; external probe recorded below. behavior-macros/src/lib.rs::crate_path emits the name returned by proc_macro_crate. The manifests expose libraries named behavior and behavior_actors, while unrenamed package keys are bombay-behavior and bombay-behavior-actors. Facade resolution already compensates for this package/library distinction; direct dependency resolution does not. Current fixtures rename the direct dependencies, which avoids the failing case. Complete when: external consumers compile #[behavior] and #[pool_worker] with unrenamed dependencies, renamed dependencies, facade only, renamed facade, and direct plus facade dependencies. Preserve the existing missing-dependency diagnostic. Use a failing consumer fixture before editing expansion paths.

• A03 — Restore logical-host projection through atomic actor products. Confirmed missing composition. actors/src/atomic/requests.rs derives send interpretation and settlement but not LogicalDeliveryProtocols. FifoRequests, KeyedRequests, FixedSupervisorRequests, and DynamicSupervisorRequests use this macro. The handwritten ProxyEffects also lacks this projection. There are no atomic implementations in actors/src/requirements.rs either. The current behavior-testkit/tests/logical_host_requirements.rs proves a synthetic DeliveryOutcomes tree, not these actual atomic families. Complete when: real FIFO, keyed, fixed, dynamic, and proxy compositions satisfy the documented projection, including transitive children and two wrapper orders. Assert exact ordered protocol products and duplicate occurrences. Audit CustomerDelivery and DiagnosticAction as part of the law: their logical routes must not disappear merely because they travel in InterpreterRequests, whose current projection is empty for every item. An empty blanket implementation is not a repair.

• A04 — Make compile-denial tests fail for the intended reason. Confirmed false-positive examples. The ChildRoute compile-fail example in actors/src/composition/message_adapter.rs imports a removed type, so it does not prove rejection of a current creator-local capability. The ActivationPermit duplicate-move example in actors/src/atomic/worker/initialization.rs omits the required W: Behavior and endpoint bounds. It can fail before testing affine ownership. The incomplete-interpreter example in behavior/src/actor/creation.rs also used an implementation signature that obscured the missing child-host bound. Complete when: each safety fixture has a compiling lawful counterpart; one deliberate invalid operation produces the intended diagnostic. Exercise the counterfactual by removing that invalid operation or weakening the relevant invariant in an isolated probe. Keep removal-of-obsolete-name tests separate from capability-denial evidence. Rustdoc compile_fail alone proves that compilation fails, not why it fails.

• A05 — Make the mutation verdict reject malformed and incomplete runs. Confirmed source defects; adversarial probe recorded below. mutants-gate/src/main.rs::usable rejects a failed baseline if present but does not require a successful baseline. tallies counts Failure and Success mutant outcomes toward completion while treating them as neither missed nor timed out. check matches counts per function, so duplicated outcomes can substitute for a different candidate in that same function. Three tests cover a clean run, a survivor, and a failed baseline only. Complete when: the gate verifies an explicitly supported baseline mode, exact candidate/outcome correspondence, valid outcome categories, missing and duplicate outcomes, unknown candidates, timeouts, viability collapse, stale baseline entries, malformed input, and command exit status. Include a case with a caught mutant plus a failed mutant at an otherwise satisfied floor. Reuse the report's actual candidate identity; function counts alone cannot prove campaign completeness.

• A06 — Strengthen partial property-test oracles to complete observations. Coverage gap. In behavior-testkit/tests/catalogue_models.rs, the sequencer model checks delivery payloads and state, but not outcome messages, destinations, creation emptiness, or the next verdict. The order-gate model similarly checks selected deliveries. In catalogue_invariants.rs, successful configuration and readiness updates often check result.is_ok() and state, discarding successful Actions. Some deduplication checks inspect element zero without excluding extra elements. These tests are useful, but do not support the existing audit's claim of complete outputs after every step. Complete when: each generated step checks every declared effect lane, cardinality and order, destination, rejected owned input, and next verdict. Check initialization too. Use distinct owned payloads for custody-sensitive cases. Demonstrate failures for extra replies, wrong recipients, unexpected stopping, and dropped ownership; retain an independently structured oracle.

P2 — improve verification reach and remove repeated machinery

• A07 — Extend mutation evidence to the actor catalogue. Coverage gap. Both mutation derivations in flake.nix select only --package bombay-behavior; test packages are core and testkit. They do not mutate bombay-behavior-actors or run its integration tests as a selected mutation test package. A strict core verdict says nothing about the largest crate's survivors. actors/tests/mutation_contracts.rs is an ordinary test file, not evidence of an actor mutation campaign. Complete when: independently reviewable actor-family campaigns exercise their relevant unit, integration, and model suites; survivors have a killed regression or a reviewed equivalence argument. Ratchet viability separately from mutant detection, and label coverage by crate and law. Fix A05 first. The current candidate listing for bombay-behavior-actors contains 3,125 mutations; no actor-wide campaign verdict is claimed by this branch. Verified selected-slice gate: nix build .#mutants-actors --no-link --no-write-lock-file passed four independently ratcheted actor campaigns. Health caught 7/7 viable mutations; WorkQueue caught 2/2 viable among four candidates; PubSub membership caught 6/6; publication caught 1/1 viable among five candidates. The remaining six whole-function replacements could not compile. All four reports had zero missed viable mutations and zero timeouts. mutants/actors/*.json records separate viability floors by function; the Nix command runs actor and testkit suites. Other actor laws retain their focused campaign evidence below, and A20 tracks their broader law coverage without claiming an actor-wide mutation verdict.

• A08 — Make external-consumer and packaging gates exercise their claims. Confirmed gate gap. behavior-macros/tests/crate_resolution.rs::facade_package_sibling_targets_resolve_the_library_crate calls cargo check -p bombay-rs without --examples or --all-targets. The intended witness is fixtures/facade/examples/sibling_target.rs, which default cargo check does not select. The Nix package check only lists archive contents; the script's archive mode uses --no-verify. Complete when: explicit target selection checks the sibling example and both macro entry points; deliberately breaking that example breaks the gate. Build extracted published packages in a suitable release lane and compile a minimal consumer of the actual documented dependency declarations. Record package-content checks separately from package build verification.

• A09 — Remove test-only indirection and unused test dependencies. Confirmed simplification. behavior-testkit/src/lib.rs::InitializeTest forwards unchanged to behavior_actors::Activate and adds a second spelling of the same operation. criterion is a dev dependency, but the benchmark is a handwritten main and no Rust source uses Criterion. Four testkit files contain 15 #[tokio::test] tests collectively and no .await at all: stash_properties, fsm_properties, compositions, and error_paths. Several destination-only fixtures implement an inert Behavior even though the route contract needs only Protocol. Complete when: callers import Activate directly, unused dependencies disappear from manifests and the lockfile where appropriate, synchronous tests use the ordinary harness, and destination fixtures keep only required capability implementations. Preserve fixtures whose actual purpose is to test behavior or creation. Report deleted surface and compile impact.

• A10 — Define what the finite test driver preserves on error and in time. Confirmed limitation. behavior-testkit/src/lib.rs::drive returns only B::Error on a later failed transition, dropping accumulated successful effects and the active behavior. Trace also appends products lane by lane, losing the boundaries between turns. Interpreting that accumulated product afterward cannot establish per-turn runtime effect order. The error test fails on the first event and checks only the remaining mailbox length. Complete when: a success-success-error case exposes or explicitly documents the successful prefix's custody, and order-sensitive tests inspect per-turn actions or an independent interpreter trace. Do not describe the accumulation driver as a full runtime witness. Reuse existing action and settlement products if a richer error observation is needed.

• A11 — Give named effect-product derivation one maintained implementation. Implemented and verified. Eleven generic named actor products now use SendProduct and #[behavior] generated products use the same procedural generators for send effects, logical-host projection, ordered interpretation, settlement classification, and source custody. The two settlement representations remain explicit. The old send_product! module, BufferSends, and atomic::request_product! were removed. requirements.rs retains only the exceptional ReplyDeliveries and HeterogeneousShutdownSends projections. The unused public behavior::settle_in_order tuple helper was removed after a source search found no Rust caller in this workspace or adjacent Bombay/Address repositories. Named products generate their ordered traversal directly; the normative settlement document states that law. Complete when: a law table compares complete equations before selecting shared machinery. A retained derivation must preserve semantic field names, declared order, corruption suffixes, source admission, and logical-host projection, and delete repeated implementations. Prove two unrelated real products and both wrapper orders before catalogue migration. Do not merge products with different ownership or retirement laws, or introduce a public product framework merely to save typing. Evidence: the equation inventory, two unrelated actor products, source-custody tests in both SendLayer orders, and workspace --all-targets tests support the retained design. A clean Nix gate on a8f15b7 passed all ten active aarch64-darwin checks, including 843/843 optimized Nextest tests.

• A12 — Reassess aggregate decomposition using retained current values. Design candidate. FIFO's root has 4,097 lines, stable proxy's root 3,506, fixed recovery 3,080, and dynamic supervisor's root 2,839. These counts include comments and tests; they are review triggers, not evidence of redundant states. FIFO keeps most transition concerns at its visibility root, while fixed supervision spreads substantial transition authority among roster, recovery, start, outcome, and shutdown implementations. Several roots use mem::replace(..., Stopped) or a dormant placeholder during a transition. Complete when: each family has the full AGENTS aggregate-drift record, including before/after states, alternatives, branches, production lines, modules, public spellings, and the future-needed value in every subordinate alternative. Investigate direct owned-data joins and one commit point; preserve distinctions needed for rejection, concurrency, or terminal custody. Reduce responsibilities only where a falsifying law proves redundancy. Keep FIFO assignment policy and keyed binding policy distinct. Reviewed distinction: StableProxy's data-free Dormant and EmptyInitial states are not duplicate history labels. Dormant admits its one initial worker submission; EmptyInitial follows a rejected initial creation and rejects another submission with the observable Overlap and ProxyPhase::EmptyInitial. proxy_command_recovery and proxy exercise this path. Merging the states would admit a second initial worker or change the documented outcome. The other subordinate alternatives and family measurements still require the full A12 checkpoint. Dynamic supervision's WorkerChangeDisposition::{Committed,Cancelled} retains the answer to a future repeated cancellation. In DynamicEntryPhase::Available, the disposition selects the same committed or cancelled receipt again. dynamic::ready_service_accepts_one_replacement_on_its_current_proxy and dynamic::accepted_start_cancellation_retires_before_fresh_key_reuse exercise these answers. Deleting the disposition would change that later reply even though service availability is the same. This read-only distinction does not close the wider family audit. The stopped and forced-retirement alternatives in StableProxy, fixed supervision, FIFO, and keyed pooling still own workers, submissions, shutdown results, or rejection causes for terminal custody. Their fields have no local read path in some cases because the whole stopped behavior is retained for the interpreter. The downstream terminal-return witness in A17 and the interpreter ownership PRD must prove each transfer before any such alternative can be removed. This is a custody question left open by the source-only review.

  Decomposition baseline at e9c8d8c (read-only): the figures below count physical lines in each family source tree, including comments and embedded tests. Production lines exclude whole spans under #[cfg(test)] but retain comments and blank lines. Match arrows are a search diagnostic, not semantic transition branch counts.

  Family	Root control representation	Source modules	Physical lines	Production lines	Match arrows	Still required
  Stable proxy	ProxyState: 8 alternatives	6	5,946	5,076	398	Enumerate each nested shutdown and retirement value against exact terminal custody.
  Fixed supervisor	FixedRoster: 5 alternatives; recovery owns a separate 2-way policy state	19	10,104	9,512	718	Check roster/recovery joins and every retained prepared worker.
  Dynamic supervisor	SupervisorAvailability: 2 alternatives; each keyed DynamicEntryPhase has 14 alternatives	8	4,120	4,020	246	Check whether per-key transitions remain an entity invariant rather than a second aggregate authority.
  FIFO pool	PoolState: 5 alternatives	5	4,783	4,783	311	Check backlog, cursor, per-member custody and forced retirement separately.
  Keyed pool	KeyedPoolState: 5 alternatives	10	5,755	5,536	268	Check binding generations and per-role order without importing FIFO policy.

  These sums have no proposed deletion yet. The source scan found no semantic bool field in these families; the observed boolean signatures are membership or equality predicates. The FifoDispatch alternatives that return the same queued job still select different lawful actions: unavailable worker may enqueue it, while exhausted assignment correlation returns an explicit rejection. Fixed recovery's LeaveEmpty and SourceUnavailable both retain recovery state but select a lifecycle fact versus exact input rejection. Those alternatives cannot be merged by payload shape alone. This baseline does not replace the future-needed-value and production measurements for every subordinate alternative; A12 remains open.

  A12 single-worker creation batch, pre-edit law: StableProxy stages one worker creation per start. Its creation settlement therefore consumes exactly one matching result; a zero- or multi-item settlement is an unexpected input that must return the complete original ordered batch to the owner while the proxy remains in its creating phase. This is Bombay's derived staged-creation correlation policy, not an actor-model allocation law. The public caller syntax and observable transition stay unchanged. The focused proxy_command_recovery malformed-batch regression covers the complete returned batch. Existing lower-order products are CreationSettlement, CreationsSettled, WorkerCreation::Unexpected, and the owner diagnostic; no new type, bound, port, or interpreter operation is needed. The candidate implementation uses the owned vector's exact-one conversion so a failed cardinality check returns every item without cloning or reconstructing a different batch. This local simplification does not close the family-wide A12 inventory.

  A12 single-worker creation batch, retained checkpoint: Root ProxyState remains 8 alternatives before/after; the touched WorkerCreation sum remains 3 and CreationSettlement remains 3. Its three top-level settlement branches and five reachable cardinality paths are unchanged; two impossible pop() == None branches are gone. The touched production method is 83 → 70 lines; the six-module family is 5,959 → 5,946 physical source lines, including unchanged embedded tests, and 5,089 → 5,076 production lines after excluding the 870 lines under #[cfg(test)]. Public spellings and module count are unchanged. WorkerCreation::Initializing still owns the committed worker, activation, and possible prior stop; WorkerCreation::Rejected owns the rejected worker, activation, and possible prior stop; WorkerCreation::Unexpected owns the pending worker, possible prior stop, and the entire anomalous batch for the owner diagnostic. No arrival-history label, repeated cause, false cardinality, nested transition authority, semantic boolean, or structural caller syntax was added. Cross-checked docs/actor-laws/proxy.md, docs/engineering/atomic-actor-essence.md, and docs/engineering/atomic-actor-retained-core.md; the focused 53-test proxy recovery suite passes. Disposition: pass for this local simplification; A12 remains open for the complete family inventory and terminal custody.

  A12 exact-one creation batch, pre-edit law: Actor research requires fresh creation but does not prescribe a Rust batch API. Bombay's ordered Creations<Item> is a derived effect product. A single-child aggregate may consume exactly one result; if the batch has zero or multiple items, the conversion must return the complete original batch in order. The intended caller syntax is creations.into_one(), returning Result<Item, Creations<Item>> without Clone. A focused external caller test will require one move-only item to succeed and empty/two-item batches to return intact; the prior API fails that test because it has no such operation. The existing lower-order value is the privately owned Vec<Item> in Creations; its exact-one array conversion already appears twice in StableProxy, while DynamicSupervisor manually checks length then has an unreachable empty branch. The design stage adds only the batch operation and its focused test. Separate migration stages will apply that proven operation to those two aggregates, preserving their current CreationSettlement outcomes and interpreter requirements. Before editing, the core batch has no state sum; StableProxy has eight root states and six modules, DynamicSupervisor has two root availability states, fourteen entry phases, and eight modules. No new actor state, effect lane, trait bound, interpreter capability, or type is proposed. The public batch method count grows by one in the design stage; branch and line measurements follow each retained stage. The external caller initially failed with three E0599 diagnostics at the intended into_one calls. After the core method was added, the focused Nix-pinned test passed for one, zero, and two move-only workers. The design stage adds 13 production source lines and 22 net test lines; it changes no aggregate state, subordinate alternative, transition branch, module, or interpreter path. On failure, the original Vec<Item> is returned inside the same ordered Creations value; there is no clone, dropped item, arrival history, repeated cause, false cardinality, nested authority, semantic boolean, or positional caller syntax. The actor transition and retained-core creation laws were cross-checked. Disposition: pass for the batch API; aggregate migrations and their separate checkpoints remain open. A12 exact-one aggregate migration, retained checkpoint: StableProxy now consumes rejected and settled worker batches through that operation. Its eight root states, three WorkerCreation alternatives, six modules, and public spellings are unchanged; the two cardinality success/failure choices are unchanged. Its production source falls by two lines, from 5,076 to 5,074. DynamicSupervisor now consumes its proxy-settlement batch through the same operation. Its two availability states, fourteen entry phases, eight modules, and public spellings are unchanged. The same reachable success/failure choice remains, while the old impossible next() == None branch after len() == 1 is gone. Its production source falls by five lines, from 4,020 to 4,015. The dynamic regression now checks empty and two-item rejection as the exact ProxyCreationsSettled event, including both untouched routes, creation IDs, kinds, item order, and the retained CreatingProxy phase; that test changes by +47/-3 lines. All 29 dynamic and 53 proxy recovery tests pass with the Nix toolchain. The full malformed batch remains owned by the rejected event, with no arrival history, repeated cause, false cardinality, nested authority, semantic boolean, or structural caller path. docs/actor-laws/proxy.md, docs/actor-laws/dynamic-supervisor.md, and the normalized atomic-actor documents were cross-checked. Disposition: pass for the mechanical migrations; the remaining family inventories and interpreter terminal custody still keep A12 open. A clean detached-worktree nix flake check -L --max-jobs 2 at 44922e2 passed all eight active aarch64-darwin checks, including 845/845 optimized Nextest tests, Rustdoc, Clippy, package, and formatting. The first run caught three test-only consuming calls inside assertions; those calls now execute before the assertions and the full rerun passes.

  A12 StableProxy root values, read-only review: at the e9c8d8c checkpoint the one control-state sum remained eight alternatives in six modules and 5,076 production lines. The retained values below are used by a later decision or returned as terminal custody; these rows do not claim that every nested sum has been reviewed.

  ProxyState alternative	Exact current value required later
  Dormant	No worker; the one initial submission is still admissible.
  Starting	Start kind and current creation, initialization, activation, or return value select correlation, rejection return, and the next effect.
  Ready	The exact current worker capability and attempts select service delivery, stop, and replacement.
  EmptyInitial	No worker; initial-start authority is spent, so another initial submission must return Overlap.
  EmptyAfter	The previous worker attempt is needed as replacement provenance.
  Replacing	The predecessor departure or successor result plus outstanding shutdown correlation must be joined before publication.
  ShuttingDown	Unresolved worker, creation, initialization, activation, and departure values must settle or transfer before retirement.
  Stopped	ProxyRetirement owns the exact residual values for the runtime custodian; A17/T16 must prove that transfer.

  WorkerStopping is a direct independent join: the shutdown request is either awaiting its exact ID or has its resolution, while the exact worker stop is absent or present. The resolved-plus-stopped combination immediately becomes StoppedWorker, so no extra arrival-order state is stored. proxy_command_recovery exercises stop-first and resolution-first joins. The root table and this join match docs/stable-proxy.md and docs/actor-laws/proxy.md; they justify retention, not a new deletion. The nested sums are inventoried next; other family inventories and the interpreter's terminal transfer still keep A12 open.

  A12 StableProxy nested values, read-only checkpoint: The current state.rs has the same eight root alternatives and sixteen subordinate sums with fifty alternatives as the earlier baseline. Across the six family modules, current source has 5,950 physical and 5,080 production lines, 398 => tokens as a search diagnostic, and fifteen top-level public declarations. This review changes none of those counts, no transition branch, and no public spelling. Each row names what a later transition or terminal custodian still needs; paired alternatives below have different legal next operations even where they carry the same payload shape.

  Subordinate sum	Alternatives and future-needed current values
  PreReadyFailure	InitializationEffects: failure plus activation plan; ActivationStart: complete request plus refusal; Activation: plan rejection. These select distinct owner outcomes after worker return.
  WorkerStartKind	Initial: no predecessor; Replacement: replaced attempt plus predecessor shutdown status, selecting lifecycle provenance and join.
  PredecessorShutdown	Settled: no outstanding shutdown; Awaiting: exact shutdown ID to match its later resolution.
  ReplacementCompletion	Ready: current worker plus result; ReadyAfterStop: worker attempt, result, exact stop; Empty: worker attempt plus result. Each joins a predecessor shutdown differently.
  ProxyReplacement	ReturningPredecessor: predecessor departure, pending successor, staged creation; SuccessorResultAwaitingShutdown: replaced attempt, shutdown ID, successor completion.
  ActivationProgress	WaitingForStart and Running each retain the exact activation attempt; only Running has admitted Started, so readiness can be consumed there.
  ActivationDuringDeparture	Pending: activation progress still awaiting input; Returned: completed activation value owed at retirement.
  WorkerActivationShutdown	Departing: activation state plus worker departure; WaitingForActivation: activation progress, current worker, optional shutdown resolution, exact stop.
  WorkerStartPhase	Creating: pending worker and optional early stop; Initializing: committed worker and optional stop; Activating: committed worker, progress, optional stop; ReturningWorker: departure and precise pre-ready failure.
  WorkerInitializationShutdown	Departing: optional returned initialization value plus worker departure; WaitingForInitialization: worker, optional shutdown resolution, exact stop.
  WorkerInitializationRetirement	Initialized: permit plus plan; EffectsRejected: failure plus plan; Stopped: plan plus optional earlier initialization stop.
  WorkerActivationRetirement	StartRejected: complete request plus refusal; Ready: readiness value; Rejected: application rejection.
  WorkerStartRetirement	Result: start result; Initialization: initialization retirement, worker, optional shutdown resolution, stop; Activation: activation retirement, worker, optional resolution, stop; ReadyWorker: result plus returned worker; ReplacementCompletion: exact successor completion.
  ProxyRetirement	Empty: optional previous attempt; ReplacementCancelled: replaced and successor attempts plus predecessor; Worker: returned worker; WorkerStart: optional replaced attempt plus start retirement; ReplacementAfterPredecessor: replaced attempt, predecessor resolution, start retirement. These are whole stopped-state custody.
  ProxyShutdown	Starting: start state; ReturningWorker: departure; ReturningWorkerStart: kind, departure, failure; ReturningPredecessor: departure and both attempts; ReturningSuccessor: replaced attempt, predecessor return, successor departure and result; Initializing: kind and initialization shutdown; Activating: kind and activation shutdown; WaitingForPredecessor: replaced attempt, shutdown ID, start retirement.
  PredecessorReturn	Awaiting: shutdown ID; Returned: exact shutdown resolution.

  The subordinate sums store current affine custody and correlation, not an independently dispatched behavior. Optional stops and resolutions mean exactly absence or presence of one fact; they do not encode mutually exclusive aggregate phases. No arrival-history-only alternative, repeated failure cause, false worker cardinality, nested transition authority, semantic boolean, or structural user syntax was found. The actor transition law, proxy law, stable-proxy guide, and normalized atomic documents were cross-checked. Disposition: pass for the StableProxy source model; A12 remains open for the other families and downstream terminal custody. A clean detached-worktree nix flake check -L --max-jobs 2 at 7574bcb passed all eight active aarch64-darwin checks, including 845/845 optimized Nextest tests, Rustdoc, Clippy, package, formatting, audit, and deny gates.

  A12 shared pool assignment join, read-only review: FIFO and keyed pools both use the four-alternative private AssignmentDelivery sum. This is one current job obligation with an exact assignment correlation; it is not a second actor transition authority. The owning aggregate still selects the complete Actions. The shared assignment module has 811 production lines and 311 embedded-test lines; this review changes zero states, alternatives, transition branches, modules, production lines, or public spellings.

  AssignmentDelivery alternative	Exact value needed by a future decision
  AwaitingReceipt	No delivery receipt exists; completion or stop must be retained until acceptance or rejection settles the moved assignment.
  Accepted	The exact receipt has committed delivery; the next matching completion or stop can select the one customer disposition.
  CompletionHasPriority	The completion is authoritative if delivery is accepted; an optional later exact stop must still drive worker recovery once.
  WorkerExitHasPriority	The exact stop is authoritative if delivery is accepted; an optional later completion must remain available for stale or contradictory settlement.

  CompletionHasPriority and WorkerExitHasPriority are observable order decisions, not duplicate arrival labels. Collapsing them into a product of two optional facts would lose which terminal event won. The two focused atomic::pool::assignment order tests and the FIFO/keyed pool law documents cross-check the retained values. AssignmentReceiptOutcome, WorkerCompletionOutcome, AssignmentRejectionOutcome, and WorkerExitOutcome return different complete values to their respective callers; they have not been merged by their common job fields. This review finds no semantic boolean, repeated cause, false cardinality, structural caller path, or redundant nested actor. Disposition: pass for this shared join only; both pool families' member, recovery, and retirement sums remain under A12 review. The PRD now states FIFO's clone-and-retry policy explicitly.

  A12 FIFO/keyed root values, read-only review: each pool has one five-alternative root sum. This review changes zero states, subordinate alternatives, transition branches, production lines, modules, or public spellings. FIFO remains five modules and 4,783 production lines; keyed remains ten modules and 5,536 production lines. The exact future-needed values differ inside their operating products:

  Root alternative	FIFO current value	Keyed current value
  Constructed	The ordered prepared worker roster must be returned intact if initialization ID reservation fails.	The same prepared roster must survive failure before the per-role queues and binding table exist.
  Operating	FifoOperating owns the ordered members, admission-ordinal backlog, and next role cursor. These select a global FIFO dispatch.	KeyedOperating owns one queue per role, current worker cells, and the bounded key binding table with generations. These select exact key affinity.
  Draining / Retiring	The exact unresolved RetiringWorker vector and ShutdownDeadline settle worker results and a bounded drain.	The same shared worker-retirement values and deadline settle keyed drain; key/queue outcomes are emitted when retirement begins.
  Stopped	When committed, no worker or job remains in the actor root and later input is rejected; it is also the temporary replacement during a consuming transition.	When committed, no worker or binding remains in the actor root and later input is rejected; it is also the temporary replacement during a consuming transition.
  ForcedRetirement	The unresolved workers and exact cause (WorkerShutdownIdsExhausted, DeadlineNotScheduled, or DeadlineElapsed) must transfer to the runtime custodian.	The same kind of unresolved worker vector and exact cause must transfer; the per-role binding policy does not turn that into a FIFO backlog.

  Constructed is a pre-initialization ownership phase and ForcedRetirement is terminal residual custody, not duplicates of the operational Stopped state. Both are source-level extensions to the three-state operational sketches in the normalized FIFO/keyed law documents; those documents now name the distinction. Existing FIFO forced-retirement tests and keyed lifecycle tests check retained workers locally. They do not prove the parent-to-root transfer, which remains A17/T16 work. The source scan found no arrival-history root alternative, repeated cause, false role cardinality, nested actor authority, semantic boolean, or positional caller syntax. Disposition: pass for these root sums only; member, recovery, deadline, and terminal-custody alternatives remain under A12 review.

  A12 fixed supervisor root/recovery values, read-only review: the root FixedRoster remains five alternatives in nineteen modules and 9,512 production lines; SupervisorRecoveryState remains a separate two-way policy sum. This review changes zero states, alternatives, transition branches, production lines, modules, or public spellings.

  Value	Exact current value needed by a future decision
  FixedRoster::New	The ordered prepared worker roster either stages one proxy per role or returns complete members on creation-ID exhaustion.
  FixedRoster::Operating	The ordered RosterOwner cells retain exact proxy, worker, pending preparation, and recovery obligations for role decisions.
  FixedRoster::ShuttingDown	FixedShutdown retains the unresolved roster and shutdown joins while late exact facts continue to settle.
  FixedRoster::Terminating	Exact owners and prepared submissions survive a terminal diagnostic or forced end for runtime custody; A17/T16 must prove transfer.
  FixedRoster::Stopped	When committed, no roster value remains and new events cannot be accepted; it is also the temporary replacement during a consuming transition.
  SupervisorRecoveryState::Automatic	Strategy, eligibility, restart budget, correlation, and WorkerSourceCustody select a lawful preparation or denial.
  SupervisorRecoveryState::Temporary	Automatic restart authority is absent; a worker stop leaves the role empty.

  Within automatic recovery, WorkerSourceCustody::Available owns the concrete source, PreparingWorkers means the in-flight request owns it, and Retirement owns the exact returned source value. These are current ownership positions, not three records of arrival history. RecoveryChoice::LeaveEmpty and SourceUnavailable both return recovery state but produce different observable outcomes: the former is the selected policy decision, the latter rejects a new preparation because the source is already transferred or retired. The fixed-supervisor initialization and recovery suites cover those distinctions locally. The normalized fixed supervisor law and retained-core document were cross-checked. The residue scan found no new arrival history, repeated cause, false cardinality, nested transition authority, semantic boolean, or structural caller path. Disposition: pass for these root/recovery sums only; individual roster owner, shutdown, preparation, and terminal-custody alternatives remain under A12 review.

  A12 dynamic supervisor entry values, read-only review: the aggregate has one SupervisorAvailability sum with Accepting(ActorDrainPolicy) and ShuttingDown(ShutdownDeadline). It owns a key map of DynamicEntry values; each entry retains its exact creation, generation, operation, and one of fourteen DynamicEntryPhase alternatives. The entry module provides status and shutdown projections but does not implement Behavior or choose the aggregate Actions. This review changes zero states, alternatives, transition branches, production lines, modules, or public spellings. The family remains eight modules and 4,015 production lines after the exact-one batch migration.

  DynamicEntryPhase alternative	Exact current value needed later
  CreatingProxy	The untransferred worker submission is returned on stop or cancellation, or sent to the committed proxy after its birth.
  ShuttingDownProxyCreation	The enclosing creation correlation remains pending; a committed proxy must be drained and a rejected birth must retire with shutdown provenance.
  DrainingProxyCreationStop	The same birth correlation remains pending, but a rejected birth must retire as an explicit stop. This cause changes the lifecycle report.
  WaitingForActivation	The exact established proxy and still-owned worker submission await activation capacity.
  WaitingForProxyInput	The exact proxy and input witness await ownership settlement of the initial operation.
  WaitingForProxyOutcome	The proxy and accepted operation ID await the later initial worker result.
  CancellingProxyCreation	The enclosing creation and operation correlations remain after the worker was returned; a later committed proxy still requires retirement.
  StoppingProxyCreation	The original start operation and untransferred submission must be returned by explicit stop while proxy birth still settles.
  Available	The exact proxy, ready-or-empty service value, and latest committed-or-cancelled disposition answer service and repeated cancellation queries.
  ReplacementQueued	The current service and successor submission coexist until capacity permits transfer.
  ReplacementAwaitingReceipt	Current service, exact proxy, and witness await successor input acceptance or rejection.
  ReplacementAwaitingOutcome	Current service, exact proxy, and accepted operation ID await replacement outcome.
  Stopping	The proxy, restorable service, shutdown settlement, and optional exact stop must join before stop completes or rolls back.
  Retiring	ProxyRetirement owns the exact proxy, shutdown and transferred-input custody, and possible stop through terminal drain.

  The three data-free creation phases still have the enclosing entry's correlation values and distinct future lifecycle outcomes; merging them by payload size would erase shutdown, explicit-stop, or cancellation cause. The dynamic-supervisor law and normalized atomic documents were cross-checked against the source and local dynamic tests. No arrival-history value without a future decision, duplicated cause, false key cardinality, nested actor authority, semantic boolean, or structural caller syntax was found in these phase sums. Disposition: pass for the entry and availability sums only; nested retirement, operation, and terminal transfer still keep A12 open.

  A12 shared pool member and recovery checkpoint, read-only: FIFO and keyed pooling share the current member/assignment ownership model, but each root selects its own queue policy. MemberState has four alternatives, WorkerPhase seven, RecoveringWorker four, ShutdownJoin three, RetirementStatus five, WorkerStartupCustody five, WorkerShutdownStatus two, PoolRecoveryState three, and WorkerRecoverySource two. The shared pool subtree has six modules, 3,760 physical lines, 3,414 production lines, 198 match arrows, and twelve top-level public declarations. This read-only batch changes zero control states, subordinate alternatives, transition branches, lines, modules, or public spellings.

  Current sum	Exact value needed by its next owner
  MemberState::{Creating,Worker,Recovering,Retired}	The pending birth with activation and possible early stop; the established worker phase; the previous attempt plus recovery work; or absence of a live role.
  WorkerPhase::{Initializing,WaitingForActivation,ActivationDispatched,Activating,Idle,Busy,Stopping}	Initialization correlation and possible stop; exact permit and plan; dispatched or accepted activation attempt with possible stop; available worker; one assigned job obligation; or the exact shutdown join. Dispatch and acceptance select different later acknowledgements.
  RecoveringWorker::{WaitingForSource,Preparing,Scheduling,WaitingForTimer}	Previous attempt and stop, plus respectively unavailable source, preparation ticket, pending replacement and timer, or the same replacement awaiting its timer. The latter two distinguish whether schedule admission still has to settle.
  ShutdownJoin::{AwaitingBoth,AwaitingStop,AwaitingSettlement}	Exact shutdown ID; accepted shutdown resolution awaiting stop; or exact stop awaiting settlement. Either arrival order must reunite both facts once.
  RetirementStatus::{AwaitingCreation,Established,AwaitingPreparation,AwaitingRestartSchedule,Drained}	Pending birth; current worker, optional startup and shutdown join; prior stop with preparation ticket; pending replacement with timer; or no remaining worker custody.
  WorkerStartupCustody::{ActivationPlan,Initializing,ActivationPermit,ActivationStart,Activation}	Respectively untransferred plan, initialization attempt, permit with plan, dispatched start, or accepted activation correlation returned during retirement.
  WorkerShutdownStatus::{NotRequested,Waiting}	No shutdown authority yet, or the exact outstanding join.
  PoolRecoveryState::{Permanent,Transient,Temporary} and WorkerRecoverySource::{Available,AwaitingReturn}	Permanent/transient retain source, limit, release and failure policy; temporary has no source and retains failure policy. Available owns the concrete source; awaiting return records that the preparation request currently owns it.

  WorkerRecoveryDecision, WorkerCustody, RetirementReturns, and the event-specific retirement outcomes are consuming transition products, not independently stored actor control states. Their distinct payloads return exact source, worker, assignment, or replacement custody to the root. A product of optional values would allow a worker to be both idle and busy or lose which shutdown fact remains; a direct vector already represents the ordered role roster. The normalized FIFO/keyed laws, actor transition law, and runtime settlement law were cross-checked. No arrival-only state, duplicated cause, false role cardinality, nested behavior authority, semantic boolean, or structural caller syntax was found. Disposition: pass for the shared member/recovery source model.

  A12 keyed binding checkpoint, read-only: RoleCell owns one role's member, admission-ordinal queue, and capacity. BindingTable owns bounded key-to-role bindings and a checked generation sequence. AdmissionBinding has two short-lived alternatives: Retained keeps the submitted key and existing evidence, while Reserved owns the fresh table reservation until admission commits or returns the key. BindingExpectation::{Absent,Exact} distinguishes a missing binding from one exact generation; the three BindingReservationRejected reasons return the same key with distinct capacity, conflict, or sequence-exhaustion causes. These are current authority/return values, not another keyed actor. Keyed pooling remains ten modules, 5,755 physical and 5,536 production lines, 268 match arrows, and twenty top-level public declarations before and after this review. Root states, subordinate alternatives, transition branches, and public spellings change by zero. The normalized keyed law and binding generation tests were cross-checked; the residue scan found no arrival history, duplicate cause, false cardinality, nested transition authority, semantic boolean, or structural caller path. Disposition: pass for source binding custody.

  A12 fixed roster and dynamic retirement checkpoint, read-only: Fixed supervision remains nineteen modules, 10,104 physical and 9,512 production lines, 718 match arrows, and twenty-seven top-level public declarations. Dynamic supervision remains eight modules, 4,115 physical and 4,015 production lines, 246 match arrows, and twenty-five such declarations. Both roots, all subordinate sums, transition branches, lines, modules, and public spellings are unchanged by this review.

  Current sum	Exact future-needed value
  RosterOwner::{Starting,Stopping,Online,Empty,Recovery,Unrecovered,Retired}	Respectively a proxy start correlation; proxy shutdown join; established proxy, worker and readiness; empty role identity; recovery batch/preparation; unrecovered worker and reason; or terminal returned proxy custody. Its status projection does not select aggregate Actions.
  ProxyStartingMember six alternatives	Pending creation with original operation; established proxy awaiting authorization; dispatched input witness; accepted input ID awaiting outcome; exact rejected input; or exact rejected birth. Each has a different next input or return value.
  RecoveryRosterOwner::{Preparing,Admitted} and RecoveryMember::{Waiting,Replacing}	Preparation owns the source/ticket; admitted batch owns prepared participants. A waiting member owns an untransferred submission; replacing owns an established proxy and exact replacement result.
  RecoveryParticipant::{Stopped,InitialInputDispatched,AwaitingInitialOutcome,Online}	Original stopped member; proxy with dispatched input witness; accepted operation ID; or current ready member.
  ReplacementResponse::{InputPending,OutcomePending,OutcomeReturned,InputRejected}	Exact input witness, accepted operation ID, returned outcome, or returned operation with rejection reason. RestartReleaseState::{Ready,Scheduling,Waiting} likewise distinguishes no timer from timer admission and an admitted timer.
  Fixed ProxyShutdown::{Dispatched,Accepted,Rejected}	Unsettled input witness, accepted operation ID, or complete rejected shutdown. An optional exact ChildStopped in the containing member joins independently.
  Dynamic ProxyShutdown::{AwaitingSettlement,Accepted,Rejected}	Pending shutdown witness, accepted operation ID, or rejection; the entry's stop remains independently correlated.
  Dynamic RetiringWork six alternatives	Distinct start failure, unexpected stop, interrupted start, supervisor shutdown with optional service, cancelled returned worker change, or transferred proxy input with exact purpose and custody. These causes select different public lifecycle reports.
  Dynamic ProxyInputPurpose four alternatives and ProxyInputCustody four alternatives	The purpose distinguishes cancellation, interrupted start, initial start, and replacement with service. Custody distinguishes unadmitted witness, accepted operation, rejected input, and returned proxy outcome. The pair determines exact terminal return without replaying a control.

  Fixed recovery policy, dynamic key/operation correlation, source ownership, and the five normalized atomic laws were cross-checked with the source. Data-free retirement causes are observable lifecycle policy, and separate accepted-input versus returned-outcome states are needed to prevent false readiness/restart. No arrival-only state, repeated cause, false worker/key cardinality, nested Behavior implementation, semantic boolean, or structural application syntax was found. Disposition: pass for these source-level subordinate sums. Terminal transfer and caught-panic ownership remain the real-runtime A17/T16 witness; this review makes no claim about those downstream effects.

  A12 final source-review disposition: pass. The five root control sums, the StableProxy nested sums, the shared worker/recovery joins, keyed binding, fixed roster/recovery, and dynamic entry/retirement sums above retain exact values used by later decisions or returned in terminal custody. The before/after production source and syntactic branch counts are identical for each read-only family checkpoint; the earlier exact-one changes record their separate reductions and branch deletions. Counts, module ownership, public spellings, residue scans, and normalized-law cross-checks are recorded at each checkpoint. Earlier statements that A12 was open describe the staged review at those revisions. No state or module deletion is justified by a falsifying law, so none is proposed. Actual parent-to-root terminal transfer and post-commit panic limits are interpreter obligations in A17 and the PRD, not source-level aggregate-decomposition claims.

  FIFO and keyed pools each move their root state out with mem::replace(..., Stopped) during initialization and transition; fixed supervision similarly substitutes Stopped or a temporary recovery value, and StableProxy substitutes Dormant during one consuming transition. Normal return commits the result once, but a caught pure-fold panic before that commit may leave only the placeholder in the actor while owned state unwinds. This is an inference from the source, not a proven runtime outcome. The PRD's T16 panic and root-custody witness must test it before these sites can be called safe or refactored. A passing ordinary transition suite cannot decide that law.

• A13 — Audit public bounds, hidden exports, and extension ownership. Confirmed surface requiring review. The current source has 10 #[doc(hidden)] annotation sites in core and 22 in actors, including members and re-exports. The public-surface inventory classifies each site by contract owner. These annotations do not make an item private. Conversely, an associated type mentioning a value does not by itself justify exporting it. Some Protocol impls carried transition-related bounds: Cache required K: Clone + Eq and V: Clone; Resolver required K: Clone + Eq before the focused A13 repair below. The four timer wrapper structs already have only one generic parameter, B; their effect signatures project address, phase, sends, and births from it, so they are a successful example rather than a gap. Complete when: classify each public item as application API, generated code obligation, or runtime port; identify each trait's lawful implementors. Move bounds only after caller-facing compile witnesses prove the narrower law. Measure diagnostics and compile cost. Document required runtime ports openly and keep representation private where Rust permits. Add no aliases, defaults, visibility, or generic parameters solely to silence the compiler. Progress: the public-surface inventory now accounts for all 78 top-level public traits by lawful implementor role, including the later ProxyControlAdmission interpreter port. Its actor-suite implementors and the isolated Bombay source identify its owner; the latter is not yet a successful A17 runtime witness. The inventory confirms that StashStatus has multiple real wrapper implementations; its name alone is not grounds for deletion. Externally authored child roles and generic logical-host owners have compile witnesses for the newly visible types. The inventory now classifies the hidden ChildProduct::stage method as a sealed structural conversion: only NoChildren and ChildCons implement the trait, Children::into_creates is its sole production caller, and the interpreter consumes the resulting Creations effect. Calling stage a runtime port had overstated its public contract. This correction changes zero Rust items, bounds, states, branches, modules, or public spellings. The cache/resolver protocol-bound comparison found no material compile-time difference in its measured pair; the caller diagnostics improved. The protocol-only caller now covers 20 catalogue actors, keeping construction and transition bounds at the operations that need them. A separate caller now proves that 14 unwrapped catalogue actors expose their read-only BehaviorBase projection without requiring the cloning, comparison, or ordering used only by construction or transition. This also includes keyed Deduplicator and OrderGate and a priority queue with opaque priority data. The proxy operation ID is now crate-private; focused external fixtures distinguish forbidden ID naming, receipt construction, and double settlement. Review of remaining hidden runtime ports and the rest of the public surface is still required. A repeatable cold actor-library check on aarch64-darwin used the same Nix-pinned Cargo 1.95.0 and two separate fresh targets per revision: main@435560c took 184.54/180.09 seconds and this branch at 1aeaed1 took 4.46/3.97 seconds. The actor .rmeta sizes were 27 MiB and 5.8 MiB. The measurement record gives the command and scope. This is a whole-branch comparison, not causal evidence for any one A13 bound; future bound edits still need focused caller diagnostics and their own cost check. A post-repair source scan of catalogue Protocol and BehaviorBase impl headers found no remaining copying/comparison/ordering bounds except Router's Route: Clone + PartialEq, which is also required by its current RoutingStrategy<Route> contract. Changing that contract would require a distinct membership and policy law, not a mechanical bound deletion. The read-only Router review found no legitimate transition for a route without identity comparison: new removes duplicates, Add/Remove select exact members, and selection clones the policy candidate so a failed route leaves it unchanged. A logical or established route whose endpoint lacks equality cannot currently satisfy that membership law. Narrowing only the protocol/base headers would create a nameable router that cannot be constructed or run; no bound edit was retained. Round-robin's cursor repair and the least-loaded/Rendezvous traces exercise the current comparable-route contract. This resolves the isolated header question, while A13's broader hidden-port review remains open.

  Pre-edit A13 transferable-route owner law: Logical, established, and mixed reply routes are transferable acquaintances. For any actor Owner, DeliveryRoute plus its associated protocol address equal to BehaviorAddr<Owner> already proves that the emitted delivery belongs to the owner's address namespace. The separate sealed DeliveryRouteFor<Owner> duplicates the same three implementations and forwards every deliver_for call to DeliveryRoute::deliver; no production consumer uses it. The only external caller is behavior-testkit::owner_scoped_delivery. This is a derived static composition law, while excluding creator-local ChildRoute from a standalone transferable route is a deliberate Bombay policy. Before deleting the trait, change that test's generic caller to use the associated address equality and preserve its logical/exact/mixed outcome assertions. Add a negative compile fixture that rejects naming the redundant trait; the fixture must fail on the prior public API for that exact name. The lower-order DeliveryRoute, Recipient, EstablishedRecipient, ReplyRoute, and their concrete send products remain. No new wrapper, route variant, runtime lookup, or child-binding capability is proposed. The negative rustdoc fixture failed on the prior API because its old-trait name still compiled. After deletion, that fixture and the existing wrong-protocol fixture pass, and the external owner-scoped delivery caller passes in debug and optimized builds with the associated-address bound for logical, exact, and mixed routes. The three touched production Rust files fall from 686 to 608 physical/production lines; the public trait count falls from 78 to 77. Root control states, subordinate alternatives, actor transition branches, and modules remain unchanged. The only removed public spelling is DeliveryRouteFor; existing route ownership stays with each concrete capability and its send product. No arrival history, repeated cause, false cardinality, nested authority, semantic boolean, or positional caller syntax was introduced. The actor transition law, composition guide, and normalized atomic documents were cross-checked. Disposition: pass; this is a deliberate source-breaking interface deletion and requires the release PR's breaking-change label. A13 remains open for the remaining surface review.

  Pre-edit A13 returned-worker custody documentation law: A host rejection of a staged worker returns WorkerCreationRejection::HostRejected containing WorkerRecovery<W>. Its consuming into_retirement() returns the exact current worker and untouched initialization actions to the custodian; no replacement worker or reconstructed actions are permitted. A committed worker outcome separately carries opaque WorkerAttempt evidence whose creation() projection is only creator-local correlation. These are existing derived ownership contracts. The external proxy_command_recovery::host_rejection_keeps_worker_and_initialization_actions_together case consumes WorkerRecovery, and proxy/fixed-supervisor callers name WorkerAttempt. Before editing, Nix-pinned Rustdoc omits both structs from the atomic index and has no item pages. The focused regression is visible pages and methods while those external callers continue passing. Only documentation hiding on these already-public types/methods and their grouped re-export may change; their private constructors, fields, result types, actor states, transition branches, and interpreter operations stay unchanged. Post-edit, Nix-pinned Rustdoc lists both types on the atomic index with item pages and shows into_retirement() and creation() on those pages. The focused external host-rejection test passes. Actor hidden annotation sites fall from 54 to 50. Root control states, subordinate alternatives, transition branches, modules, and public Rust spellings remain unchanged; the two touched Rust files fall from 440 to 436 lines as four hidden markers are removed. This edit changes documentation visibility only. WorkerRecovery still owns the rejected worker and all unattempted initialization actions, while WorkerAttempt still owns only exact issued correlation. No arrival history, repeated cause, false cardinality, nested authority, semantic boolean, or positional caller syntax was introduced. The creation/lifecycle law, stable-proxy guide, and normalized atomic documents were cross-checked. Disposition: pass for this custody documentation port; A13 remains open for the wider surface review.

  Pre-edit A13 worker initialization and activation port law: A host receives the exact InitializeWorker request, observes its established target and correlation, and consumes it once to produce a complete WorkerInitializationReport. A successful report alone carries the ActivationPermit that can construct BeginActivation; the interpreter admits Started before polling the plan and returns the exact WorkerActivation result. These are existing derived custody and ordering contracts, not new runtime effects. External proxy_command_recovery, stable_proxy_shutdown_model, fifo_pool, and interpreter-contract caller tests already name these concrete types and exercise accepted, rejected, stopped, and activation-start-rejected paths. Before editing, Nix-pinned Rustdoc omits the initialization and activation items and their public methods from the atomic pages because their declarations and grouped re-export are hidden. The focused regression is complete visible Rustdoc for the already-public host and owner methods while the external transition suites retain their results. Only documentation hiding may change; private constructors, fields, correlation tokens, return types, effects, states, branches, and interpreter ordering remain as before. Post-edit, Nix-pinned Rustdoc lists all nine named types on the atomic index with their existing public method pages. The external proxy recovery and shutdown model suites pass 53 and 7 tests. Actor hidden annotation sites fall from 50 to 23. The three touched Rust files fall from 755 to 728 lines by deleting 27 hiding markers. Root control states, subordinate alternatives, transition branches, modules, and public Rust spellings are unchanged. The worker request still owns its exact target, worker attempt, initialization attempt, and affine activation plan; the permit still authorizes just that worker and attempt; the returned activation still owns its original result or rejection. No arrival history, repeated cause, false cardinality, nested authority, semantic boolean, or positional caller syntax was introduced. The actor creation/lifecycle law, stable-proxy guide, and normalized atomic documents were cross-checked. Disposition: pass for this visibility batch; A13 remains open for the other hidden ports and the full public surface review.

  Pre-edit A13 creation-observation port law: A local interpreter may observe the exact same-action child creation named by protocol, occurrence, and creator-local CreationId. The public ObserveCreation<P, Occurrence> request carries that typed prerequisite; it does not establish freshness or let a foreign child protocol substitute because its payload shape matches. This is an existing Bombay observation policy. External creation_observation_settlement and child_shutdown_interpretation callers already name and interpret the request, while its Rustdoc compile-fail fixture rejects a different protocol. Before editing, Rustdoc hides the existing item page. The focused regression is a visible request page and retained external and compile-fail results. Only its documentation marker may change; request fields, constructor, prerequisite, effect order, behavior state, and interpreter semantics remain unchanged. Post-edit, the actor Rustdoc index links to ObserveCreation and its new method. The two external caller suites pass 5 tests and actor doctests pass 44, including the wrong-protocol compile-fail example. Hidden actor annotation sites fall from 23 to 22; the touched production file loses one marker line. Control states, subordinate alternatives, branches, modules, and public Rust spellings stay unchanged. The request retains the same exact typed prerequisite and current creation ID. No arrival history, repeated cause, false cardinality, nested authority, semantic boolean, or positional caller syntax was introduced. The actor creation/lifecycle law and normalized observation document were cross-checked. Disposition: pass for this runtime-port documentation; A13 remains open for the broader surface review.

  Pre-edit A13 proxy outcome and correlation documentation law: A caller inspecting an initial or replacement proxy result must distinguish WorkerStartResult::CreationRejected from Ready and Unavailable; the latter owns the exact ProxyDrain cause and worker lifecycle values. A trusted interpreter inspecting ProxyOperation must read its exact creator-local creation correlation before admitting private control. These are existing derived ownership contracts, not additional actor powers. External proxy, fixed-supervisor, and dynamic-supervisor tests already match these products and call ProxyOperation::creation(). Before editing, Nix-pinned Rustdoc omits WorkerStartResult and ProxyDrain from the atomic index and has no item pages; it also omits method.creation from the visible ProxyOperation page. The focused regression is their visible Rustdoc contract with those existing external callers still passing. The edit removes documentation hiding from the domain outcome, exact correlation method, and their grouped re-export; it does not add a Rust spelling, constructor, capability, bound, lane, state, or transition. Post-edit, Nix-pinned Rustdoc lists ProxyDrain and WorkerStartResult in the atomic index with item pages and lists method.creation on the ProxyOperation page. The focused external proxy, dynamic-supervisor, and fixed-supervisor suites pass 53, 29, and 98 tests. Actor hidden annotation sites fall from 56 to 54. StableProxy's eight root states, the fixed roster's five, and the dynamic entry's fourteen alternatives remain unchanged; their branches, modules, production public spellings, and ownership values are unchanged. ProxyDrain still owns one precise committed-worker failure cause, and creation() still exposes only the creator-local correlation. No arrival history, repeated cause, false cardinality, nested authority, semantic boolean, or positional caller syntax was introduced. The proxy law, stable-proxy guide, and normalized atomic documents were cross-checked. Disposition: pass for these visible contracts; A13 remains open for the wider surface review.

  Pre-edit A13 customer-delivery documentation law: A keyed-pool interpreter must name the concrete CustomerDelivery<P> action to return both the attempted delivery and original customer route on rejection. An assignment interpreter must call AssignWorker::target() to obtain a clone of the exact worker recipient before consuming settle. These are existing derived ownership ports, not new actor powers. The public caller syntax is already exercised by the keyed-pool external compile suite and the interpreter-contract assignment fixture; the four customer alternatives retain their existing complete settlement equation. Before editing, Nix-pinned Rustdoc omits CustomerDelivery from the atomic index and has no item page, and omits method.target from the visible AssignWorker page. Removing their two declaration markers and separating the existing grouped re-export exposes only those already-public names. The focused regression is their Rustdoc visibility with the existing external callers still passing. No constructor, method, bound, trait, effect lane, control state, transition branch, or interpreter operation changes. Post-edit, Nix-pinned Rustdoc lists CustomerDelivery in the atomic index, generates its item page, and lists method.target on AssignWorker. The 23 keyed-pool tests and three external assignment-delivery tests pass. Actor hidden annotations fall from 58 to 56; the two declaration markers are gone while the sealed CompletesAssignments re-export remains hidden. The root aggregate states, subordinate alternatives, transition branches, source modules, and Rust public spellings are unchanged. The exact worker recipient capability remains inside AssignWorker, and the original customer route remains inside a rejected CustomerDelivery. No arrival history, repeated cause, false cardinality, nested authority, semantic boolean, or positional caller syntax was introduced. The keyed-customer rejection law in docs/atomic-runtime-settlement.md and the normalized pool law were cross-checked. Disposition: pass for these two visible ports; the wider A13 surface and compile-cost review remain open. A clean detached-worktree nix flake check -L --max-jobs 2 at 19a38c2 passed all eight active aarch64-darwin checks, including Rustdoc and optimized Nextest.

  Pre-edit A13 diagnostic-port visibility law: An external interpreter must name the concrete DiagnosticAction, DiagnosticAccepted, and sealed DiagnosticRoute contract to settle a routed or terminal diagnostic. The accepted value either records delivery or transfers the exact diagnostic into terminal custody; it cannot silently discard the latter. This is a derived interpreter ownership port, not a new actor transition. The external diagnostic_action and interpreter-contract source_free_custody suites already use this syntax, including the constructor methods. Before editing, Nix-pinned Rustdoc builds but omits all three names from the atomic index and has no item pages for them. The focused regression is visible Rustdoc for these already-public names and methods while the existing caller suites continue to pass. The only proposed change removes documentation hiding annotations on the three declarations, their four methods, and grouped re-export. It adds no type, bound, capability, effect lane, or transition branch. Post-edit, Nix-pinned Rustdoc lists all three names in the atomic index, generates their item pages, and lists all four methods. The three diagnostic_action tests and four external source-free custody tests pass. Actor hidden annotations fall from 66 to 58. Aggregate control states, subordinate alternatives, transition branches, modules, and Rust public spellings are unchanged; the documentation-only edit removes eight source lines. The complete diagnostic remains owned by the terminal accepted variant until the interpreter transfers it. The residue scan finds no arrival history, duplicate cause, false cardinality, nested transition authority, semantic boolean, or structural caller syntax. The actor transition and retained-diagnostic laws were cross-checked against docs/actor-transition-algebra.md and docs/engineering/atomic-actor-retained-core.md. Disposition: pass for these diagnostic item pages; A13 remains open for other ports.

  The creation settlement review found a narrower documentation defect: external caller suites name CreationSettlement, CreationSettlements, and CreationsSettled to retain or return exact child-creation custody, but none appeared as an item in the generated crate-root Rustdoc index. Their public visibility and settlement equations already existed; showing them changes no actor transition. A later read-only downstream inspection found that Bombay's ActionInterpreter explicitly requires InterpretCreations in its CommitActions implementation. That is a real interpreter port and supplies the missing caller evidence to show the trait in Rustdoc as well. The three externally named settlement ports are now listed by Rustdoc: cargo doc -p bombay-behavior --no-deps --locked succeeded with the Nix-provided Rust 1.95 toolchain, and all three crate-root index links and item pages exist. The external generated_creation_custody, custody, and actor caller suites already name these products. Downstream compilation and runtime witnesses remain part of A17; this source inspection does not claim they pass. A second Nix-provided Rustdoc build after exposing InterpretCreations confirmed that all four names have crate-root index links and item pages. The bombay-behavior-doc Nix check passed on signed commit 4cd3b7f, including Rustdoc, the book, and published-document checks.

  The next required runtime method is CreateChild::into_parts. The external creation_initialization_order, creation_settlement_custody, and behavior_generation caller suites consume it to retain the exact child, creator-local ID, and provenance. The real Bombay child host also names it after consuming a RoutedCreation. Its Rust visibility is already public, but #[doc(hidden)] conceals it from an interpreter author reading the API. This is a derived ownership port, not a new actor transition. The focused documentation repair removes that one marker and gives the method an explicit custody description; it adds no type, bound, effect lane, control state, or interpreter capability. The existing external callers are its compile witnesses. The post-edit check is that Rustdoc lists the method on CreateChild and those callers still compile. Post-edit, cargo doc -p bombay-behavior --no-deps --locked generated struct.CreateChild.html with method.into_parts and its custody text. cargo check --locked passed for the external behavior-testkit/tests/creation_initialization_order and behavior/tests/creation_settlement_custody callers; mdbook build docs, formatter, and diff checks passed. The source change is +6/-1 physical lines of documentation only; tests and public type counts are unchanged. Aggregate control states, subordinate alternatives, transition branches, modules, and public spellings are unchanged. The owned child, ID, and kind remain the same complete product; no arrival history, duplicated cause, false cardinality, nested authority, semantic boolean, or positional caller syntax was introduced. The actor transition and creation-custody laws were cross-checked. Disposition: pass for this one documentation port. A13's wider surface review remains open.

  CreationCorrelation<P, Occurrence> is another required, already-public effect prerequisite. The external behavior/tests/action_interpretation and actor interpreter_request_settlement callers name it in ActionItem implementations; its compile-fail example rejects exchange of equal IDs at different occurrences. The derived law is typed correlation to exactly one creation settlement, without granting child-hosting authority. The focused visibility repair removes its Rustdoc hiding marker, retains its private representation and public constructor unchanged, and adds no transition or type. The pre-edit regression is the absence of its item in the generated crate-root Rustdoc index despite those external compile witnesses. The post-edit checks are the Rustdoc index and the occurrence-mismatch doctest. Post-edit Rustdoc has a crate-root link and item page, the focused E0308 compile-fail doctest passed, and cargo check --locked passed for both action_interpretation and interpreter_request_settlement external tests. The source change deletes one hidden annotation; tests, public types, control states, subordinate alternatives, transition branches, modules, and public spellings are unchanged. No history, repeated cause, false cardinality, nested authority, semantic boolean, or positional syntax was introduced. The actor transition and occurrence laws were cross-checked. Disposition: pass for this visible prerequisite, with A13 still open for other items.

  CreationId::get is likewise an existing public runtime port concealed in Rustdoc. The actor catalogue derives shutdown and operation correlations from its occurrence-local number; external actor tests also inspect it. Exposing the existing method does not make the number an actor identity or a freshness proof, so its documentation now says that explicitly. The pre-edit symptom was its absence from generated Rustdoc despite external callers. The source edit removes one hidden marker and adds only custody text: zero types, bounds, lanes, states, branches, modules, or public spellings change. The current owned ID remains the sole value. The residue scan is clear for history, repeated cause, false cardinality, nested authority, semantic boolean, and structural syntax. Cross-checks: actor creation law and the exact-correlation consumers. Nix-pinned Rustdoc built CreationId with a visible method.get item, and cargo check -p bombay-behavior-actors --tests --locked passed. Disposition: pass for this documentation-only port; A13 remains open for the wider surface.

  The assignment custody repair narrowed AssignWorker::receipt and AssignWorker::into_parts from public to atomic-module-only after the external consuming settlement passed. Compile-fail fixtures now reject those two old assembly paths with E0624 and reject double settlement with E0382; FIFO/keyed callers, benchmark, and fuzz campaigns use the actual exact-delivery result. The later proxy settlement stage also narrowed its operation ID, request decomposition, and receipt construction after external privacy and closed-control witnesses. The public-surface inventory reflects 81 actor #[doc(hidden)] sites at that checkpoint. The wider port and bound review remains open.

  Pre-edit A13 interpreter-name law: an external interpreter implementing InterpretItem<AssignWorker<Worker, Job>, ...> or InterpretItem<ProxyOperation<Source, Worker, Plan>, ...> must name the corresponding opaque accepted receipt in its return type. The interpreter also names ProxyControl and the immediate proxy result when implementing the concrete ProxyControlAdmission port. These are derived ownership products, not additional actor powers; their fields and receipt constructors stay private. Existing external assignment and proxy caller suites, plus the inspected Bombay interpreter source, prove the naming syntax. Before editing, Nix-pinned cargo doc -p bombay-behavior-actors --no-deps --locked built successfully, but the generated atomic index and item files omitted AssignWorker, AssignmentReceipt, ProxyControl, ProxyOperation, ProxyInputReceipt, and ProxyInputResult because their declarations or grouped re-exports carried #[doc(hidden)]. The focused regression is that these existing names and their custody descriptions appear in Rustdoc while the external caller and compile-fail fixtures keep compiling unchanged. The edit is limited to documentation visibility and regrouping the already public re-exports; it introduces no trait, type, constructor, effect lane, bound, or actor transition. The ownership proof remains the consuming settle methods and the existing static interpreter port. Aggregate states, subordinate alternatives, branches, modules, production public spellings, and current values are unchanged by this visibility repair; there is no arrival history, repeated cause, false cardinality, nested authority, semantic boolean, or structural caller path to retain. Disposition will be pass only after the item pages, external fixtures, and Nix documentation gate are checked. The focused Rustdoc build now lists all six types in the atomic index and generates their item pages. The actor source has 75 hidden annotation sites, six fewer than the preceding checkpoint. All 13 external fixture test functions passed in debug and optimized profiles. Four compile-fail snapshots changed only the diagnostic's displayed type path; their E0382 and E0599 failures remain the intended ownership and privacy errors. A clean Nix flake check at signed commit b8b9842 passed all eight available macOS checks, including Rustdoc, published-document checks, and 843 optimized Nextest tests. Disposition: pass for these six runtime item pages; A13 remains open for the rest of the surface.

  Pre-edit A13 worker-preparation port law: a trusted worker-source interpreter consumes the owner-emitted PrepareWorkers request, borrows its current source and role, then consumes either an accepted submission or its exact rejection. A multi-role request continues through the owned PendingWorkerPreparation until the complete WorkerPreparation returns. The public methods already express that affine progression; the interpreter must be able to discover those types and methods without guessing hidden Rustdoc paths. This is a derived Bombay ownership port, not a new actor-model operation. External fixed/FIFO actor tests and the inspected Bombay worker_preparation.rs use this exact syntax; no replacement trait or constructor is proposed. Before editing, Nix-pinned Rustdoc omitted the three types from the atomic index. The focused regression is that the existing three types and six progression methods become visible while their constructors, tickets, fields, and owner settlement remain private. This visibility-only batch changes zero control states, subordinate alternatives, transition branches, modules, or Rust public spellings; the exact current source, role, prepared prefix, ticket, and remaining roles retain their one owners. The residue scan is clear for arrival history, duplicated cause, false cardinality, nested transition authority, semantic booleans, and structural caller syntax. Cross-checks are the worker-preparation custody law and normalized atomic pool/supervisor documents. Disposition requires Rustdoc visibility, the external actor suites, and the clean gate. Nix-pinned Rustdoc now lists the three structs in atomic and all six progression methods on their item pages. Actor hidden annotation sites fell from 75 to 66. The external fifo_pool and fixed_supervisor_initialization actor suites passed 91 and 98 tests, respectively. The first clean Nix attempt at signed commit a74b287 stopped during optimized compilation when the machine ran out of disk space; it reported no Rust law failure. After cleaning this repository's generated Cargo target directory, the retry with two concurrent Nix builds passed all ten available macOS checks, including Rustdoc and 843 optimized Nextest tests. Disposition: pass for this documentation port; A13 remains open for the rest of the public surface.

  A13 release disposition: The public-surface inventory now assigns the canonical export groups across all five crates to application, generated-code, test-only, or interpreter ownership. It names lawful implementor roles for all 77 top-level public traits and classifies all 10 remaining core and 22 remaining actor Rustdoc-hidden sites. The still-hidden items are structural products/proofs or the internal HostedInitialization alias; the public requests, receipts, rejections, and custody methods that interpreters must name are visible. The atomic::pool::CustomerDelivery re-export remains hidden only because its canonical atomic page is visible. Caller-facing compile witnesses justify the narrower catalogue bounds, and the Router comparison law explains the one retained identity bound. The redundant DeliveryRouteFor trait was removed after its only external caller passed with DeliveryRoute's associated-address bound in debug and optimized builds; its negative rustdoc fixture failed on the prior API and now passes. The repeatable cold compile comparison and caller diagnostics are recorded in the inventory. No further bound or visibility edit is justified by the current evidence. The complete Nix gate at 7574bcb passed, including Rustdoc and 845 optimized tests. Disposition: pass for the Behavior public-surface review. A17 separately retains the real Bombay runtime witness; closing A13 does not claim that integration.

• A14 — State the trust scope of initialization capabilities accurately. Confirmed documentation/API mismatch. InitializationTurn says only the lifecycle boundary can issue initialization exactly once. However the public, doc-hidden behavior::initialize(&mut B) can be called repeatedly, and delegate_transition can be called before initialization. Active<B> provides a consuming application path, but it does not restrict those public wrapper ports. They are necessary seams to assess, not proof of universal enforcement. Complete when: specify which operations are trusted wrapper/runtime ports and which invariant the application-facing types actually enforce. Add a legal-user witness for that scope. If stronger enforcement is required, establish its composition law before changing the API; hiding rustdoc is insufficient.

• A15 — Make coding-rule enforcement agree with the actual repository. Confirmed local-rule deviations. Timer-domain tests invoke mutable accept inside assert!; catalogue models carry readiness decisions as booleans. Many rustdoc fixtures have use sections despite the explicit fully-qualified-snippet rule. Private Operating types in both pools are ambiguous outside their immediate context. These are repository-policy issues; ordinary predicates are not automatically invalid semantic state. Complete when: move transitions outside assertions, express semantic alternatives using domain sums, update snippets and ambiguous domain names, and add focused checks for rules that can be enforced reliably. Keep assertions observational in debug and optimized tests. Audit nested .sends.inner.inner access in testkit/tests/compositions.rs: interpreter structure tests may inspect structure, while ordinary consumer tests must prove syntax that survives an unrelated layer.

• A16 — Restore developer-facing documentation accuracy. Confirmed drift. The root README installs 0.14 while workspace packages are 0.17.0; four distinct linked documents moved to docs/engineering/. It still names InstallBirth and claims stricter birth-algebra equality than the current role resolver documents. Historical engineering records describe removed templates and tests. Their historical status is useful, but an old “pass” cannot certify current code. Generated-HTML checking does not validate the repository README or compile all book examples. Complete when: root and crate entry points have working links and runnable current examples; current contracts use retained names; historical verdicts clearly identify revisions. Add README link and consumer-snippet checks. Prefer links to one normative law over copied explanations in several docs.

• A17 — Validate the real downstream interpreter contract. Coverage gap explicitly acknowledged by existing docs. atomic-runtime-settlement.md says Bombay will change to implement the architecture. Local tests include useful scripted interpreters, fabricated established endpoints, and a ProxyRuntimeWitness that returns corruption for every item. Such tests prove static composition and local custody, not a working host, fresh allocation, admission, or retirement transfer. Complete when: a recorded downstream revision runs an end-to-end witness for initial and replacement creation, collisions/exhaustion, initialization stop/rejection, activation, rejection followed by independent effects, closed emitter admission, and parent-to-root residual transfer. Prove that failed replacement establishment never reports restart success. Keep allocation, scheduling, and transport in the interpreter. A read-only inspection found a real EstablishChild implementation in the sibling Bombay checkout, but that checkout has substantial uncommitted work on a separate branch. This branch has not run the required downstream revision/witness, so the scripted testkit trace is not labeled integration evidence. Isolated downstream probe: an unmodified snapshot of the sibling worktree compiled bombay-rs --lib under its Nix-pinned Rust 1.96 toolchain against published behavior crates. With Cargo patches pointing to this branch, compilation stopped at E0046: EntityAdmission<D> has not declared the newer InterpreterRequest::LogicalProtocols projection. Source review found another test-local InitializationRequest implementation with the same omission. The candidate law for a temporary compatibility probe is that both requests use already-owned capabilities and emit no logical actor Delivery, so their emitting actor's logical-host product is empty. This is an inference from the downstream source, not an actor-model guarantee or a successful A17 witness. No change was made to the sibling checkout. In a second isolated copy, those two requests declared the empty logical protocol product and Cargo patched both behavior crates to signed commit 4cd3b7f. bombay-rs --lib then compiled, and five selected downstream targets passed 27 tests: application_children (1), application_terminal_custody (2), entity_application (1), entity_runtime (11), and run_with (12). The selected tests include real application admission, activation failure, passivation, terminal custody, and caller compile fixtures. The snapshot came from the dirty downstream worktree at a7a66e391273; it is not a recorded clean revision, and the temporary projections are not present in that repository. These tests do not prove replacement-establishment failure, every creation collision and exhaustion path, independent sends after rejection, or parent-to-root residual transfer. A17 stays open.

  Address 0.3.0 is now published. In the isolated Bombay worktree codex/interpreter-ownership, Cargo resolves that release while Behavior and Communication remain path-patched research inputs. Bombay's all-target compile passes against this mixed graph. Its current library run passes 174 of 179 tests; five older startup assertions still expect publication after initialization stop or task unwind after a caught pure fold panic. This is neither an immutable integration revision nor an A17 verdict. The original Bombay checkout remains untouched.