Home Contact
Universal Substratev1.4
/
For agents Markdown

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…

Concept & directionLNK

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.

Diagram separating workload identity, policy decisions, agent and commerce proposals, and physical control into isolated trust planes.
Picture 13

Identity proves who is speaking; policy grants what may be done; only the control plane can actuate.

#39.1 Function-scoped authority lease

Table
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

Table
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

PrecedenceAuthorityBehavior
1hardware/protective boundaryPhysical interlock, fuse, relief, watchdog or certified limiter cannot be overridden by software
2emergency-stop authorityImmediate safe transition using independent path where required
3safety veto/limit controllerRejects or reshapes commands inside validated constraint set
4current function leaseOnly matching controller/epoch/sequence may command
5registered shared-control policyCombines compatible variables through one locked blending equation
6fallback controllerActivates 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

  1. PREPARE — current controller/arbiter proposes exact function set, reason, state checkpoint and desired barrier.
  2. READY — candidate proves workload health, configuration, context, link, clock, model/envelope readiness and synchronized command state.
  3. COMMIT — arbiter atomically increments authorityEpoch, issues the new lease and records the handover barrier.
  4. FENCE — old epoch becomes invalid for every command at or after the barrier; delayed packets remain rejected.
  5. ACTIVATE — new controller sends its first command and receives an accepted disposition within the declared deadline.
  6. COMPLETE — actuator/plant feedback confirms control; otherwise timeout invokes the function-specific fallback.

#39.5 Safety-state machine

Table
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.
Table
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

Table
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

GateRequired artifact
requirements/hazardfunction safety requirements, hazard analysis, assumptions, ODD/envelope and fallback
implementationsource/build provenance, binary digest, compiler/toolchain, dependencies and configuration/calibration schema
verificationunit/property/static/fuzz tests, numerical vectors, timing/WCET and fault-injection results
simulationscenario/model corpus, coverage, model limitations and differential results
hardware-in-loopexact controller/actuator/sensor versions, timing/network impairments and pass/fail evidence
vehicle releaseinstalled configuration, calibration, checks, approver, permitted envelope and rollback version
operationshealth/heartbeat, anomaly thresholds, incident response, rollback/disable and audit retention