← All privacy impact assessments

PIA: Add several events from a description

Status: Built after an assessment written before the code; awaiting a phone check. Written: 12 October 2026 · Last revised: 29 October 2026 (Jev may also mark a remark to leave out and a day or time that applies to every event, and our code then appends the member's own phrase; assessed below, no new data or processor). 26 October 2026 (Add by talking can change an event already on the calendar; a sentence asking to remove one is shown, not acted on; assessed below before that code was written; matching stays on the phone and nothing more is sent). 15 October 2026: long brain dumps, assessed in Routines and list sorting; Jev now also says whether a time written without am or pm means the morning or the evening, assessed below before that code was written; 14 October: Jev decides where to cut the words). Nothing here is legal advice. Children's Code citations refer to the exposure draft.

Purpose and scope

A member can describe several events in one box on the group's Schedule, review each proposed event and add the ones they choose. Typing and dictation use the same box; a microphone may finish transcription on the phone or through Apple or Google's speech service, as its own notice explains. This creates ordinary group events, not entries in a member's other calendars. It adds no calendar connection, device-calendar read or automatic chat announcement.

Data and destinations

The text may identify members, children or guests and may describe health appointments. It stays on the phone until the member asks for review or finishes dictating. For an eligible member of a Standard group, including a 16- or 17-year-old who has said yes to AI features themselves, the text goes to our server in Australia. Our server verifies the caller's membership, account and privacy choices, then reads the group roster to replace names before either processor sees the words. TypeSafe's Jev in the United States decides whether separate items are already present. For unstructured prose, Gemini 3.5 Flash-Lite at Google's global location proposes source-backed event items; if our server cannot use its answer, the same name-replaced words are sent once more, with the same instructions, to Gemini 3.8 Flash at the same location. Neither processor receives group records, identifiers, keys, history or a roster. From 14 October 2026 Jev may also decide where to cut the words, and when it is sure Gemini is not asked at all; that change is assessed in its own section below, and nothing in this paragraph about what is sent or where it goes becomes wider. The server returns drafts only; it does not create events. The phone interprets date and time words in the group's timezone. After review, accepted fields become ordinary group_schedule_events rows in the group's database; the description and draft are not separately stored as group records.

The phone may compare phrases such as “before basketball” and “after basketball” with scheduled events already loaded for that group, including other drafts in the batch. It first checks the selected calendar day; if the words give no date and that day has no match, it may use one clear upcoming matching event. It also uses the existing on-phone Schedule time suggestion: up to 300 recent past timed events are read through the member's group access, with sealed titles opened only by a key held on the phone, and a guarded spelling match can suggest the time and duration of a familiar event. The description and proposed title never enter that history request. The visible calendar day supplies a date when the words give none, but an inferred event is kept in the future: at 11 am, 2 pm may stay today while 10 am moves to a later day. This matching stays on the phone: no existing or historical event title, time or identifier is sent to Jev, Gemini or LangSmith for the batch route. A clear event start or end may anchor “before” or “after”; a stated reference clock or a guarded historical match without a matching scheduled event may produce a visibly labelled estimate. Known activities such as cooking dinner or shopping for furniture may receive visible, editable duration and gap suggestions. The phone may also move an explicitly named group member from “for Brendan” into the event's member field and leave it out of the title. Ambiguous matches leave the time or member for the member to choose; all suggestions remain visible in review.

Usage records contain outcomes, counts and spend, not the submitted words. LangSmith receives a separate schedule-route trace only for a member who turned on Help us improve; its outline omits text, titles and people. Optional thumbs beside the confirmation button send feedback only when that choice is on. This assessment does not claim either model provider retains no copy of the request.

Choice and access

The sheet says AI may process the words overseas before the member submits them, with processor details expandable on the same screen. The current assistant and overseas-processing choices and acknowledgement of the Gemini notice are required for the model route. Device-only groups have no entry and send no words to our server. A child account, managed account or unknown age cannot use this route; the ordinary one-event form remains. The server repeats the gates for every request, regardless of what the phone shows. Offline members keep the ordinary Schedule view and can return to their unsent description after a failed request.

Cuts decided by Jev before Gemini is asked (14 October 2026)

Until now, whenever Jev judged that a description was prose rather than a list of separate items, Gemini was asked where to cut it, which costs several seconds and a second processor. Many descriptions are simply two or three events joined by an “and”, a comma, “then” or a full stop. From this change, in the same single request to Jev, our server also asks about each of those joining points. For every line, our code finds each “and”, comma, “then” and sentence end that is followed by more words, up to six in a line. Jev is then asked, per joining point, whether the words on either side are two separate events or one event whose name happens to contain the word (“fish and chips night”); for each piece, whether, once a day or time is taken out of it, what is left is one event fit to be its title as it stands, with no lead-in or filler words, no hedge, no request to be reminded and no second event; and what kind of thing each piece is. Our code finds the points and the pieces. Jev only answers questions about them and writes nothing.

When Jev is sure about every joining point (at least 0.8 for two events, at most 0.2 for one), each resulting piece is a whole line or a single part between two cuts, every piece is rated a clean title as it stands, each piece's kind is clear, and at least one joining point separates two events, our code cuts the words there and Gemini is not asked. Google then receives nothing for that request. In every other case (a joining point Jev is unsure about, a full stop, question mark, exclamation mark or semicolon that Jev reads as one event, a piece that needs rewording, a line that would be cut in some places but not others, a line with more than six joining points, a very large request, a missing answer, or a phone too old to read the result) the request goes to Gemini exactly as before. A description Jev judged to be a list of separate items is unchanged.

What is sent, and what is not. Jev receives the same words the member submitted, with names replaced by the same step as before, now also arranged as pieces and as a line with one joining word marked, each inside the question it belongs to. A request in which a member's name contains a joining point (an initial and a full stop, for example) is not cut at all, so a name is never replaced in pieces. This adds no new data, no record, roster, history or identifier, no new destination and no new processor. Our server still reads the group roster only to replace names. The reply to the phone has the same drafts as before: the words of each piece and its kind. A piece cut by our code carries no title; the phone reads the title from the words themselves and takes any day and time out of it, as it does for a single event typed on its own. Dates and times are still read on the phone in the group's timezone. The phone tells the server that it can read a draft without a title; an older phone does not, and keeps the Gemini route.

Records. Usage records gain a label saying whether Jev's answers or Gemini produced the cuts, a count of joining points asked about and a short reason when Gemini was asked instead. They hold labels and counts only, never the words. Spend is metered as before: one Jev request, and Gemini only when it is asked. A server setting turns the new behaviour on or off without changing the app. Its effect was measured on invented descriptions in an experiment (016) that was written down before it ran, twice. The first run found no wrong cut but also found that the extra questions made the model's confidence about whether a plain one-item request is already a list fall (from 0.98 to 0.63 on one request), so the behaviour was left off. The questions now carry the words they are about themselves and leave what the routing question reads exactly as it was, and the second run met the rule written for it: of 39 requests cut in code, none was cut wrongly, none was prose passed on as an item, and no day or time was left in a title the phone derived; the routing question's confidence moved by at most 0.03; and the cuts reached 27 of the 33 Schedule requests that should have been cut. The behaviour is therefore on, and the server setting can turn it off without changing the app.

Choice and access are unchanged. The same switches, notices, gates and child, managed-account and Device-only exclusions apply, because the change sits inside the one request that already passes them. The notice already tells the member that TypeSafe checks the words and that Gemini may also process them to split a paragraph; “may also” stays accurate when Gemini is not asked, and the change sends nothing new to either processor, so it needs no change to the policy text.

Remarks left out and a day or time for every event (29 October 2026)

A founder's sentence, “Lunch with Sam 12 till one and meeting with Northwind four till five tomorrow both of the events tomorrow”, went to Gemini because its second piece carried a remark (“both of the events tomorrow”) and so was not a clean title. In the same single request to Jev, our server now asks two more kinds of question about the joined lines above.

What is asked. Our code finds the candidates, and Jev only answers yes or no. First, for each piece after a line's first, and for the end of a line's last piece where it starts at a word from a fixed list (“both”, “all”, “each”, “these”, “those”, “that's”, “it's”, “they're”, “same”, “sorry”, “yeah”, “the first one”, “the second one”, never the piece's first word), Jev is asked whether the marked words are a remark about the other events rather than an event or part of one. Second, for each day, date or clock time our code finds in the line (at most four, never a range such as “12 till one”), Jev is asked whether it applies to every event on the line.

What our code does with the answers. When Jev is at least 0.8 sure a part is a remark, our code leaves those words out, and the rest must still pass every rule above. When Jev is at least 0.8 sure a day or time applies to every event, our code adds the member's own words for it, copied from the description, to each piece that has none of its kind. Two different days judged to apply to all, or a piece whose own day differs, send the request to Gemini. A remark that holds a day or time is left out only if that day or time is already in every remaining piece. A remark such as “same day” is left out only if every remaining piece has a day. Otherwise the request goes to Gemini as before.

The safeguard still holds. Every source word is still accounted for. Each word belongs to exactly one proposed event, or is left out as a remark, or is a joining word, and an added day or time is a copy of words the member said, never a new word. Our code checks this on every cut in the experiment below. Dates and times are still resolved on the phone, in code, against the group's timezone, from those words. Nothing is written before Add these events, and every row can be edited.

What is sent, and what is not. Nothing new: the same submitted words, with names replaced in the same step, now also as a line with one part marked, each inside the question it belongs to. A request whose names would change what our code finds is not asked these questions. No record, roster, history, identifier, destination or processor is added, and the policy text needs no change. Usage records gain two counts, remarks left out and phrases added, never words. A server setting turns the behaviour off, or to remarks only, without changing the app.

Evidence. Experiment 027 (101 invented descriptions, 3 samples each, its decision rule written before it ran, 29 October 2026). With both questions, code cut 35.6% of samples, against 23.4% before. No event was left out as a remark, no day or time went onto an event that did not have it, and every word was accounted for. 34 of the 99 shared-day samples came out fully right, against none before, and the founder's sentence's twin was right in 6 of 6. The experiment's own rule said to leave it off, because one control request that was cut correctly before came out right in 1 of 3 samples instead of 2 of 3. That was a kind question sitting at the 0.6 line, and it is the same question in every arm. The founder turned it on on 29 October 2026.

Morning or evening, asked of Jev (15 October 2026)

A member typed “Dinner tonight at 7:30” and the review offered 7:30 am, which had already passed, so the dinner moved to the next day. The phone used to read any time with a colon as a 24-hour time. It now reads a time with no am or pm from the words around it: dinner, tonight or after school mean the evening, and breakfast or before work mean the morning. That reading happens on the phone and sends nothing. Word lists miss most phrasing (“movie at 8:30”, “drinks at 8”), so from this change, in the same single request to Jev, our server also asks about each time written without am or pm, up to six in a request. For each one Jev is given the time and the sentence it sits in, and asked whether a sensible person would mean the morning or the afternoon or evening. Our code finds the times. Jev only answers which half of the day, and the phone uses its answer when Jev is at least 0.7 sure of it, otherwise the reading from the words.

What is sent, and what is not. Jev receives the same words the member submitted, with names replaced by the same step as before, now also as the time and its sentence inside the question about it. No clock, date, timezone, record, roster, history or identifier is added, and there is no new destination or processor. The reply to the phone adds, for each time asked about, its position in the words and the half of the day Jev chose. The date and the time are still worked out on the phone in the group's timezone. An older phone does not ask for this, and its request is unchanged.

What the member sees. Whenever the half of the day was not written, whether Jev or the words chose it, the review row says the start time was guessed and offers the other half in one tap. The member can still choose any time.

Choice and access are unchanged. The change sits inside the one request that already passes every gate, switch, notice and exclusion. The notice already says TypeSafe checks the words, which covers this question, so the policy text does not change.

Changing what is already there (26 October 2026)

A member who says “The dinner is actually with Alex, not Pat”, “Move the dentist to Thursday at 3” or “Cancel swimming” means an event already on the calendar. Until now the review offered a new event made of that sentence. From this change, for a phone that says it can show one, the review offers a change to that event instead. A sentence asking to remove an event is recognised so that it is never added as a new one, but nothing is removed: its row says “To remove “Swimming”, open it and delete it there” (or “Couldn’t find …”), and it is never written or counted.

What is sent, and what is not. Nothing more. In the same single request to Jev, our server asks one more question per line or piece: is this something new, a change to something already on the list or calendar, or taking something off it. When Gemini splits a paragraph, it is asked the same about each item it proposes, from the same masked words. Neither processor is shown any existing event or task: no title, time, identifier, roster or history is added, and nothing is fetched to go with the words. If the extra questions would make the request larger than the size our server allows, it is sent without them, exactly as today, and every piece is reviewed as new. The reply marks a piece as a change or a removal and carries only the member's own words for it, as a draft already does. An older phone does not ask and gets today's request and answer.

Matching stays on the phone. The phone looks for the event the words name among the group's events it has already loaded and that are still to come. Every word the member named it by must be in the event's name (“piano lesson” never finds an event called “Piano”), and a day named with it must be that event's day, even when only one event matches. A name with words the member didn't say (“dinner” for “Dinner with Pat”) is never used on its own: for a change the member picks it, and a removal doesn't use it at all. Several matches narrow to the day on screen and are otherwise listed for the member to choose by name, day and people; none says “Couldn’t find …” and offers to add it as new instead. An event another group shared with this one (an accepted invitation) is never a target, as its own edit sheet changes only the group note. The new day and time are read on the phone in the group's timezone, and people only from the group's own members. Nothing is guessed silently.

What the member sees and controls. A change is a separate row in the review, labelled Change, showing before and after (“For: Pat → Alex”). Who it is for can be corrected in the row; a wrong day, time or name means leaving the row out and editing the event itself. Nothing changes before the member confirms (“Add 1, change 1”). The review keeps the version of the event it showed. At confirm the event must still be one that can be changed (not cancelled, not another group's shared event, not locked, the group not archived) and still at that version on the phone, and the write itself only succeeds while the event is still at that version, so an edit made since the review, whether it reached this phone or not, is named and left as it is. The change goes through the same store action as the event's own edit sheet and is written as that sheet writes it (the time in the group's timezone); the database's row-level rules decide whether it is allowed, and a refusal is named and left as it was. Neither path checks who created the event: any active member may edit it there too. A repeating event's change applies to its series, which the row says, as the edit sheet does.

Undo writes the earlier values back only while the event is still at the version the change itself committed, as the database answered the change. If anyone has edited it since, it is left as it is and the member is told; nothing newer is overwritten. Undo does not reverse a chat post or a notification someone already received.

Records. The route's trace notes gain a count of changes and of removal sentences: counts only, never the words or which event was meant. A member who turned on Help us improve already sends a record that carries their words, masked, and the model's questions and answers; that record now also carries the add, change or remove question and its answer. It never carries an existing event or task.

Choice and access are unchanged. The change sits inside the one request that already passes every gate, switch, notice and exclusion. A child account, a managed account and a Device-only group never reach the model route, and the phone's own fallback when nothing was sorted stays add-only. The notice already says TypeSafe checks the words and Gemini may process them, which covers this question, so the policy text does not change.

Long brain dumps (15 October 2026)

The Schedule tab's Add several refused any line over 120 characters, so about 20 seconds of dictation was "too long". The change, assessed for both tabs in Routines and list sorting, lets a description run to 10,000 characters and 60 items, keeps the words when the microphone reaches its one-minute limit, sends a description over about 600 characters to Gemini 3.8 Flash with more thinking (falling back to Flash-Lite, both at Google's global location), folds asides and speech to someone else into a "left out" group that is never saved unless the member adds it, and lets the model name words a person took back so the phone reads the corrected day and time. A time Jev reads as morning or evening is matched to its event only where those words were not taken back; elsewhere the phone's own reading applies. No new data, destination or processor is added, and the residual risks recorded there apply here.

One retry, and words said once for several events (28 October 2026; revised 29 October)

The retry is on (29 October 2026). When our server cannot use Gemini 3.5 Flash-Lite's proposed items (the most common reason is an item whose title is not among its own words), it asks Gemini 3.8 Flash once more, at the same global location, with the same name-replaced words and the same instructions, and checks the answer by the same rules. It runs only if the member's allowance and our spending ceiling allow it and enough of the phone's waiting time is left; otherwise the member sees “Couldn't read those events”, as before. It sends nothing new and reaches no new processor or place: Gemini 3.8 Flash is already named above and in the privacy policy. An experiment on invented descriptions found it took “Couldn't read” from 33 of 150 to 4 of 150 and wrote no word that was not said; it was turned on although that experiment's own rule said off, a rule that some rescued events missed because they take the day on screen when a day was said once for several (below). A server setting turns it off with no deploy.

Borrowing stays off. A member may say a day, time or place once for several events: “lunch 12 till one and a meeting four till five, both of the events tomorrow”. When Gemini splits such a description, each proposed event may also borrow source words said elsewhere in it, so both events get “tomorrow”. This is behind a server setting that is off: two experiments written down in advance found the models borrowing the wrong words in a few invented cases, so without it a day said once reaches only the event it was said with, and the others take the day on screen, which the member sees and can change before saving. Were it on, Gemini would name the borrowed words by their position only and writes none of them, at most two short stretches per event; our code refuses any that would take another event's title, words the member took back, or a name the event's own words do not already contain. A remark about the other events (“both of the events tomorrow”) is folded into the “left out” group, as other asides are. Nothing new would be sent, to anyone, and the reply would carry only the member's own words, as before.

The safeguard in the table below stays true: every source word is still accounted for (each belongs to exactly one proposed event or left-out piece, and a borrowed word is a copy of a source word, never a new one), dates and times are still resolved in code against group time, unclear fields stay incomplete, every row is editable, and no write precedes Add these events.

Risks, controls and residuals

The server gates and database permissions are structural, and so is the rule that a cut made by our code needs every joining point decided and every piece rated, since both are tested code and not wording. Whether Jev's answers are right is a measured property, not a guarantee. Review, understandable copy and the member's attention are conventional. This new route uses the existing event table and writer; it does not widen access to another group or to a device calendar. A supported weekly description can create one bounded recurrence after the member checks its first day, time and end date; an unclear recurrence or a multi-day span is held for the existing one-event form rather than being flattened into a misleading single event. Local automated checks cover the route and review flow; microphone, date picker and save behavior await a phone check.

Assignee default, assessed before the change. When the description names no matching member, the person providing it is selected on each event draft. A matching “for Brendan” still selects Brendan instead. The member can tap a selected person to leave the event unassigned or select other people before saving. This may put an event on the author's own schedule when they meant a group-wide item, so the selected member must be visible in review. The default comes from the authenticated phone session and adds no model input, provider, destination or stored field.

Sources

This design extends the assessed list-drafting flow in Routines and list sorting and the existing cloud inference assessment. The separate device-calendar assessment covers a different data flow, which this feature does not start.