Data commitments
What we hold, what we do not, and why it matters
What we hold, what we do not, and why it matters
Privacy by design means the system cannot identify you, not that it has a policy saying it won't.
What the system actually processes
The system processes signals derived from behaviour and language, not the content itself. Specifically:
- Linguistic signals: semantic features derived from text, including patterns of sentiment, categories of language, shifts in tone over time. The raw text is not stored. Only the derived features are.
- Behavioural signals: session frequency and duration, time-of-day patterns, interaction volume changes. Statistical features only, not a record of what was done.
- Interaction dynamics: messaging asymmetry, new contact patterns, changes in social graph topology. The structure of interaction, not the identity of participants.
- Risk scores: a computed escalation level and confidence score, per anonymised ID, per session.
We do not store message content, post content, images, voice recordings, or any form of raw user-generated content.
Children's data
Gaming and educational platforms have significant populations of users under 18. We treat the ICO's Children's Code as a design floor, not a compliance ceiling.
In practice, this means: the best interests of the child are the primary design consideration for every feature that may affect them. The most privacy-protective settings available are the default for any user identified or likely to be a minor. The safeguarding use case is the only basis on which we process data relating to children, there is no other.
UK GDPR and legal basis
Processing of signals that may relate to mental health, vulnerability, or sexual behaviour, even when derived rather than directly collected, may constitute special category data under UK GDPR Article 9.
We process this on the basis of substantial public interest under Schedule 1 of the Data Protection Act 2018, which applies to safeguarding functions.
A Data Protection Impact Assessment is completed before any live deployment on any platform. This is mandatory, not optional.
Your right to know what we hold
In the future, if you use a platform that operates this system, you will have the right to request access to the data we hold about you. You will be able to exercise this right through the platform, which will forward the request to us.
Our response will tell you what signals and risk scores are held against your anonymised ID, in plain English, without clinical jargon. We will include, as standard, a brief note about support resources, not because we assume you need them, but because we include it for everyone who contacts us and we think that is the right thing to do.
We will not confirm or deny whether a specific escalation recommendation was made to the platform. This protects the integrity of the safeguarding function, which cannot operate effectively if its outputs are visible to the people it is designed to protect.
No personal data by design, not by policy
The system is designed to operate without personal data. It does not receive names, email addresses, IP addresses, phone numbers, device identifiers, or any other information that could be used to identify a real person.
The system works with anonymised internal user IDs supplied by the platform, the same kind of identifier a platform uses internally to manage sessions and activity, stripped of any personal information before it reaches us. We receive the ID and the signals associated with it. We do not know who the ID belongs to.
The anonymisation is the platform's responsibility, defined contractually before any data flows begin. We require it as a condition of the relationship, not as a preference.
The goal is a system that cannot identify a real person even if it wanted to. This is a technical constraint, not a policy statement. Technical constraints do not rely on anyone keeping a promise.
Ready to partner with us?
We work with organisations that share our commitment to evidence-based practice.