> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # COPPA and minor contacts posture > The tenant-owned controls for programs that may involve children under 13: flagging minor contacts, capturing verifiable parental consent, tightening retention and deletion, and running the SB 243 minor reminder on AI sessions # COPPA and minor contacts posture The Children's Online Privacy Protection Act (COPPA) sets the rules for how operators of child-directed online services collect, use, and retain personal information from children under 13. This page maps those rules onto the controls Devotel Orbit already ships, so a tenant whose program touches a minor audience can assemble its posture from tenant-owned switches. This page describes Orbit's platform controls. It is **not legal advice.** Whether COPPA applies to your program, and what verifiable parental consent requires for your use case, are questions for qualified counsel. *** ## 1. Posture frame: Orbit is the conduit COPPA binds the **operator** of a website or online service directed at children, or an operator with actual knowledge that it collects personal information from a child. In an Orbit workspace that operator is **you, the tenant**: you design the program, write the message content, and decide who enters the audience. Orbit is the conduit and system of record that carries and stores the traffic on your instructions. Two consequences follow, and both shape every control on this page: * **Scope is your determination.** Child-directedness and actual knowledge of child participants are questions you answer with counsel. The platform does not classify your audience and does not gate it. * **Every control below is tenant-owned.** Each one is a setting you configure, and each one defaults to off or open until you set it. There is no platform-mandated COPPA gate; the wider model is described in [the posture overview](/compliance/posture-overview). *** ## 2. Identifying minors: you flag, the platform never infers COPPA work starts from knowing which of your contacts are children. In Orbit that knowledge is a flag you set, never a guess the platform makes. * **Flag the contact explicitly.** The contact record carries a boolean minor flag, `is_minor`. Set it wherever your intake knows the contact is under 13 (a program roster, an age question at sign-up, an account structure that marks dependents), and keep it current as contacts age past 13 under your policy. * **The SB 243 reminder keys off the flag.** The California SB 243 minor reminder fires only for contacts you have explicitly flagged (see [AI disclosure settings](/compliance/ai-disclosure-settings)); an unflagged contact receives no minor treatment anywhere. * **Minor status is never inferred.** Orbit does not derive minor status from a birth date or any other signal, and a contact with no flag is treated as an adult even when other data on the record might suggest otherwise (see [EU AI Act](/compliance/eu-ai-act)). If you store a birth date on contacts, it is your data for your own logic; the platform's behavior does not change with it. The never-infer design protects both sides of the conduit. You keep authority over who is treated as a minor in your program, and the platform makes no claim about a contact's age that it cannot defend. *** ## 3. Parental consent mechanics COPPA requires **verifiable parental consent** before personal information is collected from a child under 13. Orbit's consent surfaces give you the mechanics to script and evidence that consent; the consent decision itself is yours. A working pattern assembled from the existing surfaces: 1. **Capture the parent, not the child, as the consenting party.** Store the attesting parent's E.164 number (or email address) as the identifier on the consent record; the child stays the audience record the consent applies to. 2. **Record the relationship.** Use contact custom fields on the child's record for the relationship-to-minor metadata your counsel wants: parent or guardian, how authority was established, and when. 3. **Run the confirmation round trip to the parent's channel.** The [double opt-in](/compliance/double-opt-in) flow gives you a verified round trip on the parent's own number or inbox. A confirmation that only the child's device could complete is not parental consent. 4. **Persist the receipt.** Record the grant through [consent management](/compliance/consent-management) so the channel and scope are explicit, and let the resulting receipt enter the [integrity chain](/compliance/consent-receipt-integrity) so an auditor can verify it was not altered after the fact. Keep the consent scope narrower than the program: name the channels and purposes the parent approved, and let the same enforcement machinery that enforces any other consent in the workspace enforce this one. *** ## 4. Data-retention minimization COPPA's minimization obligation (keep only as long as reasonably necessary, then delete with reasonable measures) maps onto two existing surfaces: the per-domain retention policy for the standing posture, and DSAR erasure for the per-contact event. * **Set shorter windows for the standing posture.** The [per-domain data retention policy](/compliance/data-retention-policy) lets you enable message-body redaction and closed-conversation hard-delete with day windows you choose; a minor-segmented program is the case for the short end of the allowed ranges. Two floors are platform-held and cannot be lowered: audit evidence is never purged younger than 365 days, and conversation deletion has a 30-day floor. Plan the minor-data posture above those floors. * **Handle deletion requests through DSAR.** A parent's deletion request for a child's record runs through the standard [DSAR erasure workflow](/compliance/dsar); it is contact-scoped and independent of the age-based sweeps. The DSAR verification tiers, up to manual review of out-of-band evidence such as a notarised attestation, are where you record that the requester had authority over the child's data. The `education` consumer category on DSAR requests covers FERPA-class data where your disclosure posture needs it. * **The residency pin applies as-is.** The [data residency](/compliance/data-residency-overview) pin you set for the workspace governs where minor-flagged records live; there is no separate minor store to pin. *** ## 5. Marketing to a minor-segmented audience If you send marketing to contacts you flag as minors, harden the per-channel controls you already have before the first send: * **Quiet hours:** set the quiet-hours window for the minor segment wider than your default, so no program traffic reaches minors outside the hours your counsel approves. * **Frequency caps:** cap messages per period for the minor segment at the strictest level the program needs; a child audience rarely needs more than a handful of touches per month. * **DNC and suppression:** apply your suppression and do-not-call scrubbing without exception for the minor segment, and treat a parent's revocation as ending marketing traffic to both the parent and the child. Industry self-regulation points the same way. The CTIA's messaging principles and CARU's guidelines for advertising to children both treat minor audiences as requiring stricter minimization and restraint than adult audiences; use them as the floor your counsel builds on, not the ceiling. This section summarizes industry guidance for orientation. It is not legal advice and not a statement of your obligations; confirm your minor-marketing posture with qualified counsel. *** ## 6. AI-agent interactions with minors When an AI voice or chat agent may talk to a minor, two settings and one evidence surface make up the posture: * `ca_minor_reminder_enabled` turns on the California SB 243 reminder: during a session with a contact you have flagged as a minor, the agent repeats a fixed "you are talking to an AI; consider taking a break" reminder on a cadence you set. * `minor_break_reminder_minutes` sets that cadence, 1 to 1440 minutes. The reminder wording is fixed regulator-mandated copy; only the interval is yours. * The [AI turn audit](/compliance/ai-turn-audit) is your evidence record: it captures the turns of each AI session, including minor-flagged sessions, so you can show when the reminder fired and what the agent said. Configure both settings on the [AI disclosure settings](/compliance/ai-disclosure-settings) surface, and read the [EU AI Act](/compliance/eu-ai-act) page for the wider disclosure regime that stacks on top when your traffic touches other jurisdictions. *** ## 7. FAQ ### Does Orbit detect minors automatically? No. Minor status is the explicit per-contact `is_minor` flag and nothing else. The platform never infers it from a birth date, a name, a voice, or any other signal, and an unflagged contact is treated as an adult. ### What evidence does a parental-consent record need? At minimum: the identity of the consenting parent (their E.164 or email), the parent's relationship to the child, the scope approved (channels and purposes), the timestamp, and the verification method used. A consent receipt in the integrity chain carries that evidence in a form an auditor can verify after the fact. ### How does a COPPA deletion request differ from a standard DSAR? The workflow is the same contact-scoped erasure flow; the differences are who may file and how you verify them. Expect the requester to be a parent acting for the child, verify their authority with a higher DSAR verification tier (manual review of out-of-band evidence), and scope the erasure to include the consent records and custom fields the standard flow already covers. The platform's audit-retention floor still applies: audit evidence younger than 365 days is not purged. *** ## Related The tenant-owned surface behind the SB 243 minor reminder and the disclosure notices. Record parental consent with explicit channel and scope. The per-domain windows to tighten for a minor-segmented program. The erasure workflow a parental deletion request runs through. The never-infer design and the wider AI-disclosure regime. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.