The Stability Principle in CAT DILR

Halfway through a DILR set, an aspirant has two cases open and no idea which is real. So they work case one, get four minutes in, hit a contradiction, and start case two from a grid they no longer trust. The clock does the rest.

There was a faster route, and it was available before either case was opened. Some facts in that caselet had stability: they were true in both cases. Not likely in both. True in both, unavoidably, because they follow from the totals rather than from the arrangement.

Geologists call the layer that runs unbroken through a fault a marker bed: everything above and below is displaced, and that one band is continuous, which is exactly why it is the thing you measure against. Every DILR set has a few.

Why Some Facts Have Stability Across Every Arrangement

A DILR caselet usually has many valid-looking arrangements and one correct one. What separates the facts that vary from the facts that do not is whether they depend on which arrangement or only on how much there is.

A total does not care about order. If six people scored 240 between them, that stays 240 whichever way you assign the scores. Parity does not care either: if the sum of five distinct odd numbers is odd, no rearrangement changes it.

That distinction is worth making explicitly, because it decides what you can safely build on:

• Arrangement-dependent: who sits where, which product went to which region, the order of finishing.
• Arrangement-independent: the grand total, the number of items in each category, whether a count is odd or even.
• Derived invariants: a maximum or minimum forced by the totals, which holds regardless of how the rest resolves.
• False invariants: anything that only holds in the case you happen to be in, which is the trap.

The Bedrock Facts: Three Places Invariants Hide

The search is quick because it looks at the numbers rather than at the arrangement, and it happens before the grid is touched.

Totals and sums are the first thing to derive and the most frequently skipped, because they feel like a preliminary rather than a step:

• Add the given values before doing anything else. The grand total constrains every row and column.
• Subtract known entries from the total. What remains is a budget that every case must respect.
• If the total is not given, check whether it is derivable. A derivable total is worth more than two ordinary clues.

Counts and parity resolve a surprising share of sets, and they are almost never stated directly:

• Count how many entities go into each category. Often the counts are forced even when the assignments are not.
• Check whether a required sum can be odd or even. If a case demands the wrong parity, it dies without further work.
• Watch for "each" and "exactly one" statements, which fix counts across the whole set rather than for one entity.

Undisturbable order is the subtlest of the three, and it is what lets you fix relative positions long before absolute ones:

• If A is above B and no clue can move either, that relationship holds in every case.
• Chains of comparisons often fix a partial order that survives all branching.
• The extremes are frequently determined even when the middle is not. The highest and lowest are cheap to pin.

How Bedrock Kills Branches

This is where the two minutes pay for themselves. A case does not have to be worked to be eliminated; it only has to be checked against something that cannot bend.

Every row in that last column is seconds. Compare that with the three or four minutes a case takes to work through properly, and the argument for deriving invariants first stops being a matter of style.

What Is Not Bedrock, and Why It Matters

The failure mode here is promoting something to invariant status when it is only true in the case you are currently in. A few reliable tests:

• If you derived it after opening a case, it is not bedrock unless you can re-derive it without the assumption.
• If it names a specific position, it is almost certainly arrangement-dependent.
• If it followed from another entity's value that is itself unfixed, it inherits that uncertainty.
• If it is a maximum or minimum, check whether the bound comes from the totals or from the current arrangement. Only the first is bedrock.
• Write bedrock somewhere separate from the grid, so it is never confused with case-specific working.

Keeping that separation is the same discipline as tracking what is proved versus assumed, which is covered in why every impossible DILR set is actually waiting for one observation.

Common Mistakes With Invariants

Related habits that cost sets:

• Skipping parity. Never checking whether a required sum can be odd or even, which is often the fastest branch-killer available.
• Deriving inside a case. Establishing something useful within one branch and losing it when the branch dies.
• Ignoring counts. Focusing entirely on which entity goes where while never asking how many go in each category.
• Missing derivable totals. Assuming a total is unavailable because it is not printed.
• Mixing bedrock with working. Writing invariants into the grid, where they become indistinguishable from case-specific entries.

A Practice Drill for Finding Bedrock

The drill deliberately stops before any arrangement is attempted.

1. Take twelve DILR sets. Do not solve them.
2. For each, spend ninety seconds writing down everything true in every possible arrangement: totals, counts, parity, forced orderings.
3. Now read the solution and mark which of your invariants it used, and which it used that you missed.
4. Keep a running list of the invariant types you consistently miss. It will be short and it will not change much.

What tends to come out of it:

• Parity is the most commonly missed invariant by a wide margin.
• Aspirants find totals reliably but rarely convert them into a remaining budget.
• Forced partial orderings are under-used, and they are what make the extremes cheap to pin.
• Sets that previously needed two full cases often resolve with one once bedrock is derived first.

The Bottom Line

DILR rewards knowing which of your facts are load-bearing. Arrangements shift, cases die, grids get rebuilt, and through all of it a few things stay exactly where they were. Finding those first is not preparation for solving the set. It is most of solving the set.

The Bedrock Facts, Recap

• Totals and sums: fixed by the data, not the arrangement. Derive immediately.
• Counts and parity: how many, and whether it must be odd or even.
• Undisturbable order: relationships no remaining clue can move.

Build the Habit on Timed CAT DILR

Deriving invariants first feels slow until it has saved a set, so it has to be practised against a clock. Work through CAT previous year questions in timed blocks, or sit full CAT mock tests and past papers so the habit survives real fatigue. More DILR method sits in the CAT DILR blog archive, and if cases keep collapsing late it is worth having your approach reviewed honestly.

The Optima Learn Editorial Team builds CAT preparation content from exam-pattern analysis and Optima Learn's adaptive practice data. This guide is part of our CAT DILR preparation series.