← All privacy impact assessments

PIA: Member types, group types and asking at first use

Amended 28 October 2026, built, not yet released: typing indicators are off unless a member turns them on. The typing indicator ("Sam is typing…" in group chat) now starts off for every new account, and every existing member's switch is set to off once, when this ships, including members who had turned it on; nothing sets it back again, and turning it on is one tap. It stays reciprocal: with it on, you see when others who also have it on are typing, and they see you; with it off, you neither show nor see. Shared displays (walls), profiles and members under 16 neither send nor see typing, whatever their switch says, and our database enforces that rather than the app. The one-time reset is a dated exception, for this switch only, to the rule that a settings tidy-up keeps stored values. Residual risks we accept: the name in a typing mark is chosen by the sender's app, so a member can make it look as if another member is typing (a name only, gone within seconds); a member removed from a group, or a modified app after switching off, can keep seeing typing until their connection to the chat next restarts or their sign-in refreshes, a matter of minutes; members of a group can see who has the switch on; and members who had chosen "on" lose that choice once, with no message in the app telling them. HQ's PIA-013 is the assessment.

Amended 22 October 2026, before release: staged sign-up. An authorised adult still needs a birth month on record showing 18 or over to found a group. A new group's assurance is declared. The invite step after founding uses the existing code and sends through the member's own apps; opening account creation later does not join anyone to a group.

Amended 4 October 2026. The create-group posture question and the onboarding member-type step are removed; groups start Standard and can be made Device-only from Privacy. The personal request ceiling no longer changes where a request is processed, because every request that reaches a model runs at Vertex global (cloud-inference §12).

Amended 22 October 2026 (round 2, item 1): the daily brief is on for every adult in a Standard group. An adult who said no gets it only after their app has shown privacy policy v3.13. Nobody under 18 is moved, and a Device-only group has no brief. Built, server and app, not yet released; it ships only with v3.13. See the amendment at the end of §4.4.

Amended 21 October 2026 (epic 001 D2): member types are removed. There is no member-type card, picker or suggestion in Settings any more, and no "Set by your type" or "Changed by you" label on a switch. Each setting is still the member's own switch, written on its own, exactly as §4.1 describes; nothing applies several at once. Nobody's settings were changed: each stays as it was. The app no longer reads or writes the stored type (users.stance and users.stance_version); the columns are kept, unchanged, for app versions that haven't updated, which still show the card until they do. Nothing in the app now sets the personal request ceiling, which only a Show less choice used to set: a value already written stays, and can only narrow the level that member's own requests run at. A child's page names no member type. Where this assessment describes member types, it describes the app before this change.

Amended 21 October 2026: a child's settings no longer wait for a tap. When a birth month first shows that an account is under 16, our database sets that member's quiet settings straight away: no message previews, no glance details, no typing shown to others, the last message not read aloud, and no detail on the lock screen. Until now the app set them only when the child tapped OK on the Young member card, which now only tells them what is set. It happens once per account: correcting a child's birth month later doesn't set them again, so anything changed since stays changed, and children already under 16 when this shipped were left as they were. Someone aged 16 or 17, and adults, get nothing.

Amended 20 October 2026 (epic 001 D0): group types are retired. A group isn't classified. It is created by its name alone: the "What kind of group is this?" cards are gone, setup has one fixed order and pre-ticks nothing, and no screen shows or changes a type. No word, icon, routine list or default in the app depends on it any more ("the group" everywhere, one home icon, one routines catalogue), and the app no longer reads the column or keeps it on the phone. A new group is stored with the neutral type, and since this change only an owner or admin can alter it. The one place the server used to return it (the invitation card) now returns the neutral value. A type already stored on a group is kept and is not rewritten, and it is no longer shown to anyone by the current app; installed app versions still show it until they update. Where this assessment describes the cards, the sensitive types or a type-derived display, it describes the app before that change.

Planned, 10 October 2026: real notification preferences. This assessment holds the app's one notification preference today — the notification-detail preference of §4.1, which is recorded and still does nothing (§5 R4, §8). Two more are being added, and they will do something: muting one group's chat, and a switch for each kind of notification — chat; an action somebody asks of you; turns and routines; a person joining; the morning brief; and getting started. Not built. Each is one more of the member's own preferences, like the ones in §2's table: the member's own choice, readable and writable by them alone, deleted with their account, never read as agreement to anything and never a consent. Muting a group's chat is per member and per group; it stops that group's chat notifications and that group's turn-and-routine ones, and it does not stop the unread marks the member sees when they open the app.

Why these come first. The app is separately being changed so that it may send a member a small number of notifications they did not ask for — somebody gave them a task, a person joined, a suggestion in their first week. The rule that has always governed notifications here is that a member must be able to find the off switch again, so these switches ship before the notifications they govern, not after. Residual risk, accepted: the notification-detail preference of §4.1 stays a recorded choice with no effect, now sitting beside switches that do work, which may read as though it works too; §4.1's rule stands that no copy mentions it until the feature that reads it exists.

Status: Built on 30 September 2026, the same day this assessment was written; not yet released. Where this assessment disagrees with the plan it assesses, it says so and records what it recommends. Built: member types (§4.1, §4.5), the group types, choosing the group's level while creating it (§3), the daily brief becoming its own first-use consent purpose (§4.2–§4.4), and asking for consent the first time a member meets improvement traces, writing the brief on their phone, or the on-device assistant (§4.2). None of it has reached a phone yet. Written: 30 September 2026 · Last revised: 22 October 2026 (staged sign-up, before release); 21 October 2026 (member types removed; a child's settings set by our database; earlier: 20 October 2026, group types retired; 10 October 2026, planned notification switches) · 30 September 2026 Nothing here is legal advice. We have not taken legal advice at this stage; where a question needed a lawyer we took the more conservative reading and say so. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 December 2026).

As built, 30 September 2026. Every piece named above was built and merged the same day this assessment was written, matching the design in §§3, 4.1–4.5 with no deviation we found. None of it has reached a group or a member yet: database changes take effect at our next release, and each change also needs a member's phone to update to the app version built alongside it. Until both happen, the app keeps working exactly as this document describes "today".

1. Purpose and scope

Why: so that a new member makes one understandable choice about their own screens, and a group's creator makes two about the group, instead of meeting about 110 switches across 14 screens — without any of those choices switching on something that needs a person's consent.

The rule members are told:

The group sets the ceiling. You choose within it. The group's posture decides what our servers may open of shared content and where models run. Your member type decides what your own screens show and how far your own requests go. You can always be more private than the group for yourself; nobody can widen the group alone.

In scope:

• Member types — Show more, Standard (the default) and Show less: a second version of the personal preset we introduced in September ("stances"), which sets a handful of the member's own preferences and nothing else.
• Young member variants, which are decided for a person under 16, and shown differently for a 16- or 17-year-old.
• Group types — Family home, New baby, Two homes, Care team, Share house, Club or team, and Event (automatic) — which describe the group and order its tool list.
• Postures shown when a group is created — Phones only, Australia and Global — which are three of the four existing privacy levels under plainer names. Global, including baby records stays available but only under Advanced.
• A new preference column, users.notification_detail.
• Asking for consent at first use rather than at onboarding, with neutral wording and no "accept all".
• The daily brief becoming a consent purpose, and what happens to members who already have it.
• Existing members and groups: how a choice made under the first version is kept, and the one suggestion they are shown.
• An "About this group" card a joiner sees before choosing anything.

Out of scope, and assessed elsewhere:

• The personal request ceiling (users.request_ceiling, "keep my own requests in Australia even when the group allows Global") is one of the preferences a member type sets, but its enforcement on our server is a change to where requests are processed and is assessed as an amendment to the privacy levels assessment. This assessment covers only that a member type may set it, and the order in which copy may promise it (§5, R5).
• Notification detail itself — a phone opening a sealed title inside a notification — needs a native notification extension and has its own assessment when designed. This assessment covers only the column that records the preference.
• "Send to GroupApp" feedback: its own assessment.
• The four privacy levels, their widening and narrowing rules and the guardian rule: unchanged, and assessed in the privacy levels assessment. The posture step is a new entry point into the same procedure, not a new procedure.
• Home widgets and the needs chooser: the Home and onboarding assessment.
• The daily brief's own data flows: the home brief assessment. This assessment covers only the consent that now governs a member's part in it.

2. Data involved

Two group types say something sensitive about the group, and we are adding them anyway. Two homes tells whoever can see the group's type that the children's parents live apart. Care team implies that someone in the group, or known to it, needs care — an inference towards health information. Both are stored exactly where every other group type is: on the group's own row, readable by its members. We add them because the people these groups are for asked for a name that fits them, and a group that has to call itself "Family" or "Group" to use the app is being asked to misdescribe itself. Three limits hold:

• No model receives the group type. Nothing on our assistant server reads it today; the design keeps it that way, and the check listed in §6 makes that a test rather than a hope.
• The type is shown to an invitee. A person invited by email sees the group's type on the invitation before they join (they already see its name). We accept this: the person inviting them chose both.
• The type never decides anything. It does not change what the group may use, who may join, or where its requests are processed (§6).

Why each item is necessary. The member type and its version are the least that can answer "what did this member choose, against which list" — without the version, a later release that adds a setting would silently reclassify every member who chose under the earlier one. The preference columns already exist, except notification_detail, which is added so that the member types can record the choice before the feature it governs exists (see R4). The group type is the group's own description and is needed to show the group's own name for itself.

Not collected, and could have been:

• No stored group profile. The plan proposed a groups.profile column beside groups.type. We do not add it: New baby is "a family with a baby", which the app can see from the group's own records, and a second stored description of the group could only ever disagree with the first. The "This group" card works out the best-fitting type when it is shown.
• No reason for a choice, no "why do you want less?", no inferred member type, and no record of which member type was shown first or how long a person looked at it.
• No usage analytics about the choices. The plan lists measures (how many people choose a type in onboarding, how many are Custom within 30 days); each needs its own short assessment before anything is collected, and none is collected by what this assessment covers.
• No questionnaire answers from onboarding are stored on our servers beyond the choice itself.

3. Flows and locations

Nothing in this assessment sends anything to a model. Choosing a posture during onboarding goes through the existing privacy-level procedure, whose flows are assessed in the privacy levels assessment.

Starting a group at Phones only. Today a new group is always created at Australia; its first device then makes the group's key and, at Australia, offers our server a copy wrapped under our key service. A group that later moves to Phones only rotates its key so that the server's copy stops opening anything new. We recommend that the posture chosen while creating a group is applied as the group is created, so a group that starts at Phones only never offers our server a copy of its key at all. A group that chooses Global is created at Australia and then widened through the existing proposal, because a widening needs the recorded overseas-processing consent and the announcement that only exist once the group does.

4. Legal basis and consents

4.1 A member type is a preference, never a consent

A member type writes only the member's own non-consent preferences, one at a time through each setting's own writer, and records which type was chosen. It writes no consent row, and no setting that is marked as consent-class can ever be a member of a type: the list of settings a type may cover is worked out from our settings map, which excludes every consent-class setting, so a setting that becomes consent-class later drops out of the types automatically. This is the draft Code's unbundling rule (s 14(3)(b)) applied: a person cannot agree to the assistant, the brief, voice, Mail Sifter or improvement traces by picking "Show more".

Since 21 October 2026 there are no member types (epic 001 D2). What this section required of them holds without them: each preference is written only by its own switch, one at a time, and no code that writes a preference writes a consent. A test fails if any app file names the removed type code or writes users.stance.

A group type is not a consent either, and never applies a posture. It may recommend one on the next screen. The recommendation is never wider than Australia, so a highlighted choice can never be the one that needs a consent (§6).

4.2 Asking at first use

Each consent is asked the first time the member meets the feature it governs, not in a list during onboarding:

How a prompt looks, as a rule, with our position taken without legal advice: each consent is its own moment on the screen; the switch starts off; the two answers are equal in size and weight ("Turn on" and "Not now"); the wording says what is sent, to whom, where and for how long, and how to turn it off; there is no "accept all", no "recommended", and no social-proof line ("most people…", "people like you…"). Every prompt's words are tested for those phrases. "Not now" writes nothing to the consent record — a consent record is a record of acts, and a person who has not agreed has not acted. This phone remembers that the prompt was shown so that it is not shown on every visit; "Your choices" in Settings lists the feature as not turned on, with a way to turn it on.

Two layers, from 10 October 2026. The daily brief's prompt and the two on-phone prompts (the briefing written on this phone, and the assistant on this phone) now keep on the screen what the choice turns on: what it does, who receives what and where (shown), the important limit (shown — for the brief, that another member's brief can still mention tasks assigned to you; for the phone's own model, that the group's shared briefing is still written on our servers, or that a change you confirm is saved to your group), and how to turn it off (shown). How long a paragraph is kept, that your own line is written on this phone, what is not saved, how rough a phone's model can be, and that we ask again in twelve months open under "How it's handled", one tap away on the same card and above both answers (one tap). No fact was added or removed, so the wording versions moved (daily brief 2.1; each on-phone prompt 1.1) and an earlier yes still counts: nobody is asked again. We accept the shorter card under our principle of being useful first, with informed opt-in. The young member's own AI prompt and the prompt for improvement traces are unchanged and show everything.

Age. A person under 16 is not offered the brief, the assistant, voice or Mail Sifter at all, so there is nothing for them to consent to. A 16- or 17-year-old is asked like any adult member, in the same neutral way.

4.3 The daily brief becomes a consent purpose

Until now the daily brief has been on for every adult member unless they turned it off, and turning it on or off recorded no act in our consent record. We have decided to make it a consent purpose, daily_brief, recorded like the others, and lapsing after twelve months like the others. New members start with it off and are asked on Home.

What a member's answer controls needs saying plainly, because the brief is now one paragraph written for the whole group from the group's shared records. A member's consent decides whether their opening the app may cause the group's brief to be written, and whether they see it. It does not stop the brief being written for the group when another member who has agreed opens the app, and a task assigned to the member who said no can still appear in it — just as that member cannot stop another member reading the group's task list. We say this in the prompt's own words.

The new answer is recorded under a new setting (daily_brief) whose absence means "never asked", rather than by changing the meaning of the existing setting, whose absence has always meant "on". Reusing the old setting would have required writing an answer for every existing member, which our own rule forbids: no migration writes a preference or a consent.

4.4 Existing members: "keeps running until they answer" — our reasoning

We decided that existing members are asked once, on their next visit to Home, and that the brief keeps running for them until they answer. We examined whether that is defensible rather than assuming it.

For it:

1. It is the state they are in and were told about. The brief has been on by default and described in the privacy policy and on the app's AI page. Continuing it for a short period changes nothing a member was told.
2. Turning it off unasked is also a change made without their act. Our rule is that nobody's settings change without their own act. Stopping a feature someone uses, on the day an update arrives, is a change of that kind in the other direction.
3. The question is asked at the moment it matters. A member's opening of Home is what causes an edition and what shows one, and the prompt is shown on that same visit.

Against it:

1. Continuing is not consent. A member who has not answered has not agreed to anything, and our consent record must not say they have. It will not: nothing is written for them.
2. Indefinitely is not a transition. A member who dismisses or ignores the prompt forever would keep causing processing under a purpose we now say needs consent, and "Your choices" would show it as never given while it runs. That contradiction is exactly what the consent record exists to prevent.
3. 16- and 17-year-olds. Our children's assessment says the assistant and AI features are off for a young person until their own consent. A carry-over that keeps an AI feature running for a 16-year-old who never agreed would contradict it.

Our finding. "Keeps running until they answer" is defensible as a bounded transition with three conditions, and not otherwise:

• (a) It ends on a date. We recommend that the carry-over ends 30 days after the change reaches members. On that date an unanswered existing member's brief stops, and Home says so in one sentence with a way to turn it back on — our rule is that if the app alters something a member had, it says so where the member sees it.
• (b) Nothing is recorded as consent. The carry-over is a statement in the privacy policy's change summary ("members who had the daily brief keep it until they answer, or until [date]"), never a ledger row.
• (c) It does not apply to anyone under 18. A 16- or 17-year-old existing member is asked, and the brief is off for them until they say yes. (No one under 16 has the brief.)

All three conditions are adopted (30 September 2026): the carry-over ends 30 days after the change reaches members, nothing is recorded as consent, and it does not apply to anyone under 18.

Amended 22 October 2026 (round 2, item 1): on for every adult in a Standard group. The founder decided (Q1, 22 October 2026) that the brief has no switch for adults in a Standard group. It is assessed in the PIA-001 round-2 addendum §1, approved with conditions 1-1 to 1-7.

What is built: our server's half. Not yet released.

• One authority. daily_brief_answer(p_group_id) answers standard for an active member of that group who isn't a child, in a group that isn't Device-only, whose latest privacy-policy acknowledgement is v3.13-2026-10-23 or later. In every other case it answers exactly what the zero-argument function answers. Older app versions still call the zero-argument function, so their switch keeps working. Nothing in the app, the request or the group's kind infers a yes. Our server passes the group and reads the answer on every request.
• A no is overridden only after the notice. An adult's earlier no, a withdrawal, a lapsed carry-over or an account never asked becomes standard only once that member's app has shown the v3.13 policy, which says the brief has no switch. Until then the old answer stands. The version is read exactly as the fast-command notice reads it, and anything that isn't a real version and date counts as no acknowledgement.
• Condition (b) still holds. standard isn't consent, and nothing is written to the consent record. The daily_brief and dashboard_insight rows already there stay.
• Condition (c) still holds, and so do the child rules. Child accounts are refused first. "Child" uses the tests we already have: under 18 by birth month, linked to a guardian with no birth month, or once linked with no birth month since. A child with no birth month is refused before their answer is read, and is never standard. A 16- or 17-year-old with a birth month on record gets the brief only after their own yes to it, which still works: standard is never their answer, and our server refuses a standard answer for anyone under 18, or whose age it can't read. No one under 16 has the brief. A Device-only group has no brief and its phones never ask our server for one.
• Condition (a) now matters only before the notice. The 30-day carry-over still decides for an adult who hasn't yet acknowledged v3.13.
• Nothing widens. No new source and no new model call. Still at most two editions per group a day (morning from 04:00 and evening from 15:00, in the group's time zone), each shared by the whole group, repairs still capped, still paid from the group's A$0.50 a week, and at the cap the brief is unavailable rather than over budget.

What is built: the app's half (23 October 2026). Not yet released.

• The app asks about the open group. It reads daily_brief_answer(p_group_id) for the group that is open, again on every group switch, and never keeps the answer on the phone. It shows what the database says and works nothing out for itself.
• No ask and no switch for standard. Home shows no brief question, and in Your choices the daily brief is shown retired, with "On for adults in Standard groups (since 23 October 2026)" in place of a switch that would do nothing. The consent record already there stays.
• Everyone else keeps their choice. A 16- or 17-year-old keeps their own yes or no, and so does anyone whose app hasn't yet shown v3.13. An older app keeps the question and the switch, and goes by its own switch: when it's off, that app doesn't ask our server for a brief.

Residual, accepted (founder, Q1): an adult who said no gets the brief after seeing one notice, and has no switch to turn it off again.

4.5 Existing member-type choices

A member who chose Reserved or Open under the first version keeps that choice, and is measured against the first version's own list — never against the new one — so nobody reads as having changed their settings because we changed the definitions. The names they see become Show less and Show more, which describe the same direction. Once, they are shown a suggestion: "Your settings look most like Standard. Keep them, or choose a type." Keeping them writes nothing. The first version's "show message text in notifications" setting has controlled nothing since chat notifications stopped carrying message text; its old values are never read as agreement to the new notification-detail preference, which starts off for everyone.

4.6 Postures chosen in onboarding

Choosing Global while creating a group uses the existing procedure: an admin proposes it, the number of confirmations the database requires is met (a group of one completes at once), the overseas-processing consent is recorded and lapses after twelve months, and the change is announced in the group's chat. Global, including baby records is not offered in onboarding; it is under Advanced, where a guardian's confirmation is required if a child is in the group. Choosing Phones only is a narrowing and needs one tap.

5. Risks and mitigations

A finding about 16- and 17-year-olds. Our children's assessment describes 16- and 17-year-olds as having the full app with the assistant and voice off by default until their own consent, and the plan this assessment covers calls that an existing rule. We checked: nothing enforces it. Our assistant server refuses only accounts under 16, and the app treats a 16-year-old as an adult. The "Young member (16+)" card must not say that AI is off until they choose, until that rule is built on our server first. We record this so the gap is fixed rather than described. Built 30 September 2026, not yet released: the rule will be enforced by our server once released — see the children's assessment, §5.3.

6. Structural versus conventional

7. Best interests of the child

Children appear here in three ways: as members who hold an account (13–17), as the subject of a group's type (a child with two homes), and as the reason a group is a New baby group.

• What it gives a child. A child under 16 makes no privacy decision at all: their settings are decided in their favour (the quieter preferences) and every AI feature is absent. A 16- or 17-year-old makes the same one choice an adult does, in the same plain words, which respects the autonomy the Code expects for older children.
• What it costs. A Two homes group records that a child's parents live apart, visible to every member of that group and to anyone invited to it. That is information the parents chose to describe; we do not infer it.
• The safer design, and why not chosen. Leaving Two homes out would have kept that fact off the group's row, at the cost of co-parents describing their group as something it is not. We judged that the group's own accurate description, visible only to people the parents invited, serves the child's interest in a well-coordinated two-home arrangement better than a misdescription does.
• Where parent and child interests diverge. A guardian may prefer a child's phone to show more on its lock screen; the Young member settings keep a child's lock screen quiet regardless. The child's interest (not having their group's details shown to whoever holds their phone) won.
• What the child is told. Their own page lists what the adults decide and what is theirs. It names no member type: none was ever added, member types were removed on 21 October 2026, and a test checks the page's words. The Young member card at setup tells them their settings are set for them, and asks nothing.

8. Residual risk we accept

• The daily-brief carry-over, for 30 days. Existing adult members who have not answered keep causing the group's brief for up to 30 days after the change reaches them, with no consent recorded. On the end date it stops and Home says so.
• A member's "no" to the brief does not stop it being written for the group. Their assigned tasks can still appear in a paragraph another member caused. This follows from the brief being one paragraph for the group.
• Sensitive group types, already stored. Two homes and Care team say something about a family or a person's care. Since 20 October 2026 nothing new is stored and invitees are sent the neutral value, but a value already on a group's row is kept (no rewrite, by decision) and an old app version can still show it to members until it updates.
• A preference with no effect yet. notification_detail records a choice for a feature that is not built. No screen shows it until it is.
• Older copies of the app. Until they update, they still show member types, apply them without skipping settings the group's level has settled, and show "standard" as not chosen.
• The request ceiling has no switch. Since member types were removed, nothing in the app sets or clears it. A member who chose Show less keeps the value, which only narrows the level their own requests run at; no screen mentions it (§5 R5).
• The 16–17 rule is built, not yet released everywhere. Our server enforces it from the day it is deployed (children's assessment §5.3); an older copy of the app does not show the prompt, so a 16- or 17-year-old on it is refused with a sentence until they update.

9. Review trigger

• (Added 22 October 2026, before release.) The founder opens account creation more widely: an authorised adult founder still needs an adult birth month, and opening does not join anyone to a group, but this assessment is re-read on that date.
• Any setting becomes, or stops being, consent-class.
• Anything brings back a preset that sets several preferences at once.
• Anything starts reading users.stance or groups.type to decide what a member or group may do, or any model starts receiving the group type.
• The daily-brief carry-over decision changes, or its 30-day end date passes.
• The 16–17 AI rule is built (this assessment is revised to say so).
• A group type is added or renamed.
• Usage measures of these choices are proposed.

10. Checklist against exposure draft s 38(2)

11. Sources

Primary: exposure draft of the Children's Online Privacy Code (ss 13, 14(3)(b), 15–17, 20, 33, 38–39) — https://www.oaic.gov.au/__data/assets/pdf_file/0020/262631/Exposure-Draft-Childrens-Online-Privacy-Code.pdf

Our own code and documents:

• the plan this assesses: docs/privacy_personas_plan.md §§5, 6, 10–12, 14;
• the implementation design: docs/member_and_group_types_design.md;
• the first member-type version and its rules (removed 21 October 2026; in git history before epic 001 D2): lib/stances.ts, hooks/useStance.ts, supabase/migrations/20260908022846_ws19_personal_stance.sql, docs/walkthroughs/2026-09-08-ws19-demarcation-stances.md;
• the settings map and "decided for you": lib/settingsScope.ts, lib/settingsDemarcation.ts;
• the consent record: lib/consents.ts, supabase/migrations/20260907230010_consent_ledger.sql, the latest purpose list in supabase/migrations/20260914224739_group_inbox.sql, the latest sweep in supabase/migrations/20260928200001_tracing_consent_v2_sweep.sql;
• the daily brief's current switch: agent-server/src/brief/route.ts (readBriefSwitch), hooks/useDashboardInsight.ts, and the home brief assessment §§7–8;
• group types: retired on 20 October 2026 (epic 001 D0); nothing reads groups.type (lib/__tests__/groupTypeRetired.test.ts, __tests__/no_function_reads_group_type.test.ts, agent-server/checks/privacyLevel.check.ts §9);
• onboarding as built: app/onboarding/create.tsx, app/onboarding/setup.tsx, components/Onboarding/GlobalAiStep.tsx, hooks/usePrivacyLevelController.ts, lib/privacyLevelActions.ts;
• the key copy offered to our server: lib/crypto/keyring.ts (offerServerWrap);
• the 16–17 finding: the child accounts assessment §4 against agent-server/src/childAccount.ts, which reads only is_child_account (under 16);
• the invitation that shows a group's type: supabase/migrations/20260923231501_direct_group_invitations.sql.