The social-confidence practice space, and the deliberate rule that a parent cannot read what a child says inside it.
Status: Live / built, with one significant caveat — this feature was removed from the codebase during a pilot suspension and later reinstated. See "Removal and Reinstatement History" below; a reviewer or school should be told this history, not just the current state.
What It Is
A universal, everyday feature giving every child access to a private, voice-first practice space for social situations — not a clinical or referral-based "programme." It sits on the child's page in the same position as the curiosity cards, i.e. presented as an ordinary part of the app, not a stigmatised add-on.
Core Design Philosophy
See Mission and Philosophy for the full reasoning. In short: social confidence is trained through practice, not built through information. Because of this, the feature is deliberately not targeted or referral-gated:
Universal access for every child, no labelling or referral process
Confident children are expected and welcomed to use it too — this is treated as a feature, not a leak, because it is what destigmatises the space for children who need it more
Framed to schools as: screen time here enables human connection rather than replacing it
Interface
Orb-based, voice-first interface — non-avatar, neutral, private, described in design notes as calm and warm rather than character-like
Age-calibrated conversation design operating across three layers: rehearsed response, inner dialogue, and perspective-taking through drama-style role-play — tested informally across ages 5, 8, and 15 and reported to "feel right" for each age band during internal testing
Privacy Model Within the Feature
This is the most carefully engineered part of the feature, given the sensitivity of what children may disclose:
Confidentiality is honest, not absolute. Children are told the space is private, but not told it is unconditionally confidential — because it is not (wellbeing flagging exists, see below).
Parents see session counts, not content. A parent can see that their child used the feature and how often, but not what was discussed.
Wellbeing flagging uses generalised messaging. If Aria detects a concern, a flag reaches the parent (and, for school accounts, the teacher) using a fixed, generalised message — not a quote or paraphrase of what the child actually said. This was deliberately tightened during development: an earlier design surfaced more direct context, which was assessed as risking a child feeling their private words had been reproduced to an adult even in a genuine safety situation. The resolved approach: a flag with enough context to prompt action ("Aria flagged a concern... please check in with your child") without quoting the child.
Two-layer technical enforcement, verified by testing: the sanitiser strips any child-quoted content from the flag before storage, and the parent-facing display separately verified to show only the generalised message — so even if Aria's own output slipped and included child words, the stored/displayed flag still would not.
A one-off migration was run to scrub any pre-existing wellbeing flags (from early testing) that predated the sanitiser, so the guarantee holds retroactively as well as going forward.
Parent Controls (Family Accounts) — Yes, This Control Exists
A parent can turn Social Resilience off at any time. Whether such a control existed was an open question in an earlier version of this document; it is now answered from the code, and the answer is unambiguous. (For a new child profile the space starts open — see the default below — so in practice this control is used to close it.)
Per-child, parent-only toggle.setSocialEnabled() flips the flag for one child (lib/accounts.js:298-307), exposed as POST /api/children/:childId/social-enabled (lib/auth.js:476-491).
It is genuinely parent-only. The route refuses the request outright once a child PIN has narrowed the session — a child cannot switch their own access on, even from inside their own profile (lib/auth.js:477-479). The same rule applies to profile creation, PIN reset and notes: profile management stays on the parent side of the boundary.
Scoped to the family. The lookup is scoped by family_id, so one family can never toggle another family's child even by guessing an ID (lib/accounts.js:299-302).
The flag is stored encrypted, inside the child's profile blob under the family DEK — reading or writing it requires the parent's unlocked key (lib/accounts.js:303-305).
Enforced server-side on every single turn, not just in the UI. The chat endpoint re-reads the flag and returns 403 if it is off (index.js:861-864), and the transcript endpoint is gated the same way. The code comment is explicit that this "guards the API even if the button were somehow reached without being enabled." Turning it off genuinely cuts access; it does not merely hide a button.
Surfaced in the parent dashboard as an on/off control alongside a usage summary (public/dashboard.html:1185-1189, posting at public/dashboard.html:1286).
The Director tab has an exact twin of this control (lib/accounts.js:317-326, lib/auth.js:498-513, enforced at index.js:984). See Director Tab (AI Literacy).
The default is ON for new child profiles (changed 2026-08-11). A newly created child profile is written with socialEnabled: true (lib/accounts.jscreateChild), so the space is open from the moment the profile exists and the parent's toggle is a way to close it rather than a gate they must first unlock.
Two properties of that change matter and are covered by tests (test/social-default.test.js):
It is forward-only. The flag is written into the stored profile at creation, not inferred at read time — every reader still treats an absent flag as off (lib/auth.js:463, index.js:862). Child profiles that already existed on 2026-08-11 were not retroactively switched on; they stay exactly as their parent last left them. Turning a private child space on for live families without them asking would be a decision made on their behalf, not a default.
The school side deliberately did not change. A new classroom student still starts with the space closed until a teacher opens it (lib/school-accounts.js:381-395). A classroom's default is the school's safeguarding call — the parent disclaimer explicitly hands that decision to the school — so changing it is a school-governance question, not a code default. The two domains now differ on purpose.
Director remains opt-in on both sides.
On the word "universal". This document and Mission and Philosophy describe Social Resilience as universal — available to every child, not just those flagged with an identified need, with no labelling and no referral process. That remains the design intent and the reason the feature is shaped the way it is. Three points of precision, so the word isn't read as a claim about configuration:
For a new family child profile it is literally true from creation onward — the space is open the moment the profile exists, with no adult step required first.
It was not applied retroactively. Child profiles created before 11 Aug 2026 keep whatever setting they had; existing families were not switched on without asking.
School accounts are genuinely teacher-opt-in, and deliberately so. A classroom's default is the school's own safeguarding decision, not Synapse's — the parent disclaimer explicitly hands that call to the school. "Universal" describes what the product offers every child, not a setting Synapse imposes on a classroom.
Teacher Controls (School Accounts)
"Home access" is not a thing the software controls. This document previously said a teacher can enable home access per child, i.e. extend the feature beyond school hours or context. Corrected against the code (Aug 2026): no home-access, out-of-hours, or location control exists anywhere in Synapse, and therefore nothing restricts access that a teacher could relax.
Searched home_access, homeAccess, "home access", allowHome across the entire server and every front-end page — zero matches.
What is actually true: the student PIN login page is a public URL (public/school-student-login.html, route lib/auth.js:1475) reachable from any internet connection at any hour. A school-provisioned child already has unrestricted access from home, by default, and a teacher cannot turn that off.
The per-student teacher toggle that does exist (lib/school-accounts.js:381-395) controls whether Social Resilience is available to that student at all — not where or when. Turning it off closes the space everywhere, including at school; turning it on opens it everywhere, including at home. There is no middle setting.
Practical effect for a school: access location and timing are governed by the school's own device and supervision policy, not by any Synapse control. A school that assumes it can confine this feature to school hours should be told plainly that it cannot. See Synapse Public Knowledge Architecture v0.1 §6, where the same claim was load-bearing for the home-access commercial rule and has been corrected there too.
Teacher dashboard surfaces peer-connection opportunities: small groups suggested based on shared interests detected across sessions, and flags children showing no peer connections over time
Teachers can log social-facilitation interactions they take in response — creating a longitudinal evidence base following the same "AI notices, teacher acts, outcome recorded" discipline used elsewhere (see the MERIT pattern in Teacher Features (School Accounts))
Key Arguments Used With Schools
Screen time here enables human connection rather than substituting for it
Universal design eliminates stigma
Socially adept/confident children benefit from it too, not just children with identified needs
Home access creates natural parent-child conversation without a clinical framing being imposed
Removal and Reinstatement History
During a pilot suspension in July 2026 (see Pilot Programme and Adversarial Review Process), Social Resilience — along with the Director tab, peer matching, and teacher-to-student messaging — was permanently deleted from source code, not merely disabled behind a flag. This is an important factual point: there was no config toggle to flip back. The deletion also purged the associated encrypted data from both the live database and backups (cryptographically unrecoverable, consistent with the encryption design — see Security Architecture).
The features were later reinstated via git revert and manual merge-conflict resolution against several weeks of intervening commits, with teacher toggles added for related features (PAT, peer matching) that had not originally had them. Reinstatement restored the code, not historical data — the features came back working but empty of prior history.
A critic finding during the adversarial review (see Adversarial Review Process) explicitly challenged that these features had been described as "removed" while their designs remained on file, arguing the only real guarantee they'd stay removed was the developer's word — "insufficient governance." The developer's stated response was not to dispute this but to treat it as a genuine gap, addressed primarily by the school-ownership model (see Governance Model) rather than by disputing the criticism.