8.3 Analysing Scenarios and Tracking Conditions

8.3 Analysing Scenarios and Tracking Conditions

Quick Summary: OPM's description of the Occupational Reasoning Assessment includes analyze scenarios. These items present a situation with several entities and conditions and ask what follows. They are less about formal logic than about bookkeeping: recording what each condition establishes and, crucially, what it leaves open. OPM's tip to use lists or visuals to organise the information provided is aimed at exactly this.

The three states of any claim

Every claim about a scenario is in one of three states, and keeping them distinct is the whole technique.

Most wrong answers on scenario items are claims in the third state presented as though they were in the first. A candidate who does not track the difference will find undetermined options genuinely persuasive, because they are consistent with everything given.

The tracking table

When a scenario involves entities with properties, draw a grid. Entities down the side, properties across the top.

Scenario. Four case files — W, X, Y and Z — are each assigned to exactly one of two teams, Intake or Review. Files assigned to Review are always digitised. W and X are on the same team. Y is on Review. Z is not digitised.

Question. Which must be true?

Set up:

File   Team        Digitised
W      ?           ?
X      ?           ?
Y      Review      ✓ (Review -> digitised)
Z      ?           ✗ (given)

Now apply the conditions.

• Z is not digitised. Review files are always digitised, so Z cannot be on Review. Z is on Intake.
• W and X are on the same team. Undetermined which team, but they match.
• Y is on Review, therefore digitised.

Updated:

File   Team          Digitised
W      ? (= X)       ? 
X      ? (= W)       ?
Y      Review        ✓
Z      Intake        ✗

What must be true? That Z is on Intake, and that Y is digitised. What is undetermined? Whether W and X are on Intake or Review — the conditions do not settle it, only that they match.

An option saying "W is on Intake" is a could-be-true dressed as a must-be-true. It is perfectly consistent with everything stated, which is precisely what makes it a good distractor.

Chaining conditions to force a result

The Z step above is the characteristic move: a condition about one property (digitised) forces a conclusion about another (team) through a stated rule. Look for these bridges:

1. Find the rule linking two properties (Review → digitised).
2. Find the entity where one of those properties is fixed (Z is not digitised).
3. Apply the contrapositive (not digitised → not Review).

That is Section 8.2's contrapositive doing practical work.

Must be true, could be true, cannot be true

Read the question stem with care; these three demand different answers from the same grid.

A "could be true" question makes undetermined claims correct, which inverts the usual instinct. This is why the stem must be read before the options and again before submitting.

A second worked example

Scenario. A unit schedules three tasks — auditing, filing and training — on three consecutive days, one per day. Training is not scheduled on the first day. Auditing is scheduled the day immediately before filing.

Question. Which must be true?

The pairing condition means auditing and filing occupy consecutive days in that order. Two placements are possible: days 1–2 or days 2–3.

• Auditing day 1, filing day 2 → training day 3. Training is not on day 1. ✓ Consistent.
• Auditing day 2, filing day 3 → training day 1. But training cannot be on day 1. ✗ Eliminated.

Only one arrangement survives: auditing day 1, filing day 2, training day 3.

Here the conditions determine everything, so every claim is either ✓ or ✗ and nothing is undetermined. Working the small number of possible arrangements to exhaustion is the reliable method when the entity count is low.

The irrelevant-fact trap

As in Section 4.2, scenarios often contain details no condition refers to — a file's date of receipt, an employee's length of service. If no condition mentions it, it cannot force anything. After listing the conditions, cross off any scenario detail that appears in none of them.

Procedure

1. List the entities and the properties in play.
2. Draw the grid and enter directly stated facts.
3. Apply each condition, including contrapositives, and mark ✓, ✗ or ?.
4. Enumerate possibilities when a condition allows only a few arrangements.
5. Read the stem — must, could, or cannot — and select accordingly.
6. Verify that your chosen option matches the marks in your grid rather than your general sense of the situation.