The restricted child is in the published clip. Where the permission leaked

The permission was enforced once, at upload, and never again. That is the finding in most of these investigations, and it explains the pattern that confuses people: the in-app gallery behaves correctly, the club's own team page behaves correctly, and the child appears in the highlight reel, the newsletter or the printed programme — because those were produced by a different path that never asked the question.

So the diagnosis is not 'the consent record was wrong'. It usually is not. The record is fine, the withdrawal is fine, and the definition of a well-formed consent record is a separate subject covered in consent as a record with a purpose and a withdrawal path. What follows is how to find the surface that publishes without checking, and how to close it.

One restricted child, every surface an image can reach

The confirming check takes about an hour. Pick 1 child with a live restriction, find 3 assets that contain them, and attempt publication on every surface the club actually uses. Do not reason about the code; run the surface.

The stream is the surface most often forgotten and the hardest to gate, because the frame is generated live and nobody selects it. That case has its own treatment in the children who must not appear on the stream, and if your leak was an overlay or a replay clip, start there rather than here.

Five causes, ranked, and the signature that identifies each

1. Checked at upload only. Signature: every in-app surface is correct and every export is wrong. The restriction is a property of the child, the file is a property of the library, and nothing joins them after the upload screen closes.
2. Group photographs with no per-subject tagging. Signature: solo shots are clean and squad shots leak. A permission attaches to a child; a team photo of 14 children has 14 subjects and most systems store 0.
3. A permission withdrawn after publication, with no recall path. Signature: the asset's publish time predates the withdrawal timestamp, so every check passed. Consent is revocable and publication is not; without a recall job the two never reconcile.
4. The image left the system. Signature: the leak is on a surface running none of your code — a parents' group chat, a coach's personal account, a photographer's proofing gallery. No gate you build reaches it, which makes it a policy and contract problem.
5. A purpose-scoped permission read as global. Signature: the stored permission says 'team page and internal use', the use was a public social post, and the code asked a boolean question. Purpose is the field that distinguishes them and it was thrown away at the check.

Move the gate to the moment of publication

The fix is structural rather than procedural: publication becomes an operation that cannot complete without a permission evaluation, and every surface goes through it. Five evaluation steps, in order.

1. Resolve the asset's subjects. An asset with an empty subject list is not 'nobody', it is 'unknown', and unknown fails closed on every public surface.
2. Look up a live permission per subject, for the purpose class of this surface. Team page, public web, social, print and broadcast are 5 different purposes, not 1.
3. Check the permission has not expired and was not withdrawn. Season-scoped permissions expire silently, which is the point of storing the expiry.
4. Evaluate server-side, at render and at export. A gate implemented in the admin interface is bypassed by the download button, and the download button is how images actually leave.
5. Write the decision to a log with asset, subjects, surface and outcome. When somebody asks 6 months later how the clip was cleared, that log is the answer, and its absence is the reason these conversations go badly.

Step 1 is the expensive one, because subject lists have to come from somewhere. Automated grouping can propose subjects and a human confirms them; what it must never do is grant clearance on its own. The identification constraints in youth sport, where face recognition is often off the table entirely, are worked through in identifying players in footage without face recognition. This propose-then-approve split is the same pattern we apply in AI agents and automation work generally, and the operational reasons behind it are in AI in logistics operations — the model does the volume, a person owns the decision that carries consequences.

Enforcement at upload protects the library. Enforcement at publication protects the child. Only one of those is what a parent believed they were agreeing to.

The recall run, when it has already gone out

1. Unpublish at source, and record the time. Everything after this is measured against that timestamp.
2. Purge the cache. Cloudflare's cache documentation lists purge by single URL, by prefix, by hostname and by cache tag, with per-plan rate limits on single-file purges — so tag image responses with the asset identifier at delivery, and one child's media purges in a single call instead of an enumeration of URLs you may not have.
3. Handle copies on platforms you do not control: the social post, any crosspost, any reshare, the video platform's own thumbnail. Each is a separate request, and none is guaranteed.
4. Establish what already left: the newsletter sent to 400 households, the programme printed on Thursday, the file downloaded by 3 volunteers. These cannot be recalled and the record should say so plainly.
5. Tell the household, through the person they will expect to hear from — a decision covered in the coach who teaches them or the front desk who calls.
6. Open an incident record, because under most clubs' policies this is reportable as well as a defect: what a safeguarding incident log has to capture.
7. Fix the surface, not the asset. Deleting the file and leaving the gate open produces the same incident with a different child next month.

What a correct gate still will not fix

Be honest with a club about the boundary of the software, because overselling it is how the next incident becomes a breach of trust as well as a mistake. A publish gate governs the club's own channels. It has no reach into a parent filming from the touchline, a photographer's camera roll, an opposing club's feed, or a screenshot taken before the recall. Those are handled by ground rules, signage and the agreement signed with anyone who brings a camera — and the volunteer behind that camera is usually a role requiring clearance, which is a register with expiry dates rather than a note: what your system must record about who is cleared to coach.

• The historical archive predates the model. Every asset published before subject tagging existed is unchecked, and a backfill needs a decision: tag it, restrict it, or take it down.
• Direct messages are a publication surface too. An image sent by a coach to 1 player leaves no club-side record unless the channel is built for it — the reason those threads are visible by design.
• Households disagree. Where 2 guardians hold different positions on the same child, a gate needs a precedence rule rather than the last answer written: one household, 3 children, 2 guardians with different consents.
• Restrictions change mid-season, so a permission checked at publication is only true at publication. Reviewing published media against current permissions on a schedule is the only way that stays true.

None of this is unusual engineering; it is ordinary permission evaluation applied at the point of egress instead of the point of ingest. What makes it feel hard is that the club's surfaces grew one at a time, each with its own path to publication. The rest of the model around under-18s — guardian authority, consent, messaging, retention — sits in guardians, minors and safeguarding, and the wider view of what we build for clubs and academies is in sports and fitness.

• image permissions
• safeguarding
• publishing
• youth sport