← All privacy impact assessments

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

Status: Current — assesses the app as it ships on 2026-09-08, before child accounts exist Written: 2026-09-07 · Revised: 2026-09-08 (WS21 — the features step) Issues: #330 (parked legal brief), #221 (this register), #282 §4, #282 WS21

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".

The owner 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. Nothing here is legal advice. This is the app's 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.

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: the child-account design in #282 §4 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 the posture document, up front. docs/privacy_posture.md §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 the privacy-programme spec 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 the posture doc 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. The owner retrieved it on 2026-09-08 (page last updated 30/03/2026) and it is saved verbatim at docs/sources/esafety-age-restricted-platform-assessment-2026-03-30.md. 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 WS21, 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 — the owner 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. The Children's Online Privacy Code exposure draft was also retrieved by the owner on 2026-09-08 and is at docs/sources/oaic-childrens-online-privacy-code-exposure-draft.pdf; its section numbers as cited across this register were verified against it — see docs/sources/README.md.

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 (AGENTS.md → The Deal Counts. It Does Not Characterise, And It Never Ranks). §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 (derived on the client, in the group's timezone — lib/photoAlbums.ts). 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 dashboard brief writes one sentence about a list the server already assembled and selects nothing the user could not see; the task allocator chooses who from a client-computed list and may not add, drop, retime or rename an item (AGENTS.md → A Model May Choose WHO. It May Not Choose WHAT.). Neither displays selected material.

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 and traceable. The dashboard brief writes one sentence about a list the server already assembled, and its optional quick-add chips must each trace to an item already in the household's own data — a visitor arriving, an appointment, a planned meal — with the prompt forbidding an invented need and forbidding any suggestion drawn from the counted baby facts (supabase/functions/generate-dashboard-insight/suggestions.ts, SUGGESTION_CONTENT_RULES). A chip proposes creating something; it does not select existing material to display, and it is not chosen by anything inferred about the reader. That traceability is a prompt rule, which is conventional rather than structural, so it is pinned by a test named for this reason (__tests__/suggestions.test.ts → "forbids a suggestion that does not trace to an item already in the household data"). Loosening it is a change to this assessment, not a prompt tweak.

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 the architecture rules in AGENTS.md 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 (app/group-chat.tsx, pinned by __tests__/app/group-chat-conversation-start.test.tsx). 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, derived on the client in the group's timezone (lib/photoAlbums.ts). 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 as part of this workstream on 2026-09-08 rather than assumed. Do not add infinite scroll 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

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 the recommendation was reversed by the owner 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. MessageMeta's tick and ReceiptCaption deleted; lib/chatReceipts.ts deleted; the cursor poll, the broadcast subscription and the store's groupChatReadCursors 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 togglePhotoLike 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. The picker, the chip row, toggleGroupMessageReaction, the loaders and the realtime subscription deleted.

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 anon key ships inside the app bundle — so with the grant in place, a client could still have asked my_group_chat_read_cursors who had read its messages and drawn the answer itself. Migration 20260908010039 revokes EXECUTE on that SECURITY DEFINER RPC 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 refactor, a deleted component does not. The likes and reactions removals are conventional — their tables are dormant but still writable by an active member through PostgREST — and the honest note is in §12.

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

Finding: the app has no feedback feature. Combined with §5.2 and §5.4, it has no logged-in feature, and 4A(3) is not satisfied.

What holds this, since none of it is enforced by a CHECK. components/Chat/__tests__/noFeedbackFeatures.test.ts is a source scan named for this reason — it looks for the identifiers a reinstated feature would have to use, across the chat and photo directories and their store slices, and it is mutation-tested (a reinstated heart fails it). Beside it sit behavioural assertions in the sheet, the row, the tile and the viewer, and a db test asserting the RPC 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 in this codebase. 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.

The one design that WOULD have engaged this, and how it was changed. Cross-group event groups (#331) 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.

Owner decision, 2026-09-08 (#331): 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 (WS7, migration 20260908035756_ws7_event_groups). 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 whoever builds it (WS6/WS7, assessed in cross-group-events.md):

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 — the three that existed were removed on 2026-09-08 (§5.3)
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.

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 reviews genuinely are this, and they are 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 the owner's explicit and repeatedly enforced position that this is an organisational tool and not a health device (AGENTS.md → Health Content — Baby Tracker; #218/#330), a position the code has been deleted 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

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 the owner 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 (#331, WS7) 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 (the ops report in #277 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 (WS7, 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 (#282 §4; assessed in child-accounts.md, and built — WS8, #354, 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). WS8's gate is now child-accounts.md 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 (__tests__/child_accounts_rls.test.ts, merged in #354 on 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 (AGENTS.md → Check RLS Is ENABLED Before Writing Policies). 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

The posture doc 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 in #282 §4 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. 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. components/Chat/__tests__/noFeedbackFeatures.test.ts 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 a suggestion chip that stops tracing to the household's own items, 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 (#331) are exactly this and are assessed separately in cross-group-events.md, 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 (#282 §2). "Every member was vouched for by an existing member" is load- bearing in §3 and stops being true.
  7. Child accounts ship (#282 §4). 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 (AGENTS.md → The Deal Counts. It Does Not Characterise, 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 under #330.

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 (components/Chat/__tests__/noFeedbackFeatures.test.ts) — a PIA is a weaker guard than a CHECK constraint, which §12 says in those words, and the source scan is the strongest guard available for a property that lives in the client.

14. Sources

Primary, verified 2026-09-07:

Primary, not reachable:

In repo, verified against the code:

What the 2026-09-07 draft cited, and where it went (2026-09-08, WS21). 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: