39. Control authority, command fencing, handover, and safety-runtime isolation
The profile/social agent can describe a drive, book an event or propose a mission. It cannot become a motion controller. Safety-critical execution uses a separately deployed control plane with hardware-rooted workload/device identity, function-scoped…
The profile/social agent can describe a drive, book an event or propose a mission. It cannot become a motion controller. Safety-critical execution uses a separately deployed control plane with hardware-rooted workload/device identity, function-scoped leases, monotonic authority epochs, bounded command envelopes, independent supervision and asset-specific minimum-risk behavior.

Identity proves who is speaking; policy grants what may be done; only the control plane can actuate.
#39.1 Function-scoped authority lease
Monotonic, reboot-safe control ownership v1.4
AuthorityClockRef {
arbiterId, clockId, arbiterBootId, tickRate,
authorityEpoch, antiRollbackStateDigest
}
AuthorityLease {
leaseId, assetId, configurationDigest, functionId,
controllerPrincipalId, controllerWorkloadIdentity,
authorityClockRef, priorityClass, mode, allowedCommandKinds[],
operatingEnvelopeRef, safetyConstraintRef,
validFromTick, expiresAtTick, maxCommandRate,
heartbeatPeriodTicks, missedHeartbeatLimit,
predecessorLeaseId?, handoverTransactionId?, revocationChannel,
issuerDecisionRef, leaseDigest, issuerProofRef
}
Arbiter reboot changes arbiterBootId and increments persisted authorityEpoch
before arming. Anti-rollback failure latches SAFE and invalidates old leases.
AuthorityLease {
leaseId, assetId, configurationDigest, functionId,
controllerPrincipalId, controllerWorkloadIdentity,
authorityEpoch, priorityClass, mode, allowedCommandKinds[],
operatingEnvelopeRef, safetyConstraintRef,
validFromMonotonic, expiresAtMonotonic,
maxCommandRate, heartbeatPeriod, missedHeartbeatLimit,
predecessorLeaseId?, handoverTransactionId?, revocationChannel,
issuerDecisionRef, leaseDigest, issuerProofRef
}
The arbiter stores current authorityEpoch per function in safety-grade local
state. A command under an older or future epoch is rejected before it reaches
an actuator. Wall-clock timestamps do not fence controllers.#39.2 ControlCommand and disposition
Fenced, framed, expiring control command v1.4
ControlCommand {
profile, commandId, controllerId, controllerBootId,
authorityClockRef, leaseId, authorityEpoch,
commandSequence, sequencePolicy, functionId, targetSelector,
setpointOrAction, frameRef, envelopeRef,
issuedTick, expiresTick, commandDigest, controllerProofRef
}
CommandDisposition {
commandId, commandDigest, admissionResult, admissionReasonCodes[],
admittedAtTick?, executionState, executionEvidenceRefs[],
finalAtTick?, dispositionDigest, arbiterProofRef
}
Exact duplicate ID/sequence/digest returns the original disposition without
actuator re-entry. Same ID or sequence with different digest is equivocation and
fences the controller. Admission and physical execution outcomes remain distinct.
ControlCommand {
commandId, assetId, functionId, controllerId,
leaseId, authorityEpoch, sequence,
configurationDigest, controlMode,
setpoint: QuantityValue | Pose | Trajectory | DiscreteCommand,
setpointFrameRef?, issuedAtMonotonic, validFromMonotonic,
expiresAtMonotonic, rateLimits?, safetyConstraintRef,
expectedAckDeadline, commandDigest, controllerProof
}
CommandDisposition {
commandId, outcome: accepted|rejected|superseded|expired|partiallyApplied,
reasonCode, receivedAtMonotonic, appliedAtMonotonic?,
appliedSetpoint?, actuatorFeedbackRefs[], supervisorInterventionRef?
}- Setpoint units, quantity kind, frame, configuration, mode and sequence must match the active function contract. The arbiter never guesses or converts an omitted frame.
- Expiration is checked on a safety-local monotonic clock. A stale network packet cannot become valid because a wall clock moved backward.
- Every accepted command produces actuator/plant feedback or a timeout disposition. Accepted does not mean the requested physical effect occurred.
- Command and feedback telemetry use a high-integrity lane separate from social, market, profile and advertisement events.
#39.3 Deterministic arbitration precedence
| Precedence | Authority | Behavior |
|---|---|---|
| 1 | hardware/protective boundary | Physical interlock, fuse, relief, watchdog or certified limiter cannot be overridden by software |
| 2 | emergency-stop authority | Immediate safe transition using independent path where required |
| 3 | safety veto/limit controller | Rejects or reshapes commands inside validated constraint set |
| 4 | current function lease | Only matching controller/epoch/sequence may command |
| 5 | registered shared-control policy | Combines compatible variables through one locked blending equation |
| 6 | fallback controller | Activates when handover/link/health/envelope conditions require |
Shared blending is legal only for the same physical variable, compatible units/frame/timebase, a registered blend, and preserved actuator/safety limits. Otherwise simultaneous commands are a conflict and invoke the named fallback rather than an average.
#39.4 Two-phase handover protocol
- PREPARE — current controller/arbiter proposes exact function set, reason, state checkpoint and desired barrier.
- READY — candidate proves workload health, configuration, context, link, clock, model/envelope readiness and synchronized command state.
- COMMIT — arbiter atomically increments authorityEpoch, issues the new lease and records the handover barrier.
- FENCE — old epoch becomes invalid for every command at or after the barrier; delayed packets remain rejected.
- ACTIVATE — new controller sends its first command and receives an accepted disposition within the declared deadline.
- COMPLETE — actuator/plant feedback confirms control; otherwise timeout invokes the function-specific fallback.
#39.5 Safety-state machine
Reference safety-runtime transitions
DISABLED -> SAFE -> STANDBY -> ARMED -> ACTIVE
ACTIVE -> DEGRADED -> FALLBACK -> SAFE
ACTIVE -> SAFE (normal disarm only under permitted transition)
ANY OPERATIONAL STATE -> EMERGENCY_STOP
EMERGENCY_STOP -> RECOVERY_CHECK -> SAFE
FAULT_LATCHED -> RECOVERY_CHECK -> SAFE
Forbidden:
EMERGENCY_STOP -> ACTIVE
FAULT_LATCHED -> ARMED/ACTIVE
DEGRADED -> ACTIVE without recovery predicates
SAFE -> ACTIVE without STANDBY and ARMED gates
Every transition binds source condition, configuration, authority epoch,
monitor snapshot, action taken, deadline, feedback and receipt.Minimum risk is domain-specific
Loss of link does not universally mean stop. A road vehicle may pull over; a boat may hold, anchor or surface; an aircraft may loiter, return or land; a blimp may preserve altitude and navigate to recovery; a spacecraft may enter safe pointing; a robot may hold load or release energy. The fallback is an installed, verified and locally executable capability.#39.6 Safety filter and independent supervisor
Illustrative constrained safety filter - not universal certification
u_safe = argmin_u ||u - u_requested||_W^2
subject to:
actuator position/rate/effort/thermal constraints
operating-envelope constraints
collision/separation/structural/stability constraints
control-barrier condition: dh/dt + alpha(h(x)) >= 0
SafetyFilterDefinition binds:
state estimate inputs; model/constraint digests; solver/profile;
validated operating domain; maximum solve time; infeasibility response;
numerical tolerance; fallback command; verification/validation evidence.
Independent supervisor checks command freshness, lease epoch, watchdog,
critical sensors, actuator agreement, envelope and heartbeat. It can veto or
transition safe state without relying on the primary controller or cloud.#39.7 Control software release and evidence
| Gate | Required artifact |
|---|---|
| requirements/hazard | function safety requirements, hazard analysis, assumptions, ODD/envelope and fallback |
| implementation | source/build provenance, binary digest, compiler/toolchain, dependencies and configuration/calibration schema |
| verification | unit/property/static/fuzz tests, numerical vectors, timing/WCET and fault-injection results |
| simulation | scenario/model corpus, coverage, model limitations and differential results |
| hardware-in-loop | exact controller/actuator/sensor versions, timing/network impairments and pass/fail evidence |
| vehicle release | installed configuration, calibration, checks, approver, permitted envelope and rollback version |
| operations | health/heartbeat, anomaly thresholds, incident response, rollback/disable and audit retention |