Back to overview →
Module 03 / 04
Observe → validate → score → plan → gate → execute.
The catalogue is finite because every configuration must be verified before deployment. Runtime learning or experience can alter preferences and transition probabilities, but it cannot create an unverified configuration or edge.
Observe → validate → score → plan → gate → execute.Open section
Supervisory sequence
Observe → validate → score → plan → gate → execute.
01ObserveAcquire dynamic state and resource evidence.
02ValidateUpdate physical health and epistemic validity.
03ScoreEvaluate mission capability of verified configurations.
04PlanChoose a trajectory over the configuration graph, not only the next node.
05GateCheck resource/function admissibility, stability and timing.
06ExecuteSwitch, verify and remain in the configuration for its admissible dwell interval.
Guarantees belong to the graph, not to the optimiser.Open section
Configuration graph
Guarantees belong to the graph, not to the optimiser.
The catalogue is finite because every configuration must be verified before deployment. Runtime learning or experience can alter preferences and transition probabilities, but it cannot create an unverified configuration or edge.
\[
G_e=(\mathcal C,\mathcal T),
\qquad
T_{ij}\in\mathcal T
\Leftrightarrow
Adm_R(C_j,\rho)\wedge Adm_F(C_j)\wedge Stab(C_i,C_j).
\]
Architectural consequence: SAFE_STOP and the deepest degraded configurations can be terminal nodes. Removing a pathological node from the switching set can improve the guaranteed reconfiguration interval far more than tuning individual controller decay rates.