The data gap (Article 10)

⚡ TL;DR

Most risks you meet in this course have a treatment you can write: drop a leaked feature, swap in a fairness-constrained learner, retrain. The git diff is the treatment, and the control flips to GREEN. The data gap is the exception, and it is the hardest idea here. Its treatment is not code at all — it is acquire more representative data — so its control is a sufficiency gate that no commit can close. With n=215 examples and a target of n≥500, the sufficiency ratio is 0.43 at every commit, forever, until the data exists. And because the risk is treated (you have a plan) and gated (a blocking control) but has no bounded residual (you cannot measure a residual you have no data to estimate), the engine fires treated-without-residual — a hard integrity block that hides the Approve button entirely. This is one step more open than the “red door”: with a measured-but-too-high residual you may walk through with a recorded motive; here the engine does not even offer the door, because you cannot consciously accept a residual you cannot yet measure. The signature on the bundle still verifies — what is RED is the verdict, not the integrity. The only honest way out is to get the data.

🎯 By the end you'll be able to…

• Locate the data gap at the union of Art. 10(3) (data must be relevant, sufficiently representative and complete) and Art. 10(5) (processing protected attributes, exceptionally, to detect and correct bias).
• Explain why a sufficiency control is not closable by any code change, while a leakage or fairness control is — and why that makes the treatment a data_gap, not a model change.
• State precisely what treated-without-residual means (treated + gated + no bounded residual) and why the engine classes it as a hard block that hides «Approve».
• Contrast the data gap with the “red door” (override with a mandatory recorded motive) and say why the data gap is one step further open.
• Recognise the only honest remedy — acquire representative data, re-measure, then move — and why forcing the gate would be fraud while the signature stays valid.

Article 10: representativeness meets bias detection

EU AI Act Article 10 is about data and data governance for high-risk systems. Two of its paragraphs matter to us, and the lesson lives where they meet.

• Art. 10(3) says the training, validation and testing datasets must be relevant, sufficiently representative, and — to the best extent possible — free of errors and complete, in view of the intended purpose. This is where sample sufficiency and representativeness live. “Sufficiently representative” is not a slogan: it means you actually have enough data, including enough of the populations you intend to serve, to support the claims you are making about the system.

• Art. 10(5) says providers may exceptionally process special categories of personal data — protected attributes such as ethnicity or sex — when strictly necessary to ensure bias detection and correction (read together with 10(2)(f) and (g)), and only under safeguards. In other words, the law anticipates that to check a hiring or screening model for disparate impact you may need to hold, carefully, the very attribute you must not discriminate on.

Now put them together, because the data gap lives at the union of the two. You cannot perform the bias detection and correction that 10(5)/10(2) require if you do not have a 10(3)-adequate sample — that is, enough data, including enough labelled examples of the protected group, to measure disparity with statistical reliability. A fairness measurement on 18 examples of a minority class is not a measurement; it is noise with a decimal point.

A nuance worth getting right

A demo or a slide may say “the data gap is an Art. 10(5) issue” — because the visible symptom is we cannot run the bias check. That is a fair shorthand, but be precise: the bias check needs protected-attribute data (10(5)), and the underlying problem is that the sample is not sufficient (10(3)). Teach the union: 10(5) tells you what you must measure; 10(3) tells you that you cannot yet, because the sample is too small to be representative.

A control code cannot close

Most of the controls you meet are closable by a code change, and that is the whole shape of Risk-Driven Development: the treatment is a versioned change (ISO 23894 §6.5), and the git diff is the treatment.

• A leakage control: a feature is leaking the target, so you drop the feature. One commit. The control flips GREEN.
• A fairness control: a learner produces disparate impact, so you swap in a fairness-constrained learner or reweight. One commit. The control flips GREEN.

A sufficiency control is different in kind. Consider a control whose pass criterion is a sample-adequacy ratio:

sample_adequacy_ratio = n / 500 ≥ 1.0

No line of code you can write changes n. You can refactor the model, tune hyper-parameters, swap the learner, rewrite the pipeline — and the ratio does not move, because the binding quantity is how much representative data exists, not how the model is built. The treatment for this risk is therefore not a model change at all. It is a data gap (data_gap): the honest statement “the remedy is to acquire more representative data.”

Why no commit can close a sufficiency gate

With n=215 examples and a target of n≥500, the ratio is 215 / 500 = 0.43. That number is the same at every commit — at HEAD, at HEAD~1, at the commit you will write tomorrow — because none of those commits add data. The gate stays RED until n actually rises past 500. The only thing that moves the ratio is data acquisition. (And the dishonest “fixes” — lowering the threshold below what representativeness needs, or faking n — are not fixes; they are fraud. The engine leaves the gate honestly RED rather than launder a number.)

The deepest openness: treated without a residual

Here is the mechanism that makes the data gap the hardest state in the course. It is verified in the engine’s coherence layer (cloud/lib/approval/coherence.ts), not asserted.

A risk that is treated (it has a treatment plan), and that relies on a blocking control (enforcement: gate), but has no bounded residual (no residual_likelihood declared), fires the violation treated-without-residual. And treated-without-residual is classified as a hard block (hardBlockingForApprove): the portal removes the «Approve» action entirely. Not greyed out, not behind a confirmation — gone. You literally cannot approve, with or without a motive.

Why is that the right behaviour, and not the engine being unhelpful? Because the reasoning is profound and worth saying plainly:

You cannot consciously accept a residual you cannot even measure.

A residual is the risk that remains after treatment. To accept it knowingly, you must first be able to state it — “after treatment, the likelihood of harm is X, and that is what I am signing for.” On a data gap, the data needed to estimate X is not there. There is no residual to certify, so there is nothing to accept yet. The engine refuses to let you sign for a number that does not exist. That refusal is the engine being honest about the limits of its own evidence.

Why the engine hides the Approve button here

This is not a UI accident; it is the integrity layer working. treated-without-residual is a hard block precisely because approval is conscious acceptance of a stated residual, and on a data gap there is no stated residual to accept. The system stays in tested/treated/gap and the cycle pauses at request. The fix is not in the portal and not in the code — it is upstream, in the data. Once you acquire a 10(3)-adequate sample and re-measure, a residual finally exists; only then can the lifecycle move at all.

The red door, and why this is one step further

Elsewhere in the course you meet the “red door”: the case where the owner may approve a risk that is above appetite, but only with a mandatory, recorded motive. That mechanism is real, and it is different from the data gap. Both are verified in coherence.ts:

• residual-exceeds-appetite — the risk has a measured residual, and that residual is higher than the appetite. The owner may approve, but the act demands a mandatory motive that is recorded server-side. (On the CLI, froga approve has no --reason flag, so this conscious-acceptance act is portal-only.)
• untreated-above-appetite — the risk is untreated and sits above appetite. Same shape: approval is possible with a recorded motive.

That is the red door: conscious risk acceptance over appetite, recorded — eyes open, on the record. (And note: walking through it is a governance decision by the owner, not a basis of conformity. The verdict still shows the risk was accepted over appetite.)

The data gap is one step MORE open than the red door

The red door lets you walk through a residual that is measured but too high — you can see exactly what you are accepting, so the engine offers the door behind a mandatory motive. The data gap gives you no measurement to walk through at all. There is no residual on the table, so the engine does not even offer the door: treated-without-residual is a hard block and the «Approve» button is hidden. Same family of openness, but the data gap is further open — you cannot override your way out of it, because there is nothing yet to override. The way out is upstream, in the data.

The only honest remedy

So what do you do with a data gap? You acquire more representative data — enough, including enough of the protected group, to make the bias check (10(5)) statistically meaningful and the sample sufficient (10(3)). Then you re-measure. A residual finally exists. Only then can the cycle move past request.

Everything else is a lie dressed as a fix:

• Lowering the threshold so 0.43 “passes” does not make the sample representative; it just hides the inadequacy. Fraud.
• Faking n so the ratio reads ≥ 1.0 fabricates the very evidence the gate exists to check. Fraud.

The engine will not do either. It leaves the gate honestly RED and the lifecycle paused.

What is RED — and what is not

The signed bundle is still cryptographically valid: the signature verifies, the evidence is exactly what the signer recorded. What is RED is the conformity verdict, not the integrity of the evidence. That distinction is the whole product philosophy in one line: the engine never claims more than the evidence supports, so it reports a true RED rather than a comfortable green. The path forward is data acquisition → re-measurement → then (and only then) the cycle moves.

Self-check

❓ Why can't a sufficiency control be closed by a code change, when a leakage or fairness control can?

A leakage or fairness control is bound to how the model is built, so a versioned code change closes it: drop the leaked feature, or swap in a fairness-constrained learner, and the control flips GREEN — the git diff is the treatment (ISO 23894 §6.5). A sufficiency control is bound to how much representative data exists — e.g. sample_adequacy_ratio = n / 500 ≥ 1.0. No commit changes n: with n=215 the ratio is 0.43 at HEAD, at HEAD~1, and at every future commit, because none of them add data. The only thing that moves it is acquiring more data — a data_gap, not a model change.

❓ What does `treated-without-residual` mean, and why is it harder than the 'red door'?

treated-without-residual fires when a risk is treated (has a plan) and relies on a blocking control (enforcement: gate) but has no bounded residual (no residual_likelihood). The engine classes it as a hard block (hardBlockingForApprove) and hides the «Approve» button entirely — you cannot approve with or without a motive. It is harder than the red door because the red door (residual-exceeds-appetite / untreated-above-appetite) lets you approve a measured-but-too-high residual with a recorded motive — eyes open, on the record. The data gap gives you no measurement to walk through, so the engine does not even offer the door: you cannot consciously accept a residual you cannot yet measure. It is one step more open.

❓ A demo says the data gap is an 'Art. 10(5)' problem. What is the more precise framing?

The honest framing is the union of 10(3) and 10(5). Art. 10(5) lets you exceptionally process protected attributes when strictly necessary for bias detection and correction — that is what you must measure. Art. 10(3) requires the dataset to be relevant, sufficiently representative and complete — and that is why you cannot yet, because the sample is too small to measure disparity reliably (including too few examples of the protected group). The demo’s “10(5)” is a fair shorthand for the visible symptom (the bias check cannot run), but the binding requirement under it is the sufficiency/representativeness of 10(3). Teach the union.

Where to go next

Level 5 · Talent screeningThe data gap made concrete: a talent-screening model whose only honest treatment is to acquire more representative data, whose sufficiency gate stays RED at every commit, and whose lifecycle the engine refuses to let you approve — the hard block in action.

What is a risk?The foundation under everything here: likelihood, impact, appetite and residual — and why a residual you cannot measure is a residual you cannot accept.

More than the AI ActHow a sectoral regime stacks on the AI Act spine, and where data-governance obligations like Article 10 sit relative to the per-system slice the engine projects onto the signed bundle.

EU AI Act — the spineThe reference page for how the engine projects the AI Act onto the bundle, including Article 10 on data and data governance, and the difference between a RED verdict and a still-valid signature.

ISO 23894 — risk managementThe risk-management discipline behind treatment as a versioned change (§6.5), residual risk, and conscious acceptance against appetite — the vocabulary that makes the data gap's hard block legible.