← All privacy impact assessments

PIA: The home brief — one paragraph for the group, written twice a day

Amended 4 October 2026. Every edition is written by Gemini 3.5 Flash-Lite at Vertex global, for every group that is not Device-only, with real names; the Sydney route and the sensitive-sheet pin described below are gone (cloud-inference §12).

Planned, 10 October 2026: a member may choose to be sent the brief. A member will be able to ask for one notification a day — "Your day in Smiths" — at a time they pick, on their group's clock, which opens Home where the brief already is. It is off unless the member chooses it, and it is offered in two places: while they are setting the app up, and in Settings. Nothing about the brief itself changes: the same paragraph, written the same way, from the same records, for the same groups.

What it collects, and what makes the switch findable. One stored choice — the member's own chosen time — kept as one more of that member's reminders, so it appears in the list of everything they have asked to be reminded about, with its own switch, and goes out through the dispatcher that already sends reminders. The notification itself carries no content: not the brief's words, not a task or event title, not a count. It names the group, and nothing else. Never for a child account, and never for a group that has no brief — a Phones-only group has none, so there is nothing to be sent. A member who never chooses it is never sent anything, and nothing suggests it to them more than the two places above.

Why it does not count towards the limit on unasked notifications. The app is separately being changed to send a small number of notifications nobody asked for, limited to three a day per member. A brief a member chose, at a time they chose, is a promise they made to themselves, like any other reminder, so it sits outside that limit — which also means a member cannot be sent it unless they chose it. Residual risk, accepted: a daily notification is a daily habit this app has not had before, and a member who finds it too much has to find the switch to stop it. It is in the one list that holds every other reminder they have set, which is where they would look.

Status: Accepted on 29 September 2026, with the residual risks in §12, before any of it was built. Built the same day, against this design, and this revision checks the assessment against the code rather than the plan — three places changed (§2, §2.1, §6) and are marked below. Not yet released: the code is on its own branch, and reaches production only when the usual migration-then-deploy-then-OTA release runs. Where this document describes the app as it runs today, before release, it says "today". Written: 27 September 2026 · Last revised: 10 October 2026 (the second amendment at the top: a member may choose to be sent the brief) · 29 September 2026 (checked against the built code) Nothing here is legal advice. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 December 2026).

0. The short version

Today the top of Home is a short brief written by an AI model for each member separately, in three versions behind Today, Tomorrow and This week tabs. We plan to replace it with:

• one paragraph for the whole group, covering what needs doing now, what tonight and tomorrow need preparing, and what is coming up this week;
• written twice a day — a morning edition from 04:00 and an afternoon edition from 15:00, on the group's own clock — the first time an eligible member opens the app after each time;
• by at most two passes of the same model: a writer, then an editor that checks the draft against the facts it was given;
• paid for by the group, from a limit of A$0.50 per group per week that no member's own AI allowance contributes to;
• processed in Australia, or — for a group that has chosen one of the Global privacy levels — on the provider's global service with names replaced, unless the facts carry health or baby information, in which case the whole brief is processed in Australia;
• followed by a short line the reader's own phone composes from their own tasks and plan, which never leaves the phone.

We accepted this design on 29 September 2026. The finding that matters most for consent — that a group's existing Global choice already covers this use, so no new consent is asked for — is in §8. The residual risks we accept are in §12, together with one defect in today's brief that this change fixes.

1. Purpose and scope

Why build this, in one sentence: to take effort out of planning a group's day by connecting what the group has already recorded — its commitments and the preparation written down for them — in one short paragraph a member can act on.

Today, the brief is written for each member by a model, three times over (Today, Tomorrow, This week), and rewritten when the group's tasks or events change. Members read the first tab and rarely switch, so two of the three are written and not read, and the one that is read cannot see the other two horizons. Each copy is written for one reader and includes that reader's own plan.

The change replaces the three with one shared paragraph per edition, removes the Today / Tomorrow / This week control from Home altogether, and moves everything personal onto the phone.

In scope: what the paragraph is written from (the fact sheet) and what it may never be written from; where it is processed; the writer and the editor; how it is paid for; how it is stored, read, refreshed, withdrawn and deleted; the line composed on the phone; the planned fix to today's brief cache; children.

Out of scope, covered elsewhere and relied on rather than repeated:

• cloud inference — the providers, the regions, the platform spend ceilings and the kill switch;
• privacy levels — what each level permits and how a group changes it;
• a personal Home, tool shortcuts, setup and assistant widgets — the rest of Home, whose fixed summary position this brief occupies;
• first uses — the welcome shown in the brief's place in a member's first three days, which becomes a fixed sentence built on the phone with this change;
• intentions — a member's own plan and the "who is this for" question;
• the baby tracker — the counted baby lines and their two switches;
• the under-16 self-assessment — the legal classification.

What changed from the earlier draft of this assessment (27 September 2026), which assessed a different design and was never published:

• it kept every pass in Sydney at every privacy level; this design follows the group's level, with a health-and-baby exception (§4);
• the first member to open the app paid, from their own AI allowance and the assistant's budget; here the group pays from a separate weekly limit (§5);
• each member's personal part was a further model call; here it is composed on the phone with no model call (§3);
• it recalled two kinds of history; this design recalls four, including the previous time a repeating appointment happened (§2.1);
• finished sentences were struck through; here they are hidden (§6);
• it included a picture of the week and suggestion chips; neither is in this release.

2. Data involved

As built: the household's shopping habit — the usual day and the usual shopper — is not yet sent, on either side. The design described a shared "meal-plan and shopping state" fact; the code that builds the sheet, on the phone and on the server, currently passes an empty shopping input rather than a half-built one, because the usual-day/usual-shopper reader is written against the app's own client and has not yet been given the mirrored, no-imports form every other input here has (§10). The group's shop still reaches the paragraph — an ordinary "Grocery Shop" task, dated or not, goes through the same path as any task — it just does not yet carry the extra habit context ("usually Sam") or a dedicated recall of which day the shop usually falls on (§2.1's third recall kind is therefore dormant until that reader is built). Nothing is sent that this document did not already describe as planned; less is sent than was planned. This is a review trigger (§13) once it changes.

Strictly necessary, item by item (exposure draft s 38(2)(b)):

• Titles, times, assignment and linked preparation are what the paragraph is about; it has no other subject.
• Meal state answers "what is for dinner"; an ordinary shopping task answers "is it on the list".
• Recall is limited to items already on the sheet, to four facts, to the group rather than a person, and to 90 days, because recall is only useful when it helps with something coming up.
• First names let a sentence say who arranged something ("Sam's cook night"); they are stored as ids and turned back into names on the phone.
• Baby names are needed only to recognise a sheet that mentions a baby, so that it can be kept in Australia.
• Leases, money totals and attempts are needed so that only one device writes an edition and the group's limit cannot be passed; no member can read any of them, and none of them holds a member.
• The personal line is useful only to its reader, so it is built only on the reader's phone.

Not collected, and could have been. Each absence is a decision:

• No private plan, no intention and no baby line reaches our servers through this feature. The paragraph is built by a function with no input that could carry them.
• No chat. Neither the group chat nor anybody's assistant conversation is read.
• No event notes and no places. Titles and times are enough.
• No "who is this for" details. A task whose beneficiary is a baby only keeps the brief in Australia; the beneficiary is not sent.
• No per-person tally — no count of who did what, no comparison of workloads, no completion rates. A clash is a fact about two times, never a judgement about somebody's week.
• No record of who caused an edition to be written, or when. The edition carries no claimant and no creation time, and the money records name no member.
• No outside material — tips, articles, "families like yours".
• No model call for the personal line, the welcome, an edition's expiry, or suggestions.
• No picture of the week in this release.

2.1 Recall, a closed list

Four kinds, each only for an item already on the edition's sheet, each about the group and naming nobody, from the last 90 days, four facts at most:

1. The previous occurrence of a repeating event — when the same repeating series last happened. This is how an appointment can be recalled, and only a repeating one: the link is the event's own series, never a similar title.
2. What was prepared last time — preparation tasks linked to that same series that were completed last time, offered as "last time the checklist included…", never as a current requirement.
3. The shopping pattern — which day the group's shop usually happens, from completed shopping tasks. Dormant as built (the note after §2's table): it can only ever be offered alongside a shopping fact the sheet does not yet select, so it does not appear in this release.
4. When a dish was last planned.

Nothing counts how often something has happened ("four visits this year"), and nothing tells a story about a person or a child.

3. Flows and locations

The write path. Our assistant server holds no database key that can write an edition or move money, and it does not gain one. It calls a single function, brief-ledger, on our database provider's function service — the same service our other server-side functions already run on. That function accepts a request only if it carries an identity token signed by Google for our assistant server's own service account, which it checks against Google's published keys (the signature, the issuer, the audience, the exact account, and the expiry), together with the requesting member's own session token, from which the function works out who is asking. It offers three operations and nothing else: begin (take the edition's lease and reserve money for the first attempt), next (record what the previous attempt cost and reserve the next), and finish (record the last cost, then publish the edition or give the lease up). Each is one database function that only the function service can call, and each re-checks the group, the member and the privacy level itself.

What a compromised assistant server could do through this door — stated because it is the bound on the design: reserve and spend brief money, up to each group's weekly limit, and publish text that passes the database's shape checks into the edition of a group whose eligible member's session it holds (a member's session reaches our server with every request they make). It could not read an edition, a lease or a money record through this door beyond the outcome of its own operation, could not name a requester other than the member whose session it presents, could not raise a limit, and could not reach any other table. The function itself holds a key with wide database access, as our other server-side functions on that service already do; that key never reaches our assistant server.

What reaches the model, per edition. A fact sheet of at most 30 short facts, each with a pre-written time label ("tomorrow (Thursday) 8:00 am") and a short id, and a note of how many facts of each kind were left out, so that a missing fact is never mistaken for a quiet week. Free text is fenced as data, with a marker unique to the request, as every other model surface in the app already does. The writer receives the sheet; the editor receives the sheet, the writer's draft (fenced as data too) and our own validation findings as codes. The same text also goes to the same endpoint's token-counting service before each pass, at most twice, so that the money reserved matches the real size of the request; counting is not a generation.

What reaches a log. Counts, timings, token numbers, and outcome and validation codes. No titles, names, member ids, drafts, prompts or brief text.

What crosses a group boundary. Nothing. An event another group invited this group to is left out of the shared paragraph; such an event may appear only in the line of a member who is going to it, composed on their own phone.

At rest. The edition is plaintext in our Sydney database, like the tasks and events it retells. It is not end-to-end encrypted, and no copy may say it is. Member names are stored as ids and turned back into names on the phone, from the current roster, when the brief is shown.

4. Where the model runs, and what it is given

• "Health or baby content" is decided before the first pass, over every fact on the sheet including linked preparation and recall: any word on our existing health-vocabulary list, any task whose beneficiary is a baby, or any of the group's babies' names as a whole word. A sheet that trips any of these goes to Sydney as a whole — both passes — rather than being split, so that a global editor never sees the health context of a draft.
• Both passes use the same route. An Australian brief never falls back overseas, and a global brief never falls back to another provider.
• The level is read fresh, through the requesting member's own access, before the first pass, before the second, and before publishing; a change during generation discards the result. A widening still waiting for its second confirmation changes nothing: only the level the group actually has is read.
• No other provider. If the route resolves to anything but the two Vertex AI services above, the brief is not written.
• At "Global, everything" a sheet with baby content still stays in Sydney. That is more protective than the level allows, and we chose it so that the brief — which nobody asks for in the moment — is not the surface that sends a baby's name abroad.
• Name replacement is by roster. A nickname, a misspelling or a name that is not a member's or a baby's (a grandparent, a teacher) is not replaced, and a title can identify a family indirectly. Replacing names is pseudonymisation, not anonymisation (§12).

5. Who pays: the group's weekly brief limit

• A limit, not a budget. Each group has at most A$0.50 a week of brief generation, held in the database as whole millionths of a dollar. Nothing spends towards it for its own sake: a quiet day, an unopened edition and an edition read again cost nothing.
• The group pays, whoever opens the app. No member's weekly AI allowance is charged, and the assistant's budget is not used. The platform's own daily and monthly ceilings still apply across every surface, and the brief's platform spend is counted under the daily-brief surface it uses today, which it shares with the forwarded-mail assessment.
• The week starts at Monday 00:00 in the group's time zone. Its start and end are fixed when the week opens, so a change of time zone cannot reset a week or open a second one.
• Money is reserved before every attempt, never after. Inside a lock held per group, the database works out the most the attempt could cost — from the counted size of the request plus a margin, the maximum output the model is allowed including its thinking, the published price and the exchange rate — and refuses if that would take the group past its limit, if the model or its price is not one it knows, if the edition already has two attempts or would pass A$0.025, or if a platform ceiling would be passed.
• Then settled. The actual cost is recorded against the reservation; recording it twice changes nothing. A refusal by the provider costs nothing. An attempt whose outcome is unknown — a timeout, a dropped connection — stays reserved, and after 24 hours it is settled at the reserved amount. A reply that arrives without usage figures fails the edition rather than being treated as free.
• Two attempts at most per edition, each reserved first: a failed writer is retried once, and then there is no editor; a failed editor is never retried.
• If the provider charges more than was reserved, the difference is recorded, and a difference above a tenth of a cent switches the brief off for every group until we switch it back on.
• Worst case: fourteen editions and four repairs in a week, each reserved at its A$0.025 ceiling, is A$0.45 — below the limit.
• Visible to the group: eligible members can see, in the group's settings, how much of this week's limit and of the past few weeks' was used — never who opened the app, or when.

The figures below are illustrative, worked from our own price records rather than a fresh quote, and are assumptions until measured. A small synthetic comparison of one pass against two is planned before we decide whether the editor stays on each route.

6. When a brief is written, how long it lasts, and how it is withdrawn

• Editions. From 04:00 group-local, the morning edition; from 15:00, the afternoon edition; before 04:00, the previous day's afternoon edition. The boundaries are local wall-clock times, so a daylight-saving change moves with them. An edition is valid until the next boundary.

• Written on request, not on a timer. The first time an eligible member opens Home in the foreground after a boundary, our server builds the sheet and — if there is anything to say — has the edition written. One device's request writes it; others wait a few seconds and read it. No background job runs a model.

• A quiet day is not written. No dated items, no meals and nothing urgent means no model call and nothing stored; the phone shows a fixed line.

• Checked every time it is shown. The phone compares each sentence's cited facts with what it now holds, and hides: a sentence whose facts are done, changed, deleted, no longer readable or past their expiry; any sentence that depended on a hidden one; a sentence about "today" or "tomorrow" once the date has moved on; a sentence about the whole horizon once anything in it has changed; and a sentence naming somebody who has left. If everything is hidden, the phone shows the fixed line. Hiding is not deleting — the stored edition is unchanged until it is replaced or swept.

• "Since this brief". Up to two new urgent items — an appointment added today, a new clash — are listed in a fixed line under the paragraph, composed on the phone, so that an exhausted limit or a failed edition cannot hide them.

• Repairs. When something urgent changes (not merely gets done), a device may ask once for a replacement. The server rebuilds the sheet and spends nothing if the urgent facts are in fact unchanged. At most one repair per edition and four per group per week, inside the same limit. The card then says "updated", never a time.

• Withdrawn in the same transaction as the change that requires it:

  • a group moving to Device-only: every edition deleted, every member's cached brief from today's route deleted too, and any generation in progress stopped from publishing;
  • a group moving from a Global level to Australia, whether by an admin or by the twelve-month lapse of its consent: every edition written on the global route deleted;
  • a change of the group's time zone: every edition deleted, and any generation stopped;
  • a task or event an edition rests on being deleted, retitled or sealed, an event being cancelled, or a meal plan being removed: every edition resting on it deleted, and any generation relying on it stopped.

• A late writer cannot publish. Each generation holds a fencing number. Publishing checks it; the level, route and time zone the edition was written under; that the requesting member is still an eligible member; that every record it rests on still exists and is neither sealed nor cancelled; and that no attempt for this generation is still awaiting a first answer from the provider. (As built: an attempt already recorded as its outcome being unknown — a timeout or a dropped connection the device reported — does not block publishing; only one still marked "not yet answered" does. This is deliberate: an unknown outcome has already been recorded and its money is already accounted for, held until the hourly reconciliation, so refusing to publish over it would throw away a genuine retry that DID succeed, or a valid writer draft whose editor merely timed out, after the group had already paid for it.) A generation overtaken by any of these publishes nothing.

• Retention, enforced by scheduled sweeps shipped with the tables:

  • editions: deleted two days after they stop being valid, so no edition outlives its date by more than about three days;
  • leases: deleted after three days untouched;
  • spend attempts: deleted seven days after they settle;
  • weekly money totals: kept 35 days after the week ends, then deleted once nothing in them is unsettled;
  • today's per-member brief cache: rows deleted three days after they expire (new — today they are replaced, never swept).

  Deleting a group deletes all of them with it.

• On the phone, the edition is held in memory only, never saved to storage, and is dropped on switching group, signing out, a privacy-level change, or a "locked" or "off" answer from our server. A phone that is switched off or offline keeps what it holds in memory until the app is next opened or closed; we do not promise immediate erasure on a device we cannot reach.

• One switch for everything. A single setting in our database turns the brief off for every group at once: new editions are refused, existing ones stop being readable, and every phone shows the fixed line.

6.1 Sealed at rest (added 30 September 2026)

From the release that follows 30 September 2026, an edition's words are stored encrypted. The facts it cites, which sentence depends on which, and whether a sentence is about today or the week stay readable, because they are identifiers and flags rather than words.

• Who encrypts, with what. Our assistant server writes the edition, so it encrypts it, inside the same request, with the group's Tier 2 key — the key a group's phones share with our server at every level except Phones only (our content-encryption assessment describes it). Opening that key writes an audit record of the kind every other use of it writes, before the key is used. The function that saves the edition holds no key: it receives only ciphertext beside placeholder words, and refuses a half-encrypted edition.
• Who opens it. A member's phone, with its own copy of the key. An older app version that cannot do that is sent the words by our server, which opens them inside that one request (and records that it did). When neither can open an edition, the phone shows its own fixed line; it never shows the placeholder.
• When it is not encrypted, stated exactly. An edition is stored as ordinary text only when the group's phones have not shared a key with our server for the group's current key version, and until the release that adds the encrypted column. If the key exists but cannot be used at that moment — the key service is down, or the hourly limit on opening keys is reached — no edition is published at all rather than an unencrypted one.
• What this does not change. The edition is written from titles our server can already read, and the model that writes it sees them in the clear, as §4 describes. Encrypting at rest protects a copy of our database; it does not make the brief private from our assistant server.
• No history to go back over. An edition lives at most three days, so editions written before this change are gone within three days of it.
• The older per-member brief. App versions from before the shared brief still ask our server for a brief of their own. From 30 September 2026 our server keeps those only in its own memory, for as long as each is valid, and no longer stores them in our database. App versions from before 9 September 2026 are answered by an older function that still stores them, as ordinary text, for up to three days after they expire; it is retired when those versions are no longer supported.

7. Who can read it, and who can cause it

• Read: an active member of a standing group whose account is not a child account, while the brief is switched on for the platform, while the group is not Device-only, and — for an edition written on the global route — while the group is still at a Global level. The database's read rule checks all of this on every read. No member can write, change or delete an edition directly.
• Cause: the same members, by opening the app, unless they have turned their own daily-brief setting off. Our server refuses an event group, a child account and a Device-only group before it reads anything, and the begin operation refuses a child account again.
• "Eligible member" in this assessment means exactly that. A child account is held by someone under 16; a 16- or 17-year-old holds an ordinary account, and reads and can cause the brief as any member does — they can already read every task and event it retells.
• A member's own setting decides only what that member sees and whether their opening the app causes an edition. Turning it off does not stop another eligible member's use of the group's shared records, just as a member cannot today stop another from reading the group's task list. Amended 30 September 2026 (§8): it is no longer on unless turned off — it is a consent the member gives on Home, off until they do, with a dated carry-over for existing adult members.
• Nobody is told who read it, nobody is shown whether others have, and nothing counts views.

8. Legal basis, consents and what members are told

Amended 30 September 2026: the daily brief is now a consent purpose of its own. This section first found that no new consent purpose was needed, because the brief's own setting was already treated as consent-class. We have since decided, as part of our work on member types and first-use consents (member types and first-use consents §4.3–§4.4), to make it one, daily_brief, recorded in our consent record like the others and lapsing after twelve months like the others. What changes:

• New members start with the brief off and are asked on Home, the first time the brief would appear, in a prompt that says what is sent, to whom, where, for how long, and how to turn it off. The two answers are equal; "Not now" records nothing.
• What an answer controls is unchanged (§7): whether this member's opening the app may cause the group's edition, and whether they see it. It does not stop the group's brief being written when another member who has agreed opens the app, and the prompt says so.
• Existing adult members keep the brief until they answer, for a limited time: the carry-over ends 30 days after the change reaches members, and on that date an unanswered member's brief stops and Home says so in one sentence. Nothing is recorded as consent for a member who has not answered.
• Members under 18 are not carried over. A 16- or 17-year-old is asked like a new member, and the brief is off for them until they say yes. (No one under 16 is offered the brief.)
• Our server decides. Before writing or showing an edition for a member, it reads that member's own answer through their own access, on every request. Until the change is applied it reads the setting exactly as before, so nothing widens in between.

The paragraph this replaces, kept for the record: the member's daily-brief setting is treated as consent-class by our own settings rules, but switching it records no act in our consent ledger; this design keeps the setting and its default, and changes what the setting controls rather than what it collects about the member.

The Global levels: our finding, accepted on 29 September 2026. At a Global level, this brief sends the group's task, calendar and meal records to the global service. The group's existing Global consent — the overseas_processing consent given by an owner or admin of the group (by two members confirming it until 2 October 2026), announced in the group chat and lapsing after twelve months — was given against the level's own description on the privacy screen, which names exactly those records: the organising side of the app, "tasks, calendar, meals, pantry, games and group admin", may be processed in any of the provider's regions, with names replaced before anything is sent. That description never promised that the brief would stay in Australia. And because any sheet with health or baby content stays in Australia, the brief does not widen what "Global, records stay here" means to include health records. So we do not ask any group to consent again, and neither the consent's wording nor its version changes. We will say plainly, in the privacy policy and on the app's AI transparency page, that the daily brief is among the organising uses a Global level sends abroad.

Baby lines keep both switches they have today: the group's choice for that baby (recorded under the baby_summary_to_model purpose) and the baby being on the reader's own Home. They are shown as a counted line composed on the phone, and this feature sends them nowhere.

A member's own plan is shown on their own phone as their own line; this feature does not send it to our servers. Today's brief does, for the reader's own copy; that stops for app versions carrying this change (§12 covers older versions).

What members are told (planned copy, to be tested for what it must not say):

• the daily-brief setting: written twice a day from the group's shared records; paid from the group's weekly brief limit, not your allowance; your own part is added on your phone; turn it off and you neither see nor cause one;
• a daily-brief section on the app's AI transparency page: what is sent, both routes, two passes, the group limit, three-day retention, the personal line kept on the phone, no chat, and no zero-retention claim;
• the privacy policy's privacy-level paragraph and the privacy screen's table: the daily brief named among the organising uses, and health-bearing briefs kept in Australia;
• the group's settings: the week's spend against the limit.

Shortened on 10 October 2026, with every fact kept. The daily-brief setting shows that the brief is written twice a day from the group's shared records and that turning it off means you neither see nor cause one (shown); the group's weekly limit and the part added on your own phone are one tap away under it (one tap). The prompt on Home shows who writes the brief, from what, with Google's model and where Google may process it, what your answer does and does not decide, and how to turn it off (shown); the three-day retention, the line about your own plan being written on the phone, and the annual re-ask are one tap away above both answers (one tap). The consent's wording version moved to 2.1 because the layout of its words changed, not what they say, so a 2.0 yes still counts and nobody is asked again. On the AI transparency page the daily-brief section opens under its heading, below a summary that is always shown and says the brief goes to Google's AI. We accept the shorter screens under our principle of being useful first, with informed opt-in: the line that decides the choice is always in view and the rest is on the same screen.

We make no zero-data-retention claim for the provider and no end-to-end encryption claim for the edition.

Children. Child accounts are not offered the brief and cannot cause or read an edition (§7, §11), so no guardian consent is sought for a child to use it.

A setting changed during generation — the level, the time zone, the member leaving — discards the result. It cannot undo a request already sent to the provider.

9. Risks and mitigations

10. Structural versus conventional

Structural, once built:

• the edition's read rule (an active member, not a child account, the platform switch on, a standing group, not Device-only, and a global-route edition only at a Global level), and no member able to write one;
• no client privilege at all on leases, weekly money and attempts, none of which holds a member id;
• the weekly limit and the per-edition ceiling, checked inside the database under a per-group lock before every attempt, with a model or price the database does not know refused;
• the repair limits;
• the fencing number and the re-checks at publishing;
• the triggers that delete editions (and, on a move to Device-only, today's cached briefs) on a move to Device-only, on a move from Global to Australia, on a time-zone change, and on a cited record's deletion, retitling, sealing, cancellation or removal;
• the sweeps, and the cascades when a group is deleted;
• the shape checks on what an edition may hold (closed keys, lengths, fact ids, no figure);
• the platform-wide off switch, read by the read rule and by begin;
• the absence of a claimant and a writing time on the edition;
• our assistant server holding no database key, and the write function opening only for an identity token only Google can sign for our server's account (the code that checks it is listed below);
• the member-only read on today's brief cache, once released;
• an edition's words stored as ciphertext beside placeholder words, a half-encrypted edition refused by the database, and the saving function holding no key (§6.1).

Conventional, each to be pinned by a test before release:

• the write function's checks of the identity token, and its working out the requester itself;
• what the sheet builder accepts, and what it leaves out — notes, places, pending and cancelled events, other groups' events, sealed rows, beneficiary details, plans, intentions and baby lines;
• recall's closed list, its 90 days and its cap;
• routing — the health-and-baby rule, both passes on one route, the level read again, no other provider — and name replacement in every global request;
• at most two attempts, a reservation before each, and refusal on missing usage;
• that the brief's code calls no personal allowance meter;
• the validator;
• our server's refusals for child accounts, event groups and Device-only groups, in order, before any read;
• hiding on the phone, the "Since this brief" line, and dropping the in-memory edition;
• no text, names or ids in logs;
• that our server encrypts whenever the group has shared a key with it, publishes nothing when that key cannot be used, and opens an edition only for an app version that cannot (§6.1);
• the welcome and the "who is this for" question as fixed sentences in app versions with this change.

Conventional, not pinned: whether a paragraph's prose is fair and right beyond what the word lists catch. People reading it judge that, and so will the planned comparison of one pass against two.

11. Best interests of the child

• As users. A child account gets the fixed line, as today, and can neither cause nor read an edition. The safer design for a child's own screen sends none of their use anywhere, and that is unchanged.
• As subjects. A child's name, a task about a child, a child member's own tasks and a child's repeating appointment can appear in the shared paragraph, as they appear in the group's lists today. What this design adds is recall of the previous occurrence of a repeating event — for a child's appointment, a date the family recorded, recalled only because the next one is coming up, never counted, never narrated. A sheet naming a baby, or carrying health words, stays in Australia.
• What it gives a child: less chance that the adults around them miss a form, a packed bag or a clash on a day that matters to the child.
• What it costs them: one more place where their appointments are mentioned, to the same adults who can already see them, for up to about three days.
• The safer design was the earlier draft's: no recall of appointments at all. We chose linked recall of a repeating appointment because "last time" is the most concrete preparation help the group's own records can give, and bounded it as §2.1 and §4 describe.
• Nothing infers a child's wellbeing, development, parenting or fairness, and nothing counts a child's completed tasks.
• 16- and 17-year-olds hold ordinary accounts and use the brief as any member does.
• What the child is told: nothing about them becomes visible to the adults that the group's lists did not already show; a child's own screen shows the fixed line.
• These points reduce harm. They are not an argument about the service's legal classification, which the self-assessment holds.

12. Residual risk we accept, and one defect being fixed

12.1 Found: today's brief cache is readable by the whole group — fixed by this change

Today each member's brief is cached in a row that every active member of the group can read, child accounts included, through the database interface the app uses. Since the brief began including the reader's own private plan, another member could read a sentence written from somebody else's plan. This was found while writing the earlier draft of this assessment, and we checked it again against our database changes on 29 September 2026: it is still open. This change fixes it — the cache becomes readable only by the member it was written for — and sweeps expired rows. We treat it as a defect, not an accepted risk; until the fix is released, this paragraph is the record that the exposure exists. The same correction is made in the intentions assessment, whose statement that the brief "does not create a new disclosure path" was not true of reading.

12.2 What we accept

• Valid citations can support wrong prose. The validator checks shape, citations, numbers, days, names and a vocabulary list; it cannot prove that a sentence means what its facts say ("cancelled" for something that moved). The editor and the planned comparison reduce this; they do not remove it.
• Name replacement and the health word list both miss things. A nickname, a teacher's name or a family's unusual details can reach the global service. A dentist, physiotherapist or psychologist appointment uses no word on the list, so at a Global level its title can be processed globally — as the same title already can be when a member asks the assistant about the calendar. Replacing names is pseudonymisation, not anonymisation.
• Recall can still surprise. "Last time" for a child's repeating appointment is linked, recent and about the group, but it is still a reminder of a past appointment, shown to every eligible member.
• An edition's existence tells the group that someone opened the app after 04:00 or 15:00, and "updated" tells them that someone's phone saw an urgent change. Neither says who or when.
• The group's money is spent by whoever opens the app. A member who never reads the brief still belongs to a group that may spend up to A$0.50 a week on it. The limit is small and visible.
• The provider may charge more than we reserved. If the model's thinking is not held to the output limit in billing, or our 5% counting margin is too small, an edition can cost more than its reservation; the difference is recorded, can take a group slightly past its limit, and above a tenth of a cent switches the brief off for everyone.
• An unknown outcome holds money for up to 24 hours, which can make a group's limit look spent when it was not.
• The daily-brief surface's slice of the platform ceiling is shared with the forwarded-mail assessment and today's brief route; a heavy day for one can refuse the others. The platform ceilings and the kill switch can stop the brief for everybody.
• Capacity. Sydney has refused requests for lack of capacity in the Australian evening before; on such a day an afternoon edition may fall back to the fixed line.
• Older app versions keep using today's per-member route until they are updated: it receives the reader's plan, charges the reader's allowance and caches per member (readable only by that member once the fix is released). We count those requests, without their content, to see them stop, and will remove the route when they have.
• Offline phones keep an edition in memory until the app is next opened or closed; a hidden sentence on screen is not erasure.
• An erased member's id can sit in an edition, pointing at nobody, until the edition is swept.
• Which region of our database provider's function service handles the write path is chosen by that provider, and we have not verified it for this function. What it writes is stored in our Sydney database.
• Nearly every rule about what enters the sheet is conventional. Tests will pin them; tests can be removed. This register is the memory, and §13 names the changes that reopen it.

12.3 Not yet verified

These can only be checked once the build is deployed, and the first release is checked by hand on one Australia group and one Global test group: the identity token our cloud host issues to our server; the write function's check of Google's signature in its own runtime; the model honouring the thinking setting and the output limit in billing; token counting for the global model; and how long the write function takes to start.

12.4 What this assessment does not settle

The brief chooses which of the group's own records to mention by fixed rules about deadlines, timing and preparation, and the same paragraph is shown to every eligible member; the personal line filters by the reader's own assignments and plan. We do not argue from this that the service has no recommender feature. The self-assessment §15 already treats that condition as met for the proposed Home this brief belongs to, and its descriptions of the brief (one sentence, with suggestion chips) are out of date and will be revised when that section is next re-run. We did not re-read the primary sources for this document.

13. Review triggers

Re-read this assessment before any of:

• a new kind of recall, recall of anything that is not already on the sheet, or a lookback beyond 90 days;
• any material from outside the group's own records;
• chat, notes, places, private plans, intentions or baby lines entering the sheet;
• a model call for the personal line, or any model call made per member;
• per-person counts, rankings or comparisons, a picture of the week, or suggestion chips;
• an edition written on a timer or in the background, or for anything other than a member's request;
• a change of model, provider or region, name replacement relaxed, or a health- or baby-bearing sheet allowed onto the global route;
• more readers (child accounts, event groups, other groups), or any relaxation of the rules for child accounts;
• editions kept longer than about three days, money records longer than 35 days, or a claimant or writing time stored anywhere a member can read;
• the weekly limit or the per-edition ceiling raised, or a third pass;
• the write function gaining an operation or a caller;
• the build being released — this assessment is then revised against what was built.

The two triggers in the register's introduction (the Code's registration, and sign-up opening) apply as always.

14. Checklist against exposure draft s 38(2)

s 38(3): this assessment was written, and accepted, before the feature is built. s 39: listed on the published register.

15. Sources

Primary: Children's Online Privacy Code, exposure draft, ss 10, 13, 14, 38 and 39 (kept with the register's primary sources); not independently re-read for this document. Online Safety (Age-Restricted Social Media Platforms) Rules 2025, s 4A — relied on through the under-16 self-assessment §15, which read it on 29 September 2026; not re-read for this document.

Sibling assessments: cloud inference; privacy levels §3A; a personal Home, tool shortcuts, setup and assistant widgets; first uses; intentions; the baby tracker; child accounts; forwarded mail (the shared daily-brief surface slice).

The design this assesses: docs/home_brief_editions_plan.md (revision 2, 29 September 2026), which replaces revision 1 of 27 September 2026.

In repo, as they stand on 29 September 2026:

• today's brief: agent-server/src/insight/index.ts, agent-server/src/insight/prompt.ts, hooks/useDashboardInsight.ts, lib/dashboardFallbackBrief.ts, lib/babyInsightCues.ts;
• today's cache and its group-wide read rule: supabase/migrations/20260804135141_add_group_dashboard_insights.sql, supabase/migrations/20260909010328_insight_cache_member_write.sql, pinned by __tests__/dashboard_insights_rls.test.ts;
• the daily-brief setting and the consent ledger: lib/settingsScope.ts, lib/consents.ts, app/settings.tsx;
• the Global level's description: lib/privacyLevels.ts (PRIVACY_LEVEL_SENTENCE);
• the health word list and name replacement: agent-server/src/regionRouting.ts, agent-server/src/privacyLevel.ts;
• prices, ceilings and the exchange rate: supabase/migrations/20260908220125_inference_spend_ledger.sql, supabase/migrations/20260928221747_gemini_38_global_price.sql.

Built in this change, so the next revision against the code can find them: supabase/migrations/20260929022123_home_brief_editions.sql, supabase/migrations/20260929022126_insight_cache_owner_select.sql; supabase/functions/brief-ledger/; agent-server/src/brief/; lib/homeBriefFacts.ts, lib/homeBriefEdition.ts, lib/homeBriefDisplay.ts, lib/homeBriefLive.ts, hooks/useHomeBrief.ts, components/Home/HomeBriefCard.tsx, components/Home/HomeActionChip.tsx, lib/briefSpend.ts, components/Home/BriefSpendSummary.tsx; __tests__/brief_ledger.test.ts, __tests__/brief_editions_rls.test.ts, __tests__/dashboard_insights_rls.test.ts; agent-server/checks/brief.check.ts, agent-server/checks/briefFacts.check.ts.