One tick is not consent: what a consent record has to store

Purpose-based consent means one record per purpose per person, and every record is an immutable event: which purpose, the exact wording that was on the screen, who agreed, in what capacity, when, through which channel, and what evidence survives. A tick on a registration form is not that. It is a boolean with no memory of the question it answered.

The difference shows up the moment somebody asks about the past. A parent says they never agreed to photographs on the club's public accounts. A welfare officer needs the families who answered the new medical wording rather than the old. A flag answers neither: it stores an outcome and throws away the question.

A purpose is one activity, not a category

A purpose is a single processing activity in words a parent would recognise: photographs on the club's public accounts, injury information visible to the assigned physiotherapist, marketing email about holiday camps, a coach messaging a player directly. Those are 4 questions with 4 answers. Bundled into one line called club communications and media, a yes cannot be relied on for any of them and a no removes all 4.

Two of those are harder to enforce than to capture. An image permission has to be re-checked at publication rather than at upload, which is how a restricted child ends up in a highlight clip. Coach contact needs the guardian and welfare officer structurally present, which is visibility as a property rather than a setting.

Nine fields on one consent event

Two of the 9 carry most of the weight and are the 2 usually missing. Capacity is the first: an adult who is not a guardian of that child cannot answer for them, and the check runs against the relationship rather than the person — the argument in a guardian is a relationship, not an account type.

Append-only, because the position is a computation

Nothing is edited and nothing is deleted. A change of mind is a new event superseding an earlier one, and the current position is the most recent effective event for that subject and purpose. A flag a script updated last March cannot say what it held in February, and the questions that get asked are about February.

Change the wording and you have asked a different question

A consent event references a wording version, not a string. Store the text as a versioned artefact — id, full text, effective from and to, who approved it — and point the event at the id. A wording change is then a new version, and every consent already given still records what its giver read.

What a new version cannot do is update the answers underneath it. Where the change is material — a new recipient, a purpose folded into an existing sentence, a longer retention — consents against the old version answer a question the club no longer asks. Ignoring that is how a club ends up with 800 yeses to a paragraph nobody saw.

1. Draft the new wording and record the diff and the reason in a line. A version with no diff is a version nobody can defend.
2. Classify the change as clerical or material, and have the person carrying the risk sign that classification. A typo is clerical. A new recipient is not.
3. Publish with an effective date and keep earlier versions readable permanently. They are the only proof of what an earlier consent meant.
4. On a material change, mark consents against the superseded version as answering an old question and re-ask. Do not flip them, and do not delete them.
5. Until the re-ask completes, default anyone who has not answered to the more restrictive of the 2 positions rather than to their old yes.

Withdrawal is an event, and it has to travel

A withdrawal is appended, never applied by deleting the grant. Deleting it destroys the club's ability to show that what it did last season was agreed to at the time, which is what a complaint asks about.

• Exports and mailing lists. A segment pulled on Monday is still sending on Thursday and knows nothing about Tuesday's withdrawal.
• Derived data. Scores computed from behaviour outlive the rows they came from — the worked example is what a member retention score actually is.
• Published media. Withdrawing an image permission is a recall across every surface a picture reached, and the cache and the sent newsletter are separate jobs.
• Third parties. A league registry, a photographer's gallery and the streaming platform each hold a copy, and each needs an instruction with a confirmation.
• Restores. Most restore paths reinstate the old value, so a restore has to re-apply every withdrawal recorded since the backup was taken.

None of this is the same object as a safeguarding record, and they must not share access rules. An incident entry is readable by fewer people than the club administrator and runs on its own clock — what a safeguarding incident log has to capture sets out the fields. A consent record should be visible on demand to the guardian who gave it.

A consent flag tells you what the club believes today. A consent record tells you what it was told, by whom, and against which words.

What the software decides, and what it cannot

We build the mechanism: the event store, the versioned wording, the derivation, the withdrawal path and the propagation jobs. What makes a consent valid is a different question. The age at which a young person answers for themselves, whether a purpose needs consent at all rather than another lawful basis, and what verification of a guardian is sufficient differ by market and belong to the club's counsel. We hold no certifications and give no legal advice — a page on that boundary should split it explicitly, as what a verification step has to do for a young member does.

Built, this is 3 tables and a job — consents, purposes, wording versions, and a propagation runner with a dead-letter queue somebody can read — the size of scope we take on as MVP and product builds. It sits in guardians, minors and safeguarding, part of our sports, fitness and athletics work.

• consent
• safeguarding
• data model
• youth sport