Skip to content

Finite-State Map Selector

Selector model — instantiates Context-Keyed Representation Switching

Models contexts as the states of a machine and switching as guarded transitions, so the active representation can only change along legal, explicitly-allowed paths — never an arbitrary jump.

Not every switch between contexts is legal, and not every one is safe. Finite-State Map Selector models the set of contexts as the states of a finite-state machine and every switch as a guarded transition, so the active representation can only change along paths that have been explicitly allowed. Its defining property is that selection carries memory and legality: the current state constrains which state you can move to next, and each move must pass a guard condition, which makes an illegal or unsafe context jump structurally impossible rather than merely discouraged. It resolves ambiguous or conflicting cues down to exactly one current state; the raw key→map lookup it hands off to a table, and the timing of switches it hands off to a debounce.

Example

A robotic welding cell operates in a handful of modes, each with its own representation of what the arm may do: transit, positioned, weld, and fault. The selector permits only defined transitions — the arm cannot enter weld except from positioned, so a weld command received while in transit is rejected or forced first through positioned; from any state it can drop to fault. When two sensors disagree about whether the workpiece is seated, the disambiguation rule resolves the conflict to a single current state (say, staying in transit until a quorum agrees), rather than flickering. The result is that unsafe context jumps — a weld attempted mid-transit — simply cannot occur, because there is no legal edge for them.

How it works

Its distinguishing feature is that selection is stateful and legality-constrained. Because the machine knows which state it is in, the set of reachable next states is limited to explicitly-defined, guarded edges — so the model encodes not just which map but which switches are permitted from here. It first resolves incoming cues to a single unambiguous state (disambiguation), then fires only allowed transitions. It deliberately does not perform the key→map lookup for a state (a routing table does that over the resolved state) nor decide how long to dwell before switching (a hysteresis filter does that).

Tuning parameters

  • Transition topology — which switches are legal edges. A permissive graph is flexible but admits unsafe or nonsensical jumps; a strict one is safe but can trap the system with no legal way forward.
  • Guard conditions — the preconditions each transition must satisfy before it fires. Tighter guards are safer but can block a transition that reality genuinely needs.
  • Disambiguation policy — how conflicting cues resolve to one state: priority order, most-recent-wins, or quorum. This sets how the machine behaves at the messy edges between contexts.
  • Trap / error state — whether unrecognized or contradictory input routes to an explicit fault state (with a defined way out) or is dropped.

When it helps, and when it misleads

It is the right model when some context transitions are illegal or unsafe and order matters — when "you may only enter this map from that one" is a real constraint you want enforced structurally rather than by convention.

Its characteristic failures are at the extremes of its own rigidity: an over-strict topology can trap the system when a legal real-world transition was never drawn as an edge, and state explosion makes a machine with too many states unmaintainable and its guards unauditable. The classic misuse is forcing a genuinely continuous or soft context into discrete states — modeling a dimmer as an on/off switch — or piling on states until no one understands the graph. The discipline is to keep the state set minimal and reviewed, and to always include a fault state plus a human path out, so a wrong or missing edge is recoverable rather than a dead end.[1]

How it implements the components

  • switch_transition_guard — the guarded edges are the transition guard: a switch fires only if the current state permits it and its precondition holds.
  • context_disambiguation_rule — it resolves conflicting or ambiguous cues down to exactly one current state before any transition is considered.

It does NOT map a resolved state to its representation — that lookup is Context-to-Map Routing Table's — and it does not decide how long to wait before switching, which is Hysteresis and Debounce Filter's job.

Notes

It governs which switches are allowed, not which map a state resolves to nor how long to wait before switching. It is the legality layer — meaningful only when paired with a lookup that turns its state into a representation and, usually, a debounce that keeps it from transitioning on noise.

References

[1] A guard condition in a finite-state machine (as in UML statecharts) is a predicate that must hold for a transition to fire; an unlisted transition is simply illegal. Modeling contexts this way makes unsafe jumps impossible by construction, at the cost of rigidity — which is why a reachable fault state and an override path are part of doing it well. ↩