TL;DR — "They said yes" is not a permission; a permission is a scope, and the scope has at least four independent edges — purpose, artifact type, retention window, and which subjects are covered. Cross any one and you are outside it. In the check below, six planned uses were tested against one written agreement and four were out of scope, each for a different reason and each needing a different remedy. Two structural facts do most of the damage in practice: the person who holds data is often not the person who can consent to its use, and if any subject is a minor the timeline typically changes from weeks to months because a guardian has to agree. The cheapest arrangement is almost always to have the holder de-identify before transfer, since much of the obligation attaches to identifiable data. This stops being sufficient the moment the work is publishable research or crosses a jurisdiction with its own statutory basis, where an ethics board — not the engineering team — decides what is permitted.
1. Simple explanation
Before a dataset about people can be used, someone has to have agreed to that use. The engineering instinct is to treat this as a yes/no gate cleared once, early, by email. It is not a gate; it is a boundary with several edges, and work drifts across those edges without anyone deciding to.
The most common drift is purpose. Permission was given to check whether an automated system scores as well as a human. Six weeks later the same files are training a model, which is a different activity with different consequences for the people in the data, and nobody re-asked because it felt like the same project.
The second is who said yes. An institution holding records can grant access to them, but that is not the same as the individuals consenting to a new use of work they produced. Which of the two you need depends on the jurisdiction, the original basis for collection, and what you intend to do — and the person answering your email may not have thought about the distinction at all.
The third has hard timing consequences: if any subject is a minor, consent generally has to come from a parent or guardian. This is the single change most likely to turn a two-week task into a two-month one, and it is discovered late precisely because ages are not obvious until the data arrives.
Analogy — borrowing a neighbour's car. They say yes, and you drive to the shops. Driving it to another city that weekend is not covered by that yes, even though the car and the neighbour and the "yes" are all the same. Lending it to your cousin is further outside. Keeping it a month is outside on a different axis again. Nobody said "no" to any of these, because nobody was asked — and the reason the original yes felt sufficient is that it was sufficient, for the thing that was actually asked about.
2. Diagram
A PERMISSION IS A SCOPE, NOT A YES
purpose artifact type
+-------------------+ +----------------------+
| evaluate accuracy | | assessment scan |
| | | marks csv |
| train a model X | | instructor audio X |
+-------------------+ +----------------------+
\ /
\ /
+-------------------+
| THE GRANTED | cross ANY edge
| SCOPE | => outside the permission
+-------------------+
/ \
+-------------------+ +----------------------+
| until 2026-09-01 | | adults only |
| after that X | | under-18 X -> needs |
+-------------------+ | guardian consent |
retention +----------------------+
subjects
measured (§5): 6 planned uses checked -> 4 outside, one per edge
WHO CAN SAY YES — two different questions
the HOLDER the SUBJECT
+--------------------+ +---------------------+
| controls access | | produced the work |
| can hand you files | | is the person in it |
+--------------------+ +---------------------+
| |
+----- access granted -----+ +--- consent to a NEW use
|
these are not the same permission,
and one email usually answers only one
THE CHEAPEST PATH
holder redacts -> you never hold identifiable data -> fewer obligations
^
| ask for this explicitly; it is rarely offered
3. How it works
3.1 The four edges of a scope
A written permission is only useful if it is specific enough to be checked against. Four fields carry most of the weight:
Purpose — what the data may be used for. Evaluation, training, publication and demonstration are four different purposes, and a permission for one is not a permission for the others.
Artifact type — what may be collected. Scanned documents, a marks file, recordings of the assessor, and metadata about when work was submitted are separate categories, and people generally agree to the ones they were asked about.
Retention — how long. An open-ended hold is unusual to grant and awkward to justify; a date makes the obligation concrete and the deletion schedulable.
Subjects — whose data. Whether minors are included is the highest-consequence element, and it also determines whether the holder's yes is sufficient at all.
Each edge fails independently and needs a different remedy, which is the point of checking them separately rather than asking "are we allowed to do this?" as one question.
3.2 Access is not consent
An institution can usually decide who may see records it holds. Whether it can authorise a new use of work that individuals produced is a separate question, answered by the basis on which the data was originally collected and by local law.
The practical failure is that a single email conflates them. "Yes, you can have the files" answers the access question and is silent on the consent question, and it is easy to read the silence as agreement. If the new use is materially different from why the data was created, the individuals' position is at least worth asking about explicitly — and getting a clear "the holder's authorisation is sufficient here, for this reason" in writing is itself a useful artifact.
3.3 Minors change the timeline, not just the paperwork
Where subjects are under the age of majority, consent normally has to come from a parent or guardian, sometimes alongside the young person's own assent. Contacting many guardians, tracking responses, and handling non-responses is slow, and it is work the holder has to do because you do not have the contact details.
The scheduling implication is what matters for planning: this is not a form to add to a checklist, it is a change of order of magnitude in elapsed time. The two common ways out are to exclude minors from the cohort, or to work only with data the holder has already de-identified — and whether the second is sufficient is exactly the kind of question to put in writing rather than assume.
3.4 De-identify at source, and why it changes the question
Much of the obligation around personal data attaches to data that identifies people. If the holder removes the identifiers before anything is transferred, the receiving party never possesses identifiable data, and the question you are asking becomes materially simpler.
Two cautions. This is only true if the de-identification is real — renaming files while names remain inside scanned pages is not de-identification, as De-identification: Why Removing the Name Is Not Enough works through in detail. And it is not automatically a full exemption from anything; it removes one large category of concern rather than ending the conversation.
Ask for it explicitly and specify what "de-identified" means for your artifacts, because a holder acting in good faith will otherwise do the intuitive thing, which is to rename the files.
3.5 Write it down in a form that can be checked
A permission recorded as prose in an email thread cannot be checked mechanically and, in practice, is not checked at all. Recorded as fields — purposes, artifact types, retention date, subject population, whether redaction happens at source, whether onward sharing is allowed — it can be compared against what the project actually plans to do, which is what §5 does.
The value is not the automation, which is trivial. It is that writing the plan down separately from the permission makes the mismatches visible, and the mismatches are the entire risk.
3.6 Where this stops being an engineering decision
Everything above is operational hygiene. If the work is intended for publication as research involving human subjects, an institutional ethics board typically has to review it before collection begins, and their determination — including whether the work is exempt — is theirs to make rather than yours to conclude. Retrospective approval is generally not available, which makes this a scheduling dependency rather than a formality.
4. The math
4.1 Scope as an intersection
Model the granted scope as the intersection of the permitted sets on each edge. A planned use u = (purpose, artifact, date, age) is inside the permission only if it satisfies every constraint:
allowed(u) = purpose(u) in P_purposes
AND artifact(u) in P_artifacts
AND date(u) <= P_retain_until
AND ( P_subjects != adults_only OR age(u) >= 18 )
Because it is a conjunction, the failure count is not additive — one use can breach several edges at once, and a use is out of scope if any single clause fails.
4.2 Worked example
With four edges, the space of distinct single-edge failures is exactly 4. Testing the six planned uses from §5 against the granted scope:
use 1 evaluate / scan / 2026-05-01 / 19 -> all four clauses pass ALLOWED
use 2 evaluate / csv / 2026-05-01 / 19 -> all four clauses pass ALLOWED
use 3 TRAIN / scan / 2026-05-01 / 19 -> purpose clause fails BLOCKED
use 4 evaluate / AUDIO / 2026-05-01 / 19 -> artifact clause fails BLOCKED
use 5 evaluate / scan / 2026-11-01 / 19 -> 2026-11-01 > 2026-09-01 BLOCKED
use 6 evaluate / scan / 2026-05-01 / 17 -> 17 < 18 BLOCKED
blocked = 4 of 6 (66.7%)
Each of the four blocked uses fails exactly one clause, and each needs a different remedy — re-ask, drop the artifact, delete on schedule, or obtain guardian consent. A single "are we allowed?" question would have returned one answer for four unrelated problems.
5. Real code
from datetime import date
# What the holder actually agreed to, in writing. Every field is a boundary.
PERMISSION = {
"granted_by": "Northgate Training Centre",
"granted_on": date(2026, 3, 1),
"purposes": {"evaluate_scoring_accuracy"},
"artifact_types": {"assessment_scan", "marks_csv"},
"subjects": "adults_only", # 18+ at time of assessment
"redacted_at_source": True,
"retain_until": date(2026, 9, 1),
"redistribution": False,
}
# What the project actually plans to do. Written independently, which is the point.
PLANNED = [
("evaluate_scoring_accuracy", "assessment_scan", date(2026, 5, 1), 19),
("evaluate_scoring_accuracy", "marks_csv", date(2026, 5, 1), 19),
("train_scoring_model", "assessment_scan", date(2026, 5, 1), 19), # purpose drift
("evaluate_scoring_accuracy", "instructor_audio", date(2026, 5, 1), 19), # artifact drift
("evaluate_scoring_accuracy", "assessment_scan", date(2026, 11, 1), 19), # retention drift
("evaluate_scoring_accuracy", "assessment_scan", date(2026, 5, 1), 17), # subject drift
]
def check(use, perm):
purpose, artifact, when, age = use
reasons = []
if purpose not in perm["purposes"]:
reasons.append(f"purpose '{purpose}' not granted")
if artifact not in perm["artifact_types"]:
reasons.append(f"artifact '{artifact}' not granted")
if when > perm["retain_until"]:
reasons.append(f"use on {when} is past retain_until {perm['retain_until']}")
if perm["subjects"] == "adults_only" and age < 18:
reasons.append(f"subject aged {age} outside 'adults_only'; guardian consent needed")
return reasons
print(f"{'purpose':<28}{'artifact':<19}{'date':<12}{'age':>4} verdict")
print("-" * 84)
blocked = 0
for use in PLANNED:
reasons = check(use, PERMISSION)
verdict = "ALLOWED" if not reasons else "BLOCKED: " + "; ".join(reasons)
if reasons:
blocked += 1
print(f"{use[0]:<28}{use[1]:<19}{str(use[2]):<12}{use[3]:>4} {verdict}")
print(f"\n{blocked} of {len(PLANNED)} planned uses fall outside the written permission.")
# The four drifts are independent: each needs a different remedy.
remedies = {
"purpose": "re-ask; a new purpose is a new permission, not an extension",
"artifact": "re-ask, or drop the artifact type",
"retention": "delete on schedule, or agree an extension before the date",
"subject": "guardian consent, or exclude under-18 subjects from the cohort",
}
print("\nremedy per drift type:")
for kind, fix in remedies.items():
print(f" {kind:<10} -> {fix}")
assert blocked == 4, "four of the six planned uses should be out of scope"
assert not check(PLANNED[0], PERMISSION), "the in-scope use must pass cleanly"
print("\nasserts passed")
# Output:
# purpose artifact date age verdict
# ------------------------------------------------------------------------------------
# evaluate_scoring_accuracy assessment_scan 2026-05-01 19 ALLOWED
# evaluate_scoring_accuracy marks_csv 2026-05-01 19 ALLOWED
# train_scoring_model assessment_scan 2026-05-01 19 BLOCKED: purpose 'train_scoring_model' not granted
# evaluate_scoring_accuracy instructor_audio 2026-05-01 19 BLOCKED: artifact 'instructor_audio' not granted
# evaluate_scoring_accuracy assessment_scan 2026-11-01 19 BLOCKED: use on 2026-11-01 is past retain_until 2026-09-01
# evaluate_scoring_accuracy assessment_scan 2026-05-01 17 BLOCKED: subject aged 17 outside 'adults_only'; guardian consent needed
#
# 4 of 6 planned uses fall outside the written permission.
#
# remedy per drift type:
# purpose -> re-ask; a new purpose is a new permission, not an extension
# artifact -> re-ask, or drop the artifact type
# retention -> delete on schedule, or agree an extension before the date
# subject -> guardian consent, or exclude under-18 subjects from the cohort
#
# asserts passed
The check is twenty lines and finds nothing clever. Its value is that the permission and the plan were written down separately, so the comparison is possible at all — the usual situation is that the plan lives in someone's head and the permission lives in an email, and the two are never placed side by side.
6. Real-world example
A team arranged to test an automated assessment-scoring pipeline against real marked work from a vocational training centre. The centre agreed by email: "Happy for you to use our marked assessments to check your system." Collection began the same week.
Three things went wrong, in increasing order of cost. The first: the team also wanted recordings of assessors explaining marginal decisions, which nobody had mentioned in the original request. That one was cheap — they asked, and the centre said no, and the work continued without it.
The second: partway through, the results looked good enough that someone proposed fine-tuning on the same files. The original request had said "check your system." Training is a different purpose with a different footprint — the work ends up inside model weights rather than in a report — and re-asking took three weeks, during which that workstream was blocked.
The third was the expensive one. Roughly a fifth of the cohort turned out to be seventeen. Nobody had asked about ages because the request was framed around documents rather than people, and the centre had not raised it because they had not been asked. Guardian consent for that subset was a two-month process; the team eventually excluded those candidates and re-ran with a smaller sample, which cost them statistical power they had already promised in a plan.
The instructive detail is that the centre behaved reasonably throughout and said yes to everything they were actually asked. Every problem came from a question nobody thought to ask at the start, and all three would have surfaced in the first conversation had the request been written as a scope — purpose, artifacts, retention, subjects — instead of a sentence.
7. Interview questions companies actually ask
Q1. You have written permission to use a dataset for evaluation and now want to train on it. Do you need to re-ask? Yes. Purpose is one of the edges of the scope, and training is materially different from evaluation — the data ends up embedded in model weights rather than summarised in a report, which changes both the retention question and what "deleting it afterwards" can even mean. Permission for one purpose is not an extension covering the others, and the fact that it is the same data and the same people does not merge them.
Q2. The institution holding the data has approved your access. Is that sufficient? Not necessarily, and the distinction is the one most often collapsed. A holder can usually authorise who may see records it controls; whether it can authorise a new use of work individuals produced depends on the original basis for collection and on local law. One email typically answers the access question and is silent on the consent question, and silence should not be read as agreement — ask explicitly and get the reasoning in writing.
Q3. What changes if some subjects are minors? Consent generally has to come from a parent or guardian, sometimes with the young person's assent as well, and the holder has to do the contacting because you do not have the details. The practical impact is on the schedule rather than the paperwork: it commonly turns a two-week collection into a two-month one. The usual mitigations are excluding minors from the cohort or working only with data the holder has de-identified first.
Q4. Why ask the holder to de-identify before sending rather than doing it yourself? Because much of the obligation attaches to identifiable data, and if the identifiers never leave the holder you never hold it. Doing it on receipt means you held identifiable data first, which is the thing you were trying to avoid. It only works if the de-identification is real — renaming scanned files whose pages still carry names is the standard failure — so specify what you mean rather than using the word alone.
Q5. What should a permission record actually contain? Enough structure to be checked against a plan: the purposes granted, the artifact types, a retention date, which subject population is covered, whether de-identification happens at source, and whether onward sharing is allowed. Prose in an email cannot be compared with anything. The point of the structure is not automation; it is that writing the plan and the permission separately makes the mismatches visible.
Q6. When does this stop being the engineering team's call? When the work is human-subjects research intended for publication, where an institutional ethics board reviews it before collection starts and decides whether it qualifies for exemption — that determination is theirs, not yours. Approval is generally not available retrospectively, so it belongs on the schedule as a dependency ahead of collection rather than as a document produced later.
8. When to use / tradeoffs
Write permission down as a scope when:
- Data about people is coming from an organisation that is not yours.
- The subjects may include minors, or you do not yet know their ages.
- More than one use is plausible — evaluation now, training or publication later.
- The work may be published, where an ethics review is a scheduling dependency rather than a formality.
| Situation | Why it breaks | Use instead |
|---|---|---|
| Permission is a sentence in an email thread | Nothing to check a plan against; drift is invisible until someone objects | Record the four edges explicitly, even if the reply itself stays informal |
| Ages unknown at request time | The minors question surfaces after collection, when the timeline is already committed | Ask about the subject population in the first message, before anything is sent |
| Data already collected under a different purpose | Retrospective permission is weaker and sometimes unavailable | Re-ask before use; if refused, the data is not usable for the new purpose |
| Multiple institutions supplying data | Each grants its own scope; the intersection is what you can actually do | Track permissions per source and take the intersection, not the union |
Honest limits. This article describes operational practice, not law, and it is not legal advice — the obligations that actually bind you depend on your jurisdiction, your sector, the original basis for collection, and often on an institutional policy that is stricter than any statute. The four edges in §5 are a useful minimum rather than a complete model: real agreements also cover security controls, sub-processors, breach notification, audit rights and what happens at termination, none of which the checker knows about. The check itself is trivially gameable, because it validates a declared plan rather than observing what the system does — a use that nobody wrote down passes silently, which is the most common way scope drift actually happens. And "de-identify at source" reduces obligations rather than eliminating them; treating it as a blanket exemption is precisely the over-reading that gets teams into difficulty.
9. Summary + related articles
- A permission is a scope, not a yes. Its edges are purpose, artifact type, retention and subjects, and crossing any one puts you outside it.
- In the worked check, 4 of 6 planned uses were out of scope, each failing a different clause and each needing a different remedy.
- Access is not consent. A holder can grant access to records; whether it can authorise a new use of individuals' work is a separate question that one email usually leaves unanswered.
- Minors change the schedule, commonly from weeks to months. Ask about the subject population in the first message, not after the files arrive.
- De-identification at source is usually the cheapest arrangement, because you never hold identifiable data — but only if it is real redaction, not renamed files.
- Write the permission and the plan down separately, so the mismatches become visible.
- Boundary condition: for publishable human-subjects research, an ethics board decides before collection begins, and retrospective approval is generally unavailable — so this is a scheduling dependency, not a document to produce later.
Related:
- De-identification: Why Removing the Name Is Not Enough — what "de-identified at source" has to mean to be worth anything
- Guardrails & Output Validation — stopping a deployed system emitting personal data at inference time
- Fail-Closed Safety Gates: Enforcing Hard Constraints in Safety-Critical AI — refusing by default when a required check cannot be completed
- Backtesting, Baselines & Sensitivity Analysis — why excluding a subgroup late costs statistical power you may have already promised
Resources
- The Belmont Report, National Commission for the Protection of Human Subjects, 1979 — respect for persons, beneficence and justice; the source of the consent framing most institutional policies still use.
- World Medical Association, Declaration of Helsinki — the international reference for research involving human subjects, including provisions on participants who cannot consent for themselves.
- UK Information Commissioner's Office, Guide to Data Protection: Lawful basis for processing — a readable treatment of the "consent is one basis among several" point that §3.2 depends on.
- OECD, Recommendation of the Council concerning Guidelines governing the Protection of Privacy and Transborder Flows of Personal Data — purpose specification and use limitation, the principles §3.1 formalises.
- Your own institution's research-ethics or data-governance office — the only authority that can tell you whether a specific piece of work needs review, and the one to ask before collection rather than after.