Purpose Binding

Data collected to perform one function is later wanted for another. The governing question is whether the new use is compatible with the purpose stated at collection — and in most organisations that question cannot be answered at all, because nobody recorded the purpose.

Purpose binding makes the answer retrievable: the purpose and lawful basis are metadata on the data, and they propagate to everything derived from it.

Why the recording must happen at collection

Reconstructing a historical dataset's purpose after the fact is guesswork. The notice shown, the basis relied on and the scope agreed all existed at a moment that has passed, and the artefacts documenting them are usually not retained.

Once that information is lost, every reuse decision becomes a judgement made without the facts it depends on — and the safe answer, refusing everything, is not what actually happens.

Implementation patterns

• Purpose and lawful basis recorded per dataset at collection, alongside the notice version shown, since proving what was agreed requires knowing what the person was shown.
• Several purposes recorded separately where one collection serves more than one, because different purposes may rest on different bases with different subject rights attached.
• Access granted per purpose rather than per team, so a grant carries what it was granted for.
• Propagation through lineage. A model or dataset derived from purpose-limited data inherits the limitation — the step most often missed, and the one that lets constraints escape through a transformation.
• A review gate at pipeline or model proposal, not a periodic audit, because discovering a violation in an audit means the model already exists and has been serving.
• A documented route to a lawful basis — fresh consent, a legitimate interests assessment, or anonymisation to the point the rules no longer apply. A control with no permitted path gets bypassed.

Industry example

Platforms with rich behavioural data face this request continuously: the data exists, a new model would benefit from it, and the team's instinct is that possession implies permission. "We already have the data" is not a lawful basis, and the compatibility assessment turns on the relationship between purposes, the subject's reasonable expectations, sensitivity and consequences — not on technical convenience.

The organisations that handle it well treat the request as legitimate and route it, rather than treating each one as an exception to be argued. The ones that handle it badly discover in an audit that a production model was trained on data collected for something else, and remediation means deleting the model, retraining without the data, and possibly notifying.

Failure scenarios

• Purpose not recorded, making the question unanswerable for every historical dataset.
• Purpose recorded and not propagated, so derivation launders the constraint away.
• Access by team rather than by purpose, which grants everything a team could conceivably need.
• Review as an audit rather than a gate, finding violations after they are expensive.
• Refusal with no alternative path, which produces quiet non-compliance rather than compliance.

Trade-offs

Recording and enforcing purpose adds friction to collection and to every subsequent use, and it constrains exactly the opportunistic reuse that data teams value most. That friction is the mechanism, not a side effect.

The proportionate approach is to bind purpose rigorously for personal and sensitive data and lightly for the rest, rather than applying the same ceremony to operational telemetry and to customer records.

Interview question

"A team wants to train a model on data your platform collected two years ago for a different feature. Who can answer whether that is permitted, what would they need, and what do you do if the answer is 'nobody knows'?"