MIS data usage

1. What Wonde does for SoloCogs

Wonde is a UK-based MIS aggregator. Schools grant Wonde read access to their MIS once (SIMS, Arbor, Bromcom, ScholarPack, iSAMS, and others), and Wonde then exposes that data via a normalised API to whichever third-party apps the school has independently authorised. SoloCogs uses this route so a school can add SoloCogs to its curriculum without staff needing to hand-upload roster spreadsheets each September.

Wonde acts on behalf of the school, not on behalf of SoloCogs. The school remains the controller of the MIS data throughout; SoloCogs and Wonde are joint processors within the scope authorised by the school.

2. Fields we consume, per scope

SoloCogs requests four Wonde scopes. The fields actually copied into our mirror tables are listed exhaustively below. If Wonde adds new fields to any of these scopes in future, they land inside the raw_payload column (see §2a) but are not surfaced anywhere in the SoloCogs product until we explicitly map them - at which point this page is updated first.

Scope	Fields consumed	Purpose
Students	Wonde student id, UPN, legal first name, legal last name, preferred name, date of birth, gender, year group, form/tutor group, school email (where present), SEND register code, Pupil Premium flag, EAL flag, Looked After Child flag, plus the full raw Wonde payload archived as JSON	Match a student to their SoloCogs account at signup (UPN or email); hydrate year group + school; populate SEND / PP / EAL / LAC flags into the SEND-flag conflict-review queue (see §2a); auto-suspend on leaver flag
Teachers	Wonde teacher id, forename, surname, title (Mr/Mrs/etc), school email, job title / role, plus raw Wonde payload	Match teaching staff to the school's SoloSight dashboard; grant class visibility; role text distinguishes teachers from teaching assistants for permissions
Classes	Wonde class id, class name / code, subject, year group, plus raw Wonde payload	Populate the school's class list so teachers can filter SoloSight by their own classes
Class memberships	Student-to-class and teacher-to-class link rows	Enforce "teachers only see students they teach" in row-level security policies

2a. Sensitive fields: SEND, Pupil Premium, EAL, LAC

Because SoloCogs is a SEND-focused learning platform, the students scope includes four fields that are more sensitive than the rest: SEND register code, Pupil Premium status, English as an Additional Language, and Looked After Child status. Each has a specific, documented purpose that maps to how UK secondary schools already monitor these cohorts. Storage is in the same UK-region encrypted database as the rest of the roster, protected by the same tenant-scoped row-level security.

• SEND register code - used two ways. (a) A dedicated SEND-flag conflict-review queue (see safeguarding flow and sql/send_flag_governance.sql): if the school's MIS records an access arrangement that a pupil is not actively using inside SoloCogs, or SoloCogs is set to give an accommodation the school hasn't recorded, that mismatch is queued for a SENDCo or Head of Department to review rather than either side being silently overwritten. This is what makes SEND access arrangements exam-safe under JCQ "normal way of working" rules. (b) SEND-cohort progress analytics on SoloSight: are the SEND-register pupils actually engaging with the accessibility features designed for them? A pupil on the register who's never turned on a single accessibility feature is a live signal to the SENDCo that either the register is wrong or the pupil needs help finding the tools.
• Pupil Premium flag - used for the SLT-facing progress-gap monitoring that schools are already required to publish for Ofsted / OFSTED-facing reasons. SoloSight shows the SLT the PP-vs-non-PP working-grade delta per subject, and whether the gap is closing across the year. This is the standard PP-tracking pattern every UK secondary already does in some form; SoloCogs adds a subject-specific and topic-specific breakdown on top.
• EAL flag - used to measure whether the SoloCogs plain-English (jargon-simplified) content view is actually reaching the EAL pupils it's designed for. A teacher can see how much of their EAL cohort switches into plain-English mode, and whether that correlates with better knowledge-check performance. Also feeds general trend analysis for teachers (which cohorts are making the most progress on which topics).
• LAC flag - used for the SLT / DSL oversight of Looked After Children that schools are statutorily required to run (Virtual School Head reporting). SoloSight surfaces engagement and progress for LAC pupils to the DSL with the same tenant-isolation rules as safeguarding disclosures. Not visible to classroom teachers.
• Right to trim scope: any school can ask SoloCogs to skip any of these four fields for their tenant specifically; we then remove them from the wonde-sync mapping for that school and purge historical values from the mirror table. Request via hello@solocogs.co.uk with subject "MIS scope trim". A trimmed field disables the corresponding analytics for that school without affecting any pupil's access to core lessons.
• Build state as of 2026-07-08: the SEND conflict-review queue governance schema is applied (see sql/send_flag_governance.sql); the SLT-facing PP / EAL / LAC dashboards are in build ahead of the first paid school deployment. Fields are populated by the wonde-sync mirror now so the analytics have data to work against on day one.

2b. Raw payload archival

Each mirror row also stores the complete Wonde API response for that student / teacher / class as JSON (the raw_payload column). This gives us an audit trail of exactly what the MIS said at each sync, and lets us diagnose sync bugs without replaying the API call. The raw payload is treated as personal data for all retention and deletion purposes: when a mirror row is deleted (leaver, revocation, contract end - see §6), its raw_payload disappears with it. A school can request that raw payload archival be disabled for their tenant on the same "MIS scope trim" route.

3. Scopes we do NOT request

The following Wonde scopes are available but are not requested by SoloCogs. If a school inspects the scope list in their Wonde admin console they should see none of these enabled for us.

• Attendance - registers, marks, punctuality
• Behaviour - incidents, points, sanctions, exclusions
• Achievement / assessment - target grades, teacher assessments, exam entries (SoloCogs computes its own working grade from platform activity; we do not compare to the MIS's grade store)
• Timetable / lessons - period-level scheduling data
• Parent contact details - phone / email / address of parents from the MIS. SoloCogs only holds parent contact details that parents themselves enter on our platform.
• Detailed safeguarding records - CP status text, safeguarding narrative, incident notes. (The four flags in §2a are limits: the underlying case detail is never requested.)
• Medical records - conditions, medications, care plans
• Photos or biometric records

If any school specifically requires a scope beyond what we currently pull (for example, a MAT that wants us to inherit target grades), that becomes a bespoke conversation and is added to this page with the school's name before any data flows.

4. How the data flows

1. The school's MIS administrator authorises SoloCogs in their Wonde admin console, granting the four scopes above.
2. Our wonde-sync edge function (Supabase, London region) makes an authenticated API call to Wonde, pulls the school's current roster, and writes it into seven mirror tables in our database: wonde_schools, wonde_students, wonde_teachers, wonde_classes, wonde_class_students, wonde_class_teachers, and an audit trail in wonde_sync_log.
3. The mirror tables are refreshed automatically once per night (03:00 UK time) via pg_cron. Optional Wonde webhooks provide near-real-time joiner/leaver updates in between.
4. When a pupil first signs in, SoloCogs matches them against the mirror by UPN (or by email if the school has enabled Google/Microsoft SSO). If matched, their year group and school are populated automatically. If unmatched, they can still register normally without Wonde involvement.
5. All sync activity is logged: which school, which scope, how many rows added/updated/removed, and the runtime. The log is visible to Portsdown Tuition administrators and can be exported for the school on request.

5. Where the data lives

• Database: Supabase (PostgreSQL) in West Europe (London, eu-west-2). Same UK region as all other SoloCogs data.
• Encryption in transit: TLS 1.3 for both the Wonde API call and every internal service hop.
• Encryption at rest: AES-256 (Supabase-managed).
• Row-level security: every row in the mirror tables carries a tenant identifier. A teacher from School A cannot query rows belonging to School B, even at the raw database layer.
• Backups: point-in-time recovery (7 days) plus 30-day snapshots, encrypted at rest, same UK region.
• No data is copied to any third region. The Wonde API call itself terminates on UK infrastructure.

6. Retention

• While the school is a customer: mirror tables reflect the current MIS state; changes from the school's MIS overwrite them nightly.
• When a pupil leaves the school: Wonde flags the pupil as a leaver at the next sync; SoloCogs suspends the account (login blocked, no new activity) and deletes the mirror row within 30 days.
• When the school revokes SoloCogs' Wonde access: the next attempted sync fails with a scope-denied response; SoloCogs stops the sync job and deletes all mirror rows for that school within 30 days. Individual pupil accounts remain accessible to the pupil (their account has always been their own, not the school's) but no longer show school context.
• When the school ends its SoloCogs contract: the school-tier tenant is deleted 30 days after contract end; mirror tables purged; audit logs retained for the statutory 6-year period for financial records only.

7. Consent and school control

The school authorises SoloCogs in their own Wonde admin console. They can pause, resume, or revoke that authorisation at any time without needing to contact us. The school can also inspect the exact scope list SoloCogs has been granted, and see a live audit trail of every API call we make.

Parents are not asked to consent to MIS data flow separately, because the school (as controller) has the lawful basis for sharing pupil data with contracted educational suppliers under UK GDPR Article 6(1)(e) - public task. Schools remain responsible for including SoloCogs in their own pupil / parent privacy notices where their local policy requires this.

8. What happens if Wonde is not used

Wonde is optional. Schools that do not use Wonde, or that use a different aggregator, can add students via manual CSV upload from the SoloSight admin panel. No pupil is required to have an MIS record to use SoloCogs; individual family accounts (SoloCogs' B2C tier) do not touch Wonde at all.

9. Related documents

• Procurement Pack - the single-page evidence pack
• Sub-processor register - full list
• Privacy Policy
• DPIA
• GDPR & Data Residency one-pager