← All privacy impact assessments

PIA: choosing which part of the assistant answers

Amended 30 October 2026: the assistant and who is in a group. The assistant can remove a member or hand over ownership only by showing the admin a card naming the person and the group. Nothing happens until the admin approves it, and approval re-checks that they are still allowed and that the new owner is eligible. A card works once and expires after 15 minutes. Before this change, a typed request to remove a member was carried out without a card. Spoken and forwarded-email requests still can't reach these actions. Making an admin a member also needs a card; making a member an admin is still done straight away, and only for an adult who may lead the group.

Status: Assessed before code on 14 October 2026; built behind a switch that is off. Revised the same day after the pre-registered measurement, which raised one of the lines (§1). It stays off until we have accepted the residual risks in §8 and the privacy policy version that discloses it has reached members' phones. Revised on 15 October 2026 for a predefined answer (§10), assessed before its code and built with no switch: we accept the residual risks in §10. Written: 14 October 2026 · Last revised: 30 October 2026 (the assistant and who is in a group); 15 October 2026 (a predefined answer, §10; earlier: after the measured runs, and for divided replies and two calls in one request) Nothing here is legal advice. Children's Code references are to the exposure draft and may change on registration.

1. Purpose and scope

When an adult types a request to the assistant, our server first has to decide which part of the assistant should answer it: the calendar, the meal plan, tasks, the pantry and shopping list, how the group is going, group settings, the baby tracker, the games, or ordinary conversation. Today that sorting step is always a call to Google's Gemini, which reads the request and the last two turns of the conversation, and it takes between two and five seconds before the part that answers can even start.

Choosing one of nine parts is a closed choice, which is the kind of judgment TypeSafe's Jev is built for, and Jev answers in about a quarter of a second. So, for a typed request our faster commands did not recognise, we ask Jev first. If Jev is confident, our code sends the request straight to the part it chose, and the Gemini sorting step is skipped. If it is not confident, the request is sorted by Gemini exactly as it is today. Jev's answer only decides which part of the assistant answers; that part then works under its usual model, tools, checks and receipts.

Jev answers five questions about the request, in one call:

• which part of the assistant should handle it, chosen from our own one-line description of what each part does, with ordinary conversation offered last;
• whether it asks for exactly one thing;
• whether it asks to read something or to change something;
• whether it only asks to open or show a part of the app (those requests keep their existing route, which answers with a button rather than a reply);
• whether it depends on something said earlier in the conversation ("move it", "that one", "yes").

Our code routes by Jev's answer only when every one of these is clear: the chosen part at 0.85 or above and at least 0.2 ahead of the next, one request at 0.8 or above, read-or-change at 0.8 or above, and "only opening a view" and "depends on earlier conversation" each at 0.2 or below. Anything else is the existing Gemini sorting. The lines move only by a measurement whose rule was written down before it ran.

Measured, 14 October 2026. A pre-registered run of 157 invented requests, three times each, found that at the designed line of 0.8 for the chosen part, 3 of the 101 routed answers went to the wrong part — one of them "arrange my Home", which should have kept its existing route, sent to the tasks part as a change. Every wrong one scored between 0.81 and 0.83, so the rule written before the run raised that line to 0.85, where neither the cases used to choose it nor the cases held back to check it had a wrong route. The margin is small and the requests are invented. At that line Jev routed about one request in five; reports such as "I changed a nappy", and requests naming a person, mostly fell back, so the baby tracker was never reached this way. A second pre-registered run the same day reworded two of the questions — a report of something done counts as one request, and a name, a placeholder or a pronoun for a person the request names or for a baby is not a reference back — and described the baby tracker's events to Jev in more detail. On the same invented requests that raised the share routed from 16% to 23% and let some baby records through, with no wrong route in 438 answers and every request that must keep its existing route keeping it, so the new wording was kept. A fallback is today's route.

In scope: typed requests to the assistant by an adult on their own phone, in a group that is not Device-only, after that adult has seen the privacy policy version that discloses this.

Out of scope, and unchanged: a request our faster commands recognise (assessed in our faster commands assessment), a guided question-and-answer exchange or a card's Approve, anything spoken, anything at the shared display, forwarded email (our Mail Sifter assessment), child accounts, 16- and 17-year-olds, and Device-only groups. A request typed straight after the assistant asked a question also keeps the existing route, because only Gemini's sorting reads the earlier conversation it is answering.

2. Data involved

What is not sent, and could have been: the earlier conversation (Gemini's sorting step reads the last two turns; Jev reads none), any of the group's records, the member list or the baby list, the list of tools the assistant can use, the time, the group's name, or any identifier for the member or the group. The name list is used on our server to replace names before the request leaves, and is never sent.

What is not stored: Jev's answers are not saved anywhere. They decide the route for that one request and are discarded. Nothing is learned from them, and no profile of how a member phrases things is built.

3. Flows and locations

TypeSafe is a second processor in the United States beside Google. It already receives requests our faster commands recognise; this change is that it may now receive almost every other typed request an eligible adult sends, including requests about a child's health or a baby's feeds and sleeps. Unlike Mail Sifter's use of Jev, there is no health-word exclusion here, for the same reason there is none for faster commands: the request is the adult's own, and the policy says baby and health details can be included. Names are replaced; the words around them are not, so a request can still identify a child through a school, a place or an unusual event.

Failure. If TypeSafe does not answer within 1.2 seconds, refuses, is not configured, returns a reply we cannot read, or returns one without a usage count, the request goes to the existing Gemini sorting with nothing left behind. The cost of a failure is that wait plus the request's normal time. Nothing is written by this step at any point, so there is nothing to undo.

Two calls in one request. When the assistant's separate check on whether one request should be divided into parts is also switched on, a request that check considers and decides not to divide can then reach this step too. That request makes two TypeSafe calls, each with its own 1.2-second deadline — up to about 2.4 seconds of waiting when TypeSafe is slow or down — and our server reads the group's name list twice. Both calls send only that request, with names replaced, and both fall back to the existing route. We plan to skip this step whenever an earlier TypeSafe call in the same request has already failed, which needs the two steps to share a flag for the request once both are built into the same release.

4. Legal basis and choices

The adult starts each request. The group's own privacy level and the member's existing assistant choices still apply; Device-only groups never reach the assistant on our servers at all. This is a material change to what TypeSafe receives, so it is gated on notice: before our server asks Jev about a request, it reads the member's own record of the latest privacy policy version they acknowledged, on every request, and routes this way only when that version is the one that says so (version 3.6, dated 14 October 2026, or later). A member who has not seen it, or an older app that cannot show it, keeps the existing route. 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 ways to stop.

The policy wording that discloses it says, in the list of what changed: for other typed requests to the assistant, TypeSafe in the United States may first choose which part of the assistant answers, so the reply comes sooner; it sees only that request, with group names replaced; baby or health details can be included; if it is unsure, the assistant sorts the request as before. Section 5 of the policy says the same at more length and names TypeSafe among our other AI providers.

From v3.13 (23 October 2026) the disclosure is the policy body (section 5, naming TypeSafe), plus the what-changed sheet for v3.6 to v3.12; the v3.13 sheet no longer carries this line, and the gate's check asserts the body. Residual, accepted 2026-10-22: an adult last acknowledged below v3.6 who goes straight to v3.13 sees no sheet line for this feature. It is a notice gate, 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 new switch for members. The alternative we considered was a per-member setting; we did not add one because the existing assistant already sends the same words to an overseas model, the gain is speed rather than a new use of the words, and the notice tells members before it applies. A member who does not want their typed requests to reach TypeSafe can use the assistant less, or not at all, as today; we record that as a residual in §8 rather than claim a choice that does not exist.

5. Risks and mitigations

6. Structural versus conventional

Enforced in code and pinned by checks: who is eligible (adult, own phone, typed, not after a question, not the wall, not voice, not forwarded email, not Device-only, switch on, key configured, policy acknowledged, spend allowed), and that each ineligible case makes no TypeSafe call at all; that the request is the only thing in the state Jev receives, with names replaced, fenced and marked as data; that the parts of the assistant offered to Jev are built from our own list of what each part does, so a new part cannot be added without a description; the thresholds and every fallback; that a confident answer produces exactly one routed request with no other change, and that any failure produces exactly today's sorting call; and that nothing in the route log or improvement record carries words.

Structural underneath it, and unchanged: the assistant's existing refusal of child accounts and of 16- and 17-year-olds without their own switch, the group's privacy level read on every request, the database's spending ceilings, row security on every record the part that answers reads or writes, and that part's own tools and checks.

Conventional: that the policy wording describes this accurately; that the thresholds behave on phrasing people actually use; that TypeSafe's practice matches its stated terms; that "after a question" is well approximated by a question mark in any assistant reply since the member last spoke.

7. Best interests of the child

Children cannot start this route: child accounts have no assistant, and this route also excludes 16- and 17-year-olds who have turned the assistant on for themselves, because the policy notice it depends on is addressed to adults. An adult can still type a request about a child — a feed, a temperature, a school form — and that request can now reach a second overseas provider for the sorting step. Against that, the gain for the child is small but real: the carer writing the record gets their answer sooner, which matters most at the moments these requests are typed (a feed at 3 am). The safer alternative, always sorting with Gemini, does not keep the words in Australia either; Gemini already processes every eligible request outside Australia. So the added exposure is one more processor seeing the request alone, with names replaced, and we disclose it rather than deny it.

A wrong route is the risk to the child's record in the other direction: a feed logged as a task, or a medicine question answered by the wrong part. The thresholds, the "exactly one thing" and "depends on earlier conversation" questions, and the measured run exist to keep that rare, and the part that answers still shows what it did.

8. Residual risk we accept

We accept that an adult's typed request, including health information about a child, can be processed by TypeSafe in the United States after the revised notice is acknowledged, and that name replacement cannot remove every identifying detail. We accept that a confident wrong route can make a change in the wrong part of the app before anyone reviews it, and that the thresholds that decide this are measured on invented requests rather than real phrasing. We accept that there is no separate switch for this step; a member who objects can only use the assistant less. We accept that a request that falls back costs up to 1.2 seconds more than it does today, and up to about 2.4 seconds more when the separate check on dividing a request also asked TypeSafe in the same request and both were slow or failed, until the planned skip after an earlier failure is built. None of Jev's answers is stored or used to learn anything.

9. Review trigger

Reassess before Jev is sent anything beyond the current request — earlier conversation, the group's records, the member or baby list, or the list of tools; before it chooses a tool, a record, a person or any argument rather than a part of the assistant or one of the predefined answers in §10; before a predefined answer may change anything, including a member's own setting; before it splits a request into several; before the route covers spoken requests, the shared display, forwarded email, child accounts, 16- and 17-year-olds or Device-only groups; before Jev's answers are stored or used to learn; before the pinned model version or TypeSafe's location, retention or terms change; and when a measurement shows the thresholds no longer keep wrong routes rare.

10. A predefined answer (the response tree)

Assessed before code on 15 October 2026, and built with no switch.

What it does. Many typed requests need no model to word the answer. Examples:

• a greeting or a thank-you;
• today's date;
• "take me to photos";
• "what's on tomorrow?";
• "what's for dinner?";
• "what have I got to do?".

For a typed request our faster commands did not recognise, Jev is asked one more set of questions about that request. Which of about fifty predefined answers does it want, if any? Which kind of day, time span or baby event does it name? Four yes/no checks run beside them:

• does it ask for one thing;
• does it depend on an earlier message;
• does it ask for anything to change;
• does it ask for a judgment or advice.

When the answer is clear, the request is answered in one of four ways:

• A fixed sentence written by us: a greeting, a thank-you, a goodbye, what the assistant can do, the date or time on the group's clock, or who is in the group (from the member list our server already reads to replace names). No model is asked.
• The view the member asked for, with the same words and button the assistant already uses for it. No model is asked. A baby's growth chart still runs the baby tracker as it does today.
• A day's calendar, a day's dinner or the member's own tasks, read exactly as our faster commands read them. No model is asked. Which day is read by our code from the member's own words ("tomorrow", "Saturday", "tonight"). Jev's own answer about the day can only stop the read when the two disagree; it never chooses the day.
• The part of the assistant that answers it, straight away. Examples: the calendar for "when's the dentist?", the baby tracker for "when did she last feed?". That part then works under its usual model, tools and checks, and only Gemini's sorting call is skipped.

It never changes anything. Some answers would turn one of a member's own settings on or off by Jev's choice, such as the celebrations or the feed countdown. Those are not built, because the policy says Jev's choice decides only which part of the assistant answers. Every route is a read, a view or a fixed sentence. If anything is unclear, the request takes the existing route.

Data. The same as the rest of this assessment (§2):

• TypeSafe receives only the current request, with names replaced, fenced as data.
• Jev's answers are probabilities over our own fixed lists. They are used for that request and not stored.

There is one new item: the member's phone now sends the time of each recent message it already sends. Our server uses those times only to tell whether the request starts a conversation: no message in the 15 minutes before it.

• The times never go to TypeSafe or to Gemini.
• The route log records only "starts a conversation: yes or no", and which predefined answer was used, as a fixed label.
• When a request starts a conversation, the check on whether it depends on an earlier message is not applied, because there is no earlier message.

What it is measured on. Two pre-registered runs, on 15 October 2026, used 417 invented requests asked three times each.

In 3,836 answered samples:

• no request that asked for something to change was ever answered;
• no request asking for a judgment about a child or anyone else was answered with numbers;
• no setting was ever switched.

The rule written before the runs also required wrong answers to be at most 1%:

• The second run, whose questions are the ones in use, answered 2.4% wrongly in the ordinary reading and 1.4% when the request starts a conversation.
• So by its own rule it was not to be built.
• The wrong answers were all reads or fixed sentences, for example:
  • a hello instead of "you're welcome";
  • "last feed?" answered with the last feed mid-conversation, where the label said it should have gone the usual way;
  • two requests on the edge of what an answer covers.
• We decided to build it on that measured residual (below).

Gating. The same as §1 and §4:

• an adult on their own phone, typing;
• the privacy policy version that says TypeSafe may choose which part of the assistant answers (3.6 or later), acknowledged and read on every request;
• the spending pre-check.

It never applies at the shared display, by voice, to forwarded email, to children or 16- and 17-year-olds, in a Device-only group, during a guided question, or straight after the assistant asked a question.

Residual risk we accept. Two kinds of wrong answer remain:

• a few predefined answers will be wrong, at about the rate measured, and a member will have to ask again;
• a short question typed mid-conversation may be answered as a new question.

We accept both, against the gain that a large share of everyday requests is answered in about a quarter of a second instead of several seconds. We accept that the measurement used invented requests. We will count, by fixed labels only, how often requests start a conversation and which answers are used, and revisit once the public beta has run for a month.

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

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

12. Sources

• Children's Online Privacy Code exposure draft, sections 10, 14–17, 28, 33 and 38–39 — docs/sources/.
• TypeSafe model documentation and privacy policy — United States hosting; no training on input; zero data retention is an enterprise provision and is not assumed.
• TypeSafe intent routing and confidence-gated routing — the pattern this follows.
• Our faster commands assessment, our Mail Sifter assessment, where a group's words are processed, privacy policy acknowledgement, assistant tracing, child accounts.
• agent-server/src/assistantRouting.ts — eligibility, the five questions, the thresholds and the fallback; agent-server/src/run.ts — where the routed request replaces the sorting call; agent-server/src/supervisor.ts — DOMAIN_CAPABILITIES, SURFACE_PROMPT and the read-or-change definitions both steps share; agent-server/src/jevNameMap.ts and agent-server/src/fastCommandContext.ts — the server's own name list and adult check; agent-server/src/fastCommandEligibility.ts — the policy acknowledgement read; agent-server/src/typesafe.ts — the client and its failure handling.
• constants/legalTexts.ts — the privacy policy version 3.6 wording.
• agent-server/src/responseTreeRoute.ts — the predefined answers, how each is answered, and the gates (§10); agent-server/src/responseTree.ts — the questions and the reading; agent-server/src/freshTurn.ts and lib/assistantTurn.ts — whether a request starts a conversation; agent-server/src/fastCommands.ts (requestDay) — the day read from the member's words.
• docs/experiments/020-jev-response-tree/README.md — the two pre-registered runs and their results.
• docs/experiments/017-jev-router/README.md — the pre-registered measurement and its result.