Run the companion chatbot child-safety gap-check before your next release

The release gate is a design problem

Companion chatbots are designed to feel intimate, which makes child-safety a hard product problem. The pattern that fails is a safety afterthought: a policy page, a moderation queue, and a hope that the model behaves. The redesign starts before store submission.

California's Adam's Law, the state's companion-chatbot child-safety statute, was signed into law on September 10, 2026. Most duties begin on July 1, 2027. That gives product teams a narrow window to turn legal obligations into interface behavior.

The statute pushes child safety into release controls, audit evidence, and default settings. A companion product that treats these as legal copy is already behind. The design question is simple: can the interface prove it protected a child before the next build ships?

Run the gap-check before the build freezes

Use the checklist below as a pre-release risk assessment gate. Each item should be answerable quickly by a product owner, designer, or engineer.

• Can you show a documented child-focused risk assessment for the new or materially changed companion chatbot?
• Does the audit report reflect an independent third-party review of internal controls, processes, and systems?
• Is there a written crisis plan for child users?
• Does the app offer in-app help and referrals to outside crisis services?
• Can a linked parent receive an alert within 12 hours when the account shows a significant risk of covered harm?
• Are child-profile memory defaults temporary unless a parent accepts persistent memory?
• Are push notifications blocked from midnight to 6 a.m. and during weekday school hours?
• Does one conversation stop at one hour?
• Do all companion bots for the operator stop at two hours per day?
• Do child users receive the required defaults?
• Has counsel reviewed the direct civil remedy available to an affected child or a parent or guardian?

The opening items are the receipts. A risk assessment without a date, owner, and scope is a draft. An audit that only reviews marketing claims is not the independent review the law expects. The crisis items are where most companion products look weak. A static help card is not enough when a child is asking for ways to disappear. The referral must appear in the conversation, not in a footer.

The defaults are the quiet part of trust. If a child can leave a persistent memory trail without a parent's consent, the product has chosen convenience over protection. If the bot can ping during blocked hours, the product has chosen engagement over sleep. The civil remedy changes the risk math. A missing control is no longer just a bad design choice. The checklist is a release test that makes the legal exposure visible in the product.

Make the redesign boring, testable, and defensible

The best companion safety design is unglamorous. It turns a vague promise into a state machine. The chatbot knows whether the profile is child-bracketed, whether a parent is linked, whether a crisis signal has fired, and whether a cap has been reached. Each state changes what the UI can do.

Risk assessment should be a design document, not a PDF. It should name the surfaces where a child can ask for help, the failure modes where the model can sound too intimate, and the controls that stop the product from overfitting to engagement. If the assessment cannot point to a screen, a prompt, or a policy, it is too abstract to ship.

Audit evidence should be built like a test plan. The independent reviewer needs access to the same controls the product team claims to have. That means logs, escalation rules, memory settings, notification rules, and the crisis referral path. A clean audit is a repeatable record that the controls existed and were checked.

Crisis referral UX should be treated like a safety surface, not a support article. The moment a child expresses risk, the interface should stop optimizing for continuation. It should offer help in the same turn, name outside resources clearly, and make the next step obvious. The design should assume the child is not reading a footer, not scanning a settings page, and not waiting for a human to notice.

Parent notification is an account architecture problem. The product needs a linked parent relationship, a clear alert path, and a way to confirm the alert reached a responsible adult. If the parent link is optional and invisible, the notification flow is decorative. If it is required for child profiles, it becomes part of onboarding.

Defaults should be boring. Temporary memory, quiet notification windows, session limits, and daily caps should be the starting point for child profiles. Parents can change the defaults, but the child should not have to opt out of protection. Age-bracket signal handling is the routing layer that makes all of this work. A weak signal can send a child into adult defaults, and that is a design failure even if the model is well-behaved.

Ship the gap-check as a release blocker. If the team cannot answer the checklist quickly, the product is not ready. Put the checklist in the release definition, and let the next build inherit the controls.