Control-State Diagram¶
Artifact — instantiates Phase-Space Mapping
Connects states to permitted controls, triggers, gates, and action policies.
A Control-State Diagram is the one artifact in this family that is normative rather than descriptive. Where the others show what the landscape is or where movement happens, this one prescribes the operating policy: for each state, which controls are permitted, which transitions are legal, what guard condition must hold before a transition may fire, and what observed signal triggers it. Its defining move is wiring — state → permitted control → guarded transition → next state — so the diagram doubles as a rulebook the system (or its operators) is meant to obey. It answers "given where we are, what are we allowed to do, and what has to be true first?", turning a passive state map into an operable control policy.
Example¶
A payment-processing system is specified as a control-state diagram. Its states are the lifecycle of a charge: created, authorized, captured, refunded, failed, disputed. The diagram wires the permitted operations onto each state. From authorized, a merchant may capture the funds or void the hold — but a refund is illegal here, because there is nothing captured to return; the refund edge exists only out of captured. Each edge carries its guard: the capture transition is permitted only while the authorization has not expired, and is triggered by the merchant's capture call. An observed fraud signal crossing a threshold forces an automatic transition from authorized to a review hold, regardless of what the merchant wants. Illegal transitions — refunded back to authorized, say — are drawn as blocked. The result is not a picture of what charges do; it is the enforceable policy of what they are allowed to do, and under what conditions.
How it works¶
- Take the state set and its transitions — start from a defined set of states and the moves between them, supplied by a state model, not invented here.
- Attach the driving control — annotate each transition with the action or control that causes it, and with which states permit that control at all.
- Add the guard — record the precondition that must hold before each transition may fire, so no transition is unconditional.
- Name the trigger — specify the observed signal whose value fires or gates each transition, and mark the transitions that are illegal outright.
Tuning parameters¶
- Control granularity — coarse actions (simple policy, blunt) versus fine-grained operations (precise, more edges to maintain).
- Guard strictness — permissive guards (flexible, more failure modes reachable) versus locked-down ones (safe, may block legitimate operations).
- Trigger source — manual (an operator commands the transition) versus automatic (an observed proxy fires it); automation is fast but only as good as the proxy.
- Illegal-transition handling — whether forbidden moves are explicitly drawn and blocked, or merely omitted and implicitly disallowed.
- Policy scope — how many states carry full control annotations versus being left as pass-through, trading completeness against clutter.
When it helps, and when it misleads¶
Its strength is turning a state map into something operable: it prevents illegal transitions by construction, makes every gate and precondition explicit, and gives operators an unambiguous answer to "what am I permitted to do from here?" It is the artifact that connects the landscape to enforceable action.[n1]
Its signature failure is control theater — a diagram of intended controls that the real system does not actually enforce, so a transition marked illegal happens anyway because nothing in the code or the process blocks it. Close behind are guard gaps: a transition drawn with no precondition, which then fires when it should not. The classic misuse is assuming the diagram equals reality — that a drawn interlock is a wired one. The guarding discipline is to verify that each guard is genuinely enforced in the running system and to test the illegal transitions rather than trusting that the diagram alone prevents them.
How it implements the components¶
state_transition_relation— it annotates each transition with the control that drives it and the guard that permits it, making the move-set operable rather than merely descriptive.intervention_zone— it marks, per state, which controls and actions are permitted, so leverage points are read straight off the diagram.state_observation_proxy— it names the observed signals whose values trigger or gate transitions, tying control to what the system can actually sense.
It does not draw the paths a system takes through the states (trajectory_map, reachable_state_set) — that's Trajectory Mapping Diagram, its nearest twin: the control diagram prescribes what is permitted from each state, the trajectory diagram describes what routes are traveled. It also does not render the raw dynamical geometry (state_variable, attractor_region) — that's Phase Space Plot — nor shade states by danger (forbidden_state_region, constraint_boundary, trajectory_uncertainty_band) — that's Risk Landscape Map.
Related¶
- Instantiates: Phase-Space Mapping — supplies the control-and-policy layer that makes the state map operable.
- Consumes: State-Space Model — supplies the states and transitions the diagram annotates with controls and guards.
- Sibling mechanisms: Phase Space Plot · Trajectory Mapping Diagram · Risk Landscape Map · Attractor Basin Analysis · Reachability Analysis · Behavioral State Space · Scenario State Map
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Connects states to permitted controls, triggers, gates, and action policies, making its operative form a non-executable information artifact that externalizes static or prospective structure.
Independent corroboration: The frozen evidence defines Control-State Diagram as 'Connects states to permitted controls, triggers, gates, and action policies', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Systems Thinking & Cybernetics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Control theory cohered state-transition representations that associate operating states with admissible controls, guards, triggers, and next states.
Related originating lineages:
- Computer Science & Software Engineering — Finite-state machines and statecharts supply an executable notation for guarded control policy.
- Engineering & Design — Sequential-control and safety engineering contribute operating-state guards, permitted actions, and interlocks.
Review resolution: State-transition representations link the control-theory lineage to finite-state-machine and engineering notations; the exact diagram is a recognizable cross-disciplinary formalism rather than a universal device.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] A guard condition in a finite-state machine is a boolean predicate that must be true for a transition to fire, even when its trigger event occurs. It is the formal device that makes a control-state diagram a policy rather than a wish: the transition is not merely available, it is available only if the guard holds — which is also why an unenforced guard is worse than none, since it looks like protection while providing none. ↩