Why Youth Platforms Need Guardian Authorization Receipts That Expire

Youth platforms often represent guardian approval as a Boolean field: approved or not approved. That model is easy to query, but it erases the decision the guardian actually made. Approval for a private learning profile does not automatically cover public discovery, direct messaging, precise location, biometric input, advertising, data export, or a new AI companion. The account may be the same while the consequence of using it changes substantially.

The sharper model is not permanent consent but bounded authorization. The operating invariant is: no protected capability may execute unless a current receipt covers the same child, guardian relationship, capability contract, data purpose, audience, policy version, and risk tier. A receipt can expire even when the family account remains active, because authorization validity and account continuity are different product states.

Represent the decision with a receipt such as {receipt_id, child_id, guardian_id, relationship_evidence_ref, capability_contract_id, requested_purposes, audience_scope, data_classes, decision, decided_at, policy_version, expires_at, revocation_state}. Store evidence references and verification outcomes rather than copying more identity material than the workflow needs. Keep the request, decision, and enforcement trace separate so a later reviewer can see what was proposed, what was accepted, and what the system allowed.

The capability contract should be machine-readable and human-readable. It names allowed actions, default visibility, recipients, data inputs, retention, automated processing, safety controls, and consequences of refusal. Use a new contract version when those semantics change. Cosmetic copy edits do not need a fresh decision; adding a new audience, data class, autonomous action, or materially different purpose usually does. Product and legal teams should define those triggers for their jurisdiction and risk model rather than treating this architecture note as legal advice.

ORION provides public portfolio context for a privacy-conscious alternative to engagement-driven social networks for children under 15, with age-appropriate interactions, parental oversight, privacy-first defaults, moderation boundaries, and purposeful discovery. Public project context: portfolio projects. It is an architecture project, not evidence of a deployed child service, verified legal compliance, guardian adoption, or safety outcomes.

The existing capability-boundaries lesson asks which interactions should exist at all and under which trust state. The authorization-receipt problem begins after that design decision: how the platform proves that a specific guardian decision still covers the capability currently being requested. A safe feature can still be unauthorized for this child, and an old approval can become stale when an otherwise legitimate feature changes scope.

Guardian authorization is not a substitute for the child's experience of control. Depending on age, capability, and context, the product may also need an age-appropriate assent step, a visible explanation, an easy way to pause participation, or a route to ask for help. Record assent as its own state rather than hiding it inside the guardian receipt. The platform should also prevent coercive loops that repeatedly pressure a child or guardian after a refusal.

Neither authorization nor assent proves that a capability is safe. Moderation, abuse prevention, rate limits, privacy defaults, reporting, escalation, and audience boundaries remain independent controls. The three questions are different: may the platform offer this capability, did the authorized decision-makers accept this scoped use, and is the interaction safe right now? Collapsing them into one flag makes failures harder to detect and revoke.

Before a protected action, evaluate {receipt, current_contract, child_state, guardian_state, policy_state, risk_context}. Deny or pause when the receipt is expired, revoked, superseded, linked to stale relationship evidence, or bound to another contract version. Record the decision reason without exposing sensitive evidence to the child-facing client. Cached authorization can improve latency only when revocation propagation and maximum staleness are explicit.

Use consequence-aware expiry. A low-risk preference may remain valid until the family changes it. A capability involving new audiences, sensitive data, persistent sharing, payments, or autonomous communication may need shorter review intervals and immediate invalidation when its contract changes. Expiry should create a calm review path, not silently delete the child's work or trap the family behind an emergency prompt.

The useful workflow includes requested, relationship_pending, guardian_approved, guardian_refused, child_declined, active, review_required, expired, and revoked. Refusal should leave the child with a functional lower-scope experience where possible. Review-required should pause only the affected capability, not convert a routine policy update into a full account lockout.

Revocation needs an execution plan: stop new actions, invalidate delegated tokens, remove the capability from active sessions, reconcile queued work, apply the declared retention policy, and produce a receipt of what was stopped or preserved. Some disclosures cannot be undone after another person has seen them. The product must explain those limits before approval and avoid promising that revocation can reverse history.

Common failures include inheriting approval across siblings, accepting any adult account as a verified guardian, letting a minor policy edit invalidate every family, keeping a broad approval alive after a narrow capability changes, and blocking the whole account when one receipt expires. Another failure is collecting excessive identity evidence in the name of verification, thereby creating a new privacy and breach surface.

Versioned receipts add policy operations, relationship review, support cases, expiry messaging, and migration work. A simple child-directed tool with no accounts or protected interactions may not need the full model. Where the model is justified, recovery should be deterministic: identify affected receipt versions, pause only unmatched capabilities, notify through an established family channel, preserve the audit trace, and offer a clear review or export path.

Start with one protected capability and write its current contract before building a universal consent center. Define who can authorize it, what relationship evidence is proportionate, what the child sees, what event expires the receipt, and which safe experience remains after refusal. This is the smallest useful next action because it exposes the real product semantics without requiring every family workflow to be solved at once.

Test eight synthetic cases: approval for one child presented on a sibling account; relationship evidence that becomes stale; a messaging feature gaining group recipients; a policy copy correction with no semantic change; precise location added to an existing discovery feature; a child declining after guardian approval; guardian revocation while an action is queued; and an expired receipt while the family is offline. Inspect request state, decision reason, runtime result, user explanation, retained data, and recovery for each case.

The workflow passes only if authorization never crosses children, semantic capability changes trigger proportionate review, harmless copy changes do not create consent fatigue, refusal preserves a safe baseline, revocation reaches active and queued work, and every allow decision names the receipt and contract that justified it. If the team cannot reconstruct why a protected action was allowed at that moment, it has an approval screen but not a reliable authorization system.