Safeguarding Disclosure Pathway

1. What this document is

This is the operational disclosure pathway. It documents what happens when a student's free-text submission contains language that suggests they may be at risk. It is intended to satisfy school DSL / safeguarding-lead procurement queries and to give parents transparency about a quiet protective layer that's running underneath the learning surface.

2. Where the detector listens

Any free-text field the student types into. As of this writing:

• SoloCognition - written answers on quiz questions.
• Ask Cogs - typed questions to the mascot helper.
• Zone of Regulation (ZoR) - emotional check-in reflections, where present.
• Required Practical post-lab notes - the reflection box at the end of a virtual lab.

Multiple-choice answers, button clicks, and avatar selections do not enter the detector. The detector does not run on parent / staff text - they have separate disclosure channels (email + the safeguarding contact box).

3. What the detector looks for

A maintained list of literal trigger phrases organised into four categories:

• Self-harm: active intent ("kill myself", "want to die", "cut myself", "unalive"), passive ideation ("hate myself", "everyone would be better off"). High-severity by default.
• Abuse: family-based harm signals ("hits me", "touched me", "not safe at home"). High-severity.
• Distress: emotional-overload signals ("can't do this anymore", "so depressed"). Medium-severity.
• Substance: euphemistic drug references ("shrooms", "getting high"). Medium-severity.

Matching is word-boundary, case-insensitive, and literal - we deliberately do not use fuzzy or ML matching here because the false-positive risk would overwhelm the DSL queue. The trigger list is reviewed each term by the DSL and the platform admin.

4. What happens when a trigger fires

1. The detector posts a row to the safeguarding_concerns table with: the matched phrase, severity, category, source ("quiz" / "ask-cogs" / etc), a ~120-char excerpt of surrounding context, and the student's auth ID. The full submission is NOT stored - only the short excerpt.
2. The student is not notified. Showing a "we flagged you" popup would chill future disclosure, and creates a perceived punishment around something that is fundamentally a protective response. The student carries on with their lesson.
3. The new row appears on the SoloSight Safeguarding queue for the DSL. High-severity rows surface at the top with a badge count on the navigation.
4. The DSL reviews. They have four actions:
   • In review - they've seen it and are working on it.
   • Resolve - the concern was actioned. A short resolution note is captured (visible to other staff, not to the student).
   • Escalate - the concern needs onward referral (school DSL, social services, MASH, CAMHS, etc.). The DSL handles the escalation through their normal channels - SoloCogs does not auto-notify external agencies.
   • False positive - the trigger matched but the context didn't warrant action (e.g. the student typed "killed it" in a worked-example answer about chemistry).

5. Who can see the concern row

• Students: never. Not their own row, not anyone else's. Row-level security on the safeguarding_concerns table allows the student session to INSERT but blocks SELECT / UPDATE / DELETE.
• Staff (tutors, teachers, SENCos): only for students in their assignment scope, once that role-based RLS is wired (Phase 2). For B2C accounts, the platform admin acts as DSL.
• Platform admin: full access for incident review and trigger-list tuning.
• Parents: not via this table. Parents are contacted directly by the DSL if a concern warrants it; the table itself is staff-only by design.

6. SLA

• High-severity concerns: reviewed within 4 hours on a working day, by end of next working day at weekends / holidays.
• Medium-severity: reviewed within 2 working days.
• Low-severity: reviewed within 5 working days.

An emergency disclosure that requires immediate action (active intent, imminent harm) is escalated immediately - that means the DSL contacts the student / family directly and, where appropriate, MASH (Multi-Agency Safeguarding Hub) or the local A&E. The platform itself does not call emergency services.

7. Retention

Safeguarding concern rows are retained for seven years after resolution, in line with statutory guidance (Keeping Children Safe in Education / Working Together to Safeguard Children). After seven years they are anonymised - student identifier removed but the matched phrase + category + severity + resolution note kept for trigger-list tuning. Anonymised entries are retained indefinitely.

8. Audit + improvement

The trigger list is reviewed each term by the DSL with the platform admin. Reviews check:

• False-positive rate per phrase - if a phrase consistently fires on non-safeguarding context, it's tuned or removed.
• New emergent language - particularly TikTok / Discord-era euphemisms that students use to bypass content moderation.
• Category boundaries - some phrases drift between categories as cultural meaning shifts.

Aggregate (anonymised) data on disclosures-by-category may be published in the annual safeguarding report.

9. Limitations

We are explicit about what this layer does and does not do:

• It only sees text the student types into SoloCogs. Disclosures via other channels (email, social media, in-person) are out of scope.
• It uses literal phrase matching. Nuanced or coded disclosures may not trigger. The system is a safety net, not a replacement for staff vigilance or for the student's relationship with a trusted adult.
• The detector runs in the student's browser session, not on a server. A determined student could disable JavaScript and submit text without the detector running. This is a known limitation of any client-side detection layer; we mitigate by keeping the detection logic visible only in the codebase, not on a labelled UI surface.

10. How to enable on a B2B contract

For school + tutoring-company subscribers, the detector is on by default and routes to the platform admin queue. We will set up a school-specific DSL queue on request - email hello@solocogs.co.uk with subject "Safeguarding routing" and provide the named DSL email. We can also adjust SLA, escalation procedure, and trigger-list against your school's safeguarding policy.