← All privacy impact assessments

PIA: Routines, and a task with a time

Status: Built — not yet released. Written before the code, as the precondition for building Routines. Both phases it covers are now built and under review, and nothing in it has reached a member. Every mechanism below is built as described unless a sentence says otherwise — the deviations found while building are listed under "What differed" at the end, and R7 and R11 are closed. It also covers the two changes the same work makes to ordinary tasks — a time of day beside the due date, and a stored reminder choice. Written: 10 October 2026 · Last revised: 5 November 2026 (fourth model use: Sydney title embeddings for routine edits; §10 refusal details); previously 3 November 2026 (§7: seeded promotional example defaults off Home, retrospective review), 15 October 2026 (long brain dumps in Add several: longer descriptions, left-out pieces, corrections and a thinking model for long ones, assessed before that code; 14 October: built; deviations recorded; planned prose routes assessed; Add several's cuts now decided by Jev before Gemini is asked, assessed before that code; a household's run celebrated at milestones, assessed before that code) Nothing here is legal advice. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 December 2026).

1. Purpose and scope

Repeating work — bins, tablets, feeding the dog, rent — becomes a tool of its own: a routine is ticked off, goes away, and comes back on its next day, and where a group takes turns it says whose turn it is. We are building it because repeating work is most of what a group organises, and today it is an ordinary task with a hidden rotation and a reminder that fires whether or not anybody did the job.

In scope: the schedule and the deadline, which stay readable by our server; whose turn it is and when the routine was last ticked, both held on the task's own row; reminders that follow the turn; ticks from a phone, from the shared display in the house, and from the assistant; what a child account can set up and tick; the four places where a routine's words can reach a model — three uses of TypeSafe's Jev, a second processor in the United States, and title embeddings on Vertex in Sydney for routine edits; and the two notifications that say somebody handed you a turn or added you to a routine.

Out of scope, because they are assessed elsewhere and this document points at them rather than restating them: child accounts and the child-safe variant; the shared display; sealing a group's free text; and the faster typed commands, which covers ticking by meaning, the question that spots a routine inside a task request, voice ticks, and comma-separated lists. Shopping's own items and the emails Mail Sifter sorts are assessed in their own documents.

Ordinary tasks have never had an assessment of their own. This one does not fill that gap; it covers only what this work changes about them.

2. Data involved

What is not collected, and could have been. The dated-turn amendment below supersedes the original no-missed-occurrence-record design: open turns and skips now persist with the routine. No per-person count of who did or did not do a routine, beyond the games' existing scoring and the completion rows the app already keeps. No reason, excuse or note attached to a tick. Manual skips record the actor for Undo, as the amendment describes; no reason for skipping is collected. No location, no device identifier on a tick beyond which display recorded it, and no new free-text field anywhere.

Why a child's information is strictly necessary here (s 38(2)(b)), item by item: a routine's title is necessary because it is the job; the schedule is necessary because the point of the feature is for the job to come back on the right day; the member identifiers are necessary because a turn is the name of a person; the tick is necessary because the whole feature is a record that something was done. Nothing about a child is collected to improve a model, to rank anybody, or to profile how a household works.

3. Flows and locations

The rules that apply to every use of Jev, and that this document relies on rather than invents: it is a second processor hosted in the United States; roster names are replaced before anything is sent, and it is never given the group's records, a roster, a conversation history or a key; a Device-only group, a child account and the shared display never reach it and get the behaviour that needs no model; if it does not answer, the feature behaves exactly as it would without it, so no write ever depends on it; and every call is logged as usage and counted in the spend ledger, with no new table and no stored copy of what was sent.

What reaches a log is an outcome and a count, never a title, and that is the existing rule for every function here. Nothing in this work adds a log line that names a person.

4. Legal basis and consents

The purposes in the consent ledger are a closed list (terms, baby_summary_to_model, assistant, voice, on_device_brief, read_receipts, dish_photo_moderation, cross_group_events, improve_app_traces, overseas_processing). This work adds none, and needs none. The ledger itself is planned rather than built; where a switch carries the current state we say which one.

• A routine itself is a member acting inside their own group, under terms. Creating, ticking, passing a turn and editing a schedule are group writes an active member can already make, and the database's existing rule for task rows is what authorises them.
• Setting one up from a sentence, sorting a list, and the suggestions card rely on the group's existing permission to use the assistant and the member's own narrower ceiling, plus the member's acknowledgement of the privacy notice that names TypeSafe as a separate United States processor — the same gate the faster typed commands already wait behind. An older app version, or a member who has not acknowledged that notice, gets the behaviour that needs no model. Device-only is refused outright.
• Somebody aged 16 or 17 who is not on a child account has every feature that reaches a model off until their own switch is on; it is their act, and no guardian or admin may set it. A child account gets the behaviour that needs no model everywhere (§7).
• The two notifications. A per-kind notification switch, including one for turns and routines, is planned to ship before them, and a group's chat can be muted on its own. The withdrawal path is that switch, and it has to stay findable: a notification whose switch cannot be found is one somebody silences by revoking the permission for everything. Our own explanation comes before the system permission is asked for, once.
• Nothing here is consent for a model to learn. TypeSafe states that it does not train on input; zero retention is a separate enterprise provision and we do not assume it.

Withdrawing is partial by design and we say so: turning the assistant off, or being in a Device-only group, leaves routines working in full — only the four model-assisted conveniences go.

5. Risks and mitigations

6. Structural versus conventional

Structural — the database or the cryptography can prove it. The sealing, the row security, the claim a reminder makes on an occurrence before sending and the child refusals at our server exist today; tick_routine, the trigger that works the turn out, and every new column are planned, and until they are built the properties below are a design rather than a fact. The words are sealed under the group's key, per row, and a Device-only group's server holds no key for them. Only an active member of the group may read or write its task and completion rows, and an archived group is read-only. tick_routine runs as its owner and states every check the policies used to make — active membership, the archive, what a display may credit — locks the row, refuses an occurrence that is not the current one, and inserts with the identifier the client minted, so a retry is the same tick rather than a second one. The turn is worked out by a trigger from the latest tick rather than stepped forward, so two ticks, an undo, a roster edit and an old app version's plain insert all land on the same answer. The game's box claim happens in the same transaction as the tick, so an undo can take it back. The reminder dispatcher claims an occurrence with a unique row before sending, which is the only reason twelve five-minute ticks send one notification. A child account is refused at our server for everything that reaches a model, by a read of the account's own age on every request that fails closed.

Test-pinned — not proof, but it fails loudly. That a notification names a group or a person and never the group's words (a register of every sender, and a source check per sender). That roster names are replaced before anything reaches Jev. That no second copy of the occurrence rule drifts from the first: the copy our server uses is checked byte for byte against the phone's. That the reminder for a repeating job is decided by one predicate shared between the scheduled guard and the dispatcher. That the copy says what was recorded rather than what happened in the world, and carries no guilt, count or comparison.

Conventional — real, legitimate, and named so nobody mistakes it for a lock. That setup stays on phones (R11). That the thresholds chosen for Jev produce acceptable accuracy, which is unmeasured until each use has its evaluation set. That the suggestions card sends only the titles described above, and that nothing later widens the list. That the cap on notifications nobody asked for holds across the senders that count towards it. That "turns and routines" as a switch actually suppresses these two notifications. That no future screen counts how often somebody passed a turn.

Where copy makes a claim, the claim is pinned. If the empty state or the setup screen says a routine's words stay on the group's phones, or that nothing is sent anywhere until the member asks, that sentence needs a check that the behaviour happens — not only a scan for words we must not use. A promise held up by good intentions is exactly the class of thing the transparency tests exist to catch, and a cell that promised a capability has been false for eleven days before.

7. Best interests of the child (exposure draft s 10)

Seeded promotional example (reviewed 3 November 2026). New groups’ “Tell someone about GroupApp” keep-count routine stays in Routines with showOnDashboard: false. Assignment to the creator is not a visibility boundary: Home’s counter card receives the whole group’s tasks and filters only by the Home flag, including for child and under-16 members. An unsolicited prompt to promote the app serves us rather than the child’s household work, so it should not be placed on their Home by default. This also avoids tension with the child privacy page’s “There are no adverts in this app” sentence. This is a product privacy precaution, not a conclusion that every referral prompt breaches the Code. A member can still find the ordinary example in Routines and explicitly enable Show on Home; that switch is group-wide, so children can then see it too. Existing groups’ rows are unchanged. The seed and Home-render tests pin the default.

What a child account can do in Tasks today, stated as fact. It can create, edit, assign, tick, un-tick and delete any task in its group, log a count on a repeating one, set a reminder, and take part in the games that score those ticks — exactly as an adult member can. One rule authorises every task write in a group and it asks only for active membership, so the database cannot tell a child's task row from an adult's. The only limits on that screen are that search by meaning is refused, because the typed title would leave the phone; that the on-device assistant switch is not offered; and that the store-rating moment is skipped. Away from that screen, an under-16 account is refused the assistant, the written daily brief, task allocation and voice grants at our server, and a 16- or 17-year-old has them off until their own switch. The evidence for each of these is named in §11.

So routines match it, and that is the decision. A child account may set up, edit, tick and pass a turn on a routine, and takes its place in a rotation, because repeating work is the part of a group's life a child actually shares, and leaving them out would make them the only member whose jobs do not count. What they do not get is the four conveniences that reach a model — setting one up from a sentence, sorting a pasted list, the suggestions card, and finding a routine by meaning for an assistant edit — plus voice ticks; they get the behaviour that needs no model, which is the same answer the app gives them everywhere else. That is not a safer design we are claiming credit for: an age-based restriction of a model feature carries no weight in any wider argument, and we do not use it as one.

What it costs the child. A routine is a durable record of their domestic life — tablets at night, the bag for Thursday, a therapy exercise — readable by every adult in their group, sealed from us as words but legible to our server as a pattern of times (R1). Their ticks are scored per person, so what they did and did not do is visible in a standing their family can see (R9). A display in a shared room can record a tick against them that they did not make (R10). A notification can tell them an adult has handed them a job (R4).

The safer designs we did not choose, and why. A routine whose history was kept only for the group and never per person would have hidden a child's contribution as well as their absence, and the per-person scoring was chosen deliberately so that two people doing the same job both count. A sealed schedule would have made the reminder impossible to work out on the server, and a reminder nobody receives is the feature failing for the carer the routine exists to help. Not sending the suggestion titles at all remains available, and R8 is written so that choice can still be made.

Where the child's and the parent's interests diverge, the parent's won in one place: an adult can put a child in a rotation, and the reminder then goes to the child. We bounded it rather than removed it — only members already in the order can be reminded, the switch is the child's own to turn off, and the notification never names the job on their lock screen.

What the child is told. Their own privacy page is derived from the group's switches rather than written by hand, so it cannot promise a privacy the switches do not keep; it separates what everybody in the group sees from what guardians alone see. It gains a plain line for this work: that the adults in your group can see a routine's days and times and who ticked it, that the words are only readable on phones in your group, and that you can turn off being notified about turns and routines without losing anything else. Written for a young teenager to read on the first pass, as an arrangement rather than as their age being a problem.

8. Residual risk we accept

Each one is separate, and each can be accepted, refused or sent back on its own.

• R1 — A routine's schedule stays readable by us. How often a job comes round, which days, at what time and with what deadline sit in plain columns, because the reminder and the overdue check are worked out on the server. The words are sealed; the pattern is not, and a pattern of times can imply a medicine round or a child's bedtime. Recorded as an explicit decision, and to be written into the sealed-fields register alongside the new columns.
• R2 — Whose turn it is, is plain. Member identifiers in assigned_user_ids, rotation_user_ids and the turn override are readable by us for a Standard group.
• R3 — Passing a turn leaves a short-lived receipt. While the override is set, every member of the group can see that one named person handed a named job to another. It clears at the next tick, nothing records a refusal, and no screen counts it — but nothing in the database stops a later screen from doing so.
• R4 — Somebody else can make your phone ring. A reminder follows the turn, so an action of another member moves it to you. Bounded to the routine's own order, and switchable off.
• R5 — A lock screen names a person and a group. "Sam passed you a turn in Smiths" is visible to anybody holding the phone, which is the disclosed exception for every notification this app sends.
• R6 — Setting up from a sentence can be wrong. Thresholds are estimates until each use has its evaluation set. Nothing saves without the person, so the cost is a wrong draft rather than a wrong record.
• R7 — A pasted line can describe somebody who did not type it, and name replacement cannot remove every identifying context before it reaches the United States. The names themselves come from our own reading of the group's members and babies, not from anything the phone sends, so one of them being left out is no longer a way for a real name to travel. The gap this recorded — a first name written on its own, where we hold the full name — was closed on 11 October 2026: the first name of every name we hold is replaced as well, for this route and for every other request that reaches Jev, so "Sam's swimming kit" does not carry "Sam" where the group holds "Sam Parent". A first name two people share is still replaced, by a placeholder that identifies neither of them. What is left is context rather than a name: a relationship, a place, an unusual event, or a name nobody in this group answers to. Changes to what is already there (26 October 2026) do not widen this. When a phone that can show a change sends a list, the same single Jev request also asks whether each line or piece is new, a change to something already on the list or calendar, or a removal, and Gemini, when it splits a paragraph, says the same of each item from the same masked words; a request those questions would make too large is sent without them, as today. No existing task or event, title, time, identifier, roster or history is sent with the words, and nothing is fetched for it. Which task or event the words mean is found on the phone among what it has loaded: every word said must be in its name and a day said must agree, except a task's doing words ("take out"), which only ever offer it for the member to pick; another group's shared event is never a target. On Tasks, the shopping items the phone has loaded are matched the same way, only so the row can say to change one in Shopping; nothing about them is sent or changed. The member sees the change before and after, chooses when several match, and confirms it. A change is written only while the item is still at the version the review showed; Undo writes back only while it is still at the version the change committed. A removal sentence is shown, never acted on: its row says to remove the item from its own screen. So is a "done" sentence ("I've done the bins"), recognised on the phone: its row says to tick the task in Tasks, and nothing is added or ticked. A task changed this way posts the same "Task … was updated" message to the group's own chat that the task's edit sheet posts (HQ decision D91): it stays in the group, as an edit by hand does. An opted-in "Help us improve" record, which already carries the member's masked words and the model's questions and answers, now carries this question and its answer too. A child account, a managed account and a Device-only group never reach this route, and the phone's own fallback when nothing was sorted stays add-only.
• R8 — The suggestions card sends task titles nobody typed for that purpose. Up to thirty of the group's open task titles reach a United States processor because a member opened Routines, not because they asked a question about those tasks. It is the only send in this document that is not a direct consequence of what somebody typed. Accepting it means accepting that an open task called "Collect Ada's medicine" can be in that list. The alternatives, if it is not accepted, are to ask before the first send, to send only the tasks the member chooses, or to drop the card and keep setup from a sentence.
• R9 — Per-person scoring makes contribution comparable. Two people doing the same job both count, which is the point; the same change makes who did less legible inside the family. The games' no-ranking and no-guilt rules are the only thing keeping that from being a scoreboard, and they are copy and derivation rules rather than database ones.
• R10 — A tick at the display is not proof. Choosing a face in a shared room records a credit; only that display can correct it, and only on the same day in the group's time.
• R11 — "Setup stays on phones" is a product choice, not a rule. A live display is an active member of its group, and task rows are not among the tables whose writes its areas gate, so nothing in the database refuses a schedule, a rotation or a reminder written at the display — only the screens we choose to draw there. It can be closed with the same refusal the display already has for adopting a meal plan, and we would rather close it than carry it.
• R12 — The record outlives the child's interest in it. A routine and its ticks persist for as long as the group does. Nothing here adds a retention window, and we do not claim one.
• R13 — A confident cut can still be wrong. Where Jev is sure about every joining point in a list, our code cuts the words itself and Gemini is not asked. A confident answer can be wrong: a dish cut in two, or two jobs left as one. The mitigation is the thresholds, the rule that every point and piece must pass, and review before any write; it is not a promise that a wrong cut cannot be accepted by someone who does not read the rows. The benefit is that most ordinary descriptions are cut in a fraction of a second and, for those, reach one processor instead of two.

9. Review trigger

Re-read this document when: a new column is added to the routine's schedule, the turn or the tick, or any of them is sealed or unsealed; anything other than the four uses above sends a routine's words, a task title or a schedule to Jev or to any other processor; one of the first three uses stops replacing names or starts sending fetched records; the fourth use widens beyond titles; any of the four starts including a child account, a display or a Device-only group; the suggestions card's input widens beyond open plain tasks or its cap; a notification about a routine starts carrying anything beyond a group and a person, or a new sender joins the ones that count towards the shared cap; the display gains the ability to set a routine up, or the refusal in R11 is built; the games' scoring key changes again, or any surface starts showing a per-person total, share or ranking of ticks; an evaluation set measures an error rate that does not support a chosen threshold; or the feature ships, at which point the retrospective replaces this draft.

10. Checklist against exposure draft s 38(2)

Written before the feature is built (s 38(3)), and listed on the published register (s 39).

11. Sources

• Children's Online Privacy Code exposure draft, sections 10, 13–17, 33 and 38–39 — the texts kept under docs/sources/ with their verification log.
• TypeSafe model documentation and privacy policy — United States hosting; no training on input; zero retention as a separate enterprise provision.
• Gemini 3.5 Flash-Lite model documentation — the single-shot model planned for prose in Add several and in routine setup after Jev chooses those routes.
• Sibling assessments: docs/pia/child-accounts.md, docs/pia/shared-display.md, docs/pia/content-encryption-v2.md, docs/pia/assistant-fast-commands.md, docs/pia/cloud-inference.md, docs/pia/privacy-levels.md.
• What a child account can do in Tasks today (read 10 October 2026): the single policy authorising every task write, "Active group members can manage group_tasks" in supabase/migrations/20260823235140_security_fixes_p1.sql, and the completion policies in supabase/migrations/20260824042923_scope_task_completions_to_active_members.sql — neither reads a child predicate, and no migration adds one for group_tasks or task_completions; the child-safe variant itself in supabase/migrations/20260908043933_ws8_child_accounts.sql and lib/childAccounts.ts; the client's age gates in hooks/useChildAccount.ts and the table of which surface waits for a known adult in lib/__tests__/childAgeGates.test.ts, whose only Tasks-tab entries are search by meaning (hooks/useTaskSearch.ts), the on-device assistant switch and the store-rating moment (store/slices/createTasksSlice.ts); the Tasks screen's own single use of the predicate in app/(tabs)/tasks.tsx; and docs/pia/child-accounts.md §5.2, which records chat, tasks, calendar and games as full for a child account.
• What is sealed and what is not: lib/sealedFields.ts (task title, notes, why, blocked reason, beneficiary label and the completion's title copy, all at every privacy level) and docs/reference/encryption.md.
• Ticks, turns and the display: supabase/migrations/20261002125754_wall_task_completions.sql (commit_group_task_completion, record_task_tally, who a display may credit, and for how long), supabase/migrations/20261001175512_wall_managed_members.sql and supabase/migrations/20261002105226_wall_pairing_and_pin.sql (the display's areas, including task creation — the basis of R11), and lib/wallTasks.ts.
• Reminders: supabase/functions/dispatch-task-reminders/reminders.ts and its shared predicate, lib/taskReminderDue.ts, and lib/repetitiveTargets.ts for the group-time week boundaries a count is measured over.
• Notifications: agent-server/checks/genericPushes.check.ts, the register of every sender and the rule each keeps.
• Jev: agent-server/src/typesafe.ts (United States hosting, the fail-closed behaviour and the usage log), agent-server/src/privacyLevel.ts (name replacement before a third party) and agent-server/src/jevNameMap.ts (the one server-side reading of who is in the group that every one of those replacements is built from). Setting a routine up from one sentence (J3) is agent-server/src/routineSentence.ts (POST /api/routines/setup-from-sentence), with the entry in components/Routines/RoutineDescribeBand.tsx and the mapping in lib/routineSentence.ts. The exclusions, the payload, the fence, the name replacement and "an uncertain field is left blank and highlighted" are pinned by agent-server/checks/routineSentence.check.ts and block 15 of agent-server/checks/promptBoundaries.check.ts; its thresholds were measured by docs/experiments/010-jev-routine-from-a-sentence/README.md, which ran on 11 October 2026 and kept every one of them.
• The games' counting rules: lib/games/completions.ts, lib/__tests__/dealDeck.test.ts and lib/__tests__/dealCopy.test.ts.
• The plan this assessment was written against: docs/routines_and_lighter_tasks_plan.md.

What differed, found while building (11 October 2026)

Recorded because the assessment was written before the code, and an assessment that is not corrected by what building taught is worth less than no assessment.

• R7 was wider than this document described, and the gap was real. The name map held each person only by the name we store, so a first name reached Jev unreplaced — and "Sam's swimming kit" is what people write, while users.full_name holds "Sam Parent". Closed by agent-server/src/jevNameMap.ts's alias family, which replaces the stored name and its first name for every Jev caller, not only the fast route. R7's row above now says so.
• R11 is structural, not conventional. This document said "nothing in the database says so today". The database now does.
• Ticking by meaning (J1) could tick the wrong row, and the measurement is why the rule changed. Experiment 011 found a request matching nothing read as a row sharing a word stem in 15 of 15 samples, at scores to 0.97 — so no band or margin separated right from wrong. Owner decision 31: the immediate tick stays only for an exact title (normalised equality), and any stem-matched candidate always asks, whatever Jev scores. Landing as P1-25.
• A spoken tick always asks (J4). There is no immediate band on the spoken door, which is why J4 could ship while J1's rule was still open.
• A routine's reminder is off until somebody asks for it. The assessment assumed a schedule implied a reminder; a daily routine defaulting to one is a push notification every day nobody chose, so the setup sheet asks, and with no time of day only "morning of" and "off" are offered.
• The schedule columns stay plain, as R1 accepted — and the sealed-fields register (docs/content_encryption_inventory.md) now records them beside due_time and reminder_lead, which is the entry R1 said was owed.
• Nothing here has met a phone. The simulator pass is still owed; see known-issues.

Also, since: a date typed into a task's name (12 October 2026)

The sheet where a task is written now reads a day, and a time of day, out of the name the member has just typed — "Dentist Thu 3pm" becomes a task called "Dentist", due that Thursday at 3 pm. It is the same reading already assessed in section 4 for a pasted list, word for word and letter by letter on the phone itself: no model, no request, nothing sent anywhere and nothing kept between one sheet and the next. It reads only the name being typed into the box, and only words the member stated become a deadline — a name that mentions no day gets no deadline, and a deadline already set is never overwritten. What was taken out of the name is said on the screen as it happens, and both the name and the date can be changed by hand before anything is saved. It works the same way for every group and every account, including a child's and a group whose words stay on its phones, because nothing leaves the phone.

Spoken and paragraph lists (12 October 2026)

The Add several box will accept a spoken list through the phone's existing transcription button, or a paragraph pasted or typed into the same box. Typed words remain editable until Sort; spoken words are submitted for sorting when speech ends or Stop is pressed. The resulting items remain reviewable before Accept writes anything. A Standard group's submitted text then goes to our server. Jev first judges whether it is already a list of separate items. If it is, the current kind classification continues. If it is unstructured prose, one short Gemini 3.5 Flash-Lite call at Google's global location proposes one source-backed item, short title and kind per action, with no second Jev call. The person reviews each proposed item and kind before Accept writes anything. No audio is sent to our server by this flow, and neither model sees existing group records, history, identifiers, or the roster. Our server reads the roster only to replace names before either processor sees text. Every call counts against the member's allowance and the platform spend ceiling. A failed or incomplete Gemini split leaves the original text in the box for correction; it must not silently discard a clause or make a partial batch look complete.

Choice and access. Pressing Sort sends typed words; using the microphone sends transcribed words for sorting after a pause or Stop. A short line beside Sort says that AI may process the words overseas and that the draft is reviewed before adding. An adjacent, expandable explanation on the same sheet names TypeSafe in the United States and Google's Gemini at its global location; the revised notice has already been acknowledged before this route is offered. The microphone's own notice still explains that transcription may use Apple or Google's speech service when the phone cannot transcribe locally. Device-only groups will have no Add several entry or active sheet, and the client must not send this text to our server at all. Child accounts may still dictate into a local text box, but their Sort cannot call either processor. The server repeats the membership, age, consent, privacy, roster, and spend checks for every request; a stale or modified client cannot bypass them.

Additional residual risk. A spoken or pasted paragraph may describe another member's medicine, appointment, or private event. Name replacement cannot erase every identifying context. The extra Gemini call also gives a second processor those words, beyond Jev's United States judgment already accepted in R7; Google may process at any global location, including the United States. The benefit is that one breath of ordinary speech can become several reviewable tasks without the member editing line breaks by hand. We accept that trade only for Standard groups whose member explicitly presses Sort or starts dictation after the microphone notice. A model may still choose poor boundaries; the reviewed proposal, exact-word validation, and no-write-before-Accept boundary limit the harm of that error to a draft. This extension is assessed before its code is changed. The shorter spoken path removes the chance to edit the transcript before sorting, but Accept still controls writes.

Revision after the first phone trial. Boundary-only output grouped two different Friday pickups and left conversational words in task titles. On the prose route, Jev still decides whether prose extraction is needed, but Gemini returns one structured draft per action: a source span, a title span copied from that action, and its kind. There is no second Jev classification call on that route. The server rejects missing or overlapping source words, a title outside its action, and an unsplit independent subject and action; the phone rechecks the result. Dates and times still come from the original words in the group's time, not model-computed timestamps. The server may match an explicit “I” or named person in each action to an active group member using the authenticated caller and its own roster. The draft visibly shows the proposed title, kind, date/time and assignee; the member can correct a title or assignee before Add these. Nothing is written on a failed extraction. The added risk is that a wrong title or person looks plausible, so source spans, roster checks and the review controls must pass before this revision is used. No new processor, destination, group history, audio or stored draft is added.

Unpunctuated command lists. A member may speak or type several short commands without punctuation or conjunctions. The same Jev-to-Gemini route and review boundary applies. The polish instruction must identify each separate action, including one beginning with a lowercase verb, and treat a job as one-off unless repetition is stated. Exact-word validation still catches lost or duplicated words, but cannot prove that a semantically plausible split is correct. The member therefore still reviews every title and kind before saving. This refines the prompt only; it adds no input, processor, destination, retention or automatic write.

Default assignee in Add several. A task or dated event with no person named starts with the person providing the list selected in review. An explicitly matched member still takes priority; the reviewer can choose another member or clear the selection before adding. The visible default reduces the chance of work landing on nobody, but could put a task or event on the author's calendar and send their usual reminders when they meant it for the whole group. Review and an unassigned choice remain the control. The default is set on the phone from the signed-in member, not guessed by a model; no extra identity or group content goes to either processor.

Add several: cuts decided by Jev before Gemini is asked (14 October 2026)

Add several is used on the Tasks tab (five kinds of item) and on the Schedule tab (events only; assessed in its own page). Both send a description to the same server route. Until now, when Jev judged a description to be prose rather than a list of separate items, Gemini was asked where to cut it. This section assesses a change made inside that same route, before its code was written: the first request to Jev, which already asks whether the description is a list and what kind each line is, now also asks about each joining point and each piece, so that ordinary descriptions can be cut without Gemini.

What changes. Our code finds, in each line, every “ and ”, comma, “ then ”, “, and”, “and then” and sentence end that is followed by more words, up to six in a line. In the same single request, and over the same words with names replaced in the same step as before, Jev is asked, per joining point, whether the words on either side are two separate items or one item whose name contains the joining word; per piece, whether, once a day or time is taken out of it, what is left is one item fit to be its title as it stands (no lead-in or filler words, no hedge, no request to be reminded and no second item); and per piece, which of the five kinds it is. When Jev is sure about every joining point (at least 0.8 for two items, at most 0.2 for one; “one item” at a full stop, question mark, exclamation mark or semicolon is never accepted, because a new sentence almost always starts a new item), every piece is a whole line or a single part between two cuts, every piece is rated a clean title at 0.8 or more, every kind is clear (the same 0.6 the phone already applies to Jev's kinds) and at least one point separates two items, our code cuts the words there and Gemini is not asked: Google receives nothing for that request. Otherwise Gemini is asked exactly as before. When Jev judged the description to be a list of separate items, nothing changes.

What does not change. No new data, record, destination, processor or retention. Jev still receives only the submitted words, now also as pieces and as a line with one joining word marked, each inside the question it belongs to, with names replaced from our own reading of the group (a request in which a name contains a joining point is not cut at all, so a name is never replaced in pieces); it still receives no roster, history, identifier or key. The reply has the same drafts: the words of each piece and its kind, and the member's own reading of a task's person. A piece cut by our code carries no title; the phone reads the title from the words, cutting out any day and time, which is what it already does for a line typed alone. The phone tells the server that it can read such a draft, and an older phone keeps the Gemini route. Dates and schedules are read on the phone, as before. A Device-only group, a child account and the shared display never reach either processor, and the member's acknowledgement and spend gates apply before anything is sent. Nothing is written until the member accepts, with one undo.

Records. Usage records gain a label (Jev or Gemini produced the cuts), a count of joining points asked about and a short reason when Gemini was asked instead, never words. Spend is metered as before: one Jev request, and Gemini only when it is asked. A server setting turns the behaviour on or off without changing the app. It sends nothing new to either processor, so it needs no change to the policy text: the in-app line “Google's Gemini may also process them” stays true whether or not Gemini is asked.

Evidence. Experiment 016 (invented descriptions only; decision rule written before each run, 14 October 2026) ran twice. The first run (234 calls) found no wrong cut but found that the extra questions lowered the model's confidence about whether a plain one-item request is already a list (from 0.98 to 0.63 on one request), so the behaviour was left off. The questions now carry the words they are about themselves and leave what the routing question reads exactly as it was; the second run (117 calls) met the rule written for it: no wrong cut, no wrong join and no prose passed on as an item in 39 requests cut in code, no day or time left in a title the phone derived, the routing question's confidence within 0.03 of before, and a wrong kind on 5 of 93 cut pieces. Gemini is still asked for most Tasks lists: 12 of the 32 Tasks requests that should have been cut in code were (38%), against 27 of 33 on the Schedule tab. The behaviour is on, and the server setting can turn it off without changing the app.

Add several: remarks left out and a day or time for every item (29 October 2026)

The cut above can now also leave out a remark about the other items (“that's all I can think of”) and copy a day or time said once for all of them (“both tomorrow”) onto each item without one, on both tabs. Jev only answers yes or no about candidates our code finds, at least 0.8 sure each time. Every source word is still accounted for, an added day or time is a copy of the member's own words, and dates are still resolved on the phone in group time. No new data, destination or processor is added. The full assessment, its limits and experiment 027's evidence are in Schedule add several. A server setting turns it off without changing the app.

Long brain dumps in Add several (15 October 2026)

Add several is for a busy person emptying their head: a list reeled off by voice or typed in one go, as each thing occurs to them. A member was told their words were too long. Until now a description was refused over 3,630 characters, the Schedule tab also refused any single line over 120 characters (which is about 20 seconds of dictation, since speech arrives as one line), and a draft could hold at most 30 items. This section assesses the change below before its code was written; it applies to both tabs, which share one server route.

What changes.

• A description may be up to 10,000 characters, about five or six minutes of speech, and a draft may hold up to 60 items. A description that does not fit the line-by-line shape is always split by Gemini as a whole, never reviewed as lines cut short.
• The microphone still stops after five seconds of silence, or at about a minute, which is the limit of Apple's speech service. At that limit the words now stay in the box and the sheet says "Still going? Tap the mic to carry on", instead of sorting straight away. The next recording adds to the same box.
• A description over about 600 characters goes to Gemini 3.8 Flash, with more thinking, instead of Gemini 3.5 Flash-Lite. Both run at Google's global location, the same provider and place as before. If 3.8 Flash has not answered in 25 seconds, or answers in a form our checks refuse, Flash-Lite is asked instead. Each call is charged to the member's allowance and the platform ceiling at its own model's price.
• The instructions now describe this use: a list in the order things occur to the person, with filler, asides, corrections and speech to someone else in the room that the microphone picked up. Every word still belongs to exactly one item. Words that are not something to add become an item of the kind "left out". In review these are folded under "Left out 3 bits that didn't sound like anything to add · Show", and are never saved unless the member opens them and adds one.
• When the person corrects themselves ("dentist Tuesday, no, Wednesday"), the model may name the words they took back, so the phone reads the corrected words. It names positions only: it cannot add, rewrite or reorder words, the words it names must sit inside the item and outside its title, and an answer that breaks those rules is refused. Dates and times are still read on the phone, in group time.

What does not change. The gates, notices, exclusions and acknowledgement are the same: Device-only groups, child accounts, managed accounts and the shared display never reach either processor. Names are replaced from our own reading of the group before anything is sent. Neither processor receives group records, history, identifiers or the roster. Nothing is written until the member accepts, with one undo. The in-app line already names Google's Gemini at its global location, and the privacy policy already names both models, so neither text changes.

Additional residual risk.

• A longer description can carry more about more people, including someone who is not a member. When the microphone is left on, the words of someone else in the room can reach Gemini. The silence stop, the one-minute limit, and the left-out pieces being visible in review limit this but do not prevent it. We accept it, decided on 15 October 2026, for the usefulness of an unedited brain dump.
• A left-out piece can hide something the member meant to add. It is counted and one tap away, never deleted.
• Words the model marks as taken back are not shown on the review row. A wrong mark can change a day or time; the reviewed day and time are the control.
• A long description waits longer: a few seconds normally, and up to about 45 seconds when the first model is slow and the second answers. A probe on invented descriptions saw 3.5 to 24 seconds.

Records. Usage records name the model that ran and count tokens, never the words. The quality of the longer instructions was checked on a handful of invented descriptions, not measured in an experiment; we chose to ship it and watch the draft feedback.

Free-form routine descriptions (12 October 2026)

The existing Describe it entry reads one short sentence. It works when our code recognises the possible schedule and title before Jev chooses among them. A member may instead type or dictate less regular prose. The updated entry accepts that text in the same editable box, without recording audio. Typed text goes to our server when the member presses Fill it in; dictated text goes when speech ends or Stop is pressed. This is a drafting aid for one routine, not permission to create it: every proposed field remains visible and editable, and Keep it is still the only write. The card's safe-area, time-picker and example-list repairs do not introduce a new data flow.

Data and locations. The submitted description can mention a child, medicine, care or a person outside the group. It goes from the phone to our server in Australia. Our server verifies membership and reads the group's roster to recognise and replace stored names and their first names. It sends no roster, existing tasks, routines, history, group identifiers or encryption keys to either processor. Jev in the United States first chooses whether the ordinary sentence path has enough evidence or the prose path is needed. Code may also require the prose path when the text names a recurrence that the ordinary reader has no sound candidate for, even if Jev chose direct. A description with no frequency stated can leave that field open. Only the prose path sends the name-replaced description to Gemini 3.5 Flash-Lite at Google's global location, which may process it outside Australia. Behind a server setting that is off (an experiment on 28 October 2026 found Flash-Lite's answers always usable, so it had nothing to do), an answer from Flash-Lite that our server cannot use may be followed by one more request with the same name-replaced description to Gemini 3.8 Flash, the same provider at the same location. Add several's own retry, which is on, does not turn it on. Gemini proposes a short interpretation with source evidence. Our server checks that evidence against the submitted words and the form's allowed values; Jev checks ambiguous choices against the original, name-replaced description. A missing or unsupported value stays unfilled, and several different jobs are not silently merged into one. The original description and intermediate draft are not stored separately as group records; chosen fields become a routine only on Keep it. We add no raw-text log; usage logs contain only outcomes, counts and spend. We do not claim either provider keeps no copy.

Choice and access. The short point-of-use line says that AI may process the description overseas before the member fills the form; adjacent details on the same card name TypeSafe and Google and their locations. The existing assistant/overseas choice and a current acknowledgement of that revised notice are required; the current TypeSafe-only notice is insufficient for the new send. A Device-only group, child account, shared display or an eligible but offline phone keeps the manual form. A 16- or 17-year-old without their own model switch gets the same manual form. The server repeats these checks, plus roster availability and both spend limits, before each provider call. There is no automatic Gemini fallback when Jev is unavailable. A failed or unvalidated interpretation leaves the original words in the box and saves nothing.

Assessment decision. We accept the additional overseas processing for eligible groups because free-form descriptions can become one reviewable routine without the member translating their own words into form controls. That benefit depends on the revised disclosure, explicit button press, server gates, source-backed draft and no-write-before-Keep-it boundary described above. The prose route has code and synthetic checks, but no live accuracy measurement yet; this assessment preceded its code. A different payload, access rule or model destination would need another assessment revision.

Consent-gated diagnostics and draft feedback (12 October 2026)

Add several and Describe a routine are added to the existing Help us improve LangSmith export only for a person who has turned that switch on. Each request, including a refusal or failure, has a distinct route tag and an outline of the Jev routing choice, model calls, timings, usage and result counts. The outline contains no list text, routine description, transcript, proposed title or member name. No trace is sent for a child or wall account, or when the switch or Australian tracing service is unavailable. Audio is never included. This follows the separately assessed assistant tracing retention and erasure rules; it does not create a LangSmith score, annotation or longer-retained record.

Revised on 15 October 2026: both now carry the words too, typed or dictated, from an app version whose privacy policy says so: the list or description, what TypeSafe's Jev and Google's Gemini were sent and answered, and the proposed drafts or routine fields, with the group's names replaced (the assistant tracing assessment, §2.2a). Audio is still never included, and a child or wall account is still never traced. A feedback item sent from these drafts links to the record, and the sheet says so before Send.

An eligible adult in a non-Device-only group sees thumbs beside Add these or Keep it only after an AI draft was returned and only while Help us improve is on. A thumb opens the existing Send feedback to GroupApp sheet. Its editable note contains just that member's submitted words and the draft offered for their review; it is name-redacted on the phone and sent to our team only on a second tap, under a separate per-send consent. Closing the sheet sends nothing and saving the task or routine is independent of feedback. Feedback stays in the existing 90-day GroupApp store, never LangSmith. The feedback assessment covers the recipient, age and group limits, deletion and remaining risk that a description may still identify someone after name replacement.

A household's run, celebrated at milestones (14 October 2026)

Assessed before the code. We decided this on 14 October 2026.

What changes. When somebody ticks a routine that has a schedule, and that tick completes the current occurrence — or, for "N times a week", the week's count — the phone works out how many of that routine's occurrences in a row the group has now met. Two, three, five, seven, ten, 14, 21, 30, 50 and 75 in a row bring that many mascots down under parachutes, up to twelve, with a sentence that names the routine and the number. Every hundredth is a bigger drop, and one mascot on a gold canopy lands on the sentence. Nothing happens on the first occurrence and nothing happens between milestones. A late tick still counts for the occurrence it was late for; an occurrence nobody ticked before the next one arrived ends the run, silently. A routine that only keeps count has no run. This replaces the old target celebration on routines with a schedule.

Data. Nothing new is stored and nothing new leaves the group. To count the run, the phone reads the times of that one routine's ticks, and whether each was a shopping sub-tick, from the completion records every member of the group can already read — newest first, and only as far back as the run goes. It does not read who ticked. The count is worked out on the phone, held in memory for the drop, and never saved anywhere.

Why it is not a feedback feature, and why it sits inside the intentions assessment's §8A. The same three properties hold: the run is the group's, combined, with no way to ask for one person's; nobody is named or ranked; and it counts a chore, not anybody's response to somebody else's work. A rotation is a further reason it had to be the group's — with turns, nobody does two in a row.

Where it goes beyond §8A. §8A's target was off until a member chose one. This is on for every routine with a schedule, and we decided that with the difference in front of us. It is bounded instead by what it does not do:

• nothing shows the run between milestones — no badge, no number on the routine's row, nothing on Home or in the brief;
• it appears only on the phone of the member whose tick reached the milestone, and only once for that length of that run, however many times the tick is undone and made again;
• a run that ends is never mentioned anywhere;
• each member can turn it off for themselves with Celebrations at the foot of the Routines tool, or by asking the assistant. It is the same switch as the games' Celebrations, and the description says so. Reduce Motion replaces the drop with a still line.

Asking the assistant. A short fixed phrase such as "stop the parachutes" or "turn the celebrations back on" is recognised by our own server before any model is asked, so those words go nowhere else. Any other wording is an ordinary assistant request, handled and sent exactly as the assistant's other requests are. Either way the change is the member's own switch in their current group, and never at a shared display or from a forwarded email.

Children. A child account sees the same drop on its own ticks. A reward that grows with an unbroken run is a known way to keep someone coming back, and that is the risk for a child. We bound it as above rather than withholding it: there is no running count to protect, nothing is said when a run ends, the milestones thin out so it is not a daily reward, and the drop belongs to the household's run rather than to the child. A child can turn it off with the same switch.

R14 — A run can feel like something to protect, and now it is on by default (accepted 14 October 2026). §8A recorded the same doubt for a target a member chose. Here nobody chose it. Accepted because the run is invisible between milestones, its end is never remarked on, and one switch on the member's own phone turns it off. If it should become opt-in, that is one default to change.

What would reopen this: everything §8A lists, plus showing the run anywhere between milestones, any notification about a run, comparing runs across routines or groups, or keeping the count anywhere but on the phone.

10. 4 November 2026 — finding an existing routine for an edit

Assessed before implementation. A member who asks to change a routine may describe the job in different words. Within that request, the server first compares exact titles, then reuses semantic task search to compare the member's name for the job with open task and routine titles in their current group. Only titles are embedded, with the existing search limits (150 titles, 300 characters each, 200 query characters), in Sydney. No new index, processor, retention or consent purpose is introduced. Existing assistant access and privacy gates apply; embedding calls also retain the search surface's allowance and platform spend checks. Child accounts, 16–17s without consent and Device-only or unreadable levels are refused before embedding.

A clearly stronger match may be edited without another confirmation, as requested by the member. Close matches become one question naming up to three candidates, before any write. An ordinary task is identified as such and is never silently duplicated or converted. If semantic search is unavailable, the assistant asks for the exact title without suggesting unrelated tasks; titles are untrusted data, never instructions.

Structural protections: verified conversation group and caller's database session; unreadable titles excluded; the same row and version checked on update; ambiguous matches perform no write. Frequency and days still come from the member, never from similarity. Completion history and member identities are not embedding inputs. A routine remains eligible despite a legacy completion flag: its period, rather than that flag, identifies repeating work.

Residual risk accepted for this requested behaviour: semantic similarity can choose the wrong job even with a clear lead. The reply names the saved title and schedule so the member can notice; close scores ask instead. Matching thresholds require synthetic checks and an experiment, and do not establish real-world accuracy. No widening of the shared display's routine editing permissions is involved.

D132 — weekly targets can be met on one day (5 November 2026)

Founder/HQ authorised counting a weekly target against the group's whole Sunday-starting week, without a separate one-tick-per-day limit. Until the target is met, the routine remains Due and can be ticked again that day. It then stays crossed off until the next group week. This uses the existing completion rows, schedule columns, recipients and permissions; it adds no data field, recipient or collection purpose. Games keep their existing per-job/day/person scoring limits. Missed-turn representation is unchanged and belongs to the founder's separate design.

D137 — dated turns and private removal notices (5 November 2026)

This amendment supersedes the earlier description of keeping no missed-turn records. Written before implementation. Founder/HQ approved separate dated turns, a quiet Skip with Undo, and automatic removal of older open turns. At most the current turn and latest open past turn are shown. Unscheduled tallies and weekly targets without set days are excluded.

Stored facts and purpose. A routine-turn record holds the group/routine IDs, the turn’s calendar date in the group zone, its holder, and whether it is open, ticked or skipped. A skip records its date, whether it was automatic, and (for a manual skip) the actor needed to enforce Undo. It contains no task-title copy, explanation or assessment of a member. A completion names its own turn date so ticking a past row never ticks today’s row. Skips produce no completion, game credit, streak credit or rota advancement. The routine’s history shows automatic skips without naming a member.

Who sees it. Turn records follow routine-completion boundaries: active members of that group may read them; changes go through guarded routines that check membership, session and scope. Shared displays gain no new controls or access. Manual Undo belongs to its actor. A group switch clears the derived turn rows together with the tasks that carry them.

Child delivery decided (founder, dashboard, 5 November 18:59). Under-16 members receive the same prewritten words as a private notice in Tasks. They never enter the assistant session or message path; those restrictions stay unchanged. Adults retain the existing private transcript path. Delivery uses the same recipient-only removal ledger and unique routine/member/removal key. No additional copy of the title or message body is stored on the server: Tasks derives the words from the routine title this child's device can already open. Identifiers are not displayed.

Only the affected child can load or acknowledge their notice, including when their guardian is another member of the group. A notice remains pending until the child taps the existing “Got it” control. That acknowledgement sets the ledger's existing delivered timestamp, idempotently; subsequent device loads and retries cannot recreate it. An already-open second device refreshes on its next Tasks visit. Pending rows are deduplicated by their stable ledger ID, not posted anew on render. Client notice state is cleared on group/account changes and excluded from restored group caches. Unknown age fails closed. There is no new push, model call, social response, notification count or report of the child's acknowledgement to the group.

D137 private delivery. Each automatic removal creates one delivery record per affected member, keyed uniquely by routine + member + removal. Only that recipient can read or deliver it. If Alex’s and Jo’s old turns are removed together, each gets one message covering their own removed turns; neither message names or describes the other person’s turns. Repeated loads, re-renders and a second device cannot make a second delivery. A member with no eligible private recipient gets no message addressed to somebody else.

Adult delivery uses the existing private assistant transcript path, not group chat, a push, the daily brief or a model request. The recipient’s device writes the prewritten words using the existing transcript sealing helper and that member’s key; an outbox holds identifiers, not opened routine words. The existing no-key transcript fallback and later sealing job remain unchanged. Messages are delivered when the recipient next loads the group, rather than claiming immediate delivery to an offline phone. A stable message ID and a database uniqueness constraint make a retry after a lost response safe. An insert trigger acknowledges delivery in the same transaction, so closing before the client’s follow-up acknowledgement cannot create a second delivery after transcript retention. No model is called to write or deliver it.

Retention and erasure. Turn/skip records last with the routine, so a skipped turn does not reappear after a history window expires. Routine/group deletion cascades them. Download my data includes the turn and delivery rows through the caller’s existing RLS-scoped export. Private delivery records follow recipient account and group erasure; delivered identifiers remain with the routine solely to prevent repeat delivery after the private transcript’s existing 30-day sweep. For adults, the words follow the transcript’s existing retention and account erasure. Child notices have no stored message body; pending and acknowledged ledger identifiers last with the routine, including after dismissal, solely to prevent repeated delivery. Routine/group deletion and recipient-account erasure cascade those rows, and the existing recipient-scoped export includes them. No new recipient, processor, analytics event or tracing payload receives them.

Residual risk and checks. A skip is a new stored fact about a person’s turn and other group members can infer a lapse from its date; this is the founder-approved history, with no public attribution of automatic skips. The private notice can still feel like a reminder: it is limited to one notice per person/removal, uses no count or comparison, and names nobody else. RLS and RPC tests cover strangers, another member’s private delivery and Undo, group/session boundaries, and retry/concurrent delivery. Tests remove two members’ turns together, assert two private messages, then re-read and assert no duplicates. Screen tests cover each dated period, per-turn ticks, Skip/Undo, the two-row cap, group-zone/DST boundaries and histories/streaks ignoring skips.

6 November 2026 — saving routine edits during a visit

Assessed before code. Existing routine edits save after the member changes a control; text waits for blur, Return or Done. This changes when the existing group-only write happens, not its fields, recipients, retention or processors. Creation and assistant proposals still need explicit approval. A pre-filled edit is a draft until the member approves it or edits. No chat or push is added. Children keep the same editing access and server boundaries.

Risks are accidental control changes, partial invalid forms, writes after a group switch, and Undo overwriting another member. Controls keep their selection semantics; invalid forms never write; each visit captures the group, account and routine; pending work lives only in the open sheet. Done/back wait or offer leaving the last saved state. One close-time Undo restores the opening snapshot only against the version this visit committed. Offline work is never added to the outbox. People changes wait for close if intermediate rosters can change the turn. Residual: other members can see valid intermediate edits through the existing realtime channel; the member sees a live status and can undo the visit. No new history, analytics, model input or record of an Undo is kept.