← All privacy impact assessments

PIA: faster commands in the typed assistant

Status: Assessed before code; implementation authorised. Revised before the staged-card and companion action-card/share implementation on 10 October 2026, and again the same day before the routines, due-time and meaning-matching work. Amended on 11 October 2026, after the pre-registered run of the tick-by-meaning question measured it: the immediate tick is now limited to a row the person named by its own title, and a row our narrowing reached by a shared word stem is always asked about. Amended again on 14 October 2026, before the code: one request may now add several new tasks, always shown as a list for Approve first, and two more wordings are read (“add tasks …” and a feed said the way people dictate it). Amended once more on 14 October 2026, before the code: a typed request that asks for several different things may now be divided where the verifier is sure about every place it divides, and each part is handled as if it had been sent alone, except that a part the faster route handles always waits for Approve when it would change something (a part the ordinary assistant handles acts as that assistant does today); it is built behind a switch that is off. Revised again the same day after a review: several tasks in one sentence is offered only to a member who has acknowledged the policy version that describes it, on an app that can show the list, and otherwise reaches no TypeSafe call. The fast route remains off until the app can show the updated privacy disclosure and the member has acknowledged it. Written: 10 October 2026 · Last revised: 14 October 2026 Nothing here is legal advice. Children's Code references are to the exposure draft and may change on registration.

Guided-command extension (assessed before code on 10 October 2026): This release may ask a short sequence of fixed questions when an otherwise eligible direct request lacks a required field. The controls below apply to that exchange as well as a complete one-turn command.

Routines, due times and matching by meaning (assessed before code on 10 October 2026; none of it built): Repeating work is becoming a routine of its own rather than a task that comes back, a one-off task can carry a time of day, and four new judgments ask the verifier to choose between candidates our own code has already found: which open task or routine somebody means when they say they have done it, whether a task request is really a repeating arrangement, the same matching behind a spoken tick, and whether an “and” in a shopping sentence separates two items. Two things change in what leaves our server: open task and routine titles that other members wrote can be sent as candidates, and a typed shopping sentence can be sent to be split. Every control below applies to all of it, and a member sees and acknowledges the updated disclosure before any of it applies to them.

Dictation on “Add several at once” (12 October 2026): The microphone now beside the paste box on that sheet is a second surface for the same in-app dictation as the assistant's own, and not the spoken route assessed above: the phone's own transcription is preferred and named on screen while it is in use, Apple's or Google's speech service transcribes under their terms when the phone cannot, a member who has chosen on-device transcription only is refused rather than quietly sent to that fallback, and the audio never reaches our servers in either mode. The words go into the box as the member speaks; after a pause or Stop, sorting starts without another tap. The proposed lines remain reviewable, and Accept is still the only write. The exclusions that already apply to a typed list — a child account, a managed member, a Device-only group and the shared display — apply unchanged at that moment.

Phone microphones act when speech ends (12 October 2026, assessed before code): Group chat sends the final transcript as a group message and the private Assistant submits it as a turn after the recogniser's silence pause or Stop; the meal-plan constraints box reruns its existing allocation preview with the dictated constraints, still requiring Adopt to save the plan. A dictated message can be misheard and sent before its author rereads it. This removes a deliberate review moment, which is the residual risk accepted for faster hands-free use. The microphone notice must say plainly that words will be sent or processed after the pause or Stop; failed, empty and aborted sessions do not act. Group chat keeps its existing audience, sealing, notification and offline queue, while the Assistant keeps its account, privacy, consent and spend gates. Audio never reaches our server. A typed draft and the Send button remain available.

1. Purpose and scope

An adult types a direct request to the assistant, such as adding an item to the shopping list or recording a baby's feed. For a bounded set of requests, our server proposes the command from the sentence and asks TypeSafe's Jev to verify that the proposed action and its fields match what the person asked. A verified command uses the assistant's existing tool and result path, so the person receives the same outcome or clarification as they would through the full assistant. Ambiguous or unsupported requests use the ordinary assistant before any write.

Jev answers three questions about request match, field faithfulness and completeness. Their minimum probability is used as a routing estimate, not a guarantee that a command is correct. Above 0.8, one complete eligible command may run immediately and the resulting receipt offers Edit and, for a created task or event with a safe reversal, Undo while it is visible, then minimises on the current screen. From 0.6 through 0.8, the app stages the complete command with Approve, Edit and Cancel; it changes no group record until the adult chooses Approve. Below 0.6, or if verification is unavailable, the original request follows the ordinary assistant route before any fast-route write. Deterministic validation and the existing tool's own permission checks still apply at every score. Other eligible writes may also run immediately; their receipts offer Edit without a misleading Undo button.

The first version covers selected task and calendar creates, edits and completions; shopping and pantry actions; selected baby logs; and bounded reads or requests to open an app view. It does not fast-route deletion or cancellation. A recurrence change to something already saved is still excluded: a request to make an existing task or routine repeat differently, to stop it repeating, or to shift its schedule goes to the ordinary assistant. The opposite case is now in scope — creating a new routine whose schedule the person stated in a recognised shape, where our code reads the schedule from their own words and fills in nothing they did not say. A comma-separated list is still excluded too, with two exceptions assessed below: a single sentence adding several items to one shopping list, and a single request adding several new tasks that carry nothing but their titles. “Next Monday” and other dates with more than one reasonable reading use the ordinary assistant. It handles exactly one complete command — counting one sentence that adds several items to one shopping list, or several new tasks, as one command — or declines the fast route. A second, looser reading of conversational wording (a baby's name as the subject, “X is done”, “need milk”, an event without the word event, a date such as “15 October”, a schedule mentioned in passing such as “bins every Tuesday”) is marked as requiring approval: whatever the verifier scores, such a candidate can only be staged for Approve, Edit or Cancel and is never written on a score alone. It is subject to the same single-command, name-resolution and field guards. A sentence with several different requests goes as a whole to the ordinary assistant before any tool runs, unless it is divided as described in “One request asking for several different things” below. This route is for direct requests by adults on their personal devices. It excludes children, a shared display or kiosk, forwarded mail and other inbound content, and Device-only groups. It excluded spoken requests entirely; this revision opens them for ticking and reopening only, on an adult's own phone, as set out below. The separate Mail Sifter assessment and its health-word exclusion remain unchanged.

Natural phone phrasing can be handled by conservative, reversible text normalisation (for example a smart apostrophe, a polite opening or an optional final question mark) and more whole-request patterns. Normalisation must not silently remove a qualifier, second request, date, person or negation. A free-text title or target with an ambiguous separator stays on the ordinary route instead of being split into a different command. The one exception is a task title, described in “Several tasks in one sentence” below, where the verifier judges each “and” or comma and any split is shown to the person before anything is added. A staged proposal must repeat the meaningful action and fields in the saved assistant reply, because its current-screen card can disappear after Cancel, expiry or relaunch; the reply remains under the assistant conversation's ordinary retention and audience.

For a single recognisable task create or assignment, one-off event create, or feed log that lacks a required slot, the server may return a predefined question with choice chips and a place to type an answer. It may ask at most four bounded questions. The guided fast route invokes neither Jev nor a direct domain write while any required slot is missing; it does not invent a value from a previous conversation. The adult can edit the original request or cancel instead of answering. Exactly one pending exchange stays in the personal device's screen memory, scoped to the authenticated member, group and original group timezone; it expires 15 minutes after the first question. A brief switch to another tab may leave an already-presented question available on return within that original lifetime, so someone can check a schedule or other detail before answering. If someone leaves the Assistant tab while a question or staged control is still arriving, that late control is not kept; the ordinary saved reply text or receipt may still arrive. Cancel, a new request, group lock or switch, member or group-timezone change, closing the Assistant screen or app restart clears the exchange. It is not a new server-side draft or table, is never resumed by a background model call, and gives no new recipient access. A displayed question is not an action, and answers are not authority to bypass ordinary permission checks.

Contextual answer options, assessed before code: The phone may add optional choices to those fixed questions using only its current group's already-authorised data: the group's own clock for day choices; recent, explicitly logged bottle-feed volumes for the same resolved baby; and the existing on-device event-time lookup over past, timed group events for a matching event title. This is an aid to answering, not an inferred fact about a new feed or event. A feed-volume option must come from a finite, positive, explicitly recorded volume in a recent feed (bounded to the past seven days), never a target, forecast, duration, free-text note, nursing-only record, other baby's log or older routine. It must respect the recorded source: do not suggest a formula amount from an expressed-milk feed as if it were a formula precedent, or vice versa. A displayed value says Recently logged, with the source where known; it never says a baby should drink that amount. An event-time option says Previous event time and uses loadEventTimeHistory with lookupEventTimeLocally's existing exact-title-first, guarded-spelling match over past timed events. It is no claim that the person is free at that time or that the new event is advisable. A failed, stale, unreadable or cross-group history read yields no contextual option. These reads are on the phone under the member's existing access; no event title, feed row, candidate list or inferred pattern is sent to Jev, another model, a new endpoint or a tracing service merely to build the options. No remote embedding or ranking call is added. An option is never preselected or auto-submitted. Only what the adult explicitly chooses or types becomes one bounded answer in the guided exchange, where the ordinary Jev and optional trace disclosures then apply. All options clear with the pending flow and are recomputed for the current group, member, baby, title and group time rather than reused after a lock, group switch or relaunch.

Each guided request carries the original sentence, up to four bounded answers and the frozen group reference instant. The server treats that envelope as untrusted: it reparses the original request, validates the question sequence and answer shapes, re-resolves dates and names against fresh authoritative group context, and constructs only a closed eligible command. It rejects stale, changed-group, contradictory, extra-action or malformed exchanges before a fast tool. Once complete, Jev checks the current guided exchange and complete candidate, with the same name replacement and no general conversation history or fetched records. An unsupported or unavailable guided route hands the whole exchange to the ordinary assistant, even if a slot is still missing, so the adult need not repeat their answers; that ordinary route may use its model and tools under its existing clarification and permission gates. If the adult instead types a new, independently complete command in reply to a question, the pending exchange ends and only the new words enter the ordinary assistant under a fresh group clock. A bare Cancel or equivalent ends the exchange with a no-write reply. A medium-score stage and later Approve preserve the frozen reference instant and validated answers, then repeat current group, identity, permission and target checks before a write. An edited original starts a new exchange rather than silently applying old answers to different words.

Where a task command names an assignee, our server resolves it against the current active group roster before Jev, execution and later approval, using that member's recorded name. An explicit “me”, “myself” or “I” can mean only the authenticated requesting member, if that member is in the active roster. An exact full name, or a given name shared by exactly one eligible member, may identify that member; a shared given name, absent person or unsupported nickname takes the whole request to the ordinary assistant before Jev or a fast-route tool, never to an unassigned fast-created task. A task-assignee spelling suggestion is possible only for a name of at least four letters with one edit from exactly one current member's name and no competing match. It is visible on the staged proposal and forces Approve, Edit or Cancel even if Jev scores above 0.8; there is no immediate write from a correction. Baby-log names use only exact full or unique given-name matches against the current unarchived baby roster: a misspelling never becomes a fuzzy health write. The stage names the proposed person. No family relationship (“mum”, “dad”, “my partner”) is inferred from membership, chat or past actions. This release adds no alias or relationship profile; those would need explicit current profile fields and a separate assessment. The existing tool still applies its own membership, permission and target checks after verification.

Routines and due times, assessed before code: Repeating work becomes a routine of its own, and a one-off task can carry a time of day as well as a date. The strict shapes gain “Add routine Water the plants every Tuesday”, with or without a time, and the plain frequencies people say — every day, weekdays, every week, twice a day — along with “Open routines” as an opener beside opening the shopping list. The existing task shapes gain a time: “Add task Job application due Friday at 5pm” and “Set Job application due Friday at 5pm” record 5 pm on the group's clock, never the device's. “X is done” and “Reopen X” now also work on a routine: they tick or untick the occurrence that is due, and the matching Undo removes exactly that tick and hands the turn back. Two reminder phrasings stay deliberately different, because the words people use are different: “Remind me to collect the parcel tomorrow at 7pm” creates a task due at that time whose reminder is at the time, while “Remind me about task Rent tomorrow at 7pm” sets a reminder at that clock time and leaves the deadline alone — a custom time, which is not recalculated when the deadline later moves. A looser phrasing such as “bins every Tuesday” is read, but can only be staged for Approve, Edit or Cancel, whatever the verifier scores. Because a schedule is now part of what must be checked, the request we send the verifier writes the due time, the schedule and the order of turns out in words — “every Tuesday at 7:00 pm”, then the rotation in order — with every name replaced by a placeholder as before. Anyone who may tick a routine can tick it, not only the person whose turn it is: credit goes to whoever did it and the turn moves on from them, so the receipt names whose turn it was and Undo gives that turn back.

Ticking and spotting duplicates by meaning, assessed before code: A fast completion needs the task's exact title today, so “I did the bins” does nothing for a routine called “Bins out”. For a completion or reopen, our code now gathers the routines due now and the open tasks in that member's current group, narrows them to about eight by matching the words of the request, and asks the verifier one choice question: which of these does the person mean, or none of them. The candidates are the group's own titles with names replaced, in our own order of match strength, with “None of these” last, because the verifier tends to favour whatever it is shown first. A clear match above 0.8 ticks at once with Undo only where the person's own phrase for the job is that row's title, bar capitals, spacing and punctuation — “bins out” for “Bins out”, which is the person naming the row and the verifier saying which of the group's rows they named. Wherever our narrowing had to share a word stem to find the row at all, the person is asked, at every score: “watered the herbs in the greenhouse” beside an open “Water the plants” becomes “Tick “Water the plants”?” rather than a tick. That narrowing is ours, and the measured run of 11 October 2026 found it the whole of the error: a request matching nothing was read as a stem-sharing row in 15 of 15 samples at 0.90–0.95, one hundredth below the right rows, so no probability separates the two and this limit is a shape rather than a higher number. A score between 0.6 and 0.8, or a top choice that does not stand clear of the second, becomes “Tick Bins out?” for the person to confirm; below 0.6, or with no plausible candidate at all, the ordinary assistant handles the sentence and nothing is ticked. The same candidate list answers a different question when something is being created: an open task or routine that means the same as the one being added is shown as “You already have Bins out. Add another?” instead of a second copy appearing quietly. This is the material change in what leaves our server. Until now the verifier saw only the words the requester typed and the fields we proposed from them. It can now also see up to about eight existing titles, which other members may have written, and a title can name a child, an appointment or a care task.

A task request that is really a repeating arrangement, assessed before code: “Add task bins every Tuesday” and “remind me every Sunday to call Mum” describe something that repeats. The verification request we already send gains one more yes/no question — is this a repeating arrangement — so there is no extra call and no data beyond what that request already carried. Our code, not the verifier, reads the schedule from the person's own words. Above 0.8 the person is offered “Make it a routine?” and always confirms; nothing is created from the answer by itself, at any score.

Ticking by voice, assessed before code: The earlier version of this assessment kept spoken requests out of the fast route entirely. This revision opens that door for two actions and no others: ticking and reopening, using the matching described above. “Tell GroupApp the bins are out” ticks the routine, and the spoken reply says what was done, because a spoken answer has no card to show. An uncertain match is asked back as a spoken question rather than acted on, and anything below that keeps the ordinary assistant. The shared display and child accounts never take this route, and neither does a Device-only group. Correction happens afterwards in the app: the reply names what changed, and the Undo or edit for it is on the person's own phone. A spoken request is not added to an improvement trace, because spoken turns are not traced.

Several shopping items in one sentence, assessed before code: “Milk, eggs and bread” is three things somebody wants on the list; “mac and cheese” is one. Our code splits the sentence at commas and at “and”, and the verifier answers one yes/no question for each join: do the words on either side name two different items. An uncertain split is staged for the person to confirm before anything is added. This narrows the earlier exclusion of comma-separated lists for shopping adds alone: one sentence putting several items on one list is one command, while a sentence asking for two different actions is the separate case described in “One request asking for several different things” below. Whether a new item is the same thing as one already on the list, and which aisle it belongs in, are separate judgments assessed in our shopping assessment, which also covers the item words those judgments send.

Several tasks in one sentence, assessed before code (14 October 2026): “Add tasks wash the car and pay the rent” is two jobs; “add task wash and dry the dishes” is one. When a request to add a task carries nothing but its title — no person, day, time, reminder or schedule — and that title contains “and”, a comma, or a comma followed by “and”, our code finds each of those joins, at most three of them and so at most four tasks, and checks that every piece would be an acceptable task title on its own. If any piece would not be, nothing changes from before: the request goes to the ordinary assistant. Otherwise the verifier answers one more yes/no question for each join, in the same check it already makes: does that join separate two different things to do, rather than sit inside one job's name. When it is clear that every join belongs inside the name, the request stays one task with “and” in its title and follows the usual bands. When it is clear that at least one join separates two jobs, or it is unsure about any join, our code cuts the title where the verifier leans and the result is a card listing each task in order. That card always waits for Approve, whatever any probability says. It is offered only after a second check by the same verifier over the list itself — whether these are the tasks the person asked for, with nothing added, changed or left out — and below the usual staging line, or with no answer, the ordinary assistant takes the request before anything is written. On Approve, our server reads the request again, rebuilds the list and checks it against what the card showed, and adds each task in order through the existing task tool under its own checks; a title that is already an open task in the group says so on the card, and Approve then adds another, as it does for one task. The receipt names which tasks were added and which were not, nothing is retried on the person's behalf, and Undo removes exactly the tasks it added. Only an app that says it can show such a card, used by a member who has acknowledged the policy version that describes this reading, is offered it at all; for anyone else the sentence is read as it was before, refused by our code and answered by the ordinary assistant, and it never reaches TypeSafe. What reaches TypeSafe that did not before. Until this amendment our code refused a task request with “and” in its title, any request containing a comma, and the plural “add tasks”, so those sentences went to the ordinary assistant and never reached TypeSafe. Now they do: the request, as before with names replaced, and — for a request read as several tasks — a second check carrying the same request and the list of titles our code cut from the person's own words. Nothing else is added: no history, no group records beyond the existing duplicate check, no roster. The other new thing is that one request can create several tasks, each shown before any is added. A sentence asking for two different actions — a task and a feed, say — is not a list of tasks; it is the case described next.

Two more wordings, assessed before code (14 October 2026): “add tasks …” is read exactly as “add task …” is. A feed said the way people dictate it — “log a feed for Remi of 120 mils” or “log a 120 mil feed for Remi”, with “ml”, “mls”, “mil”, “mils”, “millilitres” or “milliliters” — is read as looser wording: it can only ever be staged for Approve, the amount has the same limits as every other feed, and the baby must match the group's own list exactly as for every other feed log, never by a near spelling. With no milk source named, the existing guided question asks “Was it formula or expressed milk?” and the answer fills it; nothing guesses one. The same units are accepted by the feed wordings already on the list.

One request asking for several different things, assessed before code (14 October 2026): “Log a 120 ml formula feed for Remi and add task call the plumber” asks for two different things. Until now the whole sentence went to the ordinary assistant, which takes 9 to 14 seconds, even when each part on its own is something the faster route does in about two. Now, when a typed request does not read as one faster command — the several-tasks reading above is tried first and is unchanged — and it contains a place where it could divide (“and”, a comma, “then”, “and then”, or the end of a sentence — a full stop, question mark or exclamation mark — followed by more words), our code proposes a division into at most three parts. Our code refuses the division outright, with no call to the verifier, when a later part refers back to an earlier one (“it”, “that”, “them”, “her”, “him”, “there”, “the same”, “also” and the other words the parser already refuses), when a later part opens with a word that only continues the one before (“with”, “for”, “tomorrow”, “Friday”, “at”, a date or a clock time), when any part does not open a request of its own — one of the parser's own command words (“add”, “log”, “remind”, “book” and the rest), or a shape the parser reads that is led by one of its own subject words or a baby's name (“Remi had a wet nappy”), so that “Member B from school on Friday”, “Max”, “dry the dishes tomorrow” or “eggs and bread” opens nothing — when any part carries a condition, hedge or negation, when the division would make more than three parts, or when no part would be one faster command on its own, because dividing such a sentence cannot make anything faster. Otherwise the verifier answers one yes/no question for each place, all in one call: do the words on either side ask for two separate things, each of which makes sense on its own? It sees only that request, with one place marked for each question and names from the group's member and baby lists replaced — no earlier conversation, records or roster. The request is divided only when every place is decided: at 0.8 or above it divides there, at 0.2 or below it stays joined, and anything in between, a refusal or no answer keeps exactly today's behaviour, the whole request going to the ordinary assistant. When every place stays joined, today's behaviour holds too, and so it does when the parts left after a place stays joined hold no faster command at all.

Each part is then handled as if the person had sent it alone, with two differences. A part that reads as one faster command takes the faster route with its own verification and its own bands, except that in this first version a faster part that would change anything always waits for Approve, whatever the verifier scored: nothing divided is written by the faster route without the person's own tap. A part that only reads, such as “what's on today”, answers as it would alone, because it changes nothing. A part that would wait still waits; nothing is promoted because it came from a longer sentence. Any other part goes to the ordinary assistant with only that part's words, alongside the earlier conversation the ordinary assistant always receives, and never the rest of the sentence; the ordinary assistant then acts on it as it acts on any request today, with its own receipts and, where it has one, its own Undo. And a part never starts a guided question: a part that is missing a detail goes to the ordinary assistant, which asks in words. Whether a divided faster part may ever act at once is for the pre-registered measurement and a decision after it. Measured on 14 October 2026, and the answer is not yet: on invented requests, two different actions divided correctly every time, but a task followed by a reminder about it (“add task call the plumber and remind me tomorrow at 9am”) was divided in every sample, and its task part would otherwise have been added at once. So every divided faster part keeps waiting for Approve. Since then, our code also refuses a later part that is a bare “remind me” with a time and nothing of its own to be reminded about, so that shape now takes today's route before the verifier is asked. The parts run at the same time, each under its own operation key, made from the original message and that part's own words, so no two parts share a key and a request delivered again and divided the same way meets each part's own replay guard. A request delivered again and divided differently can give a part a new key, and the ordinary assistant could then repeat that part's write, as it can when it sorts a re-delivered request differently today; the app never re-sends a request that may have started. Nothing is retried on the person's behalf. One reply shows every part in order, each labelled with its own words: a card with Approve or Undo, a receipt, a question, a refusal or an error. A part that fails is named and the others still show. Only an app that says it can show such a reply receives one, and only for a member who has acknowledged the policy version that describes it; everyone else keeps the whole request going to the ordinary assistant. All of it is behind a switch on our server that is off, and stays off until the measurement has been read and the notice that describes it has reached phones; off, nothing about any request changes.

What is new for the verifier. A sentence our parser could not read as one command now reaches TypeSafe for the division question, which it did not before. Where the separate routing step assessed in our routing assessment is switched on, such a sentence also reaches TypeSafe for that step; the division is gated, measured and switched separately, and does not depend on it. Each part that is then a faster command sends TypeSafe that part, exactly as the same words typed alone would. Design choice. Our server runs the parts itself, as parts of the one request the person sent, and answers once. We considered answering with the parts and letting the app send each as a request of its own, and rejected it: the app would choose what each request said, every part would repeat the sign-in, allowance and roster checks and wait for its own round trip, the person could type again between the parts, and a dropped connection could leave a part unsent with nobody told.

What stays out of every one of these judgments: a Device-only group, the shared display and a child account get whatever our code decides on its own, and nothing about their requests reaches the verifier. If the verifier does not answer — no key, a refusal, a timeout, or a reply we cannot read — each use falls back to the behaviour it would have had without it: a completion needs the exact title again, a create asks nothing about duplicates, a shopping sentence is added as it was typed, and a spoken request that needed a choice goes to the ordinary assistant. No write anywhere depends on the verifier answering, and no error about the verifier is shown to the person. The thresholds named above are starting estimates. Each judgment gets its own set of written-out cases, including the effect of the order candidates are shown in, and its numbers are read from that set before it is turned on for anybody.

The benefit is a quicker answer for routine commands without letting the verifier browse the group's records or choose from a tool catalogue. This assessment does not authorise open-ended action, background action, autonomous learning or transcript mining.

For a member who has separately turned on Help us improve the assistant, each server request in a guided exchange joins that request's existing LangSmith trace: the rule match, bounded question and answer state, completion or fallback, and, when complete, what was sent to Jev and returned, score and route, a staged or executed outcome, ordinary-tool result and reply. A later Approve is a separate assistant request and trace; its original reviewed sentence and answers are added only after the server has validated the member, group and review envelope. Outline traces use bounded labels and counts, never the words of an answer; full traces use the existing content scrub. This is for diagnosing the assistant, not a new learning loop. With the improvement switch off, no fast-command record is sent to LangSmith. Client-only Edit, Cancel and Undo taps are not new assistant-turn traces or telemetry.

The same release also clarifies existing assistant action cards. A task or event already created by an assistant tool is an existing group record even if an older card calls it a “draft”; that card must show the recorded outcome and offer Edit or a guarded Undo where supported. A true proposal that has not written a row offers Approve, Edit and Cancel, and says explicitly that nothing changes until approval. The old AGENT_DRAFT “Send to group” confirmation and automatic announcement path is removed; creating a group task or event must not silently publish a message to group chat. An adult may instead long-press one of their private assistant messages and choose Copy or Send to group chat. The existing group-chat Send to GroupApp action sends feedback to GroupApp's team after its separate two-tap disclosure; it is renamed Send feedback to GroupApp without changing that recipient or flow. (Since 31 October 2026 the group chat no longer offers it; see the feedback assessment.) A distinct new Send to assistant action prefills the selected group-chat text in the member's private assistant composer; it does not submit the text or contact a model until the member sends it. These changes do not add a Jev input or a background sharing path.

2. Data involved

What the verifier now receives in addition, and only for the request in front of it: for a tick, reopen or duplicate check by meaning, up to about eight of the group's existing open task and routine titles as candidates, name-replaced, in our own order, with “None of these” last; for a routine, its schedule, due time and turn order written out in words; for a shopping add, the sentence being split; for a task request whose title contains “and” or commas, that title with each join marked and, when it is read as several tasks, a second check over the list of titles our code cut from it; for a request asking for several different things that our parser could not read as one command, that request with each place it could divide marked in turn, and then each part that is a faster command, as that part alone would be sent. The task titles and the parts are the person's own words from this request, not group records. The other additions are existing group records the requesting member can already read, bounded to that member's current group and to the action they asked for. They are not stored for this purpose, not sent for any request that did not ask for one of those actions, and no candidate list, score or chosen title becomes a profile, a learned preference or a saved match. One of these judgments costs one call per request, not one per candidate; the repeating-arrangement question and the per-join task questions cost none, because they ride in the verification request we already send, and a request read as several tasks costs one more call, over the list. Dividing a request costs one call for all its places, and each part that is a faster command then costs the calls it would cost on its own. Each call is counted in our own usage and spend records, which carry counts, outcomes and reasons and no group, member or words. Beyond that, the verifier does not receive general conversation history, fetched task or calendar rows, baby records, a roster, tool outputs, credentials or a list of available tools. For a one-turn command it receives the current request; for a completed guided command it receives only that current guided exchange: the original sentence and up to four validated answers. In either case it receives the candidate's allowlisted fields and a small server-checked mapping of referenced name variants to resolved names, with names replaced by placeholders throughout. This reduces direct identification; a sentence or answer can still identify someone through a relationship, place, unusual event or a name absent from the roster. GroupApp's server necessarily receives the exchange under the existing typed-assistant flow. No new table, separate transcript, training set or per-member classifier profile is created for this route. The pending exchange, staged proposal and immediate result card live only in app memory, scoped to this member and group; the pending exchange expires 15 minutes after the first question. A presented question can survive a brief tab switch, but Cancel, a new request, lock, group or member or timezone change, closing the Assistant screen or restart clears it. A question or staged control still arriving after the tab is left is not kept; an ordinary saved reply or receipt can still arrive. These states do not enter action_stacks or another durable draft store. Assistant messages already sent may remain in the existing private conversation under its ordinary 30-day rule; clearing in-memory state does not erase those messages or an already-sent opted-in trace. An approved action remains in the underlying group record until it is changed or removed under that tool's normal rules. Existing optional tracing choices continue to apply to each server request.

Name resolution uses the existing authenticated, group-scoped roster read and a fresh read of current, unarchived baby profiles. A failed baby-roster read refuses the fast route rather than treating an unknown baby as absent. Resolution creates no reusable nickname list or inferred relationship graph. The resolved person IDs enter the server's candidate fingerprint: if a member or baby with the same name is replaced, renamed or archived before Approve, the saved preview no longer matches and cannot execute. Immediately before a fast write, the domain tool also compares its own newly resolved assignee or baby IDs with the prepared IDs and refuses the write if they differ; ordinary tool calls do not use this extra guard. Jev receives the original request, resolved candidate and a small server-checked mapping from referenced name variants to resolved names, all with names replaced by placeholders; it receives no roster or raw person IDs. The replacement maps for Jev and an opted-in full LangSmith trace cover every active member's and unarchived baby's recorded name and the first name of it, the name variants this request referenced, and one-edit typos; a reference to “me” is not a name and is not given a placeholder. Separate placeholders may represent a variant and its canonical name, with the checked mapping linking them; a first name two group members share is replaced by one placeholder that identifies neither of them. Since 11 October 2026 that family of placeholders is built beside the server's own roster read and shared with the assistant's other verified Jev requests, so this route no longer carries a replacement rule of its own and what the verifier sees here is unchanged by the sharing. Neither receives the full roster for this resolution. A reference to “me” must preserve its link to the authenticated requester without letting Jev choose a different person. A spelling suggestion is shown to the adult in the staged summary and is never treated as silent correction. The original misspelling may remain in a longer contextual phrase that name replacement misses; a name-free phrase may still identify someone. The saved summary is an existing assistant-message copy of the proposal, not a new durable action draft or an instruction to execute it later. Beside it, the saved reply carries a closed label — whether it was a card waiting for Approve, the receipt of an Approve, or an action taken at once — and, for a list of new tasks, the identifiers of the tasks it added; no words. The app uses them only to show an answered card as one line saying what happened, and an undone list as one card.

The optional LangSmith record is built by our server, then scrubbed before sending. In its outline, it names bounded guided-question and answer steps by code or count, completion or fallback, and the rule-match and verification steps, the command domain/kind, each of Jev's three question outcomes as bounded scores or codes, model, token counts, latency, a fallback or refusal reason, stage/approval status, tool name and result status, and the reply outcome. It carries no request words, candidate values, review fingerprint or raw member/group identifiers. Requests in one guided exchange may share a short keyed flow tag derived from its group, member, frozen instant and original sentence; the raw values stay off trace metadata. It links the questions and answers for up to the trace retention period and is not a client tracker. A staged request and its later approved request may share a short review tag: our server computes it as a keyed hash of the validated review's operation identifier, so LangSmith can pair the two separate requests without receiving the identifier or review envelope. A duplicate approval may carry the same tag. For a full typed-assistant trace, it can also contain the original request, guided questions and up to four answers, copied candidate fields, Jev's three question inputs and outputs, the displayed staged-proposal summary and fields, tool arguments/results and reply, including health or child-related words; the raw review envelope is not included. The existing name replacement and removal of identifiers, emails, encoded values and credentials apply to every content field before it leaves our server. Approval is its own request trace and may include the original reviewed request only after identity, group and envelope validation. A rejected approval stays an outline or records only the independently supplied current text under the existing full-trace rules; it must not expose unvalidated review contents. No raw fingerprint, group or user ID is put in trace metadata.

The changed controls on older action cards do not erase an already-created task or event. Guarded Undo acts on that exact saved row; Edit opens the authoritative task or event view. A saved-task or genuine task-proposal card may show its existing notes, why it was suggested, creation source/person, and, only when the task has an exact plan_task_id link into the already-loaded current plan, that plan task's estimated minutes and related recipe name. These are presentation of existing group data under the card's current audience, with no new model call, stored copy or title-based recipe guess; missing or sealed-unreadable detail is omitted. This does not create the missing acceptor audit for Issue 272. A person's deliberate Send to group chat action copies only the one chosen, readable assistant reply through the existing group-chat send path, prefixed “Shared from my assistant:”. It is then a group-readable message, attributed to the sending member, with group chat's existing sealing, notification, retention and deletion behaviour; it no longer shares the private assistant conversation's audience or 30-day transcript rule. There is no automatic post, hidden assistant attribution, whole-thread share or additional model call for this action. Copy stays on the device clipboard under the device's ordinary clipboard behaviour. Send to assistant only prefills the selected group-chat text; the member can edit or discard it before sending. If sent, the existing private assistant and model gates apply. Send feedback to GroupApp remains the separate consented two-tap submission to GroupApp's team, with its existing redaction, retention and recipient disclosure unchanged.

3. Flows and locations

TypeSafe is an additional United States processor. Health information, including a baby's log request, may be in the adult's original words and candidate fields sent there. The main assistant already uses Vertex AI's global endpoint for non-Device-only groups, which may process outside Australia; that does not make an additional processor implicit in the earlier disclosure. Names are replaced for Jev only. The current Mail Sifter route still withholds health-word emails from Jev.

The fast route fails closed if parsing is incomplete, the sentence asks for more than one action and is not divided as described in §1, Jev is unavailable or slow, its response is malformed, its minimum score is below 0.6, or any ordinary gate refuses. A judgment that chooses between candidates fails closed the same way: no candidate, no clear winner, or no answer means nothing is ticked, nothing is merged and no duplicate question is asked, and the behaviour is what our code would have produced on its own. A fallback happens before any fast-route write. A medium proposal is screen state, never an already-performed action. Approval and an edited proposal must recheck current group, target, membership, privacy, consent and tool preconditions when the person acts; a stale card cannot assume the world still matches the original turn. The execution endpoint accepts a closed command, never an arbitrary tool name or caller-supplied group authority. Jev determines routing, not authorisation: an authenticated adult's explicit Approve is a direct command request. The preview fingerprint detects accidental client/server drift; it is not a security credential or proof that Jev ran. Existing row security, group checks and domain tools remain the write authority. Once execution starts, a failed or uncertain write is reported from actual tool outcomes and is never retried by replaying the request. TypeSafe receives no database key. TypeSafe says it does not train on the input; zero data retention is a separate enterprise provision and is not assumed here.

4. Legal basis and choices

The adult initiates each request. The group must already permit the server assistant, and the member's own narrower privacy ceiling and existing assistant consent gates still apply. Device-only cannot use this route. Before activation, the privacy policy and in-app change notice must name TypeSafe as a separate United States processor, the categories of typed request it sees, and that baby and health words can be included. The updated client must declare an explicit fast-command version capability, and the server must read that member's acknowledgement of the matching policy version before contacting Jev. An older client, or a member who has not acknowledged the new notice, continues through the existing assistant route rather than silently activating the new processor. Acknowledgement records notice, not an independent consent to a new purpose; the existing assistant and overseas-processing choices remain the operative choices, with their existing withdrawal paths. If those choices cannot be verified, refuse according to the existing privacy gate.

The disclosure this revision needs. The notice version that turns the fast route on is replaced, because what we send changes. It must say that for a request to tick something off, to add something that may already be on the list, or to add several shopping items at once, the group's own task, routine and item words — including titles other members wrote — can be sent to the same United States verifier with names replaced, and that a spoken tick or reopen can take this route on the member's own phone. A member who has acknowledged only the earlier notice keeps the existing assistant route for these requests, exactly as an older app does, and so does a member on an app that does not declare the matching capability. Acknowledgement records notice of the change, not a new consent purpose; the existing assistant and overseas-processing choices remain the operative ones with their existing withdrawal paths. The shared display, child accounts and Device-only groups are unaffected, because none of them can use this route at all.

The disclosure the 14 October 2026 amendment needs. The policy's next version says that one request naming several new tasks joined by “and” or commas can be proposed as those tasks together, all shown for Approve before any is added, and that TypeSafe judges whether each “and” or comma separates two tasks. The reading needs that version's acknowledgement (revised after a review on 14 October 2026). This amendment first argued that the notice which turned the fast route on was enough, because these are direct typed requests from an adult and nothing of a different kind goes with them. Two things outweighed that. These sentences never reached TypeSafe before, because our code refused them, so what we send is new; and the policy's own account of the acknowledgement record says it decides whether the faster route may be used, which a member reasonably reads as this version's route. So the decision is made before anything reads the sentence: when a request holds a join this reading would offer, our server reads the member's own record of the latest version they acknowledged, and offers the reading only when that version describes it and the app says it can show the list. Otherwise the sentence is read exactly as before the reading existed: our code refuses a task title with “and” or a comma in it, the ordinary assistant answers, and no TypeSafe call is made. The record is read only for a request that holds such a join, so no other request pays for it. “Add tasks” with one title and the dictated feed wordings are single commands; they stay on the notice that turned the fast route on.

The disclosure the request-division amendment needs. This one does send something new: a request our parser could not read as one command now reaches TypeSafe for the division question. So it is gated on the notice. Before our server asks the verifier where a request divides, it reads the member's own record of the latest policy version they acknowledged, on every request, and divides only when that version is the one that describes it (version 3.6, dated 14 October 2026, or later). The policy's list of what changed, its faster-commands section and its automated-decisions section say so. A member who has not seen it, or an app that cannot show a divided reply, keeps the whole request going to the ordinary assistant. Acknowledgement records notice of the change, not a new consent purpose; the existing assistant and overseas-processing choices remain the operative ones with their existing withdrawal paths.

Where the disclosure lives from v3.13 (23 October 2026). The disclosure is the policy body (FASTER TYPED COMMANDS and AUTOMATED DECISIONS in section 5), plus the what-changed sheet for v3.6 to v3.12. The v3.13 sheet is the founder-approved summary since v3.11 and no longer carries these lines; its gates still read "this version or later", and their checks now assert the body. Residual, accepted 2026-10-22: an adult whose last acknowledgement is below v3.6 and who goes straight to v3.13 sees no sheet line for these features. They are notice gates, not consent, and the sheet links the body. New members do not see the sheet at all: sign-up acceptance records the version.

There is no background collection and no new consent purpose or database table. The optional improvement-tracing switch remains separate; turning it off must not prevent ordinary assistant use and does not authorise TypeSafe to train on a request.

The existing improve_app_traces choice governs LangSmith. It is separate from consent to use the assistant or overseas processing, and its current wording already covers a typed request, the assistant's intermediate steps, what it looked up, tool changes and response, including health and baby information. This change adds detail within that same opted-in assistant trace and no new destination or retention period. A person can use fast commands with the improvement switch off. Forwarded mail remains outline-only and is not eligible for this fast route; voice and the shared wall remain untraced, including a spoken tick. In an opted-in full trace of a typed turn, the candidate titles, the chosen match and a split sentence can appear under the existing name and identifier scrub; an outline records their count and the outcome, never the words. The trace is kept in LangSmith's Australian region for its existing 14-day base retention, subject to the deletion-on-request process and the existing unresolved possibility of overseas staff access described in the separate tracing assessment.

5. Risks and mitigations

6. Structural versus conventional

Enforced in code and test-pinned: a closed candidate schema and action allowlist; verified authenticated group context; caller and privacy-level gates; roster-name replacement before Jev; no general history or fetched-record fields in its payload; at most four bounded guided answers and one complete command before the first fast-route model verification or tool; server replay of an untrusted guided exchange at its frozen group instant with fresh context; short deadline; score bands (>0.8, 0.6–0.8, <0.6); an immediate tick by meaning only on a row the person named by its own title, with a stem-matched row always asked about; at most three joins in a task title, every piece guarded as a title on its own, a request read as several tasks always staged and checked a second time over the list, the list bound to the card's fingerprint against drift, and the reading offered, before anything reads the sentence, only to an app that can show a list and a member who has acknowledged the version describing it; for a request asking for several different things, at most three parts, the refusals before any call, one question per place in one call, a division only when every place is decided, each part run as its own request with its own words, operation key, checks and bands, no guided question started by a part, every part's outcome in one reply, every part opening a request of its own, every divided faster part that would change anything staged for Approve, both the notice and the app's capability required, and a server switch that is off unless set; no action from a medium card before approval; memory-only pending flow and cards with the guided question retained only across a brief tab switch and the stated expiry/identity/lifecycle clearing; reparse and full revalidation on approval; no arbitrary tool names; no fallback after execution starts; ordinary tool factories and outcome reconciliation. These are stronger than a prompt instruction, but most are not database or cryptographic constraints. Existing row security and group-scoped tools remain structural boundaries for the eventual record access.

Name matching and polite-text normalisation are conventional application rules, with deterministic checks that should fail loudly when a phrasing changes. The active roster read, fresh unarchived-baby read and authenticated requester are existing security boundaries; the conclusion that one given name is unique, that a one-edit task-assignee typo has one suggestion, or that a separator is unambiguous must be recomputed at each attempt, not carried from a stale client preview. The fingerprint binds the actual resolved people, not just their displayed spelling. No model or stored conversation supplies an alias or family role. A typo-forced stage is a code gate independent of Jev's probability; it is not a statistical promise.

For the companion card/share cleanup, existing tool outcomes and row ids determine whether a card is a saved receipt or an unwritten proposal. Existing task/event reversal guards constrain Undo; ordinary group-chat RLS, sealing and member attribution constrain an explicit share. A private assistant message does not become group-visible because a task or event was created; it crosses that audience boundary only when the member taps Send to group chat.

The optional contextual choices are phone-side presentation of existing group records, not part of Jev's payload or a new learned profile. The event-time lookup's RLS read and local title matching already exist; the new feed-volume filter and same-baby/source/recency constraints must be test-pinned. Choice labels and the decision to tap remain conventional. The server must still reconstruct and validate a chosen answer as untrusted input; a client option carries no authority to select a person, infer a care target or skip a required question.

The improvement record must be assembled from explicit server steps, never from the full request body, graph state or an unvalidated review envelope. The existing trace middleware reads the member's own opt-in on every request and sends to a fixed Australian workspace; its outline/full split and scrub are code paths pinned by checks of the actual outbound payload. Step labels, scores, counts and fallback codes are conventional application choices, even when test-pinned. A complete diagnostic trace is still bounded by the tracing service's step and string limits; it cannot promise to contain every byte of an unusually long turn.

For the routines, due-time and meaning work, each piece sits in a different place:

• The routine and due-time shapes are conventional parser rules with deterministic checks: which phrasings are recognised, which plain frequencies count, reading a stated time on the group's clock, keeping a custom clock-time reminder apart from a deadline so a later change to the deadline does not move it, and the rule that a looser phrasing can only stage. What holds underneath them is unchanged and structural: the existing routine and task tools, their own permission and target checks, and a tick that records who did it. The widened exclusion is a code gate on recognised shapes, not a judgment: a recurrence change to something already saved is refused before the verifier is asked, and only a new routine whose schedule was stated can be built.
• Ticking and the duplicate question by meaning are a bounded candidate read under the member's existing access (structural — the same row security as any read they could do themselves), a narrowing and ordering rule in our code with “None of these” last (conventional, test-pinned), name replacement before anything leaves (code, pinned), the score bands and the stand-clear-of-the-second rule (code), and the existing tool's own refusal when the chosen record cannot be ticked (structural). The duplicate question can only ask; a failed candidate read or an unanswered judgment never blocks a create, and the create then happens without the question rather than claiming nothing similar exists.
• The repeating-arrangement question adds no call and no payload beyond the verification request we already send, and the offer to make a routine instead always needs the person's confirmation. That confirmation is a code gate independent of the probability, not a statistical promise.
• The spoken door is a caller check in our code — ticking and reopening only, an adult's own phone only, never the shared display, a child account or a Device-only group. It is a route check, never an authorisation, and it is not a database constraint. The spoken reply's accuracy comes from the actual tick outcome rather than a model sentence.
• The shopping split is our own split with one yes/no question per join and a staged confirmation when uncertain. Whether two items are the same thing, and which aisle an item belongs in, are assessed where they are built.
• The task split is our own split too: our code finds the joins and refuses the whole reading if any piece fails a title's checks, the verifier answers one yes/no question per join, and a request read as several tasks always waits for Approve and a second check — a code gate, not a probability. The existing task tool's own checks then apply to each create, and its exact Undo removes what was created. That the thresholds suit real phrasing is conventional until measured.
• The request division is our own proposal as well: our code finds where a request could divide and refuses before asking where a part refers back, continues the one before or carries a condition, or where no part is a faster command; the verifier only answers whether each place separates two requests; and each part then meets exactly the checks it would meet alone — a code property, pinned by checks that run a part both ways. That the refusal words and the thresholds suit real phrasing is conventional until measured.
• What is conventional across all of it: that the updated notice describes what now leaves our server accurately; that about eight candidates is the right bound; that the thresholds behave on phrasing people actually use; that a person hears and understands a spoken reply; and that a confirmation card is read rather than tapped through.

Conventional: the disclosure accurately names the extra processor and health scope; the chosen thresholds produce acceptable accuracy; the visible high-score card gives a person meaningful time to correct it before minimising; the client's capability means the member actually saw and acknowledged the version; TypeSafe's operational terms match our statements. Automated copy, payload and behaviour checks should fail loudly on drift, but they cannot prove model accuracy or provider practice.

7. Best interests of the child

Children cannot invoke this route from their accounts in the first version. An adult can nevertheless use it to create or edit a child's task, appointment or baby log. The child's interest is a useful family record entered accurately and a lower burden on carers; the cost is that words about the child are processed by an additional overseas provider and a false positive may put a wrong fact into their record. The minimum data sent to Jev is the request needed to check the command and the candidate being checked. It receives no fetched history or records. The safer alternative of always using the existing assistant remains available on refusal, but it does not remove overseas processing: the existing global model already sees eligible requests. The added processor and false-write risk are therefore disclosed and bounded, not denied. Existing age-appropriate explanations of what adults can record about children remain necessary; this route adds no child-facing assistant relationship.

A guided question may draw out an extra detail about a child's routine or health that was absent from the first sentence. Limiting it to a missing field and four answers reduces the added exposure, but does not make the answer harmless; the adult can cancel or use the ordinary assistant. No incomplete answer may create a child's record through the guided fast route or reach Jev, and a completed baby-log exchange still needs the strict baby identity and domain checks before a write.

Matching by meaning changes what a child's record can expose. A child's task or routine title — a physio appointment, a medicine, a school obligation — can now be one of about eight candidates sent for verification when any adult in the group says they have done something, even if the request had nothing to do with that child. We bound it to the group's open and due items, replace names, send it for that one request, and store nothing; we cannot make a free-text title unrecognisable. Against that, matching by meaning removes a real cost to children: today a carer's “I did the bins” does nothing unless they remember the exact title, and a tick that fails quietly is a record of care that never gets made. A wrong tick on a child's routine is the risk in the other direction, which is why a close call is confirmed rather than acted on. Children still cannot start any of this from their own accounts, including by voice, and a spoken tick cannot be made at the shared display.

A request adding several tasks can name a child's task among them. Each title is shown on the card before it is added, and nothing in the list is created until the adult approves it, so this adds no write about a child that the adult has not read.

Dividing a request can put a child's part — a feed, a nappy, a child's task — on the faster route by itself. Each part is handled exactly as if the adult had sent it alone, so the baby tracker's own rules still apply to it: a baby is matched only by exact name, and a feed said loosely always waits for Approve. A wrong division could record part of a child's care without the rest of the sentence; the reply names every part so the adult can see it and correct it.

A prior bottle volume is a record of what happened, not a recommendation for what a baby needs now. Keeping it same-baby, recent, source-labelled and unselected limits the chance that a quick tap copies the wrong care fact; it cannot remove that risk, so the adult must be able to type a different amount or cancel. No nursing-only observation is converted into a bottle-volume suggestion.

Resolving a baby's name or a child's task assignee from the current roster can avoid a wrong care record or assignment. The competing risk is a plausible typo that points at another child. For that reason baby logs never use a fuzzy name correction on this route; an unknown or ambiguous baby name goes to the ordinary assistant before any fast write. A task-assignee spelling suggestion does not write until the adult sees and approves the proposed person. We do not infer that a named adult is a child's parent or carer from family language, and the adult's convenience does not justify that guess.

If that adult has separately opted into improvement traces, the child's words and relevant tool output can also appear in a scrubbed, 14-day LangSmith record. The child did not choose this. The existing tracing assessment accepts that cost for finding and fixing wrong assistant behavior; this revision adds no new trace recipient or child-facing choice. The safer outline-only record would hide the details needed to diagnose a wrong field or wrong write, so the full typed trace remains limited to the adult's separate switch, with name/identifier scrubbing and short retention.

8. Residual risk we accept

We accept that the adult's request may contain health information about a child and that TypeSafe, an additional provider in the United States, can process it after the revised disclosure is acknowledged. Name replacement cannot erase all identifying context. We also accept that live classifier thresholds have not yet been measured: a value above 0.8 is an estimate and a wrong command can write before a person reviews the result. Independently written deterministic checks are required before release; a preregistered experiment will measure accuracy separately. Undo cannot guarantee that others did not see or act on a wrong record before correction. Updates, completions, shopping and baby actions may run immediately without Undo; the receipt offers Edit through the relevant tool, and correction may be more work than a reversal. The proposal card is transient, but the adult's original request remains in their existing conversation for its ordinary 30 days even after Cancel. An unusual compound sentence might be accepted as one command. These are reasons to keep the allowlist narrow and report actual outcomes, not claims that the risks are eliminated.

A unique given-name match can still refer to a person outside the group, and a task-assignee typo suggestion can still be wrong despite being unique among current members. We accept the first only with Jev verification and an actual result that names what happened; the second requires explicit stage approval even at a high score. A typo in a baby-log name takes the ordinary route. The additional meaningful staged reply persists for the conversation's existing 30-day period, including any proposed name or care detail; its correction cannot be reconstructed after that reply expires. Resolving fresh rosters, policy acknowledgement, spend permission and Jev before an ordinary fallback adds delay on a matched but unverified request; this has not been measured in representative use.

We accept that matching by meaning sends words other members wrote. Up to about eight of the group's open task and routine titles can reach the United States verifier for a request that only one member made, and a title can carry a child's name or a health matter that name replacement does not remove. We accept that a tick by meaning can land on the wrong record, and that a tick moves a turn and can move a game score, so a mistake reaches other people before it is corrected; Undo removes the exact tick and hands the turn back, which is a correction and not an erasure of what was seen. We accept that a spoken tick names what was done out loud in a room we know nothing about, and that nothing in the spoken reply can be dismissed or hidden. We accept that a shopping sentence can be split wrongly and show up as a wrong list. We accept that a request asking for several different things can be divided wrongly when the verifier is confident about every place: a faster part is then offered for Approve on its own, and a part the ordinary assistant handles is acted on as that assistant acts today. No divided faster part changes anything without the adult's Approve in this version; the pre-registered measurement, and a decision after it, decide whether one ever may. We accept that a sentence our parser could not read now reaches TypeSafe for the division question, with names replaced. We accept that a task request naming two jobs can be read as one job when the verifier is confident, and created at once with Undo under the usual bands, and that a list card can be approved without being read. The thresholds for every one of these judgments are starting estimates: they have no measurement on real phrasing yet, the order candidates are shown in is known to influence the verifier, and the written-out case sets are what must be read before any of it is turned on. None of these records is used to learn command patterns or to act later.

An explicitly shared assistant message becomes an ordinary group-chat copy. Other members, including children with chat access, can read it and may receive a notification. Removing the original private message or undoing the related task/event does not automatically remove that separate copy. The app must make the destination clear at the moment of sharing and avoid describing any already-saved group record as an unwritten draft.

An opted-in LangSmith trace can still reveal a child or another member through an unusual description after names and identifiers are removed. It may contain Jev's judgment about a proposed health or baby action and the ordinary tool's actual result. A keyed review tag can connect two requests and reveal a repeated approval attempt, though not the raw operation identifier. The trace is a separate diagnostic copy for up to 14 days; deleting a transient stage card does not erase a trace already sent. We accept this within the existing improvement choice and deletion process, without using these records to learn command patterns or to trigger future actions.

9. Review trigger

Reassess before adding a surface, child caller, Device-only group, stored record, fetched group data or history to Jev's payload; adding a tool outside the assessed allowlist; changing TypeSafe's location, retention or terms; changing the capability or notice gate; or measuring an error rate that no longer supports the chosen threshold. Review this assessment against the implementation before release. Reassess before adding an alias or family-relationship field, learning synonyms from conversations, using fuzzy identity matching without an explicit staged choice, or sending a roster to Jev. A new pattern that can drop an action or modifier also needs a new adversarial check before it is eligible for immediate execution. Reassess the tracing scope if a client tap becomes new telemetry, the fast flow is traced without the existing improvement choice, raw review identifiers or envelopes enter metadata, LangSmith's destination or retention changes, or trace records become model-training or automatic pattern-learning input. Reassess before adding more guided questions, durable pending-flow storage, general chat history or fetched records to Jev, a model-generated question, or a new caller surface. A guided answer must not become a reusable inferred preference or person alias. Reassess before sending contextual option candidates or historical rows to a model or trace, adding remote ranking/embeddings, recommending a feed amount or event availability, widening history beyond the bounded past, or persisting an option as a preference. Reassess before widening the candidates for matching by meaning beyond the current group's open tasks and due routines, sending materially more than about eight, including a record's notes, dates, assignee or other fields alongside its title, letting the verifier choose a person rather than a title, or keeping a chosen match as a learned preference or a stored pairing. A measured error rate that no longer supports ticking on a score alone is its own trigger. Reassess before the spoken door covers anything beyond ticking and reopening, before any surface that is not an adult's own phone can use it, before a spoken reply says more than what was done, or before a spoken turn is traced. Reassess before a sentence is split into anything other than items for one shopping list, new tasks that carry nothing but their titles, or the parts of a request asking for several different things as described in §1 — at most three parts, each handled as if sent alone — before a request read as several tasks may act without Approve, before more than three joins are read in one title, before a recurrence change to a saved task or routine becomes eligible, or before a schedule the person did not state can be filled in for them. Reassess before a divided faster part may act without Approve, before a part may be divided off without opening a request of its own, before a divided part may carry another part's words or fields, before a request may divide into more than three parts, before a part may start a guided question, before the division question sees earlier conversation or the group's records, before the parts may run where the person cannot see each outcome, or when a measurement shows a confident wrong division reaching a part that acts at once.

10. Children's Code exposure draft s 38(2)

This assessment precedes implementation and is listed in the published register.

11. Sources

• Children's Online Privacy Code exposure draft, sections 10, 14–17, 28, 33 and 38–39 — docs/sources/.
• TypeSafe model documentation — no training on input; zero data retention is an enterprise provision.
• TypeSafe privacy policy — United States hosting and processing terms.
• docs/pia/cloud-inference.md; docs/pia/inbound-email.md; docs/pia/privacy-policy-acknowledgement.md.
• agent-server/src/inboxAssessment.ts; agent-server/src/regionRouting.ts; agent-server/src/typesafe.ts; agent-server/src/supervisor.ts; agent-server/src/run.ts; agent-server/src/toolOutcome.ts.
• docs/pia/assistant-tracing.md; agent-server/src/improveTraces.ts; agent-server/checks/tracing.check.ts for the existing opt-in, full/outline split, scrubbing, destination and retention.
• Our routines assessment for the routine records themselves, the turn, the wall and what a child account may set up or tick; our shopping assessment for the same-item and aisle judgments and the item words they send.
• agent-server/src/fastCommands.ts; agent-server/src/fastCommandEligibility.ts; agent-server/src/fastCommandExecution.ts; agent-server/src/fastCommandNames.ts; agent-server/src/fastCommandReview.ts; agent-server/checks/fastCommands.check.ts for the parsers, the caller and disclosure gates, the written-out schedule and date wording sent for verification, name resolution and the review path.
• docs/decisions/2026-10-10-assistant-cards-and-words.md for cards showing changes while words only ask, and the duplicate-title rule; docs/experiments/006-assistant-fast-commands/README.md for the pre-registered measurement that has not yet been run.
• agent-server/src/requestSplit.ts (where a request may divide, the refusals, the question, the decision and the parts run as requests of their own), agent-server/src/run.ts (where it sits in the turn), agent-server/src/fastCommandEligibility.ts (the notice and capability gates) and docs/experiments/018-jev-request-splits/README.md for the pre-registered measurement of dividing a request; our routing assessment for the separate step that chooses which part of the assistant answers.
• docs/experiments/015-jev-task-splits/README.md for the pre-registered measurement of the per-join questions and the second check over a list of tasks; agent-server/src/fastCommands.ts (the joins and the feed wording), agent-server/src/fastCommandExecution.ts (the per-join questions, the decision and the second check) and agent-server/src/fastCommandReview.ts (the list card and its approval).