Domain Invariant Review¶
Procedure — instantiates Essential-Accidental Complexity Triage
A review with domain owners that tests whether proposed simplification preserves required distinctions and constraints.
Domain Invariant Review is the gate where the people who own the problem — not the code — examine a specific proposed simplification and answer one question: does this preserve every distinction and constraint the domain actually requires? Its defining move is to make domain expertise the arbiter of what may not be removed. It converts tacit "you can't just merge those two states, they mean different things to a regulator" knowledge into an explicit register of invariants, then holds a candidate change against that register and passes or blocks it. It does not decide what is worth simplifying or in what order; it decides only whether a given cut is safe against the domain.
Example¶
A tax-preparation software team wants to simplify a filing module that carries four separate "dependent" categories, which engineering suspects are redundant. They convene a domain invariant review with two enrolled agents and a tax attorney — the domain owners. The review first pins the essential problem: correctly computing a return under current statute, where certain credits hinge on distinctions between a qualifying child, a qualifying relative, and two edge categories. As the owners walk the proposed merge, they articulate invariants the code must never violate: a qualifying child under a given age gates one credit that a qualifying relative can never claim, and one of the "redundant" categories exists solely to handle a shared-custody rule that changes the eligible parent. Three of the four categories turn out to encode real, statute-driven distinctions; the fourth is genuinely an artifact of an old form layout. The review's output is a signed register of the invariants any simplification must preserve and a verdict: merging category four is safe; merging the others would silently produce wrong returns. The engineers get a green light on exactly one of their four intended cuts — and, crucially, a written reason for the three refusals.
How it works¶
- Seat the domain owners. The reviewers are accountable for the real-world problem (law, safety, clinical correctness), not for the implementation; their authority is over meaning, not code.
- State the essential problem first. Before judging any cut, the review fixes what the system must get right, so "required" is measured against the problem, not against habit.
- Elicit the invariants. Each defended distinction is written as an explicit rule the system must never violate — the register that outlives this one review.
- Run the candidate through the gate. The specific proposed simplification is tested against each invariant; it passes only if none is broken, and every refusal is recorded with its reason.
Tuning parameters¶
- Owner seniority and coverage — which domain authorities sit on the panel; the true expert catches the subtle invariant a proxy misses, but over-senior panels default to "keep everything" out of caution.
- Invariant formality — whether invariants are prose assertions or executable contracts; formal ones can be handed to a test suite but cost effort to write and can ossify.
- Burden of proof — whether the default is "preserve unless proven accidental" or "cut unless proven essential"; the former is safe but conservative, the latter aggressive but risky.
- Scope of a sitting — one candidate change or a batch; batching is efficient but blurs which invariant blocked which cut.
When it helps, and when it misleads¶
Its strength is that it is the one step qualified to say no on domain grounds: it catches the simplification that looks clean to an engineer but quietly deletes a distinction the world depends on, and it converts the vague veto "everything is essential" into a finite, inspectable list of invariants that can then be respected precisely rather than feared wholesale. It is the discipline behind not removing a rule until you understand why it was put there.[n1]
Its failure mode is conservatism capture: domain owners are rewarded for catching a bad cut and rarely blamed for blocking a good one, so a review with no burden-of-proof discipline drifts toward preserving everything and rubber-stamping the status quo as "all essential." A classic misuse is letting the review expand from is this cut safe? into is this cut worthwhile? — smuggling in a value judgment that belongs to the payoff and sequencing steps. The guarding discipline is to require, for each preserved distinction, a concrete failure case ("here is the return that comes out wrong"), so an invariant must earn its place rather than being asserted by seniority.
How it implements the components¶
essential_problem_core— the review opens by fixing what the system must get right in the world, giving every "required" judgment a referent.irreducible_constraint_register— the elicited invariants are recorded as an explicit, durable register of distinctions and constraints no simplification may violate.simplification_safety_gate— the candidate change is run against that register and passed or blocked, with each refusal reasoned.
It does not surface, classify, or attribute the burdens in the first place (approach_induced_burden_inventory, complexity_attribution_rubric, boundary_of_responsibility_map) — that cross-role attribution is complexity_attribution_workshop, its nearest procedure twin: the workshop labels each burden's cause, whereas this review certifies which distinctions are irreducible and gates a cut against them.
Related¶
- Instantiates: Essential-Accidental Complexity Triage — the review is the archetype's protector of the essential core, the veto that keeps simplification from cutting bone.
- Consumes: essential_accidental_complexity_audit — supplies the classified candidates whose "essential" claims this review stress-tests against real domain constraints.
- Sibling mechanisms: complexity_attribution_workshop · interface_surface_reduction_review · simplification_regression_suite · dependency_simplification_map · legacy_constraint_map · complexity_budget_gate · refactoring_paydown_plan · residual_complexity_justification_template
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Domain Invariant Review operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a review with domain owners that tests whether proposed simplification preserves required distinctions and constraints.
Independent corroboration: The frozen evidence defines Domain Invariant Review as 'A review with domain owners that tests whether proposed simplification preserves required distinctions and constraints', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Domain-driven software design established having domain owners define and protect business distinctions that implementation simplification must preserve.
Related originating lineages:
- Engineering & Design — Requirements and systems-engineering reviews established validating simplifications against protected constraints and failure cases.
- Organizational & Management Science — Process redesign supplied domain-owner review of tacit business rules and the purpose behind legacy steps.
Review resolution: Domain-driven software design most directly cohered domain-owner protection of business distinctions, synthesized with engineering invariant review and organizational process knowledge.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Chesterton's Fence (G. K. Chesterton) — the principle that one should not remove a fence until one understands why it was put there. The invariant-elicitation step is exactly this discipline applied to a system: a distinction may not be cut until the domain owners can say what it protects. ↩