Scribble Works second loop - proposal

The question. Ruling 13 splits the photo upload into two loops: (a) update that child's plan, (b) "upping the quality across the whole service." The founder does not yet know how (b) manifests. This note proposes how at two scales: the cohort (under 10 kids, 4 households) and hundreds of households.

The constraint. Charter lines 355-356: child data "never leaves household scope... Not aggregated across households, not used to train anything." Loop 2 is cross-household. The strategy audit ([[2026-09-01-strategy-spec-audit]] §1.3) named this collision; its §4 proposed the only shape that survives it: opt-in, derived facts only, photo deleted after extraction. The mechanisms are the audit's; landing spots, scale answer, and rulings are Ray's. Every mechanism below uses that shape.

1. The two loops

Loop 1 - the child's plan. Consumes one upload: the photo of the marked-up page plus the free-text field on the playset-completion page (rulings, "Feedback loop" section). Produces an update to that child's sub-profile: per-skill state moves between introduced, practicing, and secure (charter line 346), focus topics shift, and next week's five day-cards (ruling 12) regenerate (Ray inference).

Loop 2 - the service. Consumes the same upload but keeps only derived facts: game slug, age band, a few outcome fields, the parent's note with names stripped. Produces changes to the games and the engine that picks them: a revised page, a corrected age band, a better default order in a recommended playset. The photo is deleted once the facts are out. This is where "not aggregated" has to bend; section 4 asks for that ruling.

2. Three mechanisms

One vision-model pass extracts: margin-note text, per-item marks (check, cross, blank), erasures or adult handwriting, and time-to-complete when noted.

Mechanism 1 - field findings per game

• Signal. The margin note and free-text field, classified to a closed set: too easy, too hard, unclear instructions, loved it, print problem, other.
• Lands in. field-findings/<slug>.md in studio state, one line per upload: date, label, stripped note, age band. The critic gate for that slug reads it. The queue already has this shape: "Failed-gate artifacts return here WITH findings" (~/.claude/state/studio/queue.md line 10).
• What changes. Two findings with one label on one slug send the game back through the gate with the notes as the revise spec. The same label on three games of one type becomes a rubric line for that type.
• Useful from. Household 1, upload 1. Audit §4: "A single 'instructions unclear' from a real parent outranks any fresh-eyes critic."
• Privacy. Derived text only, names stripped, no image. Opt-in checkbox on the upload page, off by default.

Mechanism 2 - difficulty calibration per game

• Signal. Completed (yes/no), correct over load-bearing items, skipped items by position, struggle flag, time-to-complete if noted.
• Lands in. A per-game calibration table: slug, age band, upload count, completion rate, correct rate, struggle rate, most-skipped item. Numeric, next to the game's meta so npm test (audit target 10) can check it.
• What changes. The age band on the card. Every game is tagged 3-4 while six need 5-6 decoding skills (synthesis verdict 2, target 4); this table replaces the guess with a count. A "commonly missed" line (audit §4) goes into the footer that target 5 adds.
• Useful from. About 5 uploads on one slug to say "this game is broken"; about 30 per slug to move an age band (strategy audit §4, Mechanism B; the audit's estimates, no basis given). Under 10 kids reach the first threshold within a month and never the second. Audit's phrase: cohort "smoke alarm," hundreds "thermostat."
• Privacy. Numbers only. Same opt-in.

Mechanism 3 - skill-progression prior per age band

• Signal. The sequence (playset, outcomes, next playset, outcomes) per kid, as transitions between the three skill states.
• Lands in. A per-age-band transition table keyed on a hashed household ID that cannot be reversed to the account.
• What changes. The wand's default ordering and the order inside recommended playsets ([[2026-09-01-recommended-playsets-spec]]). The engine's evaluator gates each generated page (engine §2, pass 3); this prior gates what it generates next.
• Useful from. Low hundreds of active kids over 2-3 months (strategy audit §4, Mechanism C; audit estimate). Under 10 kids this is anecdote. Record transitions from day one (cheap); build no logic on them yet.
• Privacy. De-identified household ID, age band, skill states. No name, birthday, or image. Whether a transition table that sets the wand's defaults counts as "training" is part of ruling 2 below; the proposed wording says it does not.

3. Recommendation

Build Mechanism 1 first. It is the only one that changes the service from a single upload, and under 10 kids one parent's sentence carries more information than any count. At 4 households the upload page does not exist, so the manual version is a parent texting a photo to Ray, Ray writing one line to field-findings/<slug>.md, and deleting the photo. That is the iMessage photo experiment the audit proposed as the cohort print test (target 2). The engine's kickback loop (engine §2: evaluator FAIL returns the page to the text pass with the finding) gains a second source of findings.

Record Mechanism 2's fields from upload one (the vision pass extracts them anyway); build no calibration logic before 5 uploads on a slug. Mechanism 3: schema only.

At hundreds of households Mechanism 1 outruns the studio: the cron takes four artifacts per round (charter line 430), so findings need a ranking before the queue. Proposed: a game re-enters the queue only when one label reaches two findings on one slug, ordered by findings per upload; the rest accumulates in field-findings/<slug>.md until it does.

Acceptance test. Within 14 days of the first 4-household print test, one game re-enters the studio queue with a field finding as its revise spec, and the photo behind it no longer exists on any disk, queue, or bucket.

4. Founder rulings needed

1. Opt-in wording. Proposed, on the upload page (wording from strategy audit §4): "Help us improve the games. We keep what we learn (which page, what worked, what didn't), not the photo." Off by default.
2. Amend charter line 356. Proposed replacement (extends the audit §4 wording): "Not aggregated across households except as opt-in derived facts (game slug, age band, outcome fields, name-stripped note text); photos are deleted after extraction; nothing is used to train a model; not sold, not exposed to third parties." This narrows line 356 in one place (aggregation) and keeps the other three protections verbatim.
3. Teachers are a different consent class. A parent uploading their own child's page under their own account is the low-risk shape (charter, "Not legal advice" paragraph). A teacher uploading another family's child's page is not. The Children's Online Privacy Protection Act (COPPA) binds Scribble Works for under-13 data regardless of who uploads; school and district consent rules bind the teacher; neither lets a teacher grant a parent's opt-in. Proposed default: classroom uploads feed loop 1 only, teacher's own notes as the sole signal, until ruled otherwise.
4. Mechanism 3 schema-only wiring is assumed. Say no if audit target 7 covers it.

Not legal advice.