These categories reflect records visible in the current system. They are listed at a high level and do not expose private rows, secrets, credentials, private links, or internal database details.
Signup records
Examples: Parent or contact name; family or school name; audience type; location; time zone; email; optional phone number; signup source and idempotency data.
Purpose: Respond to interest, review family or school fit, prevent duplicate submissions, and route follow-up.
Handling: The public form is for parent, guardian, or school contact details. It should not include student names, ages, medical details, private learning notes, or other student-sensitive information.
Account records
Examples: Owner/admin, parent, and student account identifiers; email; display name; role; activation and reset status; MFA and trusted-device state.
Purpose: Create and protect authenticated access when an account is separately enabled.
Handling: Public signup alone does not create class access or a parent/student portal account; account setup is handled separately.
Household and guardian records
Examples: Household identifiers; guardian relationships; guardian consent state; administrative updates.
Purpose: Connect parents or guardians with eligible learners and portal access.
Handling: Household records are scoped to One Time and are not a public directory.
Learner records
Examples: Learner identifiers; student access state; guardian-linked access operations; learner content entitlements.
Purpose: Enable student-safe portal and classroom experiences when accounts are issued.
Handling: Learner records are used inside protected student and parent surfaces and should not be submitted through the public signup form.
Class and classroom records
Examples: Class series and occurrences; class access requests; fulfillment intents; classroom launch grants; attendance attempts and events; student questions and moderation actions; reminder preferences and intents.
Purpose: Operate class access, reminders, attendance, questions, and classroom support.
Handling: Provider-backed classroom actions remain bounded by configuration and approval; private class links are not published in public policy pages.
Progress and learning records
Examples: Attendance marks; reward events; content access and outcome records; portal read state.
Purpose: Show progress and support review, rewards, and learning continuity.
Handling: Progress records are scoped to the relevant household, learner, and authorized One Time staff surfaces.
Communications records
Examples: Email and WhatsApp delivery intents; communication threads; redacted communication history events; reply drafts; suppression status; consent events.
Purpose: Send service messages, optional reminders, support replies, and audit-safe communication history.
Handling: Unknown consent is not treated as opt-in, and suppression or unsubscribe signals take priority over outreach.
Support records
Examples: Support submissions; attachments; delivery attempts; status projections; support audit events.
Purpose: Provide subscriber support and track support status.
Handling: Support content may contain sensitive details and belongs in protected support flows, not in the public signup form.
Provider event records
Examples: Zoom, Vimeo, WhatsApp, Telegram, email, and Buffer readiness or event records; provider reference digests; webhook receipts; provider-off attempt records.
Purpose: Operate and audit integrations only when the relevant provider path is configured and approved.
Handling: Provider references are stored as redacted summaries, hashes, digests, ciphertext, or status records where the current system requires that pattern.
Payment and test-payment records
Examples: Billing provider account references; test-mode checkout sessions; subscription projections; invoice summaries; verified billing events; entitlement projections; billing audit records.
Purpose: Support billing readiness, test-mode checkout, reconciliation, and entitlement review.
Handling: Current capability evidence is fixture and Stripe test-mode only. This notice does not claim live paid checkout is available.
Security records
Examples: Session token hashes; CSRF token hashes; IP and user-agent hashes; rate-limit buckets; MFA challenges; auth audit events; lifecycle delivery records.
Purpose: Protect accounts, prevent abuse, and verify account lifecycle actions.
Handling: Security records are used to protect the service and are not exposed on public pages.
Operational records
Examples: Audit events; worker heartbeats; synthetic probe runs; restore drills; retention job status; import inventories and change ledgers.
Purpose: Run the service, verify readiness, diagnose failures, and maintain audit-safe operations.
Handling: Operational evidence should use counts, statuses, hashes, and redacted summaries instead of raw private rows.
