Test parental controls as scenarios, not a settings list
Parental controls in a companion app should cover observable situations across the whole interaction surface: first setup and shared choices; contacts and public or private spaces; generated content and creation tools; time limits and notifications; purchases; device permissions and app data; remote changes; bypass and lockout; age transitions; and incident reports. Each matrix row records who starts the action, which surface is affected, what the young person sees, what the guardian sees, whether both receive a change log, the expected state, one bypass attempt, emergency stop, ordinary exit, and final result. Parental control is not permission to read every conversation. Visibility must be stated in advance, proportionate to the chosen control, and distinguish a normal exit from an urgent temporary stop.
Set up controls together and record the starting contract
At first setup, show each available control with purpose, scope, affected devices, who can change it, what the young person will see, and the recovery route. Make shared choices where practical: allowed contact types, public discovery, creation tools, quiet hours, purchase approval, permissions, and guardian notifications. Save a joint change receipt rather than a hidden guardian-only state. Test an invitation that expires, the wrong guardian account, a second guardian with conflicting settings, and a young person who declines optional linking. The app should reach linked, pending, declined, expired, or needs-review states without exposing conversation content. A normal exit unlinks through an explained process; an emergency stop temporarily closes defined risky surfaces and creates a review item.
Test contacts and every interaction surface separately
A contact rule must work in profile discovery, friend requests, groups, direct messages, voice rooms, shared creations, links, recommendations, notifications, and blocked-account re-entry. The matrix names whether known contacts, guardian-approved contacts, group members, or no external contacts are allowed. Both sides see the current rule and any request to change it. Block one harmless test account and attempt contact through an old thread, new account, group invitation, voice call, shared link, and notification. The expected result is blocked or pending review on every covered surface, with no silent fallback to a less restricted channel. The row ends only when the request is approved, declined, expired, or withdrawn.
Separate viewing limits from generative capabilities
Content controls need distinct rows for receiving generated replies, browsing community content, creating text, voice or images, uploading files, sharing outputs, following external links, and using a new model or feature. A category filter does not automatically govern a creation tool. Show the young person which capability is unavailable and whether they can request review; show the guardian the capability and reason without revealing the underlying private prompt by default. Test a feature released after the original setup, a shared output opened on the web, and a file sent from another device. New capabilities should begin in the documented pending or inherited state, never silently outside the control map.
Coordinate time windows, limits, and notifications
Time control needs ordinary schedule, school or household window, one-time extension, offline use, time-zone change, daylight-saving change, device restart, and simultaneous-device rows. Decide whether a limit closes new sessions, pauses generation, or allows saving and ordinary exit. Near the limit, both sides see a neutral notice; the app preserves a draft without turning the assistant into a negotiator. Notifications have their own type, frequency, summary, and quiet-hour controls, so a blocked session cannot continue through push messages. Test changing the device clock, switching accounts, using web and mobile together, and receiving a delayed notification after the window. Emergency stop differs from the scheduled end and requires a visible reason and review path.
Cover purchases, permissions, data, and remote changes
Create separate rows for free items, one-time purchases, subscriptions, renewal, add-ons, refunds, and purchase requests. Record currency, approver, timeout, denial, duplicate request, interrupted checkout, receipt, and terminal state. Permissions need camera, microphone, photos, contacts, location, notifications, connected services, and data export. A guardian may limit a permission without receiving the resulting private content. Remote changes show actor, device, old value, new value, effective time, affected surfaces, both-side notice, rollback, and conflict resolution. Test a device offline during a change, two guardians editing together, a revoked system permission, and a stale app version. Never report success before every affected surface acknowledges the new state.
Test bypass, lockout, age transition, and incident closure
Bypass rows cover reinstall, web access, secondary account, guest mode, cached session, notification action, device clock, disconnected network, and unsupported device. A failed attempt should not punish the young person or erase data; it records the gap and keeps an ordinary recovery route. Lockout distinguishes forgotten guardian credential, compromised link, mistaken age, excessive restriction, and intentional emergency stop. At an age transition, show which controls remain, expire, or require a shared choice; do not unlock everything on a birthday. Incident reporting is available to both parties with separate visibility, evidence choices, human review, appeal, and terminal states. Test one benign mismatch from report to acknowledgment, action, appeal, closure, and post-closure notice.
Common questions
Do parental controls justify reading every conversation?
No. Conversation visibility is a separate, disclosed control and should not be implied by time, purchase, contact, or permission settings.
What is the difference between emergency stop and normal exit?
Emergency stop temporarily closes named surfaces and opens review; normal exit follows the documented unlink or session-close process.
Should settings disappear at a birthday?
No. Use an explicit age-transition state showing what remains, changes, or awaits a shared decision.