Retention mismatch briefing for athlete and fan data
Problem
Retention periods for athlete and fan data are set once, in whichever system holds the record: a job configuration in the warehouse, a contact lifecycle setting in the CRM, a default left untouched in a wearables vendor's portal. Nobody revisits any of them unless an audit or a new data-sharing agreement forces the question. When that happens, the head of data ends up with several PDF contracts, the current wording of data protection law's retention obligations, and a screen open in each system, trying to work out by hand whether what is actually configured still matches what the agreement and the law say. It takes days, the answer is often already out of date by the time anyone circulates it, and the review rarely gets repeated until the next audit forces it again.
Product idea
A research agent that takes two inputs: a CSV export of each system's configured retention period, and PDF copies of the data-sharing agreements currently in force. It reads both against a fixed reference set covering the UK General Data Protection Regulation (UK GDPR) and the EU General Data Protection Regulation (EU GDPR), then produces a per-system comparison: what is configured, what the relevant agreement or regulation provision says, and a flag wherever the two diverge, with every claim linked back to the exact clause or field it came from. It does not change any retention setting itself and does not offer a legal opinion on an ambiguous clause. It surfaces the passage and lets the head of data decide what it means for that system.
Who it is for
Head of data, data engineers and the CRM and CDP manager, each of whom owns a retention setting in a different system, sponsored by the head of data who needs one place to see whether they still agree.
Possible first version
A single-page tool that accepts a CSV export of each system's configured retention period and PDF copies of the current data-sharing agreements, and returns a browsable briefing: one row per system showing the configured setting, the relevant clause or regulatory provision, and a flag where they diverge, each cited back to its source. Out of scope for version one: any live connection to a source system, since the CSV is exported by hand; any automatic change to a retention setting; and any legal interpretation beyond quoting the source passage for a person to read.
- Build classification
- Micro-tool
- Rough effort
- 10-day prototype
- Roles involved
- Head of data, Data engineer, CRM and CDP manager
- Relevant to
- Professional club, League office, Federation / governing body, Collegiate athletics
- Systems in play
- Data warehouse and BI tool, CRM, Spreadsheets
- Product framing
- Research
Questions we get asked
What do we need to have ready before the first run?
A CSV export listing each system's currently configured retention period, and PDF copies of the data-sharing agreements you want checked against. Neither has to be perfectly formatted; the agent works from what is actually in the document. What it will not do without a source is guess: if a system is missing from the CSV or an agreement is not supplied, that system is simply absent from the briefing rather than assumed to be fine.
We already keep a spreadsheet tab noting which systems need a retention review. Why replace it?
It probably should not be replaced outright at first. The spreadsheet records that a review is due; it does not do the review. The gap this closes is the days of manual comparison between a contract, the relevant law and an admin panel that happens after someone finally opens that tab. If the spreadsheet already gets acted on promptly, this tool is solving a problem you do not currently have.
Does this tell us whether we are compliant?
No, and it is built not to. It shows where a configured setting and a contract or regulatory provision appear to disagree, with the source passage attached, so a person with legal or data protection responsibility can judge what that disagreement means. Whether a given retention period is lawful is a judgement call for that person, not an output this tool is designed to produce.
Who is responsible for keeping this current once it exists?
The head of data, in practice, because the CSV export and the agreement PDFs need refreshing whenever a system setting or a contract changes, and nobody else has visibility across every system involved. If that refresh does not happen, the briefing quietly goes stale in the same way the spreadsheet did, so the ongoing cost is a recurring export, not a one-off setup.
Is this your workflow?
Tell us one sports workflow that still runs on paper, spreadsheets, WhatsApp or an outdated system. We will map it and show you what a simpler product looks like.
Tell us about itMore in Data platform & engineering
- Access permission drift monitor for warehouse and reporting toolsA monitor that compares entity access rules across the identity provider, warehouse and reporting tool, and alerts a named owner when they drift out of sync.
- Attendance reconciliation report across ticketing and till systemsA reconciliation report that turns a ticketing export and a till export for the same fixtures into one defensible attendance and spend figure, with the variance between them shown and explained.
- Chat intake assistant that triages ad hoc data requestsA chat assistant that answers a data request instantly when the metric already exists, and turns anything new into a structured, tracked ticket instead of a message lost in a chat thread.