Invalid Combination Rule Sheet¶
Checklist — instantiates Cross-Axis Product Space Design
Records constraints that filter infeasible, illegal, unsafe, semantically invalid, or unsupported cells.
An Invalid Combination Rule Sheet is the register of why cells are excluded. It is not the list of what survives; it is the constraint logic that does the culling and the recorded reason behind each cut. Its defining idea is that exclusions are generative and justified: rather than someone quietly deleting impossible rows from a table, the rule sheet states a small set of predicates — "if axis A is this then axis B may not be that, because …" — that any generated cell can be tested against, and it keeps the reason attached to every rule so a future reader knows whether the constraint is a law of physics, a legal prohibition, a safety interlock, or a temporary business decision. It is the mechanism that makes the difference between a product space that hides its assumptions and one that can defend every hole in it.
Example¶
A regional insurer sells a life policy configurable across several axes: base product (term, whole, universal), optional riders (accelerated death benefit, disability waiver, child rider), applicant age band (18–39, 40–59, 60–75), and state of issue. The raw product is large, and much of it must not exist. The rule sheet enumerates the constraints and, crucially, the reason for each: the disability-waiver rider is prohibited above age band 60–75 by regulation in three states; the child rider is not offered on the term base product by company policy; universal life cannot pair with the accelerated-death-benefit rider because the two touch the same cash-value mechanism — a semantic contradiction, not merely a business choice.
Each rule reads as a predicate a generated cell can be checked against, and each carries a coded reason (statutory / policy / structural) and an owner. When compliance later asks "can we open the disability waiver to the oldest band in Ohio?", the answer is not lost in tribal memory: it is a line on the sheet with a statute citation. And because the constraints largely arise where two axes are not independent — a rider that depends on the base product, an age limit that depends on the state — the sheet doubles as the record of exactly where the tidy Cartesian assumption breaks.
How it works¶
- Write exclusions as predicates. Each rule is a testable condition over axis values ("base = universal AND rider = ADB → forbidden"), so the whole product can be screened mechanically rather than pruned by hand.
- Attach a reason and a class. Every rule carries why — legal, unsafe, structurally impossible, unsupported-by-choice — and who owns it, so a constraint can later be re-examined on its merits.
- Locate the dependency. Because most exclusions come from axes that are conditional on one another, each rule implicitly flags where the axes fail to be independent — the sheet is where false independence gets caught.
- Preserve, don't delete. An excluded cell is marked excluded-with-reason, never silently removed, so the boundary of the feasible region stays visible for review.
Tuning parameters¶
- Reason taxonomy — how finely exclusions are classified (a flat "invalid," or graded into illegal / unsafe / impossible / unsupported). Finer classes make later relaxation decisions cleaner but demand more discipline at authoring time.
- Rule granularity — broad rules that forbid whole regions vs. narrow ones that name single cells. Broad rules are compact but can over-exclude; narrow ones are precise but proliferate.
- Hard vs. soft constraints — whether a rule is an absolute prohibition or a flagged warning requiring override. Softening a rule buys flexibility at the cost of a firm boundary.
- Review triggers — what forces a rule to be re-checked (a regulation change, a new state, a product redesign); stale constraints are as dangerous as missing ones.
- Ownership — how tightly each rule is bound to an accountable owner, which decides whether a "why" can actually be reconstructed years later.
When it helps, and when it misleads¶
Its strength is that it makes exclusion accountable: the feasible region becomes a stated consequence of named rules rather than an unexplained set of gaps, and anyone can ask why a cell is missing and get an answer. By concentrating on the reason and the dependency behind each cut, it is also the natural place where false independence between axes is discovered and documented.
Its failure mode is the invalid-cell erasure the archetype warns about — a constraint applied so long ago that its reason is forgotten, then obeyed or removed by someone who has no idea what it protected. This is Chesterton's fence[n1] in table form: the whole point of recording the why is so that no one tears down a rule without first understanding what it was fencing off. The classic misuse is treating the sheet as a static "known-bad list" and never revisiting it, so obsolete prohibitions ossify and genuine new ones go unwritten. The guarding discipline is to keep every rule tied to a live reason and an owner, and to re-run the sheet against the product whenever an axis, level, or law changes.
How it implements the components¶
feasibility_filter— its predicates are the filter that separates the raw product from the admissible subset, applied by rule rather than by hand.invalid_combination_exception_register— it is the durable register of excluded cells, each carrying its reason, class, and owner.axis_independence_check— because most rules encode a dependency between axes, the sheet is where conditional (non-independent) axes are surfaced and recorded.
It does not enumerate the product it screens (combination_enumerator — that is Full Factorial Matrix and Product Space Generator Script), and it does not publish the surviving supported envelope as a commitment (product_boundary_statement, equivalence_class_collapse_rule — that is Configuration Matrix). The rule sheet is the exclusion logic and its reasons; the configuration matrix is the bounded result those exclusions leave behind.
Related¶
- Instantiates: Cross-Axis Product Space Design — it supplies the feasibility rules that turn a raw product into an admissible subset without erasing the reasons.
- Consumes: Product Space Generator Script or Full Factorial Matrix supplies the raw product its predicates screen.
- Sibling mechanisms: Combinatorial Test Coverage Grid · Configuration Matrix · Full Factorial Matrix · Pairwise Covering Array · Product Space Generator Script · Scenario Cube · Coverage Heatmap
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Invalid Combination Rule Sheet operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it records constraints that filter infeasible, illegal, unsafe, semantically invalid, or unsupported cells
Independent corroboration: The frozen evidence defines Invalid Combination Rule Sheet as 'Records constraints that filter infeasible, illegal, unsafe, semantically invalid, or unsupported cells', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Filtering a cross-product space with explicit feasibility constraints is an operations-research and constraint-satisfaction form. Engineering configuration, software validation, legal prohibitions, and mathematical relation constraints supply distinct rule classes intentionally unified by the sheet.
Related originating lineages:
- Computer Science & Software Engineering — Constraint schemas and product-configuration rules materially make combinations machine-checkable.
- Engineering & Design — Retained as a formative lineage because an independent reviewer identified it as primary: Explicit compatibility and infeasibility matrices are rooted in engineering configuration and design-constraint management.
- Law & Governance — Legal and regulatory prohibitions materially supply reason-bearing constraints that cannot be reduced to technical infeasibility.
- Mathematics — Cartesian products and constraint satisfaction provide the formal cell structure.
Review resolution: Filtering a cross-product space with explicit feasibility constraints is an operations-research and constraint-satisfaction form. Engineering configuration, software validation, legal prohibitions, and mathematical relation constraints supply distinct rule classes intentionally unified by the sheet. The retained alternate domains identify documented formative or independently established origins, not downstream applicability alone. domain_reach=multi_domain because the operating pattern has established use in several fields. The final marks encyclopedia_synthesis=true because the entry deliberately composes those lineages.
Attribution caveat: The rule sheet intentionally unifies technical, semantic, legal, safety, and support constraints; it is broader than any one canonical constraint artifact.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
- https://developers.google.com/optimization/cp — Google OR-Tools primary documentation on constraint programming over feasible combinations.
Notes¶
[n1] Chesterton's fence — G. K. Chesterton's principle that one should not remove a fence (or rule) until one understands why it was put up in the first place. It is the precise argument for why an invalid-combination sheet must record the reason behind each exclusion, not just the exclusion: the reason is what protects a future maintainer from deleting a constraint whose purpose they cannot see. ↩