← All privacy impact assessments

PIA: a personal Home, tool shortcuts, needs-based setup and assistant widgets

Status: Built, all three stages. Written before the code, and revised on 29 September 2026 first against the second stage as built and then against the third, the assistant, as built: the whole document now describes what the app does, and where the build is narrower than the design, the section says so. The third stage's part on our assistant server goes live when this change is released; its part in the app reaches members with the next app update, and until then an older app keeps showing replies as it did, with no new views. Written: 29 September 2026 · Last revised: 29 September 2026 (four times the same day: first when the daily brief's review trigger fired — §§6, 8 and 17 point to its own assessment — then against the built second stage, then against the third stage's detailed design, in §§0, 3, 4, 9.2 and 10–19, and then against the third stage as built, in the same sections) 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

We are changing how a member finds their way around the app and how the app arranges itself for them, in three stages. All three are built.

1. Navigation (built). Home is a tab in the bottom bar. The tool shortcuts and an "All tools" button are in a tools list that opens from a button at the top left of every screen. (They were first built as a row on Home and at the top of every tool's own screen; on 29 September 2026 they moved into that list.) The tools keep their own screens. No data moves.
2. A personal Home, and needs-based setup (built). Each tool contributes a small view ("widget") to Home. Each member can pin, hide and reorder the widgets on their own Home in each group, and that arrangement is saved to our servers so it follows them to another phone. A member can also switch on Arrange by use on one phone, which reorders their unpinned tool widgets by which tools they have used on that phone in the last four weeks — a record kept on that phone and never sent to us. New members are asked what they want help with and are set up for just that. A group's creator is asked whether the group should use global AI, through the privacy choice that already exists.
3. The assistant (built; in the app with the next update). The assistant, which has held a real conversation since 28 September 2026, can read a bounded slice of the group's tasks, calendar and meal plans to answer one question, and shows the same widgets inside its replies. A reply stores a short pointer to each widget it showed — chosen by our code, never by the model — and never a copy of what the widget displayed. Using a tool's view in a reply the member asked for is a fourth way Arrange by use notes a use of that tool.

The part of this that matters most is not a privacy risk in the ordinary sense. Arranging a member's screen by their own use of it is very likely what the under-16 social media rules call a recommender feature, on the words of the Rules and on the regulator's reading of them. We re-ran the legal assessment for the proposed service in our under-16 self-assessment §15, again against the built second stage in its §15.13, and again against the third stage — its design, then as built — in its §15.14, and summarise the finding here in §15. It was stated as a finding needing a decision before the second stage is released. The decision, taken on 29 September 2026, was to release Arrange by use with the second stage and to settle the finding afterwards. The finding therefore stays open: it is not resolved by that decision, and it is not a risk we accept (§16).

1. Purpose and scope

Why build this, in one sentence: a member should be able to get back to the one place that shows what matters to them, find every tool without a hidden menu, set up only what they came for, and ask the assistant for something and see it rather than only read about it.

In scope:

• the navigation change and its (absent) effect on data — §2;
• the user_home_layouts table, its offline copy on the phone, and who can read, change, export and delete it — §§3, 5;
• which widgets a member may see, and in what order the checks run — §6;
• optional task and agenda widgets that show a bounded, paged list on Home — §6;
• needs-based, resumable setup and the device-local record that lets it resume — §7;
• the setup step that asks about global AI — §8;
• Arrange by use — §9;
• the assistant's widget pointers, the data paths the third stage opens to the assistant, and the one new way a use is noted for Arrange by use — §§9.2, 10.

Out of scope, covered elsewhere and relied on here rather than repeated: privacy levels (what each level sends where, the two-confirmation rule and the guardian rule), cloud inference (where the assistant's models run and what stops the bill), first uses (the first-use record and the tenure-aware Home, which this design keeps separate from its own new data), child accounts, photo wall, Mail Sifter, device calendars and calendar sync, the home brief, and the under-16 self-assessment, which holds the legal classification.

What this assessment is not. It is not a final legal opinion. The first two stages are described as built, and §13 names the tests that pin their conventional rules. The third stage is described as built in §10, and §13 names the tests that pin its conventional rules too.

2. Stage one: navigation only

The first stage moves doors, not data. As built:

• Home is a visible tab, and the tools keep their own screens behind it. Unfinished work inside a tool (a half-built meal plan, a running baby session) survives a switch to another tab.
• The tool shortcuts and an "All tools" button are in a tools list that opens from the top-left button on every screen (on Home, as a row, until 29 September 2026). A shortcut opens a tool; it does not filter Home and the list never reorders itself. Which shortcuts a member sees follows the existing per-account setting that already decided which tools appeared in their directory; the setting is renamed ("Show in your tool shortcuts in all groups") and is not new. The directory's labels changed from "Library / Store" to "Your tools / All tools".
• On a tool's own screen, the tools list marks the current tool. It opens other tools and moves no data either. It matters to this assessment only because a tap in it is one of the four ways a use is noted for Arrange by use (§9.2).
• A child account and an event group see the same destinations they saw before. A child is not shown Mail Sifter, connected groups or the assistant; an event group has no tools list.
• The welcome's wording changed to "open a tool to get started", which is true before and after the change. The welcome's inputs are unchanged.

No new data is collected, stored, read or sent in stage one. No table, column, request body, model input or permission changed. Every surface reached through a shortcut is the same screen, under the same access rules and the same assessments, as when it was reached through the old tab. For that reason this stage needs no assessment of its own beyond this section, and the rest of this document is about stages two and three.

3. Data involved (stages two and three)

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

• The layout row is necessary only for a member who arranges their Home; a member who never saves in Edit Home and skips setup has no row, and sees the ordinary defaults. It holds nothing but the choices the member made, and it is kept on our servers only so that the choices follow the member to another phone — the one thing a phone-only copy cannot do.
• Arrange by use is not necessary to provide the service at all, which is why it is off by default, switched on per phone and per group by the member, and deleted when switched off. It is the member's own control over non-necessary handling (s 9(2)). It is never collected by us.
• Setup progress is necessary to resume setup without asking again; it lives on the phone and holds identifiers and three-state markers, nothing a member typed.
• Widget pointers (stage three) are necessary to show, in a conversation, the view that fits the answer; a pointer and a live re-read replace a stored copy, which would be more data held for longer. Whether the member asked for the view is kept because it decides whether a tap on it is a use for Arrange by use (§9.2), and nothing else.
• The assistant's reads (stage three) are the question the member asked; they are bounded per question (§10.3) so that a question about dinner cannot become a copy of the group's records.
• The examples' shown markers (stage three) are necessary only so that an example is not offered again once seen or dismissed; they live on the phone and hold no content.

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

• No usage data on our servers. Arrange by use never sends its record to us — not to our database, our assistant server, a model, an analytics service or another member. There is no server copy to back up, sync or report on. (The phone's own backup is another matter; §4 says what it can include.)
• No event log. Arrange by use keeps one yes/no per tool per day. It does not keep which screen, what time, how long, how many times, or what was looked at.
• No dwell time, no scroll or view tracking, no notification response, no photo views, no chat activity. None of these can move a widget (§9.2).
• No scores about people or content. The only thing scored is a tool, and the score is never shown to anybody.
• No questionnaire profile. The needs chooser's answers are never sent to us. On our servers their only lasting effect is the layout they seed; on the phone, setup progress keeps which tools were chosen so that setup can resume and a tool just set up is not immediately suggested again.
• No timestamps in the layout or in setup progress. The layout table has no date column, and setup progress refuses any field it does not name, so a time cannot be added to it by accident.
• No copy of widget contents in the transcript (stage three). No title, note, name, measurement, photo link, event place or calendar entry is stored with a pointer.
• No pointer written by a model (stage three). The model cannot write a pointer, and is never shown one apart from the growth chart's older marker in that lookup's own result; the lookup that read the records, or a fixed table for a request to open a tool, chooses it.
• No copy of what the assistant read (stage three). The rows a lookup reads are used to answer that one question and are not kept by our assistant server.
• No layout written by a model. No model-facing tool can save or change a layout; our assistant server does not know the table exists.
• Nothing added to the first-use record, which stays a first-use-only table (see first uses §1A).

4. Flows and locations

What crosses a boundary. Nothing in stage two crosses to a model or a new party: the layout goes to our Sydney database, and Arrange by use and setup progress are kept on the phone. Stage three sends more of the group's records to a model per question than any one of the assistant's earlier lookups did, under the privacy level the group already chose and on the routes the assistant already uses — no new provider, region or model; §10.3 bounds it.

Logs. The layout write is an ordinary row write through the member's own session; no server line records the layout. Arrange by use and setup progress have nothing to log on a server because they never reach one. On the phone, a failed read or write of these records writes a diagnostic line naming the kind of record and the group, never its contents, and our crash reporting drops console lines. A widget pointer that fails validation (stage three) is dropped, on our assistant server and on the phone alike, and nothing about it is logged — neither the identifier nor a count.

At rest on the phone. The offline layout copy, the Arrange by use record and setup progress sit in the app's private storage, protected by the operating system's app sandbox. They are not encrypted by us, the same as the group snapshot the app already keeps there for fast loading, and they hold no content.

Phone backups. That private storage is part of what a phone's own backup can include. An iPhone backing up to iCloud, and an Android phone whose backup to the member's Google account is switched on, may copy these three records along with the rest of the app's storage; we have not excluded them. We do not receive that backup — it is between the member, their phone and Apple or Google. A phone restored from such a backup gets the records back, and they are then kept and removed by the same rules as on the original phone (§5): the next authoritative list of the member's groups removes any group they have left, and signing out removes all of them. This is why everything we write about these records says they are kept on the phone and never sent to us, and never that they cannot leave the phone.

5. Personal layout: scope, access and deletion

Scope is per member and per group. One member's arrangement never changes another member's Home, and a member's arrangement in one group never changes their Home in another. Three existing preferences keep their own scope and are not merged into the layout: which tools appear in the member's shortcuts (per account, in all groups), whether a particular baby's card is shown (per baby and member), and whether a particular game's card is shown (per game, group and member). A widget hidden in the layout is an extra gate on top of those, and resetting the layout does not reset them.

Access. Row-level security admits only the member whose row it is, and — for reading, adding and changing it — only while they are an active member of that group. Deleting their own row needs no membership, so a member can always erase it. No other member, no group owner or admin, and no route on our assistant server can read or write it. The table starts with every privilege revoked from every role, and grants back to a signed-in member only what their own row needs.

• No server reader, by construction. No server process holds a grant on the table. The export runs with the member's own sign-in, and every deletion path is either a database cascade, a database trigger or the member's own delete, so nothing needed one. A future server reader would have to be granted, and this assessment names that as a review trigger (§17).
• No live feed. The table is not published for live updates. Home re-reads the member's own row whenever it comes into view, and a save that races a save from another phone is caught by the revision number: the save states the revision it started from, the database refuses it if the row has moved on, and the phone says so rather than overwriting the other phone's arrangement.
• A refusal is not a conflict. A save the database refuses because the member is no longer an active member is reported as a failed save with a reason, never as "changed on another phone".

Deletion, by construction and by event. Five paths, each tested against the database:

1. Leaving or being removed from the group deletes the membership row, and the layout row goes with it through a foreign key on (group, member) with cascade.
2. Account deletion removes every membership, and so every layout.
3. Group deletion removes every membership in it, and so every layout.
4. A membership that stops being active without being deleted (the only other state is "pending") loses its layout through a database trigger, because losing the right to read a row is not the same as the row being erased. The test asserts both halves: the row is gone, not merely unreadable.
5. On the phone, the offline copy for a group is removed the next time the app receives an authoritative list of the member's active groups that no longer includes it — never on an offline or failed read, and never from a list restored from the phone's own cache — and every offline copy, Arrange by use record and setup record is removed on sign-out or account deletion on that phone. A save still in flight cannot bring a removed copy back; the tests queue a save before each kind of removal and check it does not.

Export. A member's "Download my data" includes their layout rows as a named section, one row per group: which widgets are pinned and in what order, which are hidden, which were added, and the version and revision numbers. The phone-only records are not held by us, so they are not in an export; the Arrange by use switch's own screen says what the record holds and lets the member clear it.

Reset. "Reset layout" deletes the member's arrangement for this group, removes the phone's copy of it, and returns the defaults, after a confirmation and with an Undo that saves the previous arrangement again. "Reset usage" clears Arrange by use for this group on this phone, after a confirmation, and leaves it switched on. Neither touches any other group, any other preference, setup progress, the setup offer, or any other phone.

6. Which widgets appear, and the optional task and agenda lists

Before the second stage, optional Home sections appeared only when the group's data called for them — a baby card when the group tracks a baby, game cards when a game is on, a photo rail when there are photos — and a member could not hide, pin or reorder them. The group's full task and event list was taken off Home on 10 September 2026 in favour of the brief and the member's own plan.

As built, the data still decides first, and a member's preference decides last. Home, top to bottom, is: the photo rail (only when the group holds photos), the brief with its action chip, the "Finish setting up" card when setup has something open, the existing first-run card, prompts and needs list under their existing rules, then the widget area, which ends with an "Edit Home" row, and after it the ceremony card. The photo rail, the brief and the ceremony card cannot be moved or hidden, and Edit Home says so in one line each.

The widget area holds at most eight widgets, from a closed list: Babies, Games, Meals, Mail Sifter and Repetitive tasks, shown by default whenever they are eligible, and Tasks list, Agenda and Other calendars, shown only when a member adds them. For every widget the checks run in this order, and a later check can never undo an earlier one:

1. the group's kind (an event group has only the Repetitive tasks widget, and no Edit Home);
2. the member's permissions (a child account is not offered Mail Sifter or Other calendars, and a Device-only group is not offered Mail Sifter; an account whose age is not yet known is not treated as a child);
3. whether the tool is on for this group and member (a game switched on; Mail Sifter switched on, or an item waiting);
4. whether the data is loaded — a widget still loading is not drawn, never drawn empty, and Edit Home says it will show once loaded; a failed load is described as unavailable ("Couldn't load right now"), never as absent;
5. whether the widget suits this spot (a baby whose card the member has not set to hide; a game whose Home card the member has not hidden);
6. the member's own hide, pin and order, and then, only if they switched it on on this phone, Arrange by use's order for the unpinned widgets (§9).

So pinning cannot grant access, reveal sealed content, switch a game on or create a baby or a meal plan; a pinned widget whose data is deleted simply disappears, and a hidden widget stays hidden until the member shows it again. Hiding a widget on Home does not disable its tool, its shortcut or its settings. The widget area is drawn only once the member's own layout for this group is known — from the phone's copy, from our servers, or, if the load fails, the defaults — so another member's layout, or the previous group's, is never shown for a moment.

What a member who never opens Edit Home sees is what Home already showed — Babies, Games and Repetitive tasks, each when the group's data calls for it — plus Meals while the group has a current or coming meal plan and Mail Sifter while an email is waiting to be sorted. None of the optional lists appears by default. The Mail Sifter widget shows only how many items are waiting, never a sender or a subject; the Other calendars widget is an opener that asks for no calendar permission when it is drawn.

Edit Home is a sheet holding a draft. Nothing is saved until the member presses Save: every move, pin, hide, show and add changes the draft only, and Cancel discards it. Each widget on Home has Move up, Move down, Pin and Hide buttons and the same four as accessibility actions, and a move is announced ("Meals moved up, 2 of 5"). There is no drag. Moving a widget by hand pins it where it was put, so pinned widgets are always the top of the list. Hide shows "Hidden from your Home" with an Undo, still inside the draft. A hidden widget offers "Show on Home in this group". The "Add widgets" list offers the optional widgets, and says honestly why a default widget is not on Home yet ("Shows here once the group has a baby", "Every baby's card is set not to show on your Home"), with a link to set that tool up or to the setting that hides it. Save is disabled while the phone is offline, and says so. A save that lands closes the sheet with "Saved" and an Undo that saves the previous arrangement again. The sheet also holds Reset layout, a link to set up tools, and the Arrange by use switch (§9).

Optional task and agenda widgets. These are an exception, which we decided to make, to the 10 September decision. They are off unless a member adds them. When added, each shows five rows; "Show list" expands it to twenty rows at a time, "Show more" adds the next twenty, and the list ends in a visible line ("End of open tasks", or for the agenda, "Nothing more until" a date). They never load more on scroll or on a timer, and there is no count. The Tasks list shows the group's open top-level tasks, soonest due first, never a step inside a task and never a meal plan's template; ticking one uses the same action as the Tasks tab, offers Undo, and is refused with a sentence while the phone is offline. The Agenda shows the group's coming occurrences from today through the next 30 days in the group's time zone, leaving out cancelled events; pressing it opens the Schedules tab. The horizon choice (Today, Tomorrow, Week) keeps controlling what the brief is given. Superseded 29 September 2026: the Today / Tomorrow / Week control leaves Home altogether. The brief becomes one paragraph for the group covering all three horizons, assessed in our home brief assessment. A member's own plan is shown on Home grouped by horizon, with the horizon chosen when an item is added. Corrected the same day: there is no separate plan section on Home and no horizon heading. The member's own plan is named inline in the personal line the phone writes beneath the shared paragraph; tapping a named item opens the plan sheet, where items are ticked, dropped and added, and the plan sheet's choice of Today, Tomorrow or This week only decides where a new item belongs. The plan is not a widget, is not in the layout, and is never moved by use.

7. Needs-based setup

Before the second stage, a new member of a group was offered seven setup steps in a fixed order (a personal preset, a profile photo, Mail Sifter, a dinner plan, group photos, a first task and a first event), once per member and group on each phone, during their first three days. The phone recorded that the offer was made; it did not record which steps were done.

As built, the first personalised step asks "What would you like help with?", with six real jobs — planning meals and shopping; keeping track of feeds, sleep and nappies; turning emails and shared documents into plans; bringing an existing calendar into the group; sharing photos with the group; making everyday jobs more playful — "You can change these later", Continue and I'll explore first. Only the chosen jobs are set up, each through the tool's own existing flow, one at a time, and the member can go to their group after the first useful result ("Go to my group", or "Set up another tool"). The personal preset and the profile photo left setup and stay in Settings; a first task or event is a link, not a step.

• Who is offered what. A child account is not offered Mail Sifter or calendar reading, and the chooser offers nothing until the account's age is known. A Device-only group is not offered Mail Sifter. An event group never enters setup and keeps its own focused joining flow. A member whose request to join is still pending is told it is waiting and offered nothing.
• Creators and joiners. Which journey a member is on is fixed when setup starts: the creator is the person who just made the group, or the owner of a group of one. A joiner is first shown what the group already has — its babies, its current meal plan, its photo wall, its games — each with Open, and is never asked to recreate them. Opening one of those settles that tool's step as finished without counting as a choice of help, so it does not stop the app suggesting the other tools later. The group's AI level is shown read-only; an owner or admin is offered a link to the privacy screen, and nobody else is invited to change it.
• The smallest useful result, per tool. Meals: open the Meals tool if the group has a current plan, otherwise adopt a starter plan through the existing adoption. Babies: open the tracker for a baby the group already has, otherwise the existing add-a-baby screen. Mail Sifter: an owner or admin turns it on with the one existing switch, under its existing consent, and the step finishes once the group's forwarding address and instructions are on screen; a member who is not an admin is told who can. An optional "Review a first item" then waits for the first forwarded email while the app is open, stops the moment one arrives or after three minutes, and nothing about it is stored. Other calendars: open the tool if this phone already keeps its calendars in step with this group, otherwise the existing import screen, which asks for calendar permission only when the member taps there; the step finishes only when at least one entry was brought in, and a refused permission leaves it to try again. Photos: open the wall if the group has photos, otherwise add some with the existing picker, which finishes the step only when an upload succeeds. Games: open the games if one is on, otherwise "Choose a game", which goes to the games hub and records nothing; a game switched on there is noticed the next time setup opens. Opening a tool that exists finishes its step; skipping a step records it as skipped.
• Returning from a tool's own screen. When setup sends a member to the add-a-baby or calendar import screen, it passes a short marker naming the step and the group. Only a successful write on that screen records the step and returns to setup; backing out, including with Android's back button, returns to setup and records nothing; and a marker for a group that is no longer the one on screen is ignored, so the screen behaves as it always has. Opened any other way, those screens are unchanged.
• Setup never counts as use. Opening a tool from setup is never a use for Arrange by use (§9.2).
• A selection is not consent. Choosing "planning meals" does not switch on AI processing, calendar access, notifications, summaries, a game, Mail Sifter or Arrange by use, and does not change the group's privacy level. Each of those keeps its own switch, its own screen and, where it has one, its own consent, and changes only on an explicit tap inside a step. A test ticks every box and checks that none of them changed.
• Selections seed a first layout, and setup only ever adds. For a member with no saved layout, pressing Continue saves a first one: an optional widget they chose is added (Other calendars is the only one), and nothing is hidden — a tool they did not tick is a tool they are not setting up now, not a card the group already uses that setup may take away, so a joiner who ticks only Meals still sees the group's baby tracker. Choosing or not choosing photos affects nothing, because the photo rail is fixed. This first layout is not shown for confirmation before it is saved: Continue on the chooser, which lists the choices, is the confirmation, and Edit Home changes it at any time. For a member who already has a layout, setup instead shows the cards it would add — a chosen optional widget, or a chosen card they had hidden — to save or to decline ("Keep my Home as it is"); it proposes no removals and never touches a pinned widget. Hiding is done in Edit Home. Offline, or if the save fails, the choices are kept on the phone, setup says the Home choices are not saved yet, and offers "Save your Home choices" once the phone is back online. "I'll explore first" writes no layout.
• What the phone keeps to resume is the setup progress record in §3: identifiers and three-state markers, versioned and bounded by the list of tools. It holds no typed answers, baby names, email text, draft contents or times, and refuses any field it does not name. It is deleted on sign-out, on leaving or being removed from the group, and on account deletion, the same way as the layout copy. Whether a tool is actually ready is always read from the tool itself: a "finished" marker never stands in for a baby, a calendar import or a meal plan that may since have been deleted, and a member who returns after the app closed mid-step is offered to open what now exists, never to add it again.
• One quiet "Finish setting up" card on Home, with Resume, Change choices and Dismiss, appears only when tools were chosen, one is still open, and the member has not dismissed it. It shows no percentage, count, streak, badge or deadline. The same way back is "Set up tools" in Edit Home and in the list of tools (not in an event group).
• Readiness in the list of tools. A tool that is not ready carries one short line — "Not set up yet", "Waiting for your first email", "Waiting on an admin" — read from the tool's own state. Nothing is said while that state is still loading, nothing for a tool that is ready, and nothing under a tool this member cannot have in this group.
• Hints. The existing "you haven't tried X" suggestions read the phone's setup progress, so that a tool the member just set up, skipped, or chose not to be helped with is not immediately suggested again; a tool chosen and still pending can still be suggested. Nothing about setup progress or choices is sent to a model, our servers, or another member.
• Existing members are not re-prompted. A phone that already recorded "setup offered" keeps that record, with unknown progress: no step is invented, no "Finish setting up" card appears, no hint is suppressed, and nobody is asked again because this design shipped.

This changes the description of the first sitting in first uses §1, which that assessment now reflects.

8. The "global AI for this group?" step

For a newly created standing group, setup asks whether the group should use global AI. The reason we offer it is model quality: the newest models are not yet available in Australia. The question is a new way into the existing privacy-level choice, not a new choice, and every rule of that choice applies unchanged (see privacy levels §3A):

• Who is asked. Only a group's creator who is its owner or an admin, on a standing group that is not Device-only, on an account that is not a child's, while the phone is online. It comes after the chooser, or after "I'll explore first", and once answered it is not asked again.
• Three answers, nothing pre-selected: global AI for organising (the existing "Global, records stay here" level), global AI including baby-related requests (the existing "Global, everything" level), or keep the current setting. Opening the step, skipping it, or pressing "Decide later" writes nothing.
• The same procedures as Settings, through the same code. The member's role is re-checked at the moment they tap. The database's own count of required confirmations decides: a lone founding adult applies it at once, and a change waiting for a second confirmation is shown as waiting. A waiting change never changes where a request is processed — every request is routed by the level the group actually has. The guardian rule still applies at "Global, everything" where a child is in the group. If the chat notice announcing the proposal fails to post, "Retry" posts the notice again and never proposes a second time.
• Joiners, ordinary members and child accounts see the group's current level with an explanation, and are not invited to reset it. Event groups do not see the step. A Device-only group is never nudged to leave Device-only.
• The copy says "supported requests". At the Global levels, the assistant's supported steps move to the global provider as that assessment describes; the daily brief and the task allocator do not today, and stay in Australia at every level. The step must not promise a global Home brief. Revised 29 September 2026: the task allocator still does not move, and stays in Australia at every level. The daily brief, as redesigned in our home brief assessment and accepted the same day, moves to the global provider at a Global level, names replaced — except a brief whose facts carry health or baby information, which stays in Australia whatever the level. So "supported requests" is still the right phrase, and the step does not promise that everything, or every brief, goes global. The line about processing in Australia appears only where the running service supports it, using the same sentence Settings already uses. Choosing a level does not move records already stored, does not let the assistant read anything sealed, and changing back affects only future processing.
• The setting is the group's, not the member's. Setup progress records only whether the step was offered and answered, never the answer.

9. Arrange by use

9.1 What it is

A member can switch on "Arrange by use on this phone" for a group, in Edit Home. Its switch says: "Uses this device's tool activity to arrange your unpinned widgets. Pinned widgets stay where you put them." Off is the default, and off means nothing is collected, not that collected data is ignored: there is no record until the switch is turned on, and turning it off deletes the record. Switching it on on one phone does not switch it on on another, and switching it off on one phone cannot reach another.

Beneath the switch, a status line says "Off — nothing is recorded", or "On since" a date with "arranging starts after 7 days", or when it last arranged, "at most once a week". Two fixed lines say "Only this phone. Your other phones keep their own setting." and "If this group's time zone changes, this starts again from that day." "Reset usage" asks first. On an app version that cannot keep the record, the switch stays off and says it is not available, rather than showing "On" over a record that was never written. The switch shows no confirmation message after it changes: its own position is the feedback.

9.2 What counts, and what never does

Rankable tools: Meals, Babies, Games, Mail Sifter, Other calendars, and the optional Tasks list and Agenda widgets. Never ranked or recorded: photos, ceremonies, the group chat, the assistant itself, the member's own plan, the brief, connected groups, the Repetitive tasks widget, and every fixed section.

A qualifying use, as built, happens in exactly four places, and a test fails if a fifth appears:

1. The tool shortcuts — a tap on another tool in the tools list that opens from the top-left button. Tapping the tool whose screen the member is already on records nothing. (Until 29 September 2026 the shortcuts were a row on Home and at the top of every tool's own screen; they moved into that list, and what a tap records did not change.)
2. The list of tools in the All tools sheet — opening a tool from it.
3. A Home widget — an explicit open or expand, "Show list" or "Show more", or an action in it that succeeds (a ticked task, for example). A widget appearing, scrolling into view or being looked at is not a use.
4. A tool's view in an assistant reply the member asked for (the third stage) — when a member asks the assistant to show or open a tool ("show my tasks", "show the meal plan", "open Mail Sifter") and then presses the view's button, opens or expands it, or completes an action in it, the same moments that count on Home. Only a view the member asked for counts: whether they did is decided by our assistant server from the request itself, never by the model, and a view the assistant offered beside an answer without being asked never counts, however it is used. A reply appearing, being redrawn, scrolled past or read never counts either, and nothing said in the conversation does. What the member asked, what the assistant said and which record the view showed are never recorded: the mark is the same yes for that tool on that day. Photos, ceremonies and Edit Home have no tool to count. The mark needs the group's own time zone and is skipped rather than guessed without it. A spoken request shows no views, and an under-16 account has no assistant, so neither can add a mark this way.

At most one mark per tool per day. The build is narrower than the plan in four ways, each of which records less: the game cards on Home never count (only opening Games from the row or the list does); the baby card counts only when it is pressed to open the tracker; the Repetitive tasks widget has no tool and is never ranked; and a baby's growth chart shown in a reply the member asked for never counts, because the chart has no control that could mark it.

Never a qualifying use: Home drawing a widget, time on a screen, scrolling, views, opening a tool from setup, a notification or a link from somewhere else, returning to a tool through the dock, background refresh, a model reading anything, anything said to the assistant, a view in an assistant reply that the member did not ask for, looking at photos, anything about other members, or opening Photos or connected groups, which are tools but never rankable.

9.3 How the order is worked out

For each rankable tool, the phone keeps 28 daily yes/no marks, in the group's own calendar days. A tool's score is twice its active days in the last seven days plus its active days in the 21 before that. Then:

• nothing moves until seven full days after the day the switch was turned on;
• the order is worked out at most once a week, when Home comes into view and the member's layout is known, and stays fixed for that visit — a use during the visit moves nothing until a later one;
• a tool must lead the one above it by at least two to pass it, and a tool moves at most one place per update; ties keep the previous order;
• widgets within one tool keep their own order; the score is per tool, never per baby, per person, per photo or per item;
• a pinned or hidden widget is never scored or moved, and moving a widget by hand pins it;
• which widgets take part is read from the member's layout, not from what happens to be loaded, so a widget that is loading or temporarily not eligible is skipped without changing the saved order;
• switching it on or off, or "Reset usage", puts Home back in the member's saved order at once;
• a change of the group's time zone clears the marks and restarts the seven days, and the switch's own screen says so.

9.4 How long it lives, and where

Marks older than 28 days are deleted every time the record is read or written. Turning the switch off deletes the record and restores the saved or standard order; "Reset usage" clears the marks and restarts the seven days without turning it off. The record for a group is deleted on that phone when the member signs out, leaves or is removed from the group (the next time the phone learns of it from our servers), or deletes their account; a phone keeps records for at most 20 groups, removing the least recently saved first. It is never sent to our servers, a model, an analytics service or another member, is never written into the first-use record, and is never used as evidence for anything else we measure. It can be included in the phone's own backup, as §4 describes. We do not describe erasure of a phone we cannot reach as immediate: a phone that is offline keeps its record until it next runs the app.

9.5 What it is, in law

It is ordering by observed behaviour, and we do not pretend otherwise. Keeping it on the phone, off by default and short-lived limits what is collected; it does not change what the feature is. See §15.

10. The assistant's widgets and the data it can read

Stage three, designed and built on 29 September 2026. This section was written against the detailed design before the code and revised against the build; its part on our assistant server goes live when the change is released, and its part in the app reaches members with the next app update. Where the design differs from the proposal this section first described, the difference is recorded here, and each one stores or sends less, or moves a choice from the model to our code; where the build is narrower than the design, that is recorded too.

10.1 The pointer

A reply may carry up to three widget pointers. Each is chosen by our code, never by the model: either the lookup that read the group's records offers the view that fits what it read, or, for a request to open a tool, a fixed table gives the one button. The model is never shown a pointer and has no way to write one, so text in a task title, an event or a forwarded email cannot become a pointer; a field shaped like one in the model's own reply is dropped before the reply is sent. The one thing the model can see is the growth chart's older marker, which the growth-chart lookup returns in its result; it is collected from that result alone, never from anything the model writes. (The proposal had the model choose a kind and an identifier from what it was given; the detailed design removes that.)

Each item holds a kind from the closed list in §10.2; a short reference worked out from the rest of the item, used only so the same view is not shown twice; whether the member asked for that view ("show my tasks") or it was offered beside an answer; and only the identifiers its kind may carry. Nothing else: no options, names, titles, measurements, links, routes or unknown keys. (The proposal allowed typed options such as a horizon; the first version has none.)

• Checked on both sides of the reply. Our assistant server validates every item before sending it, and sends only kinds the member's app says it can show. The app sends that list with each request — at most 16 kinds, from the closed list — and the server treats it as a statement of what the app can draw, never as permission to see anything. At most three items go with a reply, the ones the member asked for first. The phone validates the list again against the same rules, which both sides test against one shared set of cases, and stores it with the assistant's reply as metadata.widgets = { version: 1, items: [...] }. An item of a kind this app version does not know is shown as a plain line, "This view needs a newer version of the app."; an unknown version or a malformed item is dropped. A reply with nothing to say but its views says "The details are below.", so a screen reader has a sentence to announce first.
• Drawn from the group's records, never from the pointer. The phone draws a view only while the group it belongs to is the one on screen. It checks each identifier against what it already holds for that group — the meal plan among the group's scheduled plans, the baby among the group's babies — and then draws the same widget Home uses, re-reading through the member's own access and applying the same checks as Home does (§6). A miss becomes a small "unavailable" line with no buttons ("That view isn't available in this group."). Hiding something on Home does not take a view away in a reply: a widget hidden in Edit Home is still drawn there, and a baby set not to show on Home, or every game card switched off, gives a button into that tool instead. For a day of a meal plan, the phone uses the date the pointer names as it is and shows that day's own dinner from the group's calendar; it works out no plan day of its own.
• Nothing the widget displays is stored with it. A historical message shows today's state and says "Current"; it never shows a frozen copy from the day it was sent.
• Deletion and revocation take effect at once. A deleted plan or baby, or a kind this group can no longer show (Mail Sifter at Device-only, for example), turns the view into a small "unavailable" line with no buttons; a conversation whose group is not the one on screen, which includes a group the member has left, draws no views at all. Everything else the view shows is re-read, and governed by the same rules as the same widget on Home. No snapshot is kept to make it look nicer.
• The pointer lives as long as the conversation: assistant conversations are deleted after 30 days, and with the account.
• The assistant message's metadata is not encrypted, even when the message text is sealed on the member's phone. That is why the pointer may hold only the identifiers in §10.2, and why a kind not assessed there is never sent, saved or drawn. Whether the member asked for a view sits in the same unencrypted field.
• The existing growth-chart pointer is kept. A reply that shows a baby's growth chart already stores metadata.figure with the baby's identifier. The third stage keeps writing it beside the new list, so that an older app version on the member's other phone still draws the chart; it adds nothing the new list does not already hold.
• Nothing for a spoken request. A reply to a voice request carries no pointer; it is heard, not drawn.
• A widget is not a receipt. A widget appearing never means an action happened; outcomes are reported from what was actually saved. The third stage extends this to five more of the assistant's actions — cancelling an event (and every repeat of it, which the confirmation says), sending a meal plan to the group for approval, moving a meal plan to other dates, and marking a pantry item out or back in stock — each of which now reports what the database confirmed, and a lost connection as "could not confirm" rather than a refusal. It removed an unused action for proposing a change to an event, which the assistant was never given. Under the reply it has just given, the Assistant screen shows what was saved, and when a change could not be confirmed it says so and offers a way to check, never to try again; these lines are not stored, so a conversation opened later shows none.

10.2 What each kind may carry

"Linkability" is what a stored pointer lets a reader of the transcript learn, beyond the message text: that this member, on this day, was shown this record. The transcript is readable by the member alone through the app, by nobody else in the group, and by nobody on our assistant server; it is readable by a database administrator with direct access, as every plaintext row is.

A view may offer "Show … on Home". As built, it is offered only for a widget that can be moved and is not already on the member's Home in this group (one they hid is shown again, never added twice), only once their layout for the group is known, never in an event group, and never for a widget a child account cannot have until the account is known to be an adult's. It adds the registered Home widget for the tool — never the named baby or a particular meal plan — through the member's own layout save, with the same revision check. The button does nothing while the phone is offline; a save that lands says so and offers Undo, which puts the previous arrangement back; a refused or conflicting save changes nothing on the phone and says so, and a conflict fetches the other phone's layout before the next try. No model is involved, and the part of the app that draws these views never contacts our assistant server. A tap on an assistant view the member asked for is the fourth qualifying use for Arrange by use (§9.2), and the list of call sites and its test changed together.

While an account's age is not yet known, it sees the ordinary tabs, tools and Home views, as described above: a door that appears a moment early is not access, and what a child must not reach is refused on our servers. Anything the phone does, reads from the phone itself, or sends on the member's behalf waits until the account is known to be an adult's — offering a group AI choice, reading the phone's calendar, or showing an assistant example. A failed age lookup is treated as not yet known and asked again; it is never taken as an answer. The growth-chart pointer is taken only from the chart tool's own leading marker; a marker inside a returned name or title cannot choose a chart.

10.3 What the assistant can newly read (stage three)

• Conversation is already real, and stays in Australia. Since 28 September 2026, a request the assistant classifies as general chat is answered by one model call, with no lookup of the group's records, on the same step that reads every request — the step that stays in Australia at every privacy level. A thank-you or a plain "OK" gets a fixed sentence and no model call. An earlier version of this section said that conversation would run "under the group's level"; it does not, and the third stage does not change that.
• A bounded read across tools, now including meals. To answer one question about the group's plans — "what's on this week?", "can dinner work around swimming?", "what needs preparing for tomorrow?" — the assistant may read, through the member's own access and bound to the conversation's group: open tasks and who they are assigned to, calendar occurrences (repeats and multi-day events worked out in the group's time zone) and, new in the third stage, the group's adopted meal plans for each day, with the dinner time. A question that spans meals and the calendar or tasks is kept as one question, so that the answer sees both.
• These two lookups share ceilings per question, on what reaches the model. At most 6 lookups, 50 rows of any one kind, 120 rows in all, a window of 31 days and 32 KiB of text. The window is held by each lookup's own range — the combined read covers today, tomorrow or seven days, and the meal-plan day one day between a week back and 31 days ahead — rather than by the shared count, so a future lookup that takes a range has to keep to it itself. What was cut is flagged in what the model receives ("… more not shown — ask about one day or person"), so it can say so and the member can narrow the question; a lookup refused by the ceiling returns a plain sentence rather than an error. To work out repeats, the read still fetches up to 1,000 of the group's events and 1,000 of its open tasks, as the existing schedule lookup already does; those rows are used for that one question and are not kept, and only what fits the ceilings reaches the model. The assistant's older, narrower lookups keep their own limits. Those older lookups do not share this new read budget. The existing turn time limit and spending ceilings apply; no extra model allowance is added. Free text is fenced as data. These lookups cannot call anything that writes. (The proposal stated some of these limits per read and added a limit of three domains; the detailed design applies them once per question.)
• What these lookups never read: an event's notes or place, a baby's logs, the group chat or any conversation. A sealed title is never opened; the item is only counted as one that cannot be read here. A task's own note is looked at only to recognise an older kind of step inside a task, and is never passed on.
• The current meal-plan day is a new read-only lookup. For today, tomorrow or a date from a week ago to a month ahead, it gives the plan, calendar dinner and time. It says plainly when there is no plan, only a dinner on the calendar, a custom plan with no recipe page, more than one plan (at most three named), or data it cannot open. It selects named columns only and reads no task, baby or health table. It omits recipe-day numbers and recipe-page dishes: editable dinner names cannot establish the task-based day number that the phone uses. The view on the phone opens the calendar date using its own task linkage.
• A request to open a tool or show a view — "open photos", "review the pending mail", "import my calendar", "show my tasks", "arrange my Home" — is recognised by the step that reads every request and answered from a fixed table: a sentence and a button for a tool, or a sentence and the live view for one of the group's own lists; no further model call and no lookup. A request to see a baby's growth chart still runs the existing growth-chart lookup, which reads no rows, so that the baby is found on the group's own list. The sentence says that nothing has happened yet ("Nothing has been imported yet"). A spoken request gets a spoken sentence and no button, and a forwarded email can never make this request. A request classified as asking for something to be changed is handled as it always was, and no view is answered from the table for it — unless what was asked for is one of the doors (importing a calendar, arranging Home), which the assistant cannot do itself and whose sentence says so. An ambiguous "open that one" is answered with a question.
• "My tasks" is bound to the conversation's group — fixed on 29 September 2026. Before the fix, the assistant's own-tasks lookup was bounded only by the member's access, so for a member of two groups it could return the other group's task titles into this conversation, processed under this group's level with the other group's names not replaced. It is now bound to the conversation's group, includes tasks shared among several assignees, and is capped at 50; every assistant tool takes its group from the verified conversation rather than from the model (§16).
• Routing is unchanged, and a request that carries baby data still takes the most restrictive route that applies. The combined read runs on the step that summarises across the group's records, which stays in Australia at the Australia level and at "Global, records stay here", and at "Global, everything" may run at the provider's global service, names replaced, unless the request carries health words. "What's for dinner?" on its own runs on the meal planner's existing route — global at either Global level, names replaced — and its lookup reads no baby or health table. A sentence that asks about a baby and about dinner is split, each part on its own route, and at "Global, records stay here" a global step is not shown the conversation's earlier baby turns. The label "chat" is never a way around this. No new model, provider, region or model call is added.
• Unchanged boundaries. Our assistant server does not start reading the transcript; sealed event notes and places are opened only through the existing audited reader; there is no general "decrypt this record" route; Device-only groups, event groups and child accounts keep their current restrictions; photographs and ceremony conversations do not become model inputs.

10.4 Examples of what to ask

At most one example question at a time — "What's for dinner?", "What needs preparing for tomorrow?" or "Show the baby's growth" — may appear where a member has just finished setting up a tool, or at the top of a tool they opened themselves. It appears only when our assistant server says it can answer that kind of question and the group has what the example needs (an adopted plan, growth measurements), and never on the brief. Tapping one puts the question in the assistant's box and sends nothing; the member sends it or not. Examples are never offered to an under-16 account, in an event group or in a Device-only group, follow the same suppression rules as the app's other suggestions, and are not offered again once shown or dismissed on that phone. Which examples a phone has shown or dismissed is kept on that phone, like the existing hint markers, holds no count, and is never sent to us. Setup progress is read on the phone to decide whether to offer one, and is never sent with a request.

11. Legal basis and consents

• No new consent purpose. The layout is a preference the member sets and can reset at any time. Arrange by use is a per-phone switch, off by default, and its record never reaches us; it is the member's own control over a non-necessary, on-device use of their own activity (s 9(2)), and it is not recorded in the consent ledger because nothing is collected by us. Setup choices are not consent to anything (§7). The global AI step uses the existing overseas_processing consent exactly as Settings does.
• Preconditions before the second stage was released, and where each stands:
  • Met. The privacy policy (version 1.16) names the layout table, and describes in plain words the two records kept only on the phone and what they hold, including the dates the Arrange by use record keeps and that the phone's own backup may include them.
  • Met. Our published note on automated decisions, and the same explanation inside the app, describe Arrange by use as a fourth automated decision, made by a fixed rule on the phone rather than a model: what it uses, how the order is worked out, and how to switch it off or start again.
  • Met. A child account's own privacy page, and the children's privacy policy, say in their own words that how a child arranges their Home is theirs alone, and that Arrange by use is off unless they turn it on and is kept on that phone.
  • Decided, and still open. The legal finding in §15 was stated as needing a decision before release. The decision, on 29 September 2026, was to release with the finding open and settle it afterwards. It is not resolved and not accepted (§16).
• Preconditions for the third stage, written before its code and released with it, not before, because each describes behaviour that exists only once the third stage ships:
  • Met. The privacy policy, version 1.17, describes the bounded look-up across tasks, calendar and meal plans and its ceilings, the pointers stored with assistant replies, and which kinds only open a tool; and it replaces version 1.16's statement that the assistant never counts towards Arrange by use with the fourth way a use is noted (§9.2);
  • Met. Our published note on automated decisions, and the same explanation inside the app, say the same about Arrange by use;
  • Met. The app's page on what the assistant can see describes the bounded look-up and the views shown in replies, and no longer says the context it sends is "the whole of it". Since 10 October 2026 that page opens with a short summary that is always shown, and each section, this one included, opens one tap away under its heading; no fact was removed;
  • Met. The under-16 self-assessment was re-run for the third stage against its design, and checked again against it as built (§15).
• No new consent purpose for the third stage. The bounded read answers a question the member asked, under the assistant and privacy level they already have; the fourth qualifying use sits inside the Arrange by use switch the member already controls; examples send nothing.

12. Risks and mitigations

13. Structural versus conventional

Structural, as built:

• the layout table's shape: closed-list identifiers, no duplicates, at most eight per list, pinned and added never also hidden, no timestamp and no content column;
• the layout's row-level security (the member alone, while active; the member may always delete their own row), with every privilege revoked from every role before the member's own grants are added back, and no grant to any server process;
• the revision compare-and-set, enforced by a database trigger and procedure rather than trusted from the phone;
• the cascade from membership to layout, so leaving, removal, account deletion and group deletion remove it, and the trigger that removes it when a membership stops being active;
• the privacy-level procedures, the guardian rule and the consent row the setup step reuses;
• the 30-day deletion of the assistant transcript that carries the pointers (an existing scheduled database sweep);
• the server-side refusals for a child account and a Device-only group, which are unchanged;
• the absence of any server copy of Arrange by use or setup progress — there is nothing to read.

Conventional, and pinned by a test (the tests are listed by name under Sources):

• the phone-side pruning after an authoritative membership list — never after a failed read, a retried sign-in failure or a list restored from the phone's cache — the caps, and the protection that stops a save in flight bringing back a removed record (the member-record and pruning tests);
• the eligibility order, and that a pin can never override it (the widget registry tests; the Home widget data tests);
• that an existing member's default Home is what it was, plus Meals and Mail Sifter only when their data exists, and never a list by default (the Home widget data and Home screen tests);
• Arrange by use's score, warm-up, weekly cadence, the two-point lead, the one-place move, freeze per visit, 28-day expiry, time-zone reset, off-deletes and reset (the Arrange by use tests, run in four time zones), and that it imports nothing but the time helpers, the widget registry and the phone's own record store, that our assistant server never names the layout table, and that the photo and chat modules never import the ordering code (the boundary tests);
• the closed list of four call sites for a qualifying use, and that a widget never notes a use itself (the call-site scan);
• that photos and messages are never reordered by anything, and that nothing displays how others engaged with what a member posted (the existing source scan, extended to every widget, layout and ordering module);
• the paged, visibly ending task and agenda lists (the widget and list tests);
• that setup choices write no consent, group setting, account-wide setting, Mail Sifter switch or Arrange by use record, and that the global AI step writes nothing on "Decide later" (the setup screen and global AI step tests);
• the setup-origin contract — a successful write records, backing out does not, a stale group is ignored (the baby-add and calendar-import tests);
• that setup progress holds no field it does not name, and that a legacy member gets no card and no suppressed hint (the setup progress tests);
• that Edit Home saves only on Save, refuses to save offline, offers Reload only on a genuine conflict, and never treats a refusal as a conflict (the Edit Home tests; the layout store tests);
• the words the published policy and the automated-decisions note rely on, and the vocabulary they must never use (the privacy policy, automated-decision and Edit Home copy tests), and that every number the policy states about Arrange by use is the number the code uses (the policy numbers test).

Conventional, and pinned by a test, for the third stage as built (the tests are listed by name under Sources):

• that a model-facing tool cannot write a layout (no such tool exists, and the boundary test fails if our assistant server names the table; the inventory check fails if a tool is added without being classified);
• the closed list of widget kinds and their allowed identifiers, checked by our assistant server before a pointer is sent and by the phone before it is saved and drawn, both against one shared set of cases that includes hostile ones (extra keys, a malformed identifier, too many items, an unknown kind or version) — conventional because the column that holds them is free-form; a database check on it would move this to the structural list (the pointer tests on both sides);
• that the model never writes a pointer, and sees none but the growth chart's older marker: pointers come only from the lookups, through a per-question channel the model's messages never carry, and from the fixed table for requests to open a tool; and that a pointer-shaped field in the model's own reply is dropped (the reply-path check);
• that whether the member asked for a view is decided by our assistant server, from the request, whatever a lookup suggests (the reply-path check);
• that a view is drawn only for the group on screen, re-checked against the phone's own records for that group, and shown as unavailable, with no buttons, when a check fails; and that the part of the app that draws views never contacts our assistant server (the widget host tests);
• that the app's list of kinds it can show only narrows what is sent, at most three views go with a reply, and a spoken reply carries no pointer (the pointer check; the reply-path check);
• the per-question read ceilings, including a fixture of 200 events and 200 tasks that must respect every one of them and report what was cut, and a lookup refused by the ceiling returning a plain sentence and reading nothing (the combined-read and meal-plan-day checks);
• the columns the two lookups may select — no event notes or places, no baby logs, no chat, and for the meal-plan day no task table (the same two checks);
• the unchanged routing, level by level, including that general conversation and the reading of every request stay in Australia, and the most-restrictive-route rule for requests carrying health words (the routing check);
• that a request to open a tool runs no lookup and no further model call, that a forwarded email cannot make one, and that a request classified as a change is left to run as before (the reply-path check);
• the fourth qualifying use: a tap on an asked-for view notes a use once, a tap on an offered view never does, drawing a view never does, none is noted without the group's time zone, and the call-site scan holds exactly four (the widget host tests; the call-site scan);
• that examples only fill in the assistant's box, are offered only as §10.4 says, are recorded on the phone as shown and never counted, and that nothing about setup progress reaches our servers or a model (the example tests; the Assistant screen test);
• that the five actions moved onto confirmed outcomes report a lost connection as "could not confirm", never as a refusal (the outcome check).

14. Best interests of the child

• Home layout. A child account arranges their own Home like anyone else, over the tools a child can reach. The row is the child's alone: no guardian, admin or member can read it, and it is deleted with the child's membership. There is no "see how your child arranged their Home" view, and nothing here is a monitoring mechanism of the kind s 33 would require us to tell the child about.
• Arrange by use. Offered to a child account on the same terms as to an adult: off by default, switched on only by the child on their own phone, never switched on by setup, by a guardian or by us, and never sent to us. What it gives the child is the same small convenience it gives an adult. What it costs them is a four-week record, on their own phone, of which of a handful of tools they opened on which days. The safer design — not offering it to child accounts — was considered. We did not choose it, because the record is the child's own, is not collected by us, is off unless the child switches it on, and is the child's to switch off. It is also not a way to change the legal position: the regulator gives no weight to restricting a feature by age when deciding whether a service is age-restricted (§15). If the review in §15 leads to a change for under-16 accounts, it will be a change to child access as a whole, not to this switch.
• Setup. A child is offered only the tools a child can reach, with no assistant, no Mail Sifter, no private calendar reading and no global AI step (the level is shown read-only, as before). A child is never asked to recreate the group's babies, plans or photos.
• Assistant widgets (stage three). An under-16 account has no assistant, so no widget pointers, no new reads, no examples and no fourth way of noting a use. A 16- or 17-year-old uses the assistant under their own switch, as before, and the same rules apply — including that using a view they asked for counts towards their own Arrange by use, if they switched it on.
• What the child is told. The switch's own sentence and status lines, the "Hidden from your Home" notice with Undo, and the setup screen's "You can change these later" are the disclosures on the screen. The child's own privacy page now also says, in short sentences, that how they arrange their Home is theirs alone, and that Arrange by use is off unless they turn it on and is kept on that phone and not sent to us; the children's privacy policy adds that the app never turns it on for them, that it keeps the last 28 days, that turning it off or signing out deletes it, and that the phone's own backup can include it.

15. The under-16 rules: the finding

The full re-run is in our under-16 self-assessment §15, its re-run against the built second stage is §15.13, and its re-run against the third stage — its design, then as built — is §15.14. In short:

• We no longer rely on "no engagement signal and no recommender" for this service. Arrange by use orders what a member sees by their own usage pattern, which the regulator names as account information. The explicit layout also selects what is displayed by reference to account information, though a member choosing their own layout is a much weaker case; the choice of view shown with an assistant reply is a third — made by our code from what the member asked and what the lookup read, not by the model. We treat the Rules' extra condition (a recommender feature) as met for the service with the second stage in it.
• That does not make the service age-restricted by itself. It moves the question to whether social interaction is a significant purpose of the service. We have a reasonable argument that it is not. We do not yet have the documented evidence the regulator names, and its guidance tells a service that is unsure to presume that the purpose is significant.
• The finding: released without that evidence, the service would be presumed, on the regulator's own approach, to have social interaction as a significant purpose — and so, with the other conditions met, to be an age-restricted platform — and under-16 child accounts, which exist, would then conflict with the requirement to take reasonable steps to prevent under-16s having accounts. Restricting the new features for under-16s would not resolve it. The ways to resolve it are to gather and document the evidence on purpose and have the position reviewed, or to change under-16 access.
• The decision, 29 September 2026: release Arrange by use with the second stage and settle the finding afterwards. That decision does not resolve the finding and does not make it an accepted risk; it stays open until one of the two ways to resolve it is in place.
• Re-run for the third stage, 29 September 2026 (the self-assessment's §15.14), against its design and then against it as built. The third stage adds the fourth way a use is noted — using a view the member asked the assistant for — which widens what Arrange by use takes in, from moving around the app to one kind of act inside the assistant conversation. It is the kind of use the proposal assessed in that §15 already included, and it adds the same yes-per-tool-per-day and nothing else; as built it is a little narrower than designed (a growth chart never counts). The re-run finds that neither it nor the choice of views changes the analysis: the recommender condition is still treated as met, the question still turns on purpose, and the finding stays open — not resolved, and not a risk we accept.

16. Residual risk, and findings not accepted

Findings not accepted, because they need a decision rather than acceptance:

• The under-16 classification of the service with the second stage in it (§15). Stated as a finding, not a risk we live with. On 29 September 2026 the decision was to release Arrange by use with the second stage and settle this afterwards; the finding stays open until the purpose evidence or a change to under-16 access is in place (the self-assessment's §§15.9 and 15.13). Its re-run for the third stage, against the design and as built (§15.14), leaves it open; the fourth way of noting a use is inside its scope.

Closed:

• The own-tasks lookup's cross-group reach — fixed on 29 September 2026, and no longer open. For a member of two groups, the assistant's "my tasks" lookup in group A's conversation could return group B's task titles, which were then processed under group A's privacy level, with group B's member names not replaced. It mattered where group A had chosen a wider level than group B and the assistant chose that lookup. We recorded it as a defect not accepted, to be fixed ahead of the third stage rather than with it, and it was: the lookup is bound to the conversation's group, includes tasks shared among several assignees and is capped at 50, and every assistant tool now takes its group from the verified conversation rather than from the model. A check runs every assistant tool against a second group's data and fails if any of them reaches it. The third stage's new lookups follow the same rule.

Residual risk we accept:

• Arrange by use is a record of behaviour, on the phone. It is small, short-lived, off by default and never sent to us; it is still a record of which tools somebody used on which days that did not exist before.
• The phone's own backup can copy the phone-only records. We do not receive it; a restored phone keeps and removes them by the same rules.
• A phone we cannot reach keeps its record until the app runs again; switching Arrange by use off on another phone does not reach it.
• Pointers link a conversation to a record (stage three) — including a child's tracker — for up to 30 days, in a column that is not encrypted, together with whether the member asked to see it. No content, no measurement; the same association the growth figure already stores.
• A view the member asked for counts as a use (stage three), so Arrange by use takes in one kind of act inside the assistant conversation. The mark is the same yes per tool per day; what was asked and what was shown are not recorded.
• Adaptation can bury a useful widget that the member reads without tapping. Pinning is the remedy; we will not add dwell-time tracking to fix it.
• The on-phone records and the layout copy are protected by the phone's app sandbox, not by our encryption, like the group snapshot the app already keeps.
• Nearly every rule about what Arrange by use may count is conventional. Tests pin them; tests can be removed. This register is the memory, and §17 names the changes that reopen it.

17. Review triggers

Re-read this assessment, and the under-16 self-assessment's §15, before any of:

• a column added to user_home_layouts, any reader of it other than its member, a grant to a server process, or publishing it as a live feed;
• Arrange by use being sent anywhere by the app in any form, gaining a signal (time, views, counts, notifications), gaining another kind of qualifying use, ranking anything but the listed tools, becoming on by default, or being switched on by anyone but the member — fired for the fourth kind of use on 29 September 2026, by the third stage's design and again by its build: §9.2, and the self-assessment's §15.14;
• photos, messages, ceremonies, people, or anybody's engagement with anything becoming an input to any ordering;
• setup progress gaining a field that is not an identifier, a three-state marker or a yes/no;
• a new widget kind, or a new identifier on an existing kind in §10.2, including any identifier on a kind that is only an opener (the task and event identifiers §10.2 already assesses for a later version are not new);
• a pointer carrying anything displayed by the widget, or being chosen or written by a model;
• the assistant's read ceilings being raised, or a read that is not bound to the conversation's group;
• the third stage giving general conversation its own place in the routing between Australia and the global provider — the cloud inference assessment's table of surfaces is revised before that ships. Checked against the third stage's design, and against it as built, on 29 September 2026: it does not fire. General conversation has been answered since 28 September 2026 on the step that reads every request, which stays in Australia at every level, and the third stage changes no route; the cloud inference assessment records this in its §9;
• the global AI step being shown to anyone who cannot change the level, or pre-selecting an answer;
• the brief or the task allocator moving to the global provider at the Global levels, which changes what "supported requests" covers — fired for the brief on 29 September 2026: its redesign is assessed in our home brief assessment, and §6 and §8 above were revised the same day; the allocator is unchanged;
• any stage being released — fired for the second stage on 29 September 2026, and for the third the same day: this revision describes both as built.

18. Checklist against exposure draft s 38(2)

s 38(3): this assessment preceded the code for the second stage and for the third. s 39: listed on the published register.

19. Sources

Primary: Children's Online Privacy Code, exposure draft, ss 9, 10, 28(2)(g), 33, 38 and 39 (kept with the register's primary sources); Online Safety Act 2021, compilation No. 4 (12 September 2026), ss 63C, 63D, 63G and Division 4A, read on the Federal Register of Legislation on 29 September 2026; Online Safety (Age-Restricted Social Media Platforms) Rules 2025, compilation No. 1 (26 March 2026), s 4A, read on the Federal Register of Legislation on 29 September 2026; eSafety, "How to assess if a service is an age-restricted social media platform" (page last updated 30 March 2026), read on 29 September 2026.

Sibling assessments: ./2026-09-ban-self-assessment.md §§15, 15.13 and 15.14; ./privacy-levels.md §3A; ./cloud-inference.md; ./feature-first-uses.md §§1, 1A; ./child-accounts.md; ./photo-wall.md; ./inbound-email.md; ./device-calendars.md; ./baby-tracker.md §3.4 (the growth figure's { kind, baby_id } precedent); ./home-brief-editions.md (the daily brief in the Home's fixed summary position).

In repo, as built on 29 September 2026: supabase/migrations/<version>_user_home_layouts.sql (the table, its checks, grants, row-level security, the revision trigger, the deactivation trigger and save_home_layout); supabase/functions/export-my-data/index.ts (the export section); lib/widgetRegistry.ts (the eight widgets, the seven rankable tools, the eligibility order); lib/homeWidgetData.ts (what each widget reads, and Edit Home's sections); lib/homeLayout.ts (layout validation, composition and edit operations, the setup seed and proposal); lib/arrangeByUse.ts (Arrange by use) and hooks/useArrangeByUse.ts (the order frozen per visit); lib/groupSnapshotStore.ts (the phone-only records, their caps, pruning and in-flight protection); store/slices/createHomeLayoutSlice.ts (loading and saving the layout); store/slices/createGroupSlice.ts (pruning only after an authoritative membership list); components/Widgets/HomeWidgetArea.tsx, components/Widgets/WidgetHost.tsx, components/Widgets/EditHomeSheet.tsx and components/Widgets/ArrangeByUsePanel.tsx; components/Home/ToolShortcutRow.tsx and components/Tools/ToolsDirectory.tsx (the other two places a use is noted); app/onboarding/setup.tsx, components/Onboarding/steps/, components/Onboarding/GlobalAiStep.tsx, hooks/usePrivacyLevelController.ts, lib/setupProgress.ts, lib/setupOrigin.ts and lib/toolReadiness.ts (setup, its record, the return from a tool's own screen, readiness); lib/featureHints.ts (hints read setup progress); lib/homeModules.ts (the data half of the photo rail and the day-two welcome); lib/privacyLevels.ts (the global AI step's words); constants/editHome.ts (every word Edit Home and the switch say); constants/legalTexts.ts (the privacy policy, version 1.17, and the child's page and policy); constants/aiTransparency.ts (the app's page on what the assistant can see); constants/automatedDecisions.ts and docs/privacy/automated-decisions.md; agent-server/src/tools/generated/choreTools.ts (the own-tasks lookup, §10.3); agent-server/checks/myTasksScope.check.ts and agent-server/checks/toolGroupScope.check.ts (the lookup's group and every tool's group); agent-server/src/privacyLevel.ts and agent-server/src/regionRouting.ts (which steps go global at which level, and the steps that stay in Sydney); agent-server/src/supervisor.ts (general conversation on the step that reads every request); agent-server/src/tools/householdSnapshotTool.ts and agent-server/src/householdSnapshot.ts (the existing combined read the third stage extends, with its named columns and its fetch of up to 1,000 rows); supabase/migrations/20260902131352_chat_retention_sweep.sql (assistant conversations deleted after 30 days); supabase/migrations/20260918091630_event_detail_confirmations.sql (the composite membership foreign key this design copies); the design plan for this work, revision 4, 28–29 September 2026, with the supersessions recorded against it; our internal decision record, docs/decisions/2026-09-29-home-tools-and-widgets.md.

In repo, the third stage as built on 29 September 2026 (every name planned before the code was kept): agent-server/src/widgetReferences.ts and lib/widgetReferences.ts, with the shared cases in test-utils/widgetReferenceVectors.json (the pointer, its kinds and their identifiers, its two validators, and the capabilities /api/usage advertises); agent-server/src/turnReads.ts (the per-question ceilings and the channel that carries pointers from a lookup, never through the model); agent-server/src/surfaces.ts (requests to open a tool or show a view, and their fixed sentences); agent-server/src/supervisor.ts (the request classification that recognises them, and the chat reply's list of what can be opened); agent-server/src/run.ts (answering them with no lookup, the spoken door, and collecting each question's pointers); agent-server/src/aggregate.ts (deciding whether a view was asked for, building the reply's list, dropping a pointer-shaped field the model wrote, and the sentence for a question that looked nothing up); agent-server/src/server.ts (the app's list of kinds it can show, and /api/usage); agent-server/src/mealPlanDay.ts and agent-server/src/tools/mealPlanDayTool.ts (the current meal-plan day, shared with the combined read's meals section); agent-server/src/domains/insightAgent.ts and agent-server/src/domains/mealPlannerAgent.ts (the two prompt rules that keep a meals question a read); agent-server/src/tools/generated/calendarTools.ts, agent-server/src/tools/generated/mealplannerTools.ts and agent-server/src/tools/generated/pantryTools.ts (the five actions moved onto confirmed outcomes); lib/assistantReplyMetadata.ts (what a reply stores), components/Assistant/AssistantWidgets.tsx and components/Widgets/AssistantWidgetHost.tsx (drawing a view, Show on Home, and the fourth call site), with components/Widgets/WidgetHost.tsx and components/Widgets/MealsWidget.tsx (the renderer both surfaces share, and one day of one plan); constants/assistantWidgets.ts and constants/assistantCopy.ts (every word the views and the Assistant screen say); lib/assistantReceipts.ts and components/Assistant/OutcomeReceipt.tsx (what was saved, under the reply just given); lib/assistantExampleLedger.ts, lib/assistantExamples.ts, components/Assistant/AssistantExampleChip.tsx, hooks/useAssistantServerCapabilities.ts and store/slices/createAssistantExamplesSlice.ts (the examples and their shown markers); lib/arrangeByUse.ts (unchanged; now called from four places); docs/assistant-capability-inventory.md (every command a tool accepts, classified for the assistant).

Tests that pin §13's conventional list: __tests__/user_home_layouts_rls.test.ts (shape, grants, a second active member of the same group and an owner or admin reading nothing, a pending member refused, the compare-and-set, key immutability, and the five deletion paths); lib/__tests__/memberRecords.test.ts and store/__tests__/loadUserGroupsPrune.test.ts (caps, pruning only on success, no resurrection); lib/__tests__/widgetRegistry.test.ts and lib/__tests__/homeWidgetData.test.ts (the eligibility order, the default Home); lib/__tests__/arrangeByUse.test.ts, lib/__tests__/arrangeByUseBoundaries.test.ts and hooks/__tests__/useArrangeByUse.test.tsx (the rule, its imports, freeze per visit); lib/__tests__/toolUseCallSites.test.ts (four call sites); lib/__tests__/arrangeByUsePolicyNumbers.test.ts (the published numbers against the code); components/Chat/__tests__/noFeedbackFeatures.test.ts (the source scan); lib/__tests__/homeLayout.test.ts and store/__tests__/homeLayoutSlice.test.ts (composition, seeding, save, conflict and refusal); __tests__/app/(tabs)/home-widgets.test.tsx and __tests__/app/(tabs)/home-edit.test.tsx (Home's order, isolation, paging, Edit Home); components/Widgets/__tests__/ (each widget); lib/__tests__/homeWidgetLists.test.ts (paging and the agenda window in four time zones); components/Onboarding/__tests__/GroupSetupScreen.test.tsx, components/Onboarding/__tests__/setupSteps.test.tsx, components/Onboarding/__tests__/GlobalAiStep.test.tsx and hooks/__tests__/usePrivacyLevelController.test.tsx (setup and the AI step); lib/__tests__/setupProgress.test.ts, lib/__tests__/setupOrigin.test.ts, lib/__tests__/toolReadiness.test.ts and lib/__tests__/featureHints.test.ts (the record, readiness and hints); __tests__/app/(tabs)/tools/baby/add.test.tsx, __tests__/app/(tabs)/tools/calendar/import.test.tsx and __tests__/app/(tabs)/tools/directory-readiness.test.tsx (returns from setup, readiness lines); lib/__tests__/legalCompliance.test.ts, lib/__tests__/automatedDecisions.test.ts, lib/__tests__/childPrivacyPolicy.test.ts, lib/__tests__/aiTransparency.test.ts and lib/__tests__/editHomeCopy.test.ts (the published and on-screen words).

Tests that pin §13's third-stage list: agent-server/checks/widgetReferences.check.ts and lib/__tests__/widgetReferences.test.ts (the pointer on both sides against the shared cases, the ceilings, the channel, the fixed sentences); agent-server/checks/replyPath.check.ts (requests to open answered with no lookup, a forwarded email that cannot make one and a change request that keeps its change, whether a view was asked for, at most three views, none on a spoken reply, none for an older app, a pointer-shaped field from the model dropped, the sentence for a question that looked nothing up); agent-server/checks/householdSnapshot.check.ts and agent-server/checks/mealPlanDay.check.ts (the meals section, a repeating swimming lesson beside a dinner, the 200-row fixture, the refused seventh lookup, the columns, and the meal-plan day's parity with the app); agent-server/checks/regionRouting.check.ts (routing level by level); agent-server/checks/mutationOutcomes.check.ts (the five confirmed outcomes); agent-server/checks/capabilityInventory.check.ts (the inventory); components/Widgets/__tests__/AssistantWidgetHost.test.tsx (the group on screen, the phone's own records, unavailable with no buttons, a Home-only hide, the fourth call site, Show on Home, no contact with our assistant server); lib/__tests__/assistantReplyMetadata.test.ts; lib/__tests__/assistantReceipts.test.ts; lib/__tests__/assistantExampleLedger.test.ts and components/Assistant/__tests__/AssistantExampleChip.test.tsx (the examples); __tests__/app/(tabs)/assistant-audience-and-receipts.test.tsx (the Assistant screen's words, an example that fills the box and sends nothing, and receipts under the reply just given only).