Seat Continuity and Handover

A pair of primitive families that separate who is sitting in a seat from what the seat itself is:

1. Occupant-creation primitives, resume, fork, rebuild, fresh, produce a candidate new occupant. Answer: "where did the new occupant come from?"
2. Seat-binding operations, handover binds a candidate occupant into the topology. Answer: "what happened to the stable seat identity?" Inspect the current CLI for executable operations; design vocabulary alone does not establish a command.

Core architectural decision: stable seat identity, fluid occupant identity, explicit provenance. Do not encode successive occupants into live seat names. Keep the stable address and record lineage separately.

Use this when

• Replacing a seat's occupant via rebuild, fork, fresh, or seat-handover
• Choosing old-occupant disposition: retire / advise / shadow
• Reasoning about whether a seat's lineage is stable or has drifted
• Reading or writing the provenance record for a seat
• Designing or auditing topology stability across an occupant change

Don't use this when

• The seat is freshly created (no occupant to replace), use rig launch / rig expand directly
• The intent is to change topology shape (add/remove seats), not replace an occupant, use topology-mutation primitives

The two-outcome honesty model

Every seat-binding operation produces two independent outcomes:

continuityOutcome: rebuilt | resumed | forked | fresh | failed
seatBindingOutcome: handed_over | partial | failed | unchanged

These can disagree honestly. Examples:

• continuityOutcome: failed + seatBindingOutcome: unchanged, new occupant didn't materialize; seat correctly retains old occupant.
• continuityOutcome: rebuilt + seatBindingOutcome: failed, candidate created OK; bind failed mid-flight; provenance records the gap.