← All privacy impact assessments

Self-assessment: is GroupApp an age-restricted social media platform?

Status: Current. It assesses GroupApp as it ships on 8 September 2026, before child accounts exist. Two assessments in one document, since 29 September 2026. Sections 0–14 are the assessment of the app as it runs without the personal Home. Section 15 re-runs the test for a service with a personal Home, arrangement by use and assistant widgets; it records a finding about under-16 accounts, and corrections to the sources quoted in §§0–1 (the s 63D penalty has doubled since they were written). §15.13 re-runs it against the second stage as built — the personal Home and Arrange by use, without the assistant widgets. The decision was to release that stage with the finding open: it is not resolved and not an accepted risk, and from the day the stage is released §15 is the position that applies to the app. §15.14 re-runs it against the third stage — views in assistant replies, and a fourth way Arrange by use notes a use — first against its design before it was built, then against it as built; it leaves the analysis and the open finding unchanged. §15.15 (25 October 2026) re-runs it for tool cards on a quiet Home, chosen by account information, and a one-time tip; it too leaves the analysis and the open finding unchanged. A card inviting adults to add photos weakens the design argument in §15.6; the founder accepted it on 25 October 2026, and it is on.

§16 (31 October 2026): emoji reactions on group-chat messages are back, and the §15.9 finding is accepted by the founder. A reaction is a feedback feature, so limb (a)(iv) is now met on a second, unarguable route, and whether GroupApp is an age-restricted social media platform turns only on its purpose, limb (a)(i). §16 is the position that applies to the app from the release that ships reactions. HQ PIA-016 is the privacy assessment. Amended 22 October 2026, before release. The server still limits new accounts to authorised addresses. A listed address alone is not proof of age: a person must give a birth month before founding or joining, or join through a confirmed guardian link. When the founder opens account creation, the authorised-address requirement ends but those membership and child controls remain. A false declaration remains an accepted beta residual.

Written: 7 September 2026 · Last revised: 31 October 2026 (§16: emoji reactions; §15.9 accepted) · 25 October 2026 (§15.15: tool cards on a quiet Home) · 22 October 2026 (staged sign-up, before release) · 29 September 2026 Nothing here is legal advice. This is our own reasoning, written down so a lawyer can review a draft rather than compose one, and so that the argument can be re-run when a feature changes.

What changed on 2026-09-08, and why the position moved. The 2026-09-07 draft found that GroupApp had a feedback feature (§5.3) and therefore satisfied the Rules' additional condition, which left the whole assessment resting on limb 63C(1)(a)(i) — a purpose argument eSafety's guidance tells an unsure service to presume against. §12 recorded that as an accepted risk, on the reasoning that read receipts were "a considered privacy design and deleting them to improve a technical argument would be optimising for the wrong thing".

We reversed that trade on 2026-09-08 and removed the three feedback features instead: chat read receipts, photo-like attribution and the like action, and emoji reactions on messages. The reasoning is not that the old design was bad — it was not — but that the app was spending its entire legal position on an argument about purpose, which is unwinnable without usage evidence, in order to keep three small surfaces. Removing them settles the question one step earlier, at the features step, where the answer is a fact about the code rather than an argument about what the app is for.

The result is that §5 now fails for every limb of Rules s 4A, so 63C(1)(a)(iv) is not satisfied and the purpose question in §3 is never reached. §3 is retained in full anyway: it is still the honest state of that argument, it is what the app falls back on if any reading of §5 is wrong, and the §7A stocktake is retained as evidence for it.

0. Why this document exists, and what it is not

The under-16 minimum age has been in force since 10 December 2025. If GroupApp is an age-restricted social media platform, s 63D of the Online Safety Act 2021 requires its provider to take reasonable steps to prevent age-restricted users having accounts — civil penalty 30,000 penalty units — and there is no parental-consent exception anywhere in Part 4A. That is the fact that shapes everything downstream: our child-account design is only lawful if the service sits outside the definition. A guardian being present does not buy an exemption, and — per eSafety's guidance, §1.3 — a restricted experience for under-16s carries no weight in the purpose test either. What the guardian design buys is harm reduction under the privacy Code. The ban question is decided on how the service is used by everyone.

This assessment is written now, before any under-16 holds an account, because the answer decides whether that feature may be built at all.

A correction to our own privacy posture note, up front. That note's §4.3 says a service is age-restricted "only if all four limbs hold: significant purpose is social interaction; users interact; users post; and a recommender or 'logged-in feature' — endless feeds, displayed like counts, disappearing content." That was taken from a summary, and our privacy programme flagged it for re-checking against the primary text. Re-checked here, the framing is roughly right in outcome and wrong in two ways that matter:

  1. The fourth item is not a fourth limb of the Act. It is 63C(1)(a)(iv) — "such other conditions (if any) as are set out in the legislative rules" — and the Rules fill it in. There are also two routes into the definition the summary omits (63C(1)(b), a service the Minister specifies) and two routes out (63C(6)).
  2. The Rules define a "feedback feature" far more broadly than "displayed like counts". On the statutory wording, GroupApp has feedback features today and dropping the numeric like tally did not clear this condition. Section 5 below sets out why. That is the single most consequential finding in this document, and it means the defence rests on 63C(1)(a)(i) — purpose — much more heavily than our posture note implies.

1. The test, from the primary sources

1.1 Section 63C, Online Safety Act 2021

Inserted by the Online Safety Amendment (Social Media Minimum Age) Act 2024 (No. 127, 2024), Schedule 1 item 7. Verified against the authorised version registered 12 December 2024 on the Federal Register of Legislation. Quoted in full because the whole assessment turns on its wording:

63C Age-restricted social media platform

(1) For the purposes of this Act, age-restricted social media platform means:

(a) an electronic service that satisfies the following conditions:

(i) the sole purpose, or a significant purpose, of the service is to enable online social
    interaction between 2 or more end-users;
(ii) the service allows end-users to link to, or interact with, some or all of the other
     end-users;
(iii) the service allows end-users to post material on the service;
(iv) such other conditions (if any) as are set out in the legislative rules; or

(b) an electronic service specified in the legislative rules;

but does not include a service mentioned in subsection (6).

Note 1: Online social interaction does not include (for example) online business interaction.

(2) For the purposes of subparagraph (1)(a)(i), online social interaction includes online interaction that enables end-users to share material for social purposes.

Note: Social purposes does not include (for example) business purposes.

(3) In determining whether the condition set out in subparagraph (1)(a)(i) is satisfied, disregard any of the following purposes: (a) the provision of advertising material on the service; (b) the generation of revenue from the provision of advertising material on the service.

…

(6) An electronic service is not an age-restricted social media platform if: (a) none of the material on the service is accessible to, or delivered to, one or more end-users in Australia; or (b) the service is specified in the legislative rules.

Section 63D: "A provider of an age-restricted social media platform must take reasonable steps to prevent age-restricted users having accounts with the age-restricted social media platform. Civil penalty: 30,000 penalty units."

1.2 The Rules

Online Safety (Age-Restricted Social Media Platforms) Rules 2025 (F2025L00889), made 29 July 2025. Section 4A sets the 63C(1)(a)(iv) condition; section 5 sets the 63C(6)(b) exclusions. Section 4A, verified against the Register:

4A Additional condition a service must satisfy to be an age-restricted social media platform

(1) For the purposes of paragraph 63C(1)(a)(iv) of the Act, it is a condition that the service has either or both of: (a) a recommender feature; (b) a logged-in feature.

(2) A service has a recommender feature if the service can: (a) select material by reference to any information that the service has associated with an end-user's account; and (b) display that material to the end-user while the end-user is using the service.

(3) A service has a logged-in feature if the service: (a) has one or more of the following features: (i) an endless-feed feature; (ii) a feedback feature; or (iii) a time-limited feature; and (b) does not enable an end-user to access, or be exposed to, at least one such feature unless the end-user is using the service with an account.

(4) A service has an endless-feed feature if the service can display material to an end-user: (a) in a feed of material that has no end-point; or (b) in a feed of material that has an end-point, but to which additional material is added: (i) when that end-point is reached; (ii) at time intervals; or (iii) in response to the end-user's input.

(5) A service has a feedback feature if the service can display information to an end-user about: (a) the extent to which other end-users have viewed or otherwise engaged with material posted by the end-user, or (b) notifications opted into by other users.

(6) A service has a time-limited feature if the service enables viewing of material only within a limited period after it has been posted.

Section 5 excludes services whose sole or primary purpose is: (a) communication by messaging, email, voice calling or video calling; (b) playing online games with other end-users; (c) sharing information about products or services, such as reviews, technical support or advice; (d) professional networking or professional development; (e) supporting the education of end-users; (f) supporting the health of end-users; and two further classes covering institution-to-student and healthcare-provider-to-patient communication.

1.3 What could not be verified at first, and what the source said when it arrived

eSafety's assessment guidance timed out on every automated fetch between 2026-09-02 and 2026-09-07. We retrieved it by hand on 2026-09-08 (page last updated 30/03/2026) and keep it verbatim with the primary sources this register cites. Read against it, this document was right about the statutory test and wrong about two things, both corrected in place on 2026-09-08:

  1. Age-restricted features carry no weight in the purpose test. Step 7 of the guidance: "If a service restricts access to certain features which enable online social interaction based on age, this is not to be given any meaningful weight, as the service must consider its purpose(s) holistically." The first draft of §8 said the child-safe variant was "directly relevant evidence" under 63C(1)(a)(i). It is not. The variant is a privacy-Code measure and a harm-reduction measure; it is not part of the ban argument at all. §8 now says so.

  2. When unsure, presume significant. Step 7: "If end-users do appear to engage or be enabled to engage in online social interaction but the service is unsure whether it is a significant purpose, the service should presume it is significant." The first draft's §7 stated a position ("not an age-restricted platform") as though the purpose argument were settled. It was not, and the guidance names the evidence that would settle it — a documented stocktake of every social feature, with usage figures, and user surveys — none of which existed. §7 was rewritten the same day to presume against the app on that limb.

    This is the correction that produced the 2026-09-08 revision, and its consequence is worth following. A service told to presume against itself on the only limb it is relying on has, in effect, no position. Rather than spend months assembling usage evidence to discharge a presumption — with child accounts blocked meanwhile, and the answer decided by how ten people happened to use the app — we removed the features that made limb (a)(iv) true (§5.3). The purpose test is then never reached, and this correction's force is preserved rather than argued around: §3 and §7A still state the purpose argument honestly and still presume nothing in the app's favour. They are simply no longer what the position rests on.

The guidance also confirmed, in the regulator's words, what §4 and §5 concluded from the Rules' text: messaging in a closed group, inviting someone to join a group, and reacting with a like or an emoji are all "interaction" (Step 4); and a feedback feature is any display of "how many end-users have viewed or engaged with … material posted to their account" (Step 5(b)). Both readings are the ones §5.3 acted on — the regulator naming likes and emoji reactions as interaction, and defining a feedback feature broadly enough to catch attribution as well as counting, is why all three surfaces went rather than only the numeric tally. It broadened one thing this document had treated as obviously absent — the recommender definition (Step 5(a)) reaches any selection of material "based on any information associated with their account", explicit as well as inferred — see §5.1.

The guidance does not publish a list of specific in-scope or out-of-scope services (that is a separate page, "Which platforms are age-restricted?", not retrieved); the earlier note that such a list was unverified is withdrawn as moot. We also retrieved the Children's Online Privacy Code exposure draft on 2026-09-08 and keep it with the same primary sources; its section numbers as cited across this register were verified against it, and that verification is logged alongside them.

2. The service being assessed

GroupApp as it ships on 2026-09-08: an invite-only iOS and Android app for a group — a family, a couple, a share house, a carer team — to run its shared life. Tasks and chores, a shared calendar, meal plans and shopping, a group chat, a photo wall, a baby tracker, a games hub, and an AI assistant that acts on the group's own tasks and calendar.

Facts that bear on the assessment:

3. Limb (a)(i) — sole or significant purpose

the sole purpose, or a significant purpose, of the service is to enable online social interaction between 2 or more end-users

This is the whole defence, and it should be argued as such rather than hidden behind three weaker points.

The app's purpose is organising: who is cooking, who is collecting, what is in the fridge, when the appointment is, what the baby did today. Chat and photos exist because a family that is coordinating also talks, and because the coordination is unusable if you have to leave the app to say "running late". The store listing, the onboarding and every screen say organiser.

Arguments for the app:

Arguments against, stated because a self-assessment that only lists its own good points is worthless:

Conclusion on limb (a)(i): genuinely arguable, and the app's best point — but not a safe harbour, and it should never be described as one. The honest sentence is that a significant purpose of GroupApp is enabling a group to run its shared life, and the sharing that happens inside it is in service of that; whether a regulator agrees is not something this document can settle.

AND THIS LIMB IS NOT REACHED, WHICH IS WHY THE SECTION READS THE WAY IT DOES. Since 2026-09-08 the app fails the cumulative condition at limb (a)(iv) (§5.5), so the definition fails before the purpose question arises. This section is deliberately left as it was — argued both ways, conceding that "significant" is a low bar and that the app has no usage evidence — because a fallback that had been quietly improved once it stopped being load-bearing would be worth nothing on the day it is needed. If §5.1's recommender reading is ever rejected, this is what remains, exactly as honest as it was when it was the whole defence.

4. Limbs (a)(ii) and (a)(iii) — interaction and posting

(ii) the service allows end-users to link to, or interact with, some or all of the other end-users; (iii) the service allows end-users to post material on the service

Both are satisfied. Neither is contested, and the design should not pretend otherwise.

Limb (ii) says "some or all of the other end-users". A member interacting with the four other people in their group is interacting with some of the service's end-users. The absence of discovery makes the set small and non-expandable; it does not make the limb false.

This matters because the privacy-programme spec claimed that removing every cross-group surface from a child account "makes limb (b) false for every under-16 by construction". On the statutory wording that claim is too strong and should not be repeated: a child in a family group can chat with their parents and siblings, which is interaction with some other end-users. What the child-safe variant actually achieves is set out in §6 — it is real, and it is not this.

Limb (iii) is satisfied by any post to chat or the photo wall. The Rules' exclusion for messaging services shows that posting inside a closed conversation is not itself the mischief.

An RSVP is a coordination fact, and it is recorded rather than removed. Raised here because after the 2026-09-08 removals (§5.3) it is the most feedback-shaped thing left in the app: a member who creates a dinner event can see who has said yes and who has said no (invited_user_ids / declined_user_ids on group_schedule_events), and that is unmistakably information about how other members responded to something they created.

It is not a 4A(5)(a) feedback feature, for two reasons that should be read together rather than either alone:

What keeps this true, and what would break it. Today the display is the answer itself, for one event, to the people in that household. It would become something else if the app aggregated across events into a picture of a person's responsiveness — "Sam accepts 40% of invitations", a reliability score, a streak, a leaderboard of who turns up. That is a characterisation of a member built from their engagement, and it is exactly the shape this app has refused elsewhere — our standing rule is that the chores-and-points layer counts what was done, does not characterise the person who did it, and never ranks members against each other. §10 carries it as a review trigger.

5. Limb (a)(iv) — the Rules' additional condition

it is a condition that the service has either or both of: (a) a recommender feature; (b) a logged-in feature

5.1 Recommender feature — not present

Nothing in the app selects material by reference to information associated with an account and displays it. Chat is chronological. The photo wall is chronological, grouped by album or by the month the photo was taken in (worked out on the phone, in the group's timezone). Tasks and the calendar are ordered by date. There is no ranking, no "for you", no suggested content.

The two model-driven surfaces are worth naming so the absence is not mistaken for an oversight: the home brief writes one paragraph, per group, from a fact sheet the server already assembled, and cites the facts it draws on, so it selects nothing the reader could not already see in Tasks, Schedules or Meals; the task allocator chooses who from a list the app itself computed and may not add, drop, retime or rename an item — our rule is that a model may choose who does a task and may never choose what the task is. Neither displays material the reader could not already reach.

Read against eSafety's guidance (2026-09-08). The regulator's gloss on Rules 4A(3) is broader than the plain reading above: a recommender feature is present if the service "can select and display material to end-users based on any information associated with their account", and that information "includes information the end-user has explicitly provided … such as their age, contact list or location" as well as inferred usage patterns. On that reading a home screen that shows a member the tasks assigned to them selects material by reference to account-associated information.

The position, stated fully now that it carries weight. Since 2026-09-08 this reading is no longer academic: with no logged-in feature left (§§5.2–5.4), the recommender question is the only route by which 63C(1)(a)(iv) could still be satisfied, so it is set out at length rather than waved past.

A recommender feature under 4A(2) has two elements — selection of material by reference to account-associated information, and display of the selected material. GroupApp's filtering satisfies the second and, on the guidance's broad reading, the letter of the first. The argument that it is nonetheless not a recommender feature has four parts:

  1. The filter is identical for every member, and it is the member's own data. A task assigned to you appears on your list; the same rule runs for everyone, produces a different answer only because the underlying facts differ, and is the ordinary meaning of "showing someone their own records". On the broadest reading of the guidance, every database application with a where user_id = me clause has a recommender feature — an email inbox, a banking app, a payroll portal. The mischief 4A addresses, and the Explanatory Statement's framing, is content curation: an algorithm choosing which of many available items will hold attention.
  2. Nothing is inferred, and nothing is ranked. There is no engagement signal anywhere in the app to infer from — no dwell time, no view counts, no click history, no preference model, and since 2026-09-08 no likes, reactions or read receipts either, which were the only engagement-shaped data the app ever held. Ordering is by date and by assignment, both facts somebody typed. No surface is ordered by predicted interest.
  3. There is no corpus to select from. A recommender picks items for you out of a pool you did not author. Every item on every GroupApp surface was created by a member of the reader's own group, and the reader can already see all of it — chat is chronological and complete, the photo wall shows every photo in the group, the task list has a "show everything" view. The filters narrow a set the member can always widen by hand; they never withhold and never promote.
  4. The one model-driven selection is bounded, cited, and proposes nothing new. Revised 2026-09-29 with the shared, twice-daily home brief: one paragraph, written for the whole group twice a day, replacing the earlier design's per-reader brief and its suggestion chips, both of which are gone from the app entirely. It is built from a fact sheet the server assembles deterministically from the group's own tasks, events, meal plan and a small, closed set of household-level recall — never chat, a private plan, an intention or a baby cue — and every sentence the model writes must cite one or more facts on that sheet by id. A deterministic checker refuses a sentence whose citation is not on the sheet, whose numbers, times, days or names are not drawn from a cited fact, or that claims completeness the sheet does not support; the reader's own device separately hides (never overrides) a sentence once its cited facts are done, changed or gone. Nothing the model writes proposes anything beyond the household's own records — the brief narrates the group's own data back to it, cited, and invents nothing. The one action button Home still shows under the brief ("Add an event", "Add a task") is not model-written: it comes from a fixed list, chosen by how long the member has been in the group and which features they have not tried yet, and it opens an ordinary screen rather than selecting any material. That citation requirement is enforced by code the model cannot see or influence, which is stronger than the earlier design's prompt-only traceability rule, but it is still conventional rather than structural in this assessment's sense (a future change could weaken the checker); it is pinned by agent-server/checks/brief.check.ts and the validator's own tests. Loosening it is a change to this assessment, not a code tweak.

Note, Tasks Option B (approved by the founder, 26 October 2026): Tasks' shared sections are ordered by date and by assignment as above, and its two creator prompts ("Nobody's taken…", "Still needed?") point the creator at their own records from those same facts, chosen by no model: not a suggested-task feed (§10 item 1).

Recorded as arguable rather than settled, and it is now the assessment's main exposure. Before 2026-09-08 the outcome did not turn on it, because the feedback feature satisfied the condition anyway. It does turn on it now. §12 carries this as the accepted residual risk in place of the one it replaces, and §10 keeps "a recommender appears" as the first review trigger.

Structural? No — conventional, and pinned by our own architecture rules plus the suggestion-chip test above. Adding a ranked feed is a normal-looking product decision that nothing in the database would refuse. §9 records this as the escalation to watch.

5.2 Endless-feed feature — not present

4A(4): a feed "that has no end-point", or one with an end-point "to which additional material is added" when the end-point is reached, at intervals, or in response to input.

The argument is that GroupApp's two scrolling surfaces are lists with a visible end, not feeds — and since 2026-09-08 the chat says so on screen. The 2026-09-07 draft called this "marginal, not relied on"; it is relied on now, so it is argued properly and the one thing that made it uncomfortable has been fixed rather than explained away.

The group chat. Scrolling to the top loads the previous page of that group's own history. That is a bounded set: it is every message the group has ever sent, it does not grow while you read it, and it terminates. What made the wording uncomfortable was that the terminus was invisible — a list that simply stops is indistinguishable, on screen, from one that has not finished loading, and "it is finite, trust us" is not an argument a user can check. So the chat now renders a "Start of conversation" marker at the head of the list once there is nothing older to fetch, and a test pins it there. The distinction from 4A(4) is then a fact the reader can see rather than a claim in a document: the feed the Rules describe is one where reaching the end produces more, and this one produces a full stop.

The honest residual: paging is triggered by scroll position rather than by a tap, so material is added "in response to the end-user's input" in a literal sense. Two things answer it. The set is closed and exhausts — 4A(4)(b) describes a feed to which material is added, and walking backwards through history that already exists is retrieval of the reader's own archive, not addition. And 4A(4)(a)'s "no end-point" is the paradigm the sub-paragraphs elaborate; a feed that visibly ends is not that paradigm. Recorded as the second-weakest point in §5 after the recommender question, and carried in §12.

The photo wall. Not paginated at all: the group's photos load as a whole and are grouped into albums, or into the month they were taken in, worked out on the phone in the group's timezone. There is no auto-load on scroll, and none was added — a bounded set rendered in sections, which reaches its oldest month and stops. Checked on 2026-09-08 rather than assumed. Infinite scroll must not be added here; §10 keeps it as a review trigger, and if the wall ever needs paging for performance it should page on an explicit control with the same visible terminus the chat now has.

5.3 Feedback feature — removed 2026-09-08; reactions reinstated 31 October 2026 (§16)

31 October 2026. The founder brought emoji reactions on group-chat messages back (HQ PIA-016). They are a feedback feature on the words of 4A(5)(a), present for every member, and this section's finding below no longer holds. Read receipts and photo likes stay removed. §16 is the current position.

4A(5)(a): information displayed to an end-user "about the extent to which other end-users have viewed or otherwise engaged with material posted by the end-user".

The 2026-09-07 draft found three of these and recommended keeping them. That finding was correct and we reversed the recommendation the next day. All three are gone, for every member — not for children, because eSafety's Step 7 gives an age-restricted experience no weight (§1.3), so a child-only version would have bought nothing at all.

Surface What it displayed Removed
Chat read receipts The Sent/Read tick on a sent bubble, and Read by 2 of 3 under the newest one. The tick and the caption deleted, along with the code that computed them; the cursor poll, the live subscription and the other members' read positions the app used to hold deleted; the settings switch removed.
Photo likes A heart on the grid tile when a photo had any like, and Liked by You and Sam in the viewer naming every liker. The heart action, the badge, the names and the code that recorded a like deleted. The Home rail's like-ranked band went with them (§5.1, point 2).
Message reactions An emoji chip row under a bubble, counted per reaction, and a picker in the long-press sheet. Removed 2026-09-08: the picker, the chip row, the code that recorded a reaction, the loaders and the live subscription deleted. Reinstated 31 October 2026 (§16): up to 3 emoji per member per message from a closed list of 46, chips under the bubble with counts, names only in the long-press sheet, on a new table (group_message_reactions_v2); never counted, ranked or notified anywhere else. Since 1 November 2026 (§16): one reaction per member per message, from five organising answers (Got it, Done, Can’t do it, Need a hand, Thanks), chips on the bubble with counts, names and times only in the long-press sheet.

THE REMOVAL IS ALSO AT THE SERVER, AND THAT IS THE PART THAT MAKES IT A PROPERTY OF THE SERVICE RATHER THAN OF THIS BUILD. 4A(5) asks what the service can display, and the app's public key ships inside the app itself — so with the grant in place, a copy of the app could still have asked my_group_chat_read_cursors who had read its messages and drawn the answer itself. The database change of 8 September 2026 revokes EXECUTE on that SECURITY DEFINER function from every role, drops the trigger that broadcast a poke on every cursor advance, and drops the realtime.messages policy that authorised listening for it. On this register's own structural vs conventional test, the read receipt is now structural: a missing grant survives a rewrite, a deleted screen element does not. The likes and reactions removals were structural too, from the same day: that day's database change revoked every client privilege on group_photo_likes and group_message_reactions.

Corrected 31 October 2026. This paragraph used to say the likes and reactions tables were "dormant but still writable by an active member through PostgREST", and §12 repeated it. That was wrong from the day it was written: the database change of 8 September 2026 revoked every client grant on both tables, and the grants audit of 18 September 2026 kept them ungranted. No client could read or write either table after 8 September 2026. Emptied on 31 October 2026 (PIA-016 F6); the reactions that came back are on a new table (§16).

What was kept, and why each is not a feedback feature:

Finding (8 September – 30 October 2026): the app has no feedback feature. Combined with §5.2 and §5.4, it had no logged-in feature, and 4A(3) was not satisfied. Superseded 31 October 2026 (§16): reactions are a feedback feature, so 4A(3) is satisfied.

What holds this, since none of it is enforced by a CHECK. A source scan named for this reason looks for the identifiers a reinstated feature would have to use, across the chat and photo code and the state it keeps, and it is itself tested against a deliberate breakage (a reinstated heart fails it). Beside it sit behavioural assertions on the sheet, the row, the tile and the viewer, and a database test asserting that my_group_chat_read_cursors answers permission denied for function my_group_chat_read_cursors — the message, not the bare 42501, because authenticated holds table grants underneath and a code-only assertion would pass with the grant back in place.

What users lost, stated plainly rather than left for them to notice. A sender can no longer tell whether anyone has read a message. A photo cannot be acknowledged without typing something. A message cannot be answered with a single tap. These were small, well-liked features and two of them were carefully designed — the read receipt's unattributed return shape is one of the better privacy decisions we have made. They were removed because keeping them cost the app its whole position at Step 5 and left everything resting on a purpose argument that, on the regulator's own rule, is presumed against a service that cannot evidence it.

5.4 Time-limited feature — not present

4A(6): a service has one if it "enables viewing of material only within a limited period after it has been posted."

Nothing in the app disappears. No stories, no view-once messages, no auto-expiring posts. A message, a photo, a task and a baby log are all readable until somebody deletes them or the account is erased. The retention sweeps that exist — assistant history at 30 days, sweep-moderation-log, sweep_baby_history_deletions — are the opposite of a viewing window: they are the app disposing of its own records, not a limit on how long a member may look at something they were shown.

Note, Tasks Option B (approved by the founder, 26 October 2026): a skipped task is closed by a person's tap and stays readable in History's "Skipped" list; the 14-day "Still needed?" asks the creator and never closes, hides or removes anything on a timer.

The one design that WOULD have engaged this, and how it was changed. Cross-group event groups were specified with a lifecycle that deleted a temporary group, and its chat and photos, some days after the event. That is 4A(6) almost verbatim — material viewable only for a limited period after posting — and it would have put the app back inside the condition through a feature nobody thought of as social at all.

Our decision, 2026-09-08: an event group is ARCHIVED READ-ONLY after the event plus seven days, and is deleted only by an explicit admin action or by the ordinary erasure rules. Never by a timer. The nightly sweep archives and does not delete; the cap on active event groups per founding group is unchanged. Archived means the material stays readable to the people who were there — which is what makes it not a viewing window.

BUILT THAT WAY, 2026-09-08. The decision is now a property of the schema rather than a note in a plan, and three things are worth naming because each is what a later change would have to undo:

Two things follow for the cross-group event feature, assessed separately in our cross-group events assessment:

5.5 Conclusion on limb (a)(iv)

Not satisfied.

Rules s 4A feature Present?
Recommender (4A(2)) No — argued at length in §5.1, and recorded as arguable rather than settled
Endless feed (4A(4)) No — a chat with a visible start, a wall in month sections (§5.2)
Feedback (4A(5)) No from 2026-09-08 — the three that existed were removed (§5.3). Yes from 31 October 2026 — emoji reactions on group-chat messages, 4A(5)(a) (§16)
Time-limited (4A(6)) No — nothing expires, and event groups archive rather than delete (§5.4)

4A(1) requires either a recommender feature or a logged-in feature. A logged-in feature is one of the last three (4A(3)), and the app has none of them, so the only live question is the recommender one — which is why §5.1 is now the longest part of this document and why §12 carries it as the principal residual risk rather than a footnote.

From 31 October 2026, satisfied (§16). Reactions are a feedback feature, which makes a logged-in feature (4A(3)), so 4A(1) is met on that ground alone, whatever the reading of §5.1.

Rules s 4A feature, from 31 October 2026 Present?
Feedback (4A(5)(a)) Yes — emoji reactions on group-chat messages, for every member (§16)
Logged-in feature (4A(3)) Yes, through the feedback feature
4A(1) Met, on the logged-in route; the recommender route (§15.3) is a second

6. The exclusions in Rules s 5 — none is claimed

For completeness, and because claiming one wrongly would be worse than claiming none:

Exclusion (sole or primary purpose) Why not claimed
(a) messaging, email, voice or video calling GroupApp is not primarily a messaging service. Chat is one surface among many, and the app's own architecture rules treat it as subsidiary to organising. Claiming this would be wrong on the facts and would sit oddly beside a store listing that says organiser.
(b) playing online games The games hub is a chores-and-points layer over the task system, not the purpose of the app.
(c) sharing information about products or services (reviews, technical support, advice) Public meal-plan star ratings (since 21 October 2026, no text or photos) are a small instance of this, and the app's only cross-group surface — but they are a small part of one module, not the primary purpose. Noted because it is the exclusion nobody thought to check; it does not apply.
(d) professional networking or development Not applicable.
(e) supporting education Not applicable.
(f) supporting health Deliberately not claimed, and this is a decision rather than an oversight. The baby tracker records infant feeds, sleeps, nappies, medicine doses, temperatures and growth. Arguing that GroupApp's primary purpose is supporting health would contradict our explicit and repeatedly enforced position that this is an organisational tool and not a health device — a standing rule about what the baby tracker may and may not say, and a position we have deleted our own code three times over to make true. It would also cut directly against the argument the app wants available under the Privacy Act's health-service question, where the case is that the tracker records rather than manages health. Two inconsistent stories in two forums is worse than one imperfect one in both.

63C(6)(a) (no material accessible in Australia) plainly does not apply. No service has been specified under 63C(1)(b) or 63C(6)(b) that reaches this app.

7. Overall position on the app as it ships today

Element Satisfied?
63C(1)(a)(i) sole or significant purpose is online social interaction Not reached — see below
63C(1)(a)(ii) end-users can link to or interact with some or all others Yes
63C(1)(a)(iii) end-users can post material Yes
63C(1)(a)(iv) Rules s 4A condition (recommender or logged-in feature) No — §5.5
Rules s 5 exclusion None available or claimed
From 31 October 2026: 63C(1)(a)(iv) Yes — a feedback feature (reactions) and, as §15.3 already treated it, a recommender (§16)
From 31 October 2026: 63C(1)(a)(i) Reached, and decisive — Step 7's presumption applies and the §7A stocktake doesn't exist (§16)

31 October 2026. The position below is the app as it shipped on 8 September 2026. From the release that ships reactions, the position is §16's.

Position (2026-09-08): GroupApp is not an age-restricted social media platform, because it has neither a recommender feature nor a logged-in feature. The condition in 63C(1)(a)(iv) fails, so the definition fails, and the purpose question in 63C(1)(a)(i) is never reached.

The four limbs of 63C(1)(a) are cumulative. Limbs (ii) and (iii) are conceded — members interact and members post, and this document has never pretended otherwise. Limb (iv) is where the app now sits outside the definition: after 2026-09-08 there is no endless feed, no feedback feature and no time-limited feature, so there is no "logged-in feature"; and the recommender question is argued in §5.1 and answered no.

Why the app was taken out here rather than at limb (i), which is the whole point of this revision. The purpose argument in §3 is good and it is honest, and it is also a losing position to rely on. eSafety's Step 7 says a significant purpose is decided by how all end-users actually use the service, not by how it describes itself; that a restricted experience for children counts for nothing; and that "if the service is unsure whether it is a significant purpose, the service should presume it is significant." GroupApp has a group chat as a first-class tab, a photo wall, and roughly ten users' worth of evidence about any of it. Under the regulator's own rule the app was therefore obliged to presume against itself on the only limb it was relying on. Limb (iv) is not like that: it is a question about what the code does, answerable by reading the code, and re-checkable by anybody. Three small features were the price of moving the argument from one that has to be believed to one that can be verified, and we paid it.

§3 is retained in full and is not now surplus. It is the fallback if any reading in §5 is wrong — most plausibly the recommender reading (§5.1), which is recorded as arguable. A document that deleted its purpose argument the moment it stopped being load-bearing would have nothing to say on the day somebody disagrees with §5.1.

What follows from the position, stated so nobody softens it later:

7A. The social-interaction stocktake — retained as evidence, no longer a gate

eSafety recommends a documented stocktake of every feature that enables online social interaction, answering for each: how many and what share of members use it; what share of time on the service it carries; how integral and how prominent it is; and whether members would keep using the service without it. Plus the effort spent maintaining those features relative to the rest, the terms of use governing behaviour, and a survey of members on why they use the app.

A feature was added on 2026-09-08 and does not change the list. Event groups add a cross-group chat and bring list. They are social interaction and belong in the count below; they add no s 4A feature — no ranking (the group is reached from My Groups, never suggested), no endless feed (the same chat, with the same visible "Start of conversation" terminus), no feedback feature (the chat is the ordinary one, which has had none since 2026-09-08), and no time-limited content (§5.4). What they DO change is §3 and §9, which is why the count below gains a line.

Its status changed on 2026-09-08 and the change is worth being precise about. It was the gate on child accounts, because the position then rested entirely on limb (a)(i) and the stocktake was the only thing that could have discharged the presumption against it. The position no longer rests there (§7), so the stocktake gates nothing. It is retained for two reasons that are not ceremonial:

  1. It is the evidence for §3, and §3 is the fallback if §5.1's recommender reading is ever rejected. Discovering on that day that nobody had begun collecting it would be discovering it at the worst possible time.
  2. It is the instrument that would detect the drift in §9 — teen-only groups, the app being used as a social space rather than an organiser. That risk is unchanged by anything in this revision, because it was never about the definition.

Constraints on how the evidence is collected, so the stocktake does not itself become a privacy problem: counts, never profiles — per-surface event counts and session-share figures aggregated server-side with no per-person series retained (our operations report is the instrument); the survey is the tester group answering in their own words; and it is re-run on every trigger in §10. The features to count, from Steps 4 and 5: chat messages sent, photos posted and viewed, invites sent and redeemed, message pushes delivered, RSVPs answered — against tasks created and completed, events created, meal plans adopted, baby logs written, event groups created, joined and left to archive (added 2026-09-08). (Reactions, read receipts shown and likes were on this list until 2026-09-08; there is nothing left to count.)

8. The child-safe variant: harm reduction under the Code, not a ban argument

The child-account design (assessed in our child-accounts assessment, and built on 2026-09-08) does not create an exemption. Part 4A has no parental-consent carve-out, and if the service were age-restricted, an under-16 account would be prohibited however carefully it was configured.

Corrected 2026-09-08. The first draft said the variant made the app's position "checkable rather than rhetorical" and called it the verifiable half of the ban argument. eSafety's guidance (§1.3) says the opposite in terms: age-based restriction of social features "is not to be given any meaningful weight" in the purpose test, and a service "may be an age-restricted social media platform even if it restricts some or all of these features and functions to end-users above or below a certain age." So the variant contributes nothing to whether GroupApp is age-restricted. What it does is reduce the harm to a child if the app is used by one, and satisfy the privacy Code's data-minimisation and best-interests duties for children who hold accounts. Every item below is planned, and is justified on those grounds alone:

Corrected again 2026-09-08. Nothing above changes — the variant is still a privacy-Code and harm-reduction measure and still contributes nothing to the ban question. What changes is what it is waiting on: §7A was the gate on this feature and is no longer (§7). The child-account work's gate is now our child-accounts assessment alone, which is the gate it always should have had.

Every one of those is built as a database refusal proven with a child account in the same group — a test that has run since 2026-09-08 — which is the only kind of proof that means anything here. A stranger is excluded by is_active_group_member no matter what the policy says, and our rule is that row-level security must be switched on before any policy is written. Hidden tabs are not enforcement and were not accepted as such: the Assistant tab is hidden for a child AND the server refuses the caller AND the policies refuse the rows the screen would write.

9. The risk this ban creates for us specifically

Our privacy posture note names it and it is worth restating because it is our own market thesis inverted: the ban creates a population of under-16s looking for a group chat with a photo wall and no restrictions. A teen-only "group" — six friends, one of them nominally an adult — would be exactly that, and a pattern of them would be direct evidence that a significant purpose of the service in practice is social interaction. The argument in §3 is the kind that erodes from use rather than from a code change.

Structural answers, all part of the child-account design and all planned:

The metric that would show the pattern, and the only one worth collecting: per group, the number of child accounts and the number of active guardians. A group with several child accounts and one guardian who never posts is the shape to look at. It is a count, never a profile; it is not per-member behavioural data, it is not shown to anyone outside the operator, and it exists to answer one question. Collecting more than that in the name of enforcing the ban would be the wrong trade and, if the app were age-restricted, 63F would require its destruction after use in any case.

The escalation path, if teen-only groups appear as a real pattern: a stronger age-assurance method at founding. Never per-member age checks. One check per group founding, ever. The reasoning, which belongs on the record before the pressure arrives:

10. What would change this answer

Re-run this assessment when any of the following becomes true. Each is a change somebody would make in good faith, which is why the list is specific:

  1. TRIPPED 31 October 2026: emoji reactions on group-chat messages returned (§16). The re-run is §16. Any further feedback feature, or reactions anywhere outside the message, trips it again. ANY FEEDBACK FEATURE RETURNS. First on the list because it is now the whole position, and because each candidate is a small, obviously-nice thing somebody would add in good faith: a heart on a photo, an emoji tap on a message, a read tick, a view count on an album, "3 people have seen this", a seen-by list on an event. The test is whether it displays to a member how others responded to something they posted. The source scan named for this is what makes the reflex fail loudly, and re-granting EXECUTE on my_group_chat_read_cursors would be the same event by another route.
  2. A recommender appears. Anything that selects what to show by reference to account- associated information — a "you might like" rail, a ranked chat summary, a photo memories surface, a suggested-task feed. Today's absence is conventional, not structural, and §5.1 is already the assessment's thinnest ice: an ordering by anything inferred, or the home brief citing a fact that is not actually on its own sheet, or gaining any mechanism that proposes material beyond the group's own records (a chip, a suggestion, anything the reader did not already have), would end the argument rather than weaken it.
  3. An endless feed appears. Auto-loading older content on scroll in a surface with no visible end, or removing the chat's "Start of conversation" marker, or paginating the photo wall.
  4. Disappearing content appears. Any view-once or auto-expiring post — including an event group whose archive becomes a deletion on a timer (§5.4). 3a. RSVPs become a characterisation. An acceptance rate, a reliability score, a streak, or any aggregate across events describing a member's responsiveness (§4).
  5. A cross-group surface for individuals appears. Cross-group RSVP invitations and event groups are exactly this and are assessed separately in our cross-group events assessment, which re-runs this test. Any directory, discovery, people search, or child-to-child link across a group boundary is a line not to cross.
  6. Sign-up opens. "Every member was vouched for by an existing member" is load- bearing in §3 and stops being true. (Still a future trigger, 22 October 2026: the staged code ships with the database gate closed; this fires when the founder opens it.)
  7. Child accounts ship. The population being assessed changes.
  8. Marketing or the store listing changes register — anything that sells the app as a place to share, connect or keep in touch rather than to organise. Purpose is assessed on how a service presents itself as well as how it is built.
  9. The Games Hub gains a cross-group or ranked-across-groups surface. Its leaderboards are within-group and deterministic today, and The Deal deliberately refuses to rank members at all, by the same standing rule: it counts what was done, it does not characterise the person, and it never ranks. Keep it that way.
  10. The §7A stocktake produces a result, in either direction, or usage changes enough that a previous result no longer describes the service. It no longer gates anything, but a result that undermined §3 would matter on the day §5.1 is challenged.
  11. eSafety publishes new guidance or a decision about a comparable service (a family organiser, a group-chat-plus-photos app).

11. Store policies — a separate constraint, noted once

Neither Apple nor Google requires a minimum account age for a general-audience app, but both treat an app "directed to children" differently (Apple's Kids Category rules, Google Play's Families policy). GroupApp should remain a general-audience family app with a mixed-audience declaration, not a kids app: it is compatible with under-16 members, much cheaper, and matches what the app actually is. Unverified against the current text of either policy — this is a note to check before child accounts ship, not a conclusion.

12. Residual risk, accepted

The two risks this section carried on 2026-09-07 are gone, and it is worth saying what replaced them rather than quietly swapping the list. It used to record that the whole position rested on one limb which was presumed against us, and that the app had a feedback feature and would keep it. Both were true, and both were fixed by removing the features rather than by re-arguing them (§7). What is left:

13. Review trigger

Any item in §10 — and §10's item 0, any feedback feature returning, is now the one most likely to be tripped by a change nobody thought of as legal. Additionally: on registration of the Children's Online Privacy Code, and before this document is given to a lawyer.

This assessment is a gate on nothing, and that is a change from the 2026-09-07 version. §7A used to gate child accounts; it does not (§7). What replaces the gate is the review trigger and the mechanical check named after it — an assessment is a weaker guard than a database constraint, which §12 says in those words, and the source scan is the strongest guard available for a property that lives in the app on the phone.

14. Sources

Primary, verified 2026-09-07:

Primary, not reachable:

Our own code and documents, verified against the code:

What the 2026-09-07 draft cited, and where it went (2026-09-08). Kept because the removal is the substance of this revision and a reader checking the old citations should find out why they no longer resolve, rather than assuming the document rotted:

15. Proposed service assessment — personal Home, usage-based arrangement and assistant widgets (29 September 2026)

What this section is. A re-run of this assessment for a proposed service, triggered by §10 item 1 ("a recommender appears"). The proposal is assessed for privacy in our Home, widgets and setup assessment; nothing in it is built. Sections 0–14 above assess the app as it runs today and remain our position for that app, unchanged. This section does not revise them; where a source they quote has changed, §15.1 says so here rather than rewriting them.

What this section stops doing. §5.1's second point — nothing is inferred, nothing is ranked, and there is no engagement signal anywhere in the app — is not true of the proposed service, and we do not rely on it for that service. Nor do we rely on the rest of §5.1 as settling the recommender question for it. Two claims we also do not make: that adding these features automatically makes GroupApp an age-restricted platform (it does not — the other limbs still have to be met, §15.6); and that other services with similar features show that ours is exempt (what other services do is not evidence of how the test applies to this one, and no regulator decision about any of them is relied on here).

15.1 The sources, re-read on 29 September 2026

The Act. Read in the current compilation on the Federal Register of Legislation (compilation No. 4, compilation date 12 September 2026). Section 63C is unchanged from the text quoted in §1.1. The Online Safety Amendment (Strengthening Enforcement for the Social Media Minimum Age) Act 2026 (No. 83, 2026), in force since 12 September 2026, changed four things that bear on this document:

The practical point is the phrase "is or may be": a provider that has concluded its service is not age-restricted can still be required to produce its reasoning and its evidence. That is one reason this register, and the stocktake described in §7A, need to be current and producible (§15.10).

The Rules. Read in the current compilation (compilation No. 1, compilation date 26 March 2026, in force). Two corrections to §1.2, neither of which changes an argument above:

eSafety's guidance. Retrieved on 29 September 2026; the page still shows "Last updated: 30/03/2026", and the passages this document relies on — Step 5(a)'s reading of the recommender feature, Step 5(b), and Step 7's "no meaningful weight" and "presume it is significant" — read as §1.3 describes them. The retrieved page says, under Step 7, that the introduction of new features may reflect a change in a service's purpose, and recommends that a service re-assess when it introduces a new feature. The guidance is the regulator's reading, not the law; the Act and the Rules are the test, and a court would decide purpose on the facts. The guidance is still the best available account of how eSafety says it will approach the question, and eSafety says it uses the guidance in its own assessments.

15.2 The proposed service, as far as it bears on the test

All of this is planned, in three stages:

  1. Navigation. Home becomes a tab; a row of tool shortcuts in a fixed order, which never reorders itself, and an "All tools" button. No data change.
  2. A personal Home. Each tool contributes a widget. Each member can hide, pin and order the widgets on their Home in each group, saved to our servers; a member's first arrangement can be seeded from what they said they wanted help with during setup. Arrange by use, off by default and switched on per phone and per group by the member, reorders the member's unpinned tool widgets by which of a handful of organising tools they used on that phone over the last 28 days. Its record never leaves the phone. Optional task and agenda widgets show the group's own tasks or calendar on Home, twenty rows at a time behind an explicit control, with a visible end.
  3. The assistant. Real conversation, bounded reads across the group's tasks, calendar and meals to answer one question, and up to three widgets shown with a reply, chosen by the assistant from a closed list and drawn by the phone from the group's own records.

What the proposal does not add: anything that displays to a member how others viewed, engaged with or subscribed to what they posted; any ordering of photos, messages, people or anybody's engagement; any discovery, suggestion of other users, or cross-group surface; any content that expires. Photos, the group chat and ceremonies are excluded from Arrange by use by design.

15.3 Step 5(a): a recommender feature — treated as present

Rules s 4A(2) has two elements: the service can select material by reference to any information that the service has associated with an end-user's account, and display it while the end-user uses the service. Display is not in doubt for any of the features below. On selection:

Feature The information it uses Our reading
Arrange by use which tools the member used on which days — their own usage pattern, which eSafety's reading names as account-associated information Likely within s 4A(2). The record is kept on the phone rather than on our servers, but the app keys it to the member's account and group and the app is part of the service; we do not argue that phone storage takes it outside "information that the service has associated with an end-user's account". There is an argument that reordering a set that is all displayed is not "selection"; on a phone screen, order decides what is seen first, and we do not rely on the argument
The member's own layout, and the first layout seeded from setup what the member told us — hide, pin, order, and which jobs they wanted help with Arguable. eSafety's reading includes information a user explicitly provided. Against that, the member is choosing what their own screen shows and the service is following an instruction, not recommending anything; if a display setting were a recommender feature, nearly every app would have one. We do not treat this as settling anything
The assistant's choice of widget the member's request, their group and their permissions Arguable. It selects which view to display by reference to account-associated information. Against that, it is retrieval in answer to an explicit request, closer to a search than to a feed
The optional task and agenda widgets assignment and date No change from §5.1, which already addresses filtering the group's own records by who they are assigned to

Re-reading §5.1's four points for the proposed service: the first (the same filter for every member) is weakened — with Arrange by use, each member's order depends on their own behaviour; the second (nothing inferred or ranked) is no longer true; the third (there is no corpus to select from — every item is the reader's own group's record, fully visible to them elsewhere) still holds, and it now carries the argument: what moves is a handful of the member's own organising tools, not items chosen from a pool of other people's content; the fourth (the model-driven selection is bounded, cited, and proposes nothing new) still holds for the brief, and the assistant's widget choice is bounded to a closed list of the group's own records. The third point is an argument about what s 4A is aimed at, not about its words, and the words are broad.

Conclusion on Step 5(a): for the proposed service we treat the recommender condition as met. It is likely met on the words for Arrange by use, and arguable for the rest; we do not build a position on the arguable half.

15.4 Step 5(b): logged-in features — none added

So Step 5(b) is unchanged. It no longer decides the outcome, because s 4A(1) is met by either feature and §15.3 treats the recommender feature as present.

15.5 Limbs (a)(ii) and (a)(iii): unchanged

Satisfied, as §4 says. Nothing proposed adds or removes a way to interact or to post.

15.6 Limb (a)(i): now reached, and not yet evidenced

For the app as it runs today this limb is never reached (§7). For the proposed service it is, and §3's argument — argued both ways, conceding that "significant" is a low bar — is the argument we have. The proposal adds evidence each way:

For the app:

Against the app:

Conclusion on limb (a)(i): genuinely arguable in the app's favour on design, not yet supported by evidence, and presumed against the app on the regulator's approach until it is.

15.7 Step 8: exclusions — none claimed

§6's reasons are unchanged. The assistant's new reads and widgets do not make the service's primary purpose messaging, games, product information, education or health, and the health exclusion stays unclaimed for the reasons §6 gives.

15.8 Position for the proposed service

Element The app as it runs today (§7) The proposed service
63C(1)(a)(i) significant purpose of online social interaction Not reached Reached. Arguable; not evidenced; presumed on the regulator's approach
63C(1)(a)(ii) interaction Yes Yes
63C(1)(a)(iii) posting Yes Yes
63C(1)(a)(iv) recommender or logged-in feature No Yes — a recommender feature (§15.3)
Rules s 5 exclusion None None

Position (29 September 2026): we cannot say that the proposed service is outside the definition. Whether it is an age-restricted social media platform turns on the purpose limb. Adding Arrange by use does not by itself make it one. But the features step, which today settles the question on facts anybody can check in the code, would no longer settle it, and the purpose step, where it would then rest, is one where the regulator tells a service without evidence to presume against itself.

15.9 The finding, for decision before the second stage is released

Under-16 child accounts exist today (§8, built 8 September 2026). If the proposed service were an age-restricted platform, s 63D would require reasonable steps to prevent under-16s having accounts — with no parental-consent exception anywhere in Part 4A, and a civil penalty now of 60,000 penalty units. That is a genuine legal incompatibility risk between the proposed service, released without evidence on purpose, and under-16 accounts. It is recorded as a finding that needs a decision, not as a residual risk we accept.

Three things about it should be read together:

The ways to resolve it, for the decision (the product decision to build these features stands; what is open is what has to be true when they are released):

  1. Evidence the purpose before release. Carry out the §7A stocktake — counts, never profiles — the survey of members in their own words and the review of our terms, document them, and have this position reviewed by a lawyer on this question; the brief is currently parked. eSafety recommends documenting the evidence and considering giving the self-assessment to it. If the evidence supports the organising purpose, the position becomes "outside the definition at limb (i), on evidence": arguable and defensible, weaker than today's, and dependent on how the app continues to be used (§9's drift risk applies with more force).
  2. Change under-16 access. If the evidence is not in hand at release, or points the other way, keeping the proposed features means under-16 accounts would have to end, with reasonable steps to prevent them and the limits in ss 63DA, 63DB and 63F on how age is assured and what is kept. Accounts for 16- and 17-year-olds are not affected by s 63D.

Until the decision is made, §§0–14 continue to describe the app as it runs, and child accounts continue under them.

Status, 29 September 2026. The decision is to release Arrange by use with the second stage and to settle the purpose evidence and the question of under-16 access afterwards. This finding therefore stays open: it is not resolved by that decision and it is not a risk we accept. From the day the second stage is released, §§0–14 no longer describe the whole app, and this section is the position that applies to it until the evidence in option 1, or the change in option 2, is in place.

Status, 31 October 2026: accepted by the founder. Bringing emoji reactions back (§16) put a feedback feature in front of every member, and the founder chose to keep under-16 accounts knowing the position now rests on purpose alone: "I believe the intention of the social media restriction is for things like instagram posts, not for small private group chats which have a guardian presence required. We are too small a fish to fry and the commission would contact us before fining us. Overall I believe they will view GroupApp as a safe alternative to others and support us." (HQ decision log, 31 October 2026.) Option 1, the evidence, remains the route that could turn a presumed significant purpose into a position on evidence; it is not a condition of release.

15.10 Obligations and commitments that follow

15.11 What this section does not change, and the uncertainty in it

15.12 Sources for this section

15.13 Re-run against the built second stage (29 September 2026)

§15.10 committed us to re-run this section against the built service before the second stage is released. This is that re-run. The second stage is the personal Home — widgets, each member's own arrangement of them, needs-based setup — and Arrange by use. The third stage, the assistant's widgets and wider reads, is not built, and this section says nothing new about it.

What was built, as it bears on the test.

The test, re-run.

Position for the app once the second stage is released. The table in §15.8 applies to it unchanged: we cannot say that the service is outside the definition, and whether it is an age-restricted social media platform turns on the purpose limb, which is not yet evidenced.

The §15.9 finding stays open. Under-16 child accounts continue, and a child account may switch Arrange by use on for itself on the same terms as an adult. The decision recorded in §15.9's status — to release Arrange by use with the second stage and to settle the purpose evidence and the question of under-16 access afterwards — is the decision this stage is released under. It does not resolve the finding, and the finding is not a risk we accept. The two ways to resolve it are still the ones §15.9 sets out: evidence the purpose, or change under-16 access. Until one of them is in place, nothing further may be added that orders by use or selects what to display by account information without re-running this section first.

Next. This section is re-run against the third stage before that stage is released, and then §15 is folded into one current position for the whole app.

15.14 Re-run against the third stage, as designed and as built (29 September 2026)

§15.10 committed us to re-run this section before the third stage, and §15.13 said that nothing further that orders by use, or selects what to display by account information, may be added without re-running it first. This is that re-run, against the third stage's detailed design as it stood on 29 September 2026, before any of it was built. The third stage was then built the same day, and this subsection was checked against the build; the result is at its end ("Checked against the build"). Folding §15 into one current position is still to be done.

What the third stage adds, as it bears on the test.

What it does not add: nothing displays to anybody how others viewed or engaged with what they posted; nothing orders photos, messages, people or content; nothing suggests other users or reaches another group; no content expires; and nothing in a conversation is visible to anybody but the member who had it.

The test, re-run.

Position for the app once the third stage is released. The table in §15.8 applies unchanged: we cannot say that the service is outside the definition, and whether it is an age-restricted social media platform turns on the purpose limb, which is not yet evidenced.

The §15.9 finding stays open. This re-run does not resolve it, and it is not a risk we accept. The fourth way of noting a use is inside the finding's scope, as the rest of Arrange by use is. It cannot arise for an under-16 account, because an under-16 account has no assistant — but, as §15.9 says, what one cohort can see is not the question s 4A asks, so that is a fact about who is affected, not a way of resolving the finding. The two ways to resolve it are still the ones §15.9 sets out: evidence the purpose, or change under-16 access.

Checked against the build, 29 September 2026. The third stage as built matches the design above in every respect that bears on the test, and is narrower in two:

The conclusions above stand unchanged: the recommender condition is treated as met, no logged-in feature is added, the purpose limb is still unevidenced, no exclusion is claimed, and the §15.9 finding stays open — not resolved, and not a risk we accept.

15.15 Re-run for tool cards on a quiet Home, and a one-time tip (25 October 2026)

§15.13 said that nothing further that orders by use, or selects what to display by account information, may be added without re-running this section first. Tool cards on a quiet Home select what to display by account information, so this is that re-run, made before release against the design and the build together. The feature is described for privacy in the first-use record's assessment, §1D.

What it adds, as it bears on the test.

What it does not add: no card shows anybody's content, names a member or says how anybody engaged with anything; nothing is ranked by use or by anybody's behaviour; nothing is counted; nothing reaches another group; nothing expires; and nothing new is recorded on our servers. Arrange by use is unchanged: a card tap is not a way a use is noted, and there are still exactly four.

The test, re-run.

Children and young members. Child accounts, including under-16 child accounts, see the cards for Meals, Routines and Shopping, selected by the same rules. That is account information selecting what is displayed to an under-16 account, so it is inside the §15.9 finding's scope. As §15.9 says, what one cohort sees is not the question s 4A asks; that is a fact about who is affected, not a way of resolving the finding.

Position for the app once this is released. The table in §15.8 applies unchanged: we cannot say that the service is outside the definition, and whether it is an age-restricted social media platform turns on the purpose limb, which is not yet evidenced.

The §15.9 finding stays open — not resolved by this re-run, and not a risk we accept. The two ways to resolve it are still the ones §15.9 sets out: evidence the purpose, or change under-16 access.

16. Re-run for emoji reactions on group-chat messages (31 October 2026)

What changed. On 31 October 2026 the founder brought emoji reactions back: "Let each user put up to 3 emojis on each message." HQ PIA-016 is the privacy assessment; this section is the re-run §10 item 0 requires. It applies to the app from the release that ships reactions.

The feature, as it bears on the test. A member can put up to 3 emoji, from a fixed list of 46, on any message in their group chat, their own included. They show as chips under the bubble, each with a count from 2; holding the message shows who added which. A wall and a profile neither see nor add them. Nothing about a reaction is counted, totalled, ranked, recommended or notified anywhere else: not Home, the wall, the daily brief, widgets, Photos, an export summary or analytics. No push, badge, in-app notice or unread count follows a reaction, and there is no setting to turn one on. In an encrypted or Device-only group the emoji is encrypted on the phone.

Amended 1 November 2026 (HQ PIA-016 addendum, the organising reaction set). The 46 emoji and the cap of 3 are gone: a member now gives one reaction per member per message, from five organising answers: 👍 Got it (with an optional when: in 15 min, later today or tomorrow), ✅ Done, ❌ Can’t do it, 🙋 Need a hand and ❤️ Thanks. These are answers to a request, not approval, which is the purpose case in point 1 below. The test's result is unchanged: 4A(5)(a) is still met. This change adds no notification; the addendum's pushes to the author, and the rewrite of point 4 they need, come with that later change. Applied by the next note, with the author push: point 4 now says that reactions are notified only to the message's author, only from the five organising answers, never counted or badged.

Amended 1 November 2026, later (HQ PIA-016 addendum A5–A18; founder amendment ~19:15: every answer notifies, Thanks included). A reaction now sends one notification to the message's author, and to nobody else: no guardian copy, never a wall or a profile, nothing on a take-off, a muted chat, a block either way or a message more than 7 days old, at most one per message every 10 minutes, and no badge or unread count. It shows the answer and a short quote only where a notification may show what was written (both people 16 or over, an unencrypted chat, previews on); otherwise "Sam responded to your message". Point 4 below and the 4A(5)(b) line are rewritten for it. The addendum's §4 is plain that this moves the app toward the line, not away from it: a push saying someone reacted to your post is the textbook "promotes engagement through notifications". What keeps the purpose case arguable is in point 4; it is a judgement, not evidence, and residual R7 records it (accepted by the founder).

The test, re-run.

The strongest truthful position.

  1. Purpose. The service is for organising a household or group. Chat and its reactions coordinate it, and a reaction is a one-tap reply inside a conversation ("✅ got it", "🛒"), not a public metric: it sits under the message it answers and nowhere else.
  2. Closed groups. Membership needs an invitation or an approval. There is no discovery, search, public content or cross-group surface for individuals.
  3. Guardian presence. Every under-16 account is in a group only alongside an active guardian of theirs, enforced by a database trigger. Children can't found a group or invite anyone.
  4. No engagement machinery. History visibly ends ("Start of conversation") and no feed adds material. Nothing is ranked or recommended by reactions; reactions are notified only to the message's author, only from the five organising answers, never counted or badged; and no count of them exists outside the message. The source scan named for this keeps reaction code inside the chat and forbids any count or ranking of reactions anywhere.
  5. Evidence, still owed. The §7A stocktake (counts only) and the parked lawyer review are what could turn "presumed significant" into "outside at limb (i), on evidence".

Under-16s react and see reactions on the same terms as adults. An age-gated version buys nothing in law (§5.3; Step 7), and the guardian is present in the same chat.

What it means for the app. The §15.9 finding is accepted by the founder, 31 October 2026 (§15.9's status, quoting them). The founder's view that GroupApp is "too small a fish to fry" and that "the commission would contact us before fining us" is recorded as their expectation, not as part of this argument: nothing in the Act makes size or a prior contact a defence. eSafety has had information-gathering powers since 12 September 2026 (§15.10), and s 63D now carries 60,000 penalty units (§15.9).

Position from the release that ships reactions. We can't say the service is outside the definition. Limbs (a)(ii), (a)(iii) and (a)(iv) are met; the position rests on limb (a)(i), purpose, argued on the five points above and not yet evidenced. Under-16 accounts continue by the founder's decision. §12 carries the risk; §10 item 0 is tripped.

What would make this worse, and must not be built (C2–C7 of HQ PIA-016): reactions anywhere but under a group-chat message; any count, total or "most reacted", on any surface; anything ordered, ranked or selected by reactions; any notification of a reaction to anyone but the message's author, or a badge, count or digest of them, or an opt-in for one; reactions on the wall; more than one per member per message, or an open vocabulary.