SpektraBot Docs

Appearance

UK Age Appropriate Design Code (Children's Code) Compliance Assessment ​

Service: SpektraBot SEND Support System Controller: Spectrum Dynamics CIC Assessment date: 2026-03-12 Assessor: Spectrum Dynamics CIC compliance team ICO reference: Age Appropriate Design Code (AADC), effective 2 September 2021

Overview ​

The ICO's Age Appropriate Design Code (commonly called the Children's Code) sets out 15 standards of age-appropriate design that online services must conform to when they are "likely to be accessed by children" (under 18). The Code applies whenever an Information Society Service (ISS) processes personal data and is likely to be accessed by children.

Applicability to SpektraBot ​

SpektraBot is a web application that provides SEND (Special Educational Needs and Disabilities) guidance. Its primary users are parents and carers of children with SEND, along with education professionals (teachers, SENCOs). Children themselves are not the intended direct users. However:

  • Parents/carers enter information about their children (name, year group, SEND diagnosis, EHCP status, school).
  • Conversation data may contain information relating to children.
  • The service is invite-only (gated by waitlist approval and invite codes), which limits access, but cannot technically guarantee a child will never use the service.

Conclusion: The AADC is partially applicable. While SpektraBot processes children's data (entered by parents), it is not designed for direct child use. A conservative approach is taken: we assess against all 15 standards and document compliance, partial compliance, or justified non-applicability.

Compliance Status Summary ​

#StandardStatusPriority
1Best interests of the childCOMPLIANT--
2Data protection impact assessmentsPARTIALHIGH
3Age appropriate applicationCOMPLIANT--
4TransparencyPARTIALMEDIUM
5Detrimental use of dataCOMPLIANT--
6Policies and community standardsPARTIALMEDIUM
7Default settingsCOMPLIANT--
8Data minimisationCOMPLIANT--
9Data sharingCOMPLIANT--
10GeolocationN/A--
11Parental controlsCOMPLIANT--
12ProfilingCOMPLIANT--
13Nudge techniquesCOMPLIANT--
14Connected toys and devicesN/A--
15Online toolsPARTIALMEDIUM

Legend:

  • COMPLIANT -- Standard is met with evidence.
  • PARTIAL -- Standard is partially met; specific gaps identified with remediation actions.
  • GAP -- Standard is not met; remediation required.
  • N/A -- Standard does not apply to SpektraBot's architecture or use case.

Detailed Assessment ​

Standard 1: Best interests of the child ​

What the standard requires: The best interests of the child should be a primary consideration when designing and developing online services likely to be accessed by children. Services must consider whether the way data is collected, shared, or used could be detrimental to children's physical or mental wellbeing.

Compliance status: COMPLIANT

Evidence:

  • SpektraBot's core mission is to support families of children with SEND, directly serving children's best interests.
  • The system uses trauma-informed design principles throughout its AI responses -- validating emotions before providing guidance, using accessible language, and maintaining crisis protocols.
  • AI system prompts include hard rules for safeguarding: crisis detection triggers immediate signposting to Childline (0800 1111), Samaritans (116 123), and Crisis Text Line (text SHOUT to 85258).
  • The /trust page explicitly states limitations and signposts to human experts (IPSEA, SENDIASS, Contact).
  • Child data (SEND category, year group, EHCP status) is collected solely to personalise guidance in the child's best interests.
  • No child data is used for commercial purposes, advertising, or profiling.

Evidence paths:

  • packages/web/src/app/trust/page.tsx (trust and safety disclosures)
  • System prompt modules (trauma-informed rules, crisis protocols)
  • packages/api/prisma/schema.prisma (Child model -- minimal fields)

Recommended actions: None required. Continue embedding best-interests consideration in any new feature design.

Priority: --

Standard 2: Data protection impact assessments ​

What the standard requires: Undertake a DPIA for any new processing of children's data or for existing processing that may result in a high risk to children's rights and freedoms. The DPIA should specifically consider children's needs and include an assessment of risks to children.

Compliance status: PARTIAL

Evidence of compliance:

  • A risk assessment covering children's data sensitivity exists within the GDPR controls documentation (validation/trust-center/gdpr-controls.md, Section 6).
  • The assessment identifies that while no direct child identifiers are stored, the combination of SEND category, year group, and school could narrow identification.
  • Mitigations are documented: parent-only access, no cross-user sharing, cascade deletion, tiered data retention (see Data Retention Policy).

Gap identified:

  • No formal standalone DPIA document exists that follows the ICO's DPIA template.
  • The risk assessment does not explicitly frame its analysis through the lens of children's rights and freedoms as required by the AADC.
  • The DPIA should be reviewed whenever new features process child data (e.g., the ChildMemory system, advocate referrals).

Recommended actions:

  1. Complete a formal DPIA using the ICO's screening checklist and DPIA template (https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/data-protection-impact-assessments-dpias/).
  2. Include an explicit "impact on children" section assessing effects on children's physical safety, mental health, and developmental wellbeing.
  3. Review and update the DPIA when introducing new features that process child data (e.g., ChildMemory extraction, advocate data sharing).
  4. Document the DPIA review schedule (at least annually or on material changes).

Priority: HIGH

Standard 3: Age appropriate application ​

What the standard requires: Take a risk-based approach to recognising the age of individual users and ensure you apply the standards in the Code to child users. Where the service is not aimed at children but is likely to be accessed by them, the approach should be proportionate.

Compliance status: COMPLIANT

Evidence:

  • SpektraBot is not designed for direct child use. The intended audience is adults (parents/carers, teachers, SENCOs).
  • Access is gated by an invite-only waitlist system requiring admin approval before account creation. There is no open self-registration.
  • The waitlist categorises users as PARENT or PROFESSIONAL during sign-up, and role/persona is assigned accordingly.
  • All accounts require explicit GDPR consent, which is a legal act requiring capacity (implying adult users).
  • The service does not need formal age verification because its gated access model, professional context, and content nature make it unlikely that children would independently access or use it.
  • Children's data is entered by parents, not by children themselves. The Child model stores year group and SEND category -- information that parents provide about their children.

Evidence paths:

  • packages/api/src/auth/routes.ts (invite code validation at registration)
  • packages/api/src/services/waitlist/ (admin-approved waitlist flow)
  • packages/web/src/app/signup/page.tsx (consent-gated account creation)

Recommended actions: None required. If the service ever opens to direct child users (e.g., young people aged 16+), implement age verification and age-appropriate UX.

Priority: --

Standard 4: Transparency ​

What the standard requires: Publish privacy information in a clear, prominent, and age-appropriate manner. Where the service processes children's data, provide bite-sized explanations at the point data is collected, alongside a full privacy policy.

Compliance status: PARTIAL

Evidence of compliance:

  • A concise privacy policy exists at /policies/privacy, written in plain language.
  • The Trust & Privacy page (/trust) provides accessible explanations of data practices, AI disclosure, and limitations.
  • The signup page includes a data protection section with a link to the privacy policy.
  • The registration flow includes a prominent notice explaining data protection practices, including tiered retention (conversation transcripts deleted after 90 days of inactivity; support memories retained for account lifetime).

Gap identified:

  • The privacy policy is described as "concise" and states "link to your full legal policy when available" -- indicating the full legal privacy policy has not yet been published.
  • There is no specific children's privacy notice or section explaining how children's data (entered by parents) is processed, retained, and protected.
  • Bite-sized explanations are not provided at every point where child data is collected (e.g., when adding a child profile, when entering SEND details in chat).

Recommended actions:

  1. Publish a full legal privacy policy (not just the concise version) that includes a specific section on children's data processing.
  2. Add a brief in-context explanation when parents first add a child profile, explaining what data is stored, how it is used, and the retention period.
  3. Consider adding a "How we handle your child's information" section to the Trust page.
  4. Ensure the privacy policy explicitly states the lawful basis for processing children's data (parental consent under UK GDPR Article 8).

Priority: MEDIUM

Standard 5: Detrimental use of data ​

What the standard requires: Do not use children's personal data in ways that have been shown to be detrimental to their wellbeing, or that go against industry codes of practice, other regulatory provisions, or Government advice.

Compliance status: COMPLIANT

Evidence:

  • Children's data (SEND needs, year group, EHCP status) is used exclusively to personalise SEND guidance for the child's benefit.
  • No data is used for advertising, commercial profiling, behavioural targeting, or sale to third parties.
  • The privacy policy explicitly states: "We do not sell your data."
  • Analytics (Umami) are privacy-focused, self-hosted, cookieless, and do not track PII.
  • Azure OpenAI does not retain prompts or responses after processing; data is not used to train AI models.
  • The system is designed with trauma-informed principles, actively avoiding communication patterns that could cause distress.

Evidence paths:

  • packages/web/src/app/trust/page.tsx ("We never sell your data. Data is not used to train AI models.")
  • validation/trust-center/gdpr-controls.md (purpose limitation, Section 1.2)
  • Umami analytics configuration (no PII, no cookies)

Recommended actions: None required. Maintain this position and review if new data uses are proposed.

Priority: --

Standard 6: Policies and community standards ​

What the standard requires: Uphold your own published terms, policies, and community standards, including privacy policies, age restriction policies, behaviour rules, and content policies. Enforce them consistently.

Compliance status: PARTIAL

Evidence of compliance:

  • Privacy policy and terms of service are published and linked during registration.
  • GDPR consent is enforced at the API level via middleware (packages/api/src/middleware/gdpr.ts) -- requests without consent are rejected with HTTP 403.
  • The waitlist and invite code system enforces access restrictions consistently.
  • Audit logging captures consent events, logins, and administrative actions.

Gap identified:

  • Terms of service content was not reviewed in this assessment; ensure it covers acceptable use, prohibited activities, and data handling commitments consistent with the privacy policy.
  • There is no published acceptable use policy specifically addressing what types of information users should and should not enter about children.
  • No documented content moderation policy for user-generated content in chat (beyond the AI's built-in safeguarding protocols).

Recommended actions:

  1. Review and update the terms of service to include clear acceptable use rules.
  2. Create brief guidance for users on what information to share (and not share) about their children in chat.
  3. Document the content moderation approach (AI safeguarding prompts, admin review capabilities).

Priority: MEDIUM

Standard 7: Default settings ​

What the standard requires: Settings must be privacy-protective by default (unless there is a compelling reason for a different default, taking account of the best interests of the child).

Compliance status: COMPLIANT

Evidence:

  • User preferences default to privacy-protective settings:
    • chatHistoryEnabled: true (required for service functionality; conversations auto-deleted 90 days after last activity)
    • emailNotifications: true (service communications only, not marketing)
    • emailCommunicationConsent is optional and defaults to unchecked at signup
    • soundEnabled: false (off by default)
  • No tracking cookies are used. Umami analytics are cookieless and respect Do Not Track.
  • No social sharing, public profiles, or discoverable user information exists.
  • Data sharing with advocates requires explicit opt-in consent that can be withdrawn at any time.
  • The advocate data sharing notice explicitly states: "If withdrawn, advocate access is revoked immediately and no further sharing occurs."

Evidence paths:

  • packages/api/prisma/schema.prisma (UserPreferences model -- default values)
  • packages/web/src/app/signup/page.tsx (optional email consent checkbox)
  • packages/web/src/app/policies/privacy/page.tsx (advocate sharing consent)

Recommended actions: None required. Continue applying privacy-by-default to new features.

Priority: --

Standard 8: Data minimisation ​

What the standard requires: Collect and retain only the minimum amount of personal data needed to provide the elements of the service in which a child is actively and knowingly engaged. Give children separate choices over which elements they wish to activate.

Compliance status: COMPLIANT

Evidence:

  • The Child model collects only data necessary for SEND guidance personalisation:
    • Required: Name (for conversational context), parent relationship
    • Optional: Year group, SEND diagnosis, EHCP status, school, key needs, provision, SENCO name, key worker
  • No photographs, addresses, phone numbers, financial data, or government identifiers are collected for children.
  • The dateOfBirth field exists in the schema but is optional and not required for core functionality.
  • Data retention follows a tiered model aligned with Standard 8's requirement to differentiate by service element (see Data Retention Policy):
    • Tier 1 — Chat conversations: Deleted 90 days after last activity (updatedAt), enforced by a Kubernetes CronJob (PR #446).
    • Tier 2 — Child support memories: Retained for account lifetime (closure or 12-month dormancy). These enable long-term continuity of SEND support — the service's core value.
    • Tier 3 — User profiles: Retained for account lifetime.
    • Tier 4 — Safeguarding records: Retained indefinitely (statutory requirement).
  • The schema uses onDelete: SetNull on ChildMemory's sourceConversationId, so memories survive conversation deletion — the transcript is removed but distilled facts persist.
  • ChildMemory facts extracted from conversations include only educational context (diagnosis, school, professional contacts, preferences).
  • User account data is minimal: email, name, role, school affiliation.

Evidence paths:

  • packages/api/prisma/schema.prisma (Child model, ChildMemory model, onDelete: SetNull)
  • docs/compliance/data-retention.md (authoritative retention policy)
  • validation/trust-center/gdpr-controls.md (Section 1.3 -- Data Minimisation)
  • helm/spektrabot/templates/cronjob-data-retention.yaml (automated enforcement, PR #446)

Recommended actions: None required. Consider whether the dateOfBirth field on the Child model is necessary; if it serves no current purpose, consider removing it from the schema to further minimise data collection.

Priority: --

Standard 9: Data sharing ​

What the standard requires: Do not disclose children's data unless you can demonstrate a compelling reason to do so, taking account of the best interests of the child. Where you share children's data, ensure it is protected.

Compliance status: COMPLIANT

Evidence:

  • Children's data is not shared with third parties for commercial purposes.
  • The only data sharing pathway is advocate referrals, which:
    • Require explicit parental consent before any sharing occurs.
    • Allow consent withdrawal at any time, with immediate revocation of advocate access.
    • Auto-delete shared data 30 days after case closure or consent withdrawal.
    • Include an exception for safeguarding concerns (in line with Working Together to Safeguard Children 2023).
  • Azure OpenAI processes conversation data for inference only; it does not retain or share data.
  • Sub-processors are documented in the GDPR controls: Civo (UK infrastructure), Azure OpenAI (UK inference, no retention), Umami (self-hosted, no PII), Resend (transactional email only, no conversation data).
  • No data is shared for advertising, analytics, or profiling purposes.

Evidence paths:

  • packages/web/src/app/policies/privacy/page.tsx (advocate data sharing section)
  • validation/trust-center/gdpr-controls.md (Section 4.2 -- sub-processors, Section 5 -- transfers)
  • packages/api/prisma/schema.prisma (Referral, SafeguardingLog models)

Recommended actions: None required. Maintain the consent-first approach to any future data sharing.

Priority: --

Standard 10: Geolocation ​

What the standard requires: Switch geolocation options off by default and provide an obvious sign when location tracking is active. Options that make a child's location visible to others should default to off.

Compliance status: N/A

Evidence:

  • SpektraBot does not collect, process, or use geolocation data.
  • No GPS, IP-based location tracking, or location-aware features exist in the application.
  • The service does not request browser location permissions.
  • The only geographic data is the user's optionally-provided school name/URN and the local authority associated with knowledge base content, neither of which constitutes geolocation tracking.

Recommended actions: None required. If location-based features are ever introduced (e.g., "find your nearest SENDIASS"), ensure they comply with this standard.

Priority: --

Standard 11: Parental controls ​

What the standard requires: If you provide parental controls, give the child age-appropriate information about this. If the service allows a parent or carer to monitor their child's online activity or track their location, provide an obvious sign to the child when they are being monitored.

Compliance status: COMPLIANT

Evidence:

  • SpektraBot is designed for parents as the primary users, not children. The parent is the account holder and data controller for their child's information.
  • All child data is entered, viewed, and managed by the parent through their own account.
  • There are no "parental controls" in the traditional sense (monitoring a child's independent use), because children do not have independent accounts.
  • The system architecture inherently gives parents full control over their children's data (adding/editing/deleting child profiles, conversation history, documents).
  • Cascade deletion ensures all child data is removed when a parent account is deleted.

Evidence paths:

  • packages/api/prisma/schema.prisma (Child.parentId relationship, onDelete: Cascade)
  • Account structure: parents own and control all child data

Recommended actions: None required. If child-facing features are ever introduced (e.g., young person accounts), implement transparent monitoring notices.

Priority: --

Standard 12: Profiling ​

What the standard requires: Switch off options that allow profiling of children by default, unless you can demonstrate a compelling reason for profiling, taking account of the best interests of the child. Where profiling is permitted, ensure appropriate safeguards and do not use profiling to target harmful content.

Compliance status: COMPLIANT

Evidence:

  • SpektraBot does not profile children in the AADC sense (building a behavioural profile for targeting, advertising, or decision-making about the child).
  • The ChildMemory system extracts facts from conversations (e.g., "has EHCP finalised", "attends year 5") solely to personalise SEND guidance. This is contextualisation for the child's benefit, not profiling for commercial or targeting purposes.
  • No behavioural scoring, prediction, or automated decision-making about children occurs.
  • Analytics (Umami) are aggregated and cookieless; no individual user or child profiles are built.
  • No data is used for targeted advertising, content recommendation algorithms, or engagement optimisation.

Evidence paths:

  • packages/api/prisma/schema.prisma (ChildMemory model -- educational context only)
  • validation/trust-center/gdpr-controls.md (Section 1.2 -- purpose limitation)
  • Umami analytics (no PII, no individual profiling)

Recommended actions: None required. If any feature is introduced that uses child data for automated decision-making, conduct a DPIA and consider whether it constitutes profiling under the AADC.

Priority: --

Standard 13: Nudge techniques ​

What the standard requires: Do not use nudge techniques to lead or encourage children to provide unnecessary personal data, weaken or turn off their privacy protections, or extend their use of the service.

Compliance status: COMPLIANT

Evidence:

  • SpektraBot does not employ dark patterns, gamification, or engagement-maximising nudge techniques.
  • The UI does not use streaks, rewards, notifications urging return, or any mechanism designed to maximise time on service.
  • Optional data fields (child SEND details) are clearly marked as optional and do not use persuasive language to encourage completion.
  • Email communication consent is an unchecked optional checkbox at signup, not pre-selected.
  • No "complete your profile" nudges or progress bars incentivise providing additional data.
  • The trauma-informed design approach prioritises user wellbeing over engagement metrics.

Evidence paths:

  • packages/web/src/app/signup/page.tsx (optional email consent, no nudge patterns)
  • packages/api/prisma/schema.prisma (Child model -- optional fields clearly designated)
  • Trust page design (honest, non-manipulative communication)

Recommended actions: None required. Maintain this approach in future feature design. Review any notification or engagement features for nudge patterns before launch.

Priority: --

Standard 14: Connected toys and devices ​

What the standard requires: If you provide a connected toy or device, ensure it includes effective tools to enable conformance with the Code.

Compliance status: N/A

Evidence:

  • SpektraBot is a web application only. It does not include, connect to, or integrate with any physical toys, IoT devices, wearables, or connected hardware.

Recommended actions: None required. Not applicable to SpektraBot's architecture.

Priority: --

Standard 15: Online tools ​

What the standard requires: Provide prominent and accessible tools to help children (or, where appropriate, their parents) exercise their data protection rights and report concerns. This includes tools for accessing, correcting, and deleting their data.

Compliance status: PARTIAL

Evidence of compliance:

  • Right to erasure: Administrators can delete user accounts and all associated data (cascade deletion including child records, conversations, memories).
  • Right of access/portability: A self-service DSAR (Data Subject Access Request) endpoint is being implemented (PR #452) to allow users to export their complete data in JSON format. Until deployed, data exports are handled manually via admin database queries upon request.
  • Right to rectification: Users can update their profile information through the settings page.
  • Consent management: Users can update their GDPR consent via the API (PUT /api/auth/consent).
  • Advocate data sharing: Parents can withdraw consent for advocate data sharing at any time, with immediate effect.
  • Contact channel: The Trust page provides support@spektrabot.co.uk for reporting concerns.

Gap identified:

  • Data access, export, and deletion currently require admin intervention -- there is no self-service "download my data" or "delete my account" button accessible to users directly.
  • There is no prominent in-app tool for users to view what child data is stored and request its deletion without contacting an administrator.
  • The process for exercising data rights is not prominently documented in the application UI (beyond the concise privacy policy mention).

Recommended actions:

  1. Add a self-service "Download my data" feature in user settings that exports the user's data (including child profiles) in a structured format.
  2. Add a self-service "Delete my account" feature in user settings with appropriate confirmation steps and clear explanation of what will be deleted.
  3. Add an in-app "Your data rights" section in user settings that explains how to access, correct, export, and delete data, with clear instructions.
  4. Ensure the child profile management UI includes a clear option to delete individual child records.

Priority: MEDIUM

Remediation Roadmap ​

High Priority ​

ActionStandardDescriptionEffort
DPIA-0012Complete formal DPIA using ICO template with children's impact section2-3 days
DPIA-0022Establish DPIA review schedule (annually + on material changes)0.5 day

Medium Priority ​

ActionStandardDescriptionEffort
TRANS-0014Publish full legal privacy policy (replacing concise version)2-3 days (legal)
TRANS-0024Add children's data processing section to privacy policy1 day (legal)
TRANS-0034Add in-context explanation when creating child profiles0.5 day
POLICY-0016Review and update terms of service for completeness1-2 days (legal)
POLICY-0026Create user guidance on sharing children's information0.5 day
TOOLS-00115Implement self-service "Download my data" in user settings2-3 days (dev)
TOOLS-00215Implement self-service "Delete my account" in user settings1-2 days (dev)
TOOLS-00315Add "Your data rights" section to user settings UI0.5 day (dev)

Low Priority / Maintenance ​

ActionStandardDescriptionEffort
MIN-0018Evaluate whether dateOfBirth field on Child model is necessary0.5 day
POLICY-0036Document content moderation approach0.5 day

Review Schedule ​

This assessment should be reviewed:

  • Annually as a minimum (next review: March 2027)
  • When introducing new features that process children's data
  • When the ICO publishes updated guidance on the Children's Code
  • Following any data breach or incident involving children's data
  • When expanding access to new user groups (e.g., young people, students)

References ​

Confidential · Spectrum Dynamics CIC

© 2026 Spectrum Dynamics CIC. All rights reserved.