State Exclusivity Table¶
Specification table — instantiates Overlap Exclusion Design
A design-time table that enumerates the states of one entity and marks which pairs may never hold at once, so incompatible modes are declared explicitly before any code enforces them.
Before anything can enforce "never both," someone has to write down which combinations are the forbidden ones. State Exclusivity Table is that written-down artifact: a design-time specification that lists the states, modes, or conditions a single entity can take and marks, pair by pair, which of them may never be active simultaneously. Its defining role is declaration, not enforcement or detection — it is the reference designers, reviewers, and verification tools consult to know what "mutually exclusive" concretely means for this system. It also records how the transitional and boundary moments between states are meant to behave, which is exactly where informal designs go wrong.
Example¶
An elevator controller can be in states such as doors-opening, doors-open, doors-closing, moving-up, and moving-down. Several of these must never co-occur: the car may never be moving while the doors are open. The team captures this as a State Exclusivity Table — states along both axes, each cell marked "allowed together" or "forbidden" — and, crucially, it spells out the boundary behavior: what counts as the exact moment doors are considered "closed enough" for motion to be permitted, and how a door-obstruction event during closing resolves. The table becomes the source the safety review checks against and the specification the runtime interlock is later built to satisfy.
The table itself moves no motor and blocks no command; it is paper (or a model). But because the incompatible pairs and their edge cases are declared once, explicitly, everyone downstream — the coder writing the interlock, the reviewer signing off, the tester writing cases — works from the same statement of what may never overlap.[n1]
How it works¶
- Enumerate the states — list every mode the entity can occupy along both axes of the table.
- Mark each pair — for every cell, record whether the two states may hold together or are mutually exclusive.
- Specify the boundaries — define how transitions and ambiguous in-between moments are classified, so "which state are we in right now" has an answer at the edges.
- Publish as the reference — make the table the single artifact that design, review, and verification all cite.
Tuning parameters¶
- State granularity — coarse modes versus fine sub-states. Finer granularity captures dangerous edge combinations but grows the table quadratically.
- Boundary strictness — how transitions are treated: as their own explicit states, or folded into adjacent ones. Explicit transition states are safer but heavier to specify.
- Symmetry and defaults — whether unmarked cells default to "allowed" or "forbidden." A forbidden-by-default table is conservative but demands justifying every permitted pair.
- Coverage discipline — whether every pair must be adjudicated or only the safety-critical ones; full coverage is safest but costly.
When it helps, and when it misleads¶
Its strength is that it makes incompatibility a shared, inspectable object before a line of enforcement code exists — reviewers and test authors argue over one table rather than reverse-engineering intent from scattered conditionals. It is especially valuable for the boundary moments that informal designs leave undefined. Its limitation is precisely that it is only a declaration: a correct table sitting beside incorrect enforcement gives no protection, and a table that omits a state or mislabels a boundary case propagates that gap to everything built on it. The classic misuse is treating the table as if writing it were the safeguard, when nothing yet checks that the running system obeys it. The guarding discipline is to tie the table to something that enforces it and to re-derive test cases directly from its cells.
How it implements the components¶
collection_role_register— the table is the register of the entity's states and the incompatibility relation among them.boundary_case_policy— it specifies how transitional and ambiguous in-between moments are classified, so edge cases have a declared home.downstream_use_boundary— it states what the rest of the system may assume (e.g., "motion implies doors closed") and, by omission, what it may not.
It does not enforce the rule at run time, evaluate a per-write membership predicate, or act as the accepting authority — no_shared_member_invariant (as enforcement), membership_resolution_rule, and assignment_authority belong to Mutual-Exclusion Constraint, which turns one row of this table into a live gate.
Related¶
- Instantiates: Overlap Exclusion Design — declares, at design time, which state memberships must remain disjoint.
- Sibling mechanisms: Holdout Leakage Test · Mutual-Exclusion Constraint · Namespace Collision Scan · Overlap Exception Register · Overlap Matrix · Pairwise Intersection Audit · Quarantine and Reassignment Queue · Segregation-of-Duties Check · Single-Assignment Workflow
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: State Exclusivity Table operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it a design-time table that enumerates the states of one entity and marks which pairs may never hold at once, so incompatible modes are declared explicitly before any code enforces them.
Independent corroboration: The frozen evidence defines State Exclusivity Table as 'A design-time table that enumerates the states of one entity and marks which pairs may never hold at once, so incompatible modes are declared explicitly before any code enforces them', so its operative form is Representation, Specification & Plan.
Nearest alternative: Rule, Policy & Commitment — State Exclusivity Table includes features of a standing rule, threshold, contractual commitment, or policy constraint governing future conduct, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Enumerating mutually incompatible states is finite-state design.
Related originating lineages:
- Engineering & Design — Mode incompatibility is safety-critical.
- Law & Governance — Statuses may be legally exclusive.
Review resolution: The blind reviewers agree that computer_science is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, domain reach disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain convergent because the combined evidence shows independent disciplinary development. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] In finite-state modeling, a system's legal configurations are constrained by which states may hold at once; Harel's statecharts distinguish exclusive (OR) states, where exactly one is active, from orthogonal (AND) regions that run in parallel. An exclusivity table records the OR relationships a design must never violate. ↩