The table you will not send

A partner agency has asked for case counts by area, category, age band and sex, so they can plan where to place a mobile team. They are entirely well-intentioned and the request is routine.

The table has 200 cells and 19 of them hold one case.

The files

protection-referrals-2024.v1.csv — 1,850 protection cases with the pathway fields and the minimum demographic set. Synthetic.

protection-case-management-2024.v1.csv — the case management register for the 1,108 cases that consented and had a referral made. Synthetic.

Neither contains a name, contact detail, free text, incident date, location below admin2, exact age, incident type or perpetrator detail.

Set up first

A project directory, both files read-only, an outputs/ directory, and a script that runs top to bottom from a clean kernel. Nothing in outputs/ should be a file you would be uncomfortable emailing — that is a requirement of this lab, not a suggestion.

Part one: build the requested table and measure its risk

Produce the four-way cross-tabulation the partner asked for. Then, before looking at it as data, characterise it as a disclosure risk:

• how many cells, how many below five, how many holding exactly one;
• which combinations of dimensions produce cells of one, and in which areas;
• what someone who works in that area would learn from a cell of one.

Write three sentences on the last point. Be specific about what is disclosed — “someone could be identified” is not an analysis.

Part two: apply a rule, including the secondary pass

Write a suppression function that takes a table and a threshold, suppresses cells below it, and then suppresses enough additional cells that a suppressed cell cannot be recovered by subtracting the published cells from a published row total.

Test it: after suppression, verify by code that no row has exactly one suppressed cell. A rule you have not tested is a rule you have not applied.

Apply it at thresholds of 5 and 10 and report how much of the table survives each.

Part three: three safe answers to the same question

The partner wants to know where to place a mobile team. Produce three products that answer that question and pass the disclosure test:

• an aggregated table — drop one dimension until no cell is below five, and say which dimension you dropped and what was lost;
• a rate rather than a count — pathway completion by area, on annual denominators, with the n for each;
• the direct answer — one paragraph naming the areas where a mobile team would do most good, with the evidence for it.

The third is the one the partner actually wanted.

Part four: the caseload cross-check

Join the case management register and compute mean and peak caseload per area, alongside case plan reviews per case and the share of closures for lost contact.

Two things to handle before the join: one caseworker identifier appears in two areas, and 472 cases are still open at the cut-off. Say what you did about each, and make sure your caseload does not double-count the transferred worker.

Then answer in three sentences: does the caseload table change your mobile-team recommendation, and if so how?

Part five: the reply

Write the reply to the partner. It must contain:

• the decline, in one sentence, with the specific reason;
• what you are providing instead, as three named products;
• one question back — what decision the request feeds;
• one route to the thing they asked for, if they genuinely need it.

Then write the requested-and-declined entry as it would appear in the report, which is not the same document as the reply.

Check your numbers

	Expected
Cells in the four-way table	200
Cells holding exactly one case	19
Cells holding four or fewer	85
Cells below five in area by category	0
Completion, disability reported	about 26.7%
Completion, not reported	about 46.2%
Highest mean caseload	about 33

If your disability completion figures differ, check how many values disability_reported has — one area used Yes and No, and a boolean filter silently drops them.

The questions to answer in prose

Three sentences each.

1. Your suppression rule removes cells but the equity finding survives it intact. Explain why that is not a coincidence, and what it says about which analyses are worth defending.

2. The partner could reconstruct some suppressed cells from your published row totals if you had not applied a secondary pass. Show a worked example from your own table, and say what it implies about publishing marginal totals.

3. You have declined a request from a well-intentioned colleague. Explain what you would say if the request were escalated to your director, in the two sentences you would have before being interrupted.

What to hand in

A Python script or notebook producing:

• the requested table with its risk characterisation
• the suppression function, its test, and the table at two thresholds
• the three safe products
• the caseload cross-check with the transferred-worker and censoring decisions stated
• the reply and the requested-and-declined entry, as markdown cells
• the three prose answers

How to know you are done

Delete outputs/, restart the kernel, run once, everything regenerates. Then open every file in outputs/ and ask whether you would attach it to an email to someone outside your organisation. If the answer is no for any of them, the lab is not finished — a suppressed table that is safe to send should be the only tabular output that exists.

What this lab is not

It is not a legal or policy exercise. Which data-sharing agreement applies, who signs it, and what the national data protection law requires are questions for your organisation’s protection lead. This lab is the analyst’s part: recognising the risk in a table you can produce, quantifying it, reducing it, and writing the sentence that declines the request without ending the conversation.