TDS 2026 May · Project 2 · study guide

How to work each case, without being told the answer.

Eight scenarios, eight different analytical shapes. This guide names the shape of each one and the questions worth asking the data. It contains no conclusions, no numbers, and nobody's submitted note — finding out what is true is the part you are graded on.

The method that scores

Every question is marked the same way: evidence first, conclusion second. A precise “insufficient evidence” earns as much as the intended answer. You are not hunting a hidden result; you are showing that your judgment is traceable.

Run it, don't estimate it

  • Every number in your note comes from a script you actually ran. Keep the script and its raw output.
  • Cite so a stranger can re-run it: file name, column, row count or row id, exact quoted text. recharges.csv, posting_date, n=1204 of 8915 beats “most rows”.
  • Load everything before you theorise: row counts, date ranges, distinct values per key column, null counts. Half the findings in these cases live in the shape of the file, not in its contents.

Interrogate the document, not just the data

  • An email, an SOP, a note, a chat log is a claim. For each one, say whether the data confirms it, contradicts it, or cannot test it. All three are legitimate outcomes.
  • Ask what the file is before asking what it says: who exported it, over what window, filtered how. An extract that has already been filtered can only answer questions about the filter.
  • Watch for the thing that is missing. A column the process requires but the export does not contain is a finding, not an inconvenience.

Separate four things, always

TypeSounds like
Observed fact“1,204 of 8,915 rows carry that posting date.”
Inference“That is consistent with a batch upload rather than customer activity.”
Causal claim“The batch caused the cluster.” — needs far more support.
Unknown“Nothing here can tell us who triggered the upload.”
The most common way to lose marks

Writing a confident verdict with a thin evidence table under it. The table is the highest-scoring section. Fill it first, then write the judgment your table can actually carry.

Writing the note

Every question wants the same backbone. Check your own question's output contract for extras — one asks for interview questions, one caps the number of items you may raise.

## Judgment
<the call, in one or two lines, with your confidence>

## Evidence
| Claim | Source | Confidence |
|---|---|---|
| <observed fact> | <file, column, n=> | High / Medium / Low |

## Rejected hypotheses
- <hypothesis> — killed by <the specific evidence that rules it out>

## Unknowns
- <what you cannot establish> — <what evidence would change the call>

## Next action
<one reversible step: a query, a targeted sample, a reconciliation, a hold>

Calibration that means something

  • High — computed directly from the data, reproducible by anyone with the file.
  • Medium — the data supports it, but an alternative explanation survives.
  • Low — consistent with the data, not established by it. Say what would settle it.
  • A rejection needs a killer: name the evidence that makes the hypothesis impossible, not unlikely.
  • Reversible next action means it cannot destroy or restate data — a query, a sample, a hold. Not “rebuild the pipeline”, not “notify the regulator”.
CASE 1A

DTH Month-End Mystery

Shape: a cluster at a calendar boundary · Files: transactions, an import log, an email · Budget: 200–6,000 characters

A reviewer flagged a pile-up of records on one date. Your job is to decide what kind of thing it is — duplicated revenue, manipulated reporting, a pipeline defect, or nothing material.

Questions worth asking the data

  • How many records sit on the flagged date, out of how many, and how does that compare with every other date in the file? A cluster is only a cluster relative to a baseline you computed.
  • The file carries more than one date concept. What does each one mean, and do they disagree only for the flagged rows or throughout?
  • Is any record duplicated on a key that should be unique? That single check separates “duplicate revenue” from every other explanation, and it is cheap.
  • The import log exists to reconcile batches. Do its control totals agree with what the transaction file actually contains?
  • The email offers an explanation. Test it: if it were true, what would the data have to look like? Does it?
Trap

Treating the operations email as evidence. It is a hypothesis with a sender.

CASE 1B

DTH Complaints Went Quiet

Shape: a metric moved after an intervention · Extras: pick one person, write exactly five questions · Budget: 200–6,000 characters

Cases fell in one region after a pilot launched. The question is not whether they fell — it is whether that fall is evidence of what someone says it is, and whether to expand.

Questions worth asking the data

  • Decompose the drop. By channel, by region, by category, before versus after. If the pilot caused it, the decline should concentrate where the pilot operates. Does it?
  • Did anything else move in the same window — the underlying volume of problems, not just the complaints about them? A drop in reports with no drop in causes points somewhere specific.
  • Follow the funnel. Which interactions never reach the system that produces the metric, and is that number stable across the period? Counting rules changing can look exactly like behaviour changing.
  • What does the untouched part of the business do over the same period? That is your closest thing to a control.

The five interview questions

  • They are graded. Each should be answerable with a record, a config, a date, or a number — not an opinion.
  • Pick the person who owns the mechanism you are unsure about, and ask them about that mechanism.
  • A good question closes a specific unknown from your own note. If you cannot say which unknown it closes, replace it.
Trap

Correlation stated as cause. “Cases fell after the pilot” is a fact; “the pilot improved experience” is a claim needing a mechanism and a control.

CASE 2A

Solar Inverter Smell Test

Shape: is this small export worth more time? · Hard rule: at most two findings, five substantive items total · Budget: 150–3,000 characters

Ten minutes, one small file, one decision: escalate, run one cheap check, or stop. “Nothing here warrants escalation” is a full-marks answer if you earn it.

Questions worth asking the data

  • What is the file's coverage? Rows, distinct entities, time span, and how those compare with the fleet or period the reader will assume it represents.
  • Which columns never vary? A field that holds one value in every row usually says something about the export, not about the equipment.
  • Do the categorical values look like a complete set or like a selection? Selection changes what the file can possibly tell you.
  • If one more source would change your decision, name the smallest one and do not assume you have it.
Trap

Reading failure, intent, or money into event wording. Also: exceeding the item cap — the count is part of the question, and a sixth item can cost you.

CASE 2B

The 31.6% Impact Claim

Shape: verify a headline number · Files: a written impact note, an operational table, a commercial PDF · Budget: 200–6,000 characters

Someone has published a percentage. State the strongest thing the evidence can defend, and be explicit about what it cannot establish.

Questions worth asking the data

  • Reproduce the number first. Which rows, which column, which arithmetic reaches it — and does any reasonable route reach it exactly? If not, that gap is your finding.
  • Check the arithmetic's direction: are deviations being netted against each other or summed in absolute terms? The two answers differ, and only one matches the words.
  • What is the sample behind each side of the comparison? Count the units, not the rows.
  • What else differs between the two periods or groups being compared? Anything you cannot rule out belongs in Unknowns, not in the verdict.
  • Pull the numbers out of the PDF rather than reading them off — and reconcile them against the table.
Trap

Concluding “the claim is false”. Usually the defensible statement is about what the design of the comparison can and cannot support.

CASE 3A

Mismatch Control

Shape: a control fired — is the control right? · Budget: 150–3,000 characters

Two records disagree and a check flagged it. Before you escalate anything, establish whether the disagreement is about the world or about the way the world was encoded.

Questions worth asking the data

  • Compare the two values at every level of granularity, not just as strings. Codes are often hierarchical; agreement at one level and disagreement at another means something specific.
  • Are the two sides using the same code system, the same version, the same vintage? Ask whether the schema even records which system a code came from.
  • Reconstruct what the control actually compares. A control that compares two things which were never meant to be identical will fire forever.
  • Distinguish a data-quality problem, a process problem, and a modelling gap. The fix is different for each.
Trap

Escalating an encoding artefact as a declaration error. Ask what a correction would even mean before recommending one.

CASE 4A

QC Queue Smell Test

Shape: can this dashboard be built at all? · Budget: 200–6,000 characters

You are asked to measure something. The first question is not how to measure it — it is whether the supplied extract contains what the definition requires.

Questions worth asking the data

  • Write the metric definition out from the SOP, then map each term in it to a specific column. Any term with no column is a blocker, and naming it is worth more than a chart.
  • Where a definition needs a duration, check that both endpoints exist. One timestamp is not an interval.
  • Do the operational words in the SOP and the values in the data mean the same thing? Status vocabularies drift.
  • Check the queue's shape before interpreting it: coverage window, entities, gaps, records that never close.
Trap

Silently substituting an available field for the one the definition requires, and reporting the result as the KPI. If you must proxy, say so and quantify the difference.

CASE 3B

Is the Preference Claim Supported?

Shape: a claim rests on something not being found · Budget: 200–6,000 characters

Someone searched a register, found nothing, and drew a conclusion. Absence of evidence is the weakest form of evidence there is — test the search before you accept the finding.

Questions worth asking the data

  • Reproduce the search yourself. What key was used, and is it the right key for the entity in question?
  • Separate three states: never existed, exists but was not matched, existed and has lapsed. Records carry validity dates; check them against the date that matters, not today's.
  • Confirm you are looking at the right party. Documents in a chain name several, and it is easy to test one and conclude about another.
  • State the claim's status precisely. “Unsupported” and “disproved” are different findings, and only one of them may be available to you.
Trap

Recommending an irreversible remedy — an amendment, a disclosure, a notification — on a claim you have only shown to be unproven. Prefer a hold.

CASE 4B

Spare-Parts Search

Shape: is the proposed solution the right solution? · Budget: 200–6,000 characters

A brief arrives with the answer already chosen and a headline figure attached. Test the framing before you optimise inside it.

Questions worth asking the data

  • Rebuild the headline figure from the records. Then break it into what is genuinely actionable, what needs a judgment call, and what is not addressable at all under the stated policy.
  • Try the dumbest possible matching first — an exact join on the obvious identifier. Whatever that resolves is not evidence for a more sophisticated approach.
  • Look at the identifier columns themselves: blanks, inconsistent formats, duplicates. Matching problems are often data-entry problems wearing a search costume.
  • If a file the brief refers to is missing from your download, say so in the note and scope your conclusion accordingly. A disclosed gap costs far less than a silent one.
Trap

Answering “how do we build the search?” when the evidence supports “this is not a search problem”. A well-supported reframing scores.