Scribble Works account + relationship model

Founder decision 2026-09-02 18:15 ET: AMEND. D2 full birthday; D3 lead may promote other adults to lead; D4 agreed, teacher/classroom paradigm planned into the schema, not actioned; D0, D1, D5, D6, D7, D8 at Ray's default. Counsel sourcing done (shortlist on [[2026-09-02-counsel-shortlist]]); OUTREACH PARKED by founder 18:30 ET until "ready for counsel"; 18:33 ET ruling 30: counsel is NOT a gate, v2 builds as planned with the D5 diligence posture (D0).

Founder, 2026-09-02 11:08 ET: "a lead parent account, who can add kids to their household. They can also add two adult family members (a spouse and a grandparent)… the teacher, their classroom of kids, which school system they are part of. There should be a way for parents and teachers or parents and schools to link their kids profiles… Should that be reviewed by the growth and legal angles as well as the technical?" Yes, all three, before Accounts v2 starts. Accounts v1 (household + identities + magic link) is in flight and not re-opened here.

Founder ruling, 11:22 ET (verbatim): "So start with parents/households and we can expand to teachers/schools. We will have more legal to cover and we can plan it out state by state. Teachers may use this independently, but we would treat them as a household for now." Applied throughout: the school phase is separate and later; teachers are households meanwhile (§1a); school law moves to an appendix plan, not a v2 blocker; the decisions are limited to v2. Not legal advice; [counsel] marks what a lawyer decides.

1. Entities and relationships

The structural rule everything hangs on

Rows marked (v3) are designed now and built later, so v2's schema is not rewritten when the school phase arrives.

Every child record is created by a parent and owned by a household. A teacher never creates one. In v3 a teacher creates an empty seat ("Seat 12"); a parent redeems a join link and attaches her own child profile to it. That rule does most of the legal work in the Children's Online Privacy Protection Act (COPPA) analysis in §4, because a child's information is always collected from a parent under their own account and we never hold a school roster. It does most of the growth work in §3 too, because redeeming a link requires a parent account.

The consent record

Scopes are enumerated, each separately grantable and revocable: child_profile (we may hold this profile at all) · personalized_generation (fields may reach the generation path) · classroom_link:<id> (v3: a named teacher in a named classroom sees the matrix fields until that school year ends) · progress_share:<id> (that teacher also sees skill states, not artifacts) · ugc_theme_log (a theme stripped of personal data may enter the marketplace pipeline; ruling 21, anonymous, never the name).

Each row stores who (adult id + identity used), what (scope + policy_version), when, how verified (magic_link_verified_email, card_charge_v1, …), evidence (an immutable pointer: link, charge, or invite id), and revocation. Revoking writes the row and an event and ends the dependent Enrollment in one transaction; every dependent read checks revoked_at IS NULL AND (expires_at IS NULL OR expires_at > now).

erDiagram
    HOUSEHOLD ||--|{ ADULT : "1-3, at least one lead"
    ADULT ||--o{ IDENTITY : "signs in with"
    HOUSEHOLD ||--o{ CHILD_PROFILE : owns
    ADULT ||--o{ CONSENT : grants
    CHILD_PROFILE ||--o{ CONSENT : "is subject of"
    CONSENT ||--|{ CONSENT_EVENT : "audited by"
    ORGANIZATION ||--o{ ORGANIZATION : "district contains school"
    ORGANIZATION ||--o{ ORG_MEMBERSHIP : has
    ADULT ||--o{ ORG_MEMBERSHIP : "is teacher via"
    ORGANIZATION ||--o{ CLASSROOM : hosts
    ADULT ||--o{ CLASSROOM : "owns as teacher"
    CLASSROOM ||--o{ SEAT : "has empty"
    CLASSROOM ||--o{ LINK_INVITE : issues
    SEAT ||--o| ENROLLMENT : "filled by"
    CHILD_PROFILE ||--o{ ENROLLMENT : "linked through"
    CONSENT ||--o| ENROLLMENT : authorizes

    HOUSEHOLD { text id PK
                text plan_tier }
    ADULT { text id PK
            text household_id FK
            text role "lead|adult" }
    IDENTITY { text id PK
               text adult_id FK
               text provider "email_magic|google|apple|sms|password"
               text provider_subject
               int verified_at }
    CHILD_PROFILE { text id PK
                    text household_id FK
                    text first_name_or_nickname
                    text birth_date
                    text interests_json
                    text focus_topics_json }
    ORGANIZATION { text id PK
                   text type "school|district"
                   text parent_org_id FK
                   text verified_domain }
    ORG_MEMBERSHIP { text adult_id FK
                     text org_id FK
                     text role "teacher|admin"
                     int verified_at }
    CLASSROOM { text id PK
                text org_id FK
                text owner_adult_id FK
                text school_year }
    SEAT { text id PK
           text classroom_id FK
           text label }
    ENROLLMENT { text id PK
                 text seat_id FK
                 text child_id FK
                 text consent_id FK
                 text status "invited|active|ended" }
    CONSENT { text id PK
              text child_id FK
              text granting_adult_id FK
              text scope
              text method
              text evidence_ref
              int granted_at
              int expires_at
              int revoked_at }
    CONSENT_EVENT { text id PK
                    text consent_id FK
                    text event
                    int at }

What each actor can see of a child

"Break-glass" is a logged, reason-required path used only on a support ticket the household itself opened. Enforced at the query layer, not the user interface: every read takes (actor, child_id) and resolves to a field mask. No code path returns a child row unmasked to a non-household actor.

Deletion and retention

Deletion is real, not a flag (charter §6). A district's contractual "delete on request" must run without touching the parent's household: its unit is enrollments and org-scoped copies, never the child profile.

1a. Teachers as households — the interim posture

Founder ruling: "Teachers may use this independently, but we would treat them as a household for now." Concretely, until v3:

• A teacher signs up exactly like a parent — one household, same terms, same billing, same caps. No teacher role, no organization, no classroom, no school relationship exists in the product.
• What she gets: shelf, ready-made playsets, planner, customize, and printing for a class, which the terms already allow (ruling 23).
• What we deliberately do NOT do: no class roster upload · no child profile created by anyone but a parent for their own child · no data received from a school or district · no per-student progress held on a school's behalf · no claim in copy or terms that we are a school official or a district's vendor. A teacher may create profiles for her own children; she may not create them for her students.
• Why this looks safe, at the confidence the evidence supports. FERPA reaches a vendor only through a school's disclosure of education records (34 CFR §99.31(a)(1)), and we receive none. On the state side the hooks differ more than a summary suggests: California is conjunctive and is the clean escape — actual knowledge and used primarily for K-12 and designed and marketed for K-12 (§22584(a)(7), quoted in the companion). Illinois hooks on a written agreement with a school and New York on a contract with an educational agency, neither of which exists. Texas we have not read at the trigger section (§32.151); it is restated from the companion, not verified. Forty-five states are unread. This is "what we checked," not a national conclusion, and [counsel] should confirm it, because this section describes what real teachers do with the real product this quarter.
• And Florida, the home state, is the one that does not fit. Fla. Stat. §1006.1494(1)(e) is disjunctive: an operator is one with actual knowledge the service "is used primarily for K-12 school purposes, or the site, service, or application was designed and marketed for K-12 school purposes." School-facing marketing alone can trigger it, with no actual knowledge and no school relationship. That collides with §3, whose two cheap tests are school-facing marketing (proposed, not scheduled — nothing runs until this is answered): a join-code sheet printed for a teacher's class, and a landing page reading "Ms. Alvarez is using Scribble Works with Room 12." This is a live question, not a v3 one, and Ray does not have the answer. It is the first thing to put in front of counsel alongside the "directed to children" read, and until it comes back, Ray's default is to run the §3 tests as a parent offer (the sheet says "ask your child's teacher," the landing page names no classroom) rather than as a school offer.
• The hole in it, named rather than papered over. In v2 there is no teacher role and no seat, so nothing in the schema distinguishes a teacher's own two children from her twenty-five students. A teacher-as-household can type twenty-five first names, birth dates and interest lists into child profiles and the product will accept every one: the roster this page promises never to hold, arriving through the front door. In v2 the parent-owned rule is contractual, not technical. Ray's mitigation, to build with v2: a child-per-household cap that bites at eight profiles, where the over-cap prompt asks "are you setting this up for a class?" and routes to a waitlist instead of silently raising the limit. That turns an invisible compliance risk into a visible demand signal for v3.
• Tells that v3 is earned (any two): a teacher asks to add her students rather than her own kids; asks for a class-set print; a school address asks about a purchase order; anyone sends a data privacy agreement, vendor packet or security questionnaire; the §3 test clears its bar.

2. Auth roadmap

v1 (now): magic link via Resend, so email is verified by construction, which is what ruling 25 needed for feedback screening. The identities table exists from day one so nothing forks later. v2: Google and Apple as Identity rows keyed on provider subject, matched to an existing adult by verified email; an Apple private-relay address is itself the identity. Later: SMS as a channel verifier and second factor (Twilio), never a primary login, because a phone that is the only way in inherits SIM-swap risk for no gain.

Passwords: Ray recommends not building them. Magic link plus Google plus Apple covers every parent who can receive email. A password adds credential storage, breach surface, reset flows, credential-stuffing defense, and above all multi-factor authentication, because a password without it is the weakest option on the page and a password with it means enrollment, recovery codes and a support path for the parent who lost their phone. That is a real build for sessions protecting a nickname, an age band and a list of interests.

Honest counter-argument. Some parents read the absence of a password as the absence of security, an unmeasured conversion cost. Email becomes a single point of failure, so a Resend outage or a school spam filter is a total sign-in outage. Shared family inboxes make a magic link a shared credential. And districts are the real threat, because schools rarely accept a teacher signing in by personal magic link — but what they mandate is single sign-on (Google Workspace for Education, then Clever and ClassLink), which is federation rather than a password. The district objection argues for more federation. Ray's read: passwords stay unbuilt until a named district asks for something federation cannot give.

3. Growth — both funnels

Both funnels belong to the school phase. Only the two tests below run now, and both run as a parent offer until counsel answers the Florida question in §1a.

School to parents (the stronger one). A teacher prints a classroom playset; the parent-facing page carries a join code, and linking a child requires creating a household. The consent flow is the acquisition flow: the affirmative parental act we want on record is the signup we wanted anyway. One teacher is roughly one warm impression per child in the class carrying a trusted referrer (Ray's estimate, unmeasured), at no paid-acquisition cost beyond the printing. Founder: "schools bring in new parents."

Parents to schools (slower, higher ceiling). A one-tap "share with your teacher" produces a classroom-ready pack — six games, an answer key, a one-page "what this covers" — plus an ask your teacher link. Founder: "parents apply pressure to their schools." The pack has to be good enough that a teacher forwards it to the grade-level team; that forward is the metric, not the share tap. The classroom tier it eventually points at (v3, sketched only): content tagged to a grade band and a skill, a class-set print, progress notes inside the school's consent envelope, priced per teacher seat on a school purchase order.

Cheapest test of each, both runnable before v3 exists. School to parents: no product build. Print a join-code sheet for every child in one warm-contact teacher's class, worded as an offer to parents, and count scans; fewer than one scan per five sheets kills the funnel. That threshold is pre-registered but arbitrary until measured, which is the point of registering it before the test rather than after. Parents to schools: one "share with your teacher" button on the existing tray that emails the pack and instruments the open, with no classroom, organization or consent entity behind it.

Metrics. Scans per sheet, scan-to-household conversion, households per teacher, and the one that matters, second-teacher rate (a teacher in the same school starting unasked). On the other side: share taps, teacher opens, forwards past the first teacher. Both: consent-completion rate, because a legal-flow design failure shows up there as a growth number.

4. Legal for v2 — what the sources say

The school-phase law (FERPA, state operator statutes, district DPAs) moves to Appendix A per the 11:22 ruling: it is a plan to work through state by state, not a gate on v2.

COPPA — the finding that changes v2

If counsel confirms the site is not "directed to children," we may not be collecting personal information from a child at all. The predicate is unresolved, so this is a conditional finding, not a settled one. The Rule defines collection as "the gathering of any personal information from a child" (16 CFR §312.2), and FTC staff FAQ A.8 answers directly: *"Does COPPA apply to information about children collected online from parents or other adults? No."* (COPPA FAQs; F.4 repeats it for parent uploads). Adult-only sign-in, no child credentials, every child field typed by a parent: our design sits inside that answer — a lighter posture than the charter assumed, and worth confirming rather than assuming.

Two ways we lose it, both ours to control. (1) Being "directed to children": §312.2 weighs subject matter, visual content, animated characters, child-oriented activities, and "marketing or promotional materials or plans, representations to consumers." Printable games with cartoon art is not a comfortable distance from that line. [counsel] should read the live site and the marketing copy against §312.2 — copy is now a compliance surface. (2) Actual knowledge that a child is typing, which is why a kid-facing login stays unbuilt.

If counsel reads it the other way, the defense does not weaken; it disappears. The same FAQ carries the counter-sentence: an operator whose service is primarily directed to children must assume the person uploading is a child, and a child-directed service treats every visitor as a child, full stop. In that world the parent-typed-fields argument is irrelevant, §312.3's notice duties attach, and persistent identifiers become the larger exposure: passive collection is collection under §312.2, and an internet-protocol address or cookie identifier is personal information regardless of who typed the profile. That is a different v2, not a modified one. The consent path there is §312.5(b)(2)(viii) "email plus" or the newly codified (ix) "text plus", both open only to an operator that does not disclose children's information (the 2025 COPPA amendments, published 2025-04-22, general compliance date 2026-04-22; the eCFR source note for Part 312 pins the amendment at 90 FR 16977, so cite the document rather than a page). Two corrections to carry: facial age estimation is still not an approved parental-consent method — the ESRB/Yoti/SuperAwesome application was denied 4-0 in March 2024, without prejudice, the Commission taking no position on the merits. Read that alongside the FTC's February 2026 COPPA policy statement on age-verification technologies, which offers enforcement forbearance for information collected solely to determine age on stated conditions. That is forbearance for age-gating, not approval of face estimation as parental consent, and it is the current document to read if age-gating ever comes back on the table, and the school-authorization exception was never codified — the FTC dropped it from the 2025 final rule pending ED's FERPA rulemaking, leaving school consent as staff guidance (FAQ Section N) only.

Adopt regardless — cheap, and what a district reviewer will later look for: a published retention policy with a deletion timeframe and no indefinite retention (§312.10, surfaced per §312.4(d)(2)); separate consent before any third-party disclosure (§312.5(a)(2)); a written security program with a named coordinator and annual review (§312.8(b)), plus written assurances downstream (§312.8(c)).

Sign-in providers, briefly

Apple's Guideline 4.8 (App Store Review Guidelines) is narrower than its reputation: provider-neutral, triggered only when a third-party login sets up the primary account, excepted for apps using your own account system, and it binds apps, not websites. A web-only Scribble Works with Google login owes Apple nothing; a pluggable identity layer is the cheap insurance if an app ever ships. Google's basic sign-in scopes need no verification review, but its branding rules are prescriptive and its user-data policy requires a privacy policy disclosing how Google user data is used.

What would tell us the COPPA posture is wrong

The school phase has tells and the growth funnels have kill numbers; this posture needs one too, and it is cheap. Any of these means the assumption is failing and counsel gets a second look: a support message written by a child; a feature request for a child login; session evidence that the person typing into Customize is the kid; a listing, review or advertisement of ours that reads as addressed to children rather than to their parents; or any surface where a child would land first. Instrument the first and the last; the rest arrive on their own.

What this page does not cover

COPPA here, and FERPA plus state student-privacy law in the companion note. Deliberately out of scope and unexamined: general state consumer-privacy law, the Federal Trade Commission Act §5 unfairness angle, Florida's own consumer-privacy regime, and anything outside the United States. Named so the blank is visible.

Data minimization — what we never collect

No child login or credential · no child email or phone · no last name · (the birth date is held: decision 2, founder chose the charter's full birthday over Ray's month+year narrowing) · no photograph of a child, ever · no home address · no school or student ID · no biometric identifiers (newly enumerated in the amended §312.2) and no voice data (a child's voice in an audio file has been personal information since 2013, not a 2025 addition) · no precise geolocation · no advertising identifier. And no third-party analytics on any surface where a child profile is visible, no ad pixel anywhere, at any tier, ever (charter §6). Customization logs stay stripped of personal data and never carry the name (ruling 21). Age-gating: none is needed while there is no kid-facing login and none is planned. If it ever comes up, the governing document is the FTC's February 2026 age-verification policy statement, not the 2024 denial; either way it is a decision, not a feature.

5. Phased plan

v1 — lead parent + identities (in flight). Household, adult, identity, magic link, sessions, session-gated generative endpoints, plus the privacy-page rewrite specified in the Accounts v1 build brief (a dispatch document, not a vault note). Size: built.

v2 — household adults + child profiles + consent + paid fill-on-demand. Adults 2 and 3 with the lead/adult split, child profiles on the minimized field list, the consent table and event log, the field-mask read layer, and ruling 26's planner split. Teachers ride along as households (§1a) with no new build. Privacy/terms: a real children's-data section — what we collect about a child, from whom, why, the published retention policy, deletion and revocation paths, no third-party disclosure, no ads ever; terms add household-membership rules and the paid generation entitlement, and keep the existing permission to print at home or in a classroom. Decides: all nine rows below. Size: M (Ray's estimate, judgment not measurement; the consent layer is the half that gets underestimated, so read M as the optimistic end). Gates: this note through verify-strategic-output and verify-vault-write; [counsel] on the §4 "directed to children" read before v2 reaches production, not after.

v3 — the school phase (separate, later, evidence-gated). Organization and district hierarchy, teacher verification, classroom, seat, link invite, enrollment, the classroom tier's surfaces, a vendor-side DPA position, and a school-facing privacy addendum. Decides: tier boundaries and district-paper appetite, when it arrives. Size: L (Ray's estimate). Gates: [counsel] state by state per Appendix A, before the first district signature. Trigger: the §1a tells plus a number from the §3 test. Building the org hierarchy before one teacher has handed one code to one parent is the charter's §7 failure shape.

The bear case on this model

The consent layer is the expensive half and it buys nothing a customer can see. A field-mask read layer, an append-only event log, cascading revocation and a published retention policy are plausibly as much work as everything else in v2 combined, built for a school phase just deferred and a legal regime that may not apply. The cheap version is a household with kid profiles, a plain deletion path, an honest privacy page and no consent table, and if counsel says we are not child-directed that version is defensible and ships weeks earlier. The counter: consent records are the one thing genuinely painful to retrofit, because you cannot reconstruct who agreed to what in the past. So build the event log now, start the scope enumeration with two values rather than five, and if the founder wants the cheap version, cut the scope enumeration and the field-mask layer, not the log.

6. Decisions for the founder — v2 only

Per the 11:22 ruling these cover v2 only. School-phase questions (classroom tier boundaries, whether we ever sign district paper) are deferred to v3. Silence means the default proceeds and the build starts — except on the three blocking rows, where Ray builds everything else and stops at that line until you answer. Rows 7 and 8 are live choices about what ships this quarter, not future ones; they are in the table rather than buried in §1a for that reason.

Appendix A — the school phase (moved)

FERPA, the five-state student-privacy comparison and the district-agreement norms live in [[2026-09-02-scribble-works-school-phase-state-law-plan]]. The one finding from it that belongs in a v2 decision is already in §1a: Florida's operator test is disjunctive, so school-facing marketing alone can trigger it, which is why the §3 tests run as a parent offer until counsel answers.

Related

• [[2026-09-02-scribble-works-school-phase-state-law-plan]] — FERPA, the five-state table, district agreement norms
• [[2026-08-31-studio-charter]] §6 account model, §7 case against, §8 open decisions
• [[2026-08-31-product-model-rulings]] rulings 20–27, including ruling 27 (2026-09-02 11:22 ET), the parents-first / teachers-as-households ruling that restructured this page
• [[DESIGN-scribble-works]] photography and child-imagery rules

Changelog

• 2026-09-02 18:15 ET - founder decision AMEND (iMessage): D2 full birthday (charter §6 stands), D3 leads can promote other adults to lead, D4 agreed as revised 11:55 with the teacher/classroom paradigm planned into the schema and not actioned, D0/D1/D5-D8 at Ray's default; counsel sourcing authorized.