← All privacy impact assessments

PIA: cross-group events — RSVP invitations and event groups

Amended 30 October 2026: deleting a group. An owner can delete a group. Members are told at once, and the group is deleted seven days later unless the group's owner cancels; meanwhile anyone can export their own data or leave. Deleting removes everything the group holds for everyone in it, children included: messages, photos (sealed or not), lists, routines, baby records, the group's inbox and its attachments, and its keys. Our backups expire within 90 days and a deleted group is not restored from them. A star rating a member gave stays, with no group attached. Copies of the group's events in connected groups say the group no longer exists.

Status: Built. RSVP invitations and event groups both shipped 8 September 2026; the event-group photo wall shipped 9 September 2026. Written: 7 September 2026 · Last revised: 30 October 2026 (deleting a group); 14 October 2026 Nothing here is legal advice. Children's Code citations are to the exposure draft.

This is the first feature in GroupApp's history that would let two groups touch. That is the whole reason it needs an assessment before a schema: the absence of any cross-group surface for individuals is doing real work in the ban self-assessment, and it is the property this feature spends.

Amended 14 October 2026, before the code: an event group's history reaches everyone who joins it. From the app update released after 14 October 2026, members' phones send a group's earlier keys to every person's phone in it, so a member can read what was written before they joined (the key architecture assessment, §3.7). Event groups follow the same rules as every group. Their first keys are made after the change that gave keys a check value, so sharing is on from an event group's first key (made while its host is the only member), with no notice in a group that has nobody else to tell; each adult joining is told before they join (under-18s still cannot join an event group, §6). This means an adult from another family who joins an event group late can read its earlier chat and see its earlier photos, which can include other families' children. We accept that (§13): it is what lets a late joiner catch up on the arrangements, and the photos were posted to everyone in the event.

1. Purpose and scope

What it is for. A birthday party. One family is hosting, five others are coming, and today the app has nothing for it — the invitation goes out by text message and the RSVPs come back in six different threads. The feature is a calendar invitation that crosses a group boundary and comes back answered, plus (Step B) a temporary group for the coordination a bigger event needs, and (Step C) persistent connections and direct attendance for own groups.

Step A — RSVP invitations. A host issues a code for one of their events. An adult in another group redeems it, picks which of their groups' calendars it lands on, and answers. The event is mirrored into that group as an ordinary calendar row.

Step B — event groups. groups.kind = 'event': a temporary group with chat, a bring list, the one event, and members. Nothing else. It goes read-only on a date, is announced as going read-only on that date, and is kept as a record of the event until an admin of the host group deletes it. and is deleted. — the draft said deleted on a timer; see §1B.

Step C — connected groups and direct attendance. Added 24 September 2026. Bilateral connections between groups, targeted event invitations, and direct attendance for an adult's other groups. Assessed in detail in the connected groups assessment.

1B. Step B as built (2026-09-08)

We changed the lifecycle before this was built, because of the app's legal position. The draft (§7, below, as first written) said an event group is deleted thirty days after it goes read-only, chat and tasks included, and treated that as a privacy virtue. It is also, almost verbatim, the time-limited-content limb of the logged-in-feature definition in the Online Safety (Age-Restricted Social Media Platforms) Rules 2025 s 4A(6) — "enables viewing of material only within a limited period after it has been posted" — and this app's whole position under the under-16 ban is that it satisfies NO s 4A feature. A deletion timer on a chat would have put the app back inside the condition through a feature nobody thought of as social at all.

So: an event group archives seven days after its event, and is never deleted by anything but an explicit act. No delete_after column, no deletion sweep, and no copy that promises otherwise. The ban self-assessment §5.4 records the same decision from the other side.

This is the second time this register has changed the product rather than described it (the first was the feedback features, §5.3 there), and it is worth noticing that both times the change came from taking the statute's own words seriously against a design that read well.

Built later, and re-assessed (9 September 2026): the event-group photo wall (§8). Until the photo-encryption work shipped, group_photo_albums / group_photos were on the restrictive list precisely so it could not arrive by accident; an event group now admits a photograph only when it is sealed on the device (encrypted = true).

In scope: everything that crosses the boundary, in both directions; who may cross it; what each side learns about the other; the lifecycle and deletion of an event group; and a re-run of the ban self-assessment, because this feature changes the answer's inputs.

Out of scope: the sealing of photographs itself, which the photo wall assessment covers; the event-group photo wall is designed in §8 and was re-assessed there as built on 9 September 2026, with the photo-encryption work; the child-account design itself (see the child-accounts assessment); the universal invite link, which is a transport decision, not this feature.

1C. Revision, 25 September 2026: the group's answer and each member's attendance

Accepting an event from another group used to put it on every member's schedule. It now records two separate facts:

• The group's answer (accepted or declined, with headcounts and a note), which is what the host sees. This is unchanged.
• Each member's attendance — Going, Not going, or no answer — which stays inside the responding group. The adult who accepts chooses who is going (themselves by default; children can be included). Everyone else starts with no answer.

Who can change attendance. A member can change their own. A group admin can change anyone's. A guardian can change their own under-18 child's. All three go through one server action; the database refuses any other change to attendance on a copied event, so a broad edit to the event row cannot be used to change somebody else's answer.

Where it shows. An accepted event appears on the Schedule only for members marked as going. Members who said no, or have not answered, still see the event, their answer and everyone else's in the group's Other Groups Events tool, which also lists declined events (which have no schedule entry at all) and pending proposals. That tool is shown to adult members only, as every other cross-group surface is.

What this does not change. The host still learns only the responding adult's name, the headcounts and the note — never which members are going. Attendance is a coordination fact within one group, in the same way as an ordinary event's RSVP; nothing counts or ranks it.

The tool and the assistant use the same server actions. The assistant can list these events, redeem an event code, add an event to another of the member's groups, answer a proposal, and change attendance within the same permissions. It does not repeat an event code in its replies.

1A. Step A as built (2026-09-08)

Everything in §§3–6 and §10 that concerns Step A is now a description of the code, not a plan. Where the build departed from the draft, the departure and its reason:

What each side learns, as built, is exactly the §5 table, and a test we run against the database asserts the key list of both closed returns rather than trusting the prose.

2. The design rule that comes before the schema

A child's interaction graph never leaves their guardian's groups. Anything cross-group that touches a child is addressed to an adult in the child's group and answered by that adult. Adults may interact across groups directly.

This is how parties already work for children in the physical world: the invitation goes to the parent, the parent answers. Building it that way costs nothing in realism and keeps every under-18's experience provably group-only.

The boundary is 18, not 16. Under-16 is the ban's line and 18 is the Code's definition of a child; for a brand-new feature that creates a cross-group surface for the first time, the Code's line is the one to take. A seventeen-year-old RSVPs through a parent. That is more restrictive than the in-group variant, which stays at 16, and the asymmetry is deliberate rather than an oversight.

Three lines not to cross, whatever this grows into. Each of them, crossed, moves the service toward the definition in the ban assessment in a way a regulator weighs by actual use:

1. No directory or discovery of people or groups. Ever.
2. No cross-group messaging for children.
3. No child-to-child link of any kind.

3. Data involved

What is deliberately not collected, and is the more interesting list:

• No email lookup, no user search, no "is this person on the app". There is no RPC that could answer it. An enumeration oracle over personal information is precisely what a convenience feature here would become.
• No guest list crossing back. A responder never learns who else was invited or who else accepted.
• No roster ever crosses. Neither side sees the other group's member list.
• No child is ever enumerable across a boundary. A headcount of children is a number; a name only appears if an adult types one into a free-text note.
• Codes are never logged. Not in application logs, not in edge-function logs. A code in a log is a live credential sitting somewhere an account erasure cannot reach — our own rule that an identifier written to a log outlives any deletion we can perform on it.

4. Flows and locations

The mirror carries the host's start_local_time and timezone, so the existing dual-storage trigger derives the same instant and each group renders it in its own zone. That is a correctness decision, and it also means no new time-handling code exists to get wrong.

Two model-exposure decisions worth stating explicitly:

• The mirrored event reaches the responder group's assistant, because it is an ordinary row in that group's calendar and the assistant reads the calendar. That is the intended behaviour — a family should be able to ask "what's on Saturday" — but it means another group's event title, which may name another family's child, is in the context of a model call. A planned change routing group data to Australian inference is the answer; until then it follows whatever the assistant's region is. The transparency copy must not claim otherwise.
• Event-group chat text never reaches any model. Our assistant server re-reads groups.kind on every request carrying a group id — the voice-grant pattern — and refuses event groups outright; the Assistant and Tools tabs are hidden for the kind. In v1 a participating group's own assistant sees the mirrored event only; bring-list tasks assigned to that member are a v2 candidate; chat never.

5. What each side learns, and what it does not

The preview is the sharpest edge in the design, because it is the one call that returns information about strangers to someone with no relationship to them. Four things bound it:

• It returns title, time, place and the host's first name, and nothing else — a closed list, not a filtered row.
• It is rate-limited per account, in the shape request_join_group already uses (5 failed guesses per 15 minutes; a sixth is refused and not charged).
• It refuses an under-18 before reading anything — built, not only the redeem (§1A).
• The RPC returns {success, error} rather than raising, because a rate limiter that raises an error instead of returning a result writes no row and counts nothing — it would protect nothing. Which failures are charged is a decision, not a detail: a code that does not exist is charged; expired, revoked and exhausted are not, because the caller was holding a real code.
• Codes are hashed at rest, so the table is not a list of live invitations to anyone who reaches it.

A forwarded code is the accepted failure mode. A code passed on reaches someone the host did not choose. Bounds: max_groups caps redemptions, expires_at defaults to the event's end plus a day, the host can revoke the code and remove a response, and the preview reveals only what a paper invitation would. For event groups, joining keeps the existing pending → approve ceremony, because approval grants chat membership and that is a higher bar than seeing a date.

The host group's name reaches the responder only after their group answers. The preview, before any relationship exists, still shows the first name alone. Once a group has answered — accepted or declined — its adult members see the host group's name beside the event in Other Groups Events, the same way an event from a connected group is shown, and that group's assistant reads it when it lists those events. Children never see it: that list refuses an under-18 before reading anything. We decided this on 10 October 2026: a family with several invitations needs to tell "the Smiths" from "Jo", and a paper invitation is usually signed by the family. The app had been showing the name since 25 September, and this assessment said otherwise until 10 October. The host is told on the screen where they share the code. The residual is in §13.

6. Under-18s: what the rule looks like in the database

• respond_to_event_invitation refuses an under-18 caller. Not a hidden button — an RPC refusal, checked server-side, proven in our database tests with an under-18 account.
• An under-18 cannot request to join an event group.
• A child sees the party on their own group's calendar, as an ordinary event, once a guardian has accepted it. Nothing about the experience says "cross-group"; it is simply on the calendar.
• No child appears in an event group's member list, so an event group's chat is adults from several groups and its photo wall (§8, planned) holds photographs posted by adults.

7. Event groups: caps and lifecycle, stated on screen

The caps are a privacy design as much as an abuse control: a temporary group that quietly became permanent is a cross-group social space, which is the thing this app is not.

Stated in plain words on the create screen and the join screen, from one function (eventGroupLifecycleCopy), and the group's card in My Groups shows both dates. Somebody joining a temporary group is entitled to know before they type anything what it holds, when it stops taking writes, and what happens to it afterwards. The third sentence is the one that would have been wrong, and a test we run scans every string the feature can render for a promise of automatic deletion.

• create_event_group enforces the cap and returns {success: false, code: 'cap'} rather than raising, along with every other refusal (a child, a non-member, an event group trying to host one).
• What an event group structurally cannot have: one as restrictive policy per tool table, with check (is_standing_group(group_id)), on 29 tables — group_babies and every baby table, meal-plan instances and collections, pantry, game settings and the game ledger, duty handoffs, voice grants, photo albums and photos, and chat_sessions. Additive, one predicate, ANDed with the existing permissive policies, and proven by an adult member of an event group trying each insert and by the same insert succeeding in their own standing group. A hidden tab is not enforcement.
  • AND A RESTRICTIVE POLICY IS NOT ENOUGH WHERE A SECURITY DEFINER FUNCTION WRITES. Nothing in this schema has force row level security, so a policy is skipped inside a function owned by the table owner. For the baby domain that is not academic — log_baby_event, log_feed and log_past_feed take a group id straight off the request and the row is a child's health record — so BEFORE INSERT triggers close it there. Elsewhere the gap is stated rather than closed (§1B), which is the honest position and the one this register exists to make legible.
• Archival is enforced by a restrictive policy on writes, not by the client. A nightly sweep_event_groups ARCHIVES, is idempotent, and never deletes. Reads are untouched.
• No group-specific assistant. §4.

8. The photo wall in an event group — built 9 September 2026

Re-assessed 9 September 2026, as built. The three rules below were written when this was a deferred design; each is now either held by the database or explicitly not, and this preamble says which. The detail of the sealing itself is in the photo-wall assessment, revised the same day.

What the build added that the design did not say. Reporting had to change with it. A report used to be addressed to us; with the photograph sealed we cannot look at it, so a report now goes to that group's admins, and the reporter is still never named (the admin-facing function does not select reported_by). That is a real reduction in what we can do about a bad photograph in an event group, and it is assessed in the photo-wall assessment §8 rather than hidden here.

The original text follows, unchanged.

We decided event groups get a photo wall, and guests may copy a photo to their own group's wall — provided it holds up against deletion rights. It does, on three rules, and it ships only once photo encryption exists, never before, so that no event group ever holds an unencrypted photograph of another family's child.

1. A copy is a new object, re-encrypted on the copying device under that group's key, carrying source_photo_id and a provenance line — "from Maya's party, posted by Sam". The server never sees either plaintext.
2. The poster's delete offers "also remove the copies", on by default. The provenance link makes a cascade possible without the server reading anything. Account erasure removes copies of that person's uploads the same way. Copies survive the event group's own scheduled deletion, which is the point of copying, and the copy button says so.
3. A destruction request about a child's photograph is honoured by the poster or a group admin, not by us, because with the photo encrypted we cannot identify it. The written procedure for this must say so in plain words rather than promising an operator search that end-to-end encryption makes impossible. An honest limitation stated is better than a capability implied.

The residual, stated: a copy lands on a group wall where that group's own children may see it. That is the same exposure as any photograph their own parent posts, and it is the reason children are never members of the event group itself.

9. Risks and mitigations

10. Legal basis and consents

• The first answer writes a cross_group_events consent row to the consent ledger, as a user consent, from the accept screen: the notice is on the screen in plain words every time, and the first time (or after the twelve months lapse) sending the answer is preceded by a sheet with the same words and two equal buttons. The row is the record of that act, matching the wording shown on the consent screen.
• The consent is always an adult's, because an under-18 cannot redeem. There is no guardian-on-behalf-of-a-child consent in this feature, which is a consequence of the §2 rule rather than a separate decision.
• The notice is specific, not bundled (s 14(3)(b)): it names the host's first name, the event, and the three things the host will learn — your name, your headcounts, your note — and the two things easy to leave out: that everyone in the chosen group sees the event on the calendar, and that the group's assistant can read it like any other event. It claims nothing about encryption or anonymity; a test we run asserts the absence.
• Withdrawal is withdraw_rsvp, which removes the response and the mirrored event.
• Twelve-month expiry (ss 15–16) applies as it does to every purpose; in practice an event is over long before that, so the live case is a household that has stopped attending cross-group events being asked again.

11. The ban self-assessment, re-run for this feature

The ban self-assessment concluded the app is not an age-restricted social media platform, on limb 63C(1)(a)(i) alone. This feature is the one most capable of undermining that conclusion, so the test is re-run rather than assumed.

What preserves the argument, and must be preserved with it:

• No directory, no discovery, no search. A code someone gave you is the only way in. This is the single most important property in the feature and it should be treated as load-bearing.
• No cross-group chat outside an event group, and an event group is capped, goes read-only a week after the event, and holds nothing but a chat, a bring list and the one event — every tool refused by the database rather than hidden. It is not deleted on a timer, and that is a deliberate trade recorded in §1B: a disappearing group would be a 4A(6) time-limited feature, which costs the app more than a permanent archive of a party's bring list does.
• No under-18 crosses a boundary at all, so every child's experience remains provably group-only. This is a privacy-Code and harm-reduction property, not a ban argument: eSafety's guidance (ban self-assessment §1.3, 2026-09-08) gives age-based restriction of social features no weight in the purpose test, so what matters for the ban is what the feature does to the service as used by everyone — which is why the next two bullets are the load-bearing ones.
• No photo wall in event groups until photo encryption exists, and none at all in Step A.

What would break it: any people search; any "groups near you" or suggested-events surface; any persistent cross-group space; any child able to redeem, join or message across a boundary; any ranked or endless feed of events. Each of those is a normal-looking product idea and each one moves this feature from "a calendar invitation" to "a network".

12. Best interests of the child (exposure draft s 10)

What children get. Their family's social life is legible on their own calendar. A child sees "Maya's party, Saturday 2pm" the same way they see soccer training — which is the correct amount of involvement for a child in an arrangement their parent made.

What they are spared. They cannot be contacted by an adult from another family, they cannot be added to a group chat with children they have not met, they cannot be enumerated by anyone outside their own group, and their name reaches the host only if their own parent types it.

The design cost, and who bore it. A seventeen-year-old cannot RSVP to their own friend's party in the app, which is patronising and they will notice. The Code's line was taken over convenience for a brand-new cross-group surface, on the reasoning that the first version of a boundary-crossing feature should be the restrictive one — loosening later is a decision someone makes deliberately, and tightening later takes something away that people have started using. This is the item most likely to be revisited, and revisiting it is legitimate.

Where a child's interest and the host's diverge: the host wants to know who is coming and whether anyone has an allergy; the child's interest is in not having their name and health information typed into another family's app. The parent decides, in a free-text field, having been shown what the host will see. That is the right person to decide, and the notice at first redemption is what makes it an informed decision rather than a default.

13. Residual risk we accept

• This feature weakens the ban argument's strongest limb. §11. Accepted, with the §11 preservation list as the standing constraint and the assessment re-run on any change to it.
• A free-text note can carry a child's name and health information across a group boundary, and nothing filters it. Accepted — it is the information a host actually needs — with the notice at first redemption as the mitigation.
• A mirrored event title reaches the responder group's assistant. Accepted; addressed rather than removed by our planned Australian-inference rule, and it must be stated in the copy.
• A forwarded code reaches someone the host did not choose. Accepted; bounded by caps, expiry, revocation and the approve ceremony.
• Anyone whose group answers a code learns the host group's name, including someone the code was forwarded to. A group's name often carries a surname, so with the host's first name it can identify a family. Declining is enough, and declines are not capped the way acceptances are. Accepted, because the name is what makes an invitation recognisable; bounded by needing a code, its expiry and the host stopping the codes working, and the host is told when sharing it (§5).
• We cannot honour a destruction request about an encrypted copied photograph ourselves. Accepted and disclosed; the poster or a group admin does it, and our written procedure for it says so plainly.
• "Codes are never logged" is a test for the app's own code, and a convention for anything outside it (an edge function, a future public landing page). Accepted.
• A leaked event_invitations table is a list of live codes until they expire, because the hash is over a 30-bit space. Accepted and stated in the migration.
• Added 14 October 2026: someone who joins an event group late sees its history, including photos another family posted of their children. Accepted, as the amendment above explains; each joiner is told before they join.
• An archived event group is kept indefinitely, including its chat, unless an admin of the host group deletes it. Accepted, and it is the deliberate consequence of §1B: the alternative is a retention timer on member-posted content, which is the 4A(6) limb. Erasure of an individual account still removes that person's rows as it does everywhere else.
• Outside the baby domain, a restrictive tool-table policy is skipped by any SECURITY DEFINER function that writes that table. Accepted and stated (§1B): the RPC would have to be handed an event group's id by hand to write a row nothing renders, and closing it properly means force row level security across thirty tables, which is a wider change than the risk earns. The baby domain is closed by triggers rather than left in this bucket.

14. Review trigger

• Before RSVP invitations started — this document was the gate.
• Before event groups started, re-read §7 against what RSVP invitations actually built. Done, 2026-09-08 — §1B is the record, and is_standing_group is the one function event groups had to change.
• Before the event-group photo wall ships — §8 is re-assessed then, not now.
• Any change to the §2 rule, the §11 preservation list, or the age boundary in §6.
• If bring-list tasks or anything else from an event group becomes visible to a participating group's assistant (the v2 candidate in §4).
• Any change to whether a late joiner sees an event group's history.
• When the universal invite link replaces code-only transport — a public landing page is a new surface and must not log invite codes.

15. Sources

Primary: Online Safety Act 2021 Part 4A and the Rules — see 2026-09-ban-self-assessment.md §14, where they are quoted and the verification is recorded. Children's Code exposure draft ss 10, 14–17, 32, 38 — via docs/privacy_posture.md §4.2, not re-read for this document.

In repo: our own rules that a rate limiter which raises an error instead of returning a result records nothing, that an identifier written to a log is data an account erasure cannot reach, that row-level security must be switched on before a policy is written on top of it, and the dual-storage timezone rules the mirror relies on; the rate limiter added to request_join_group, whose shape the preview RPC copies.

Built (8 September 2026): Step A — §1A, §§3–6 and §10 as they concern RSVP invitations; the database migration that added event invitations, and __tests__/event_invitations_rls.test.ts. Built (8 September 2026): Step B — §1B and §7; the database migration that added event groups, __tests__/event_groups_rls.test.ts, lib/__tests__/eventGroups.test.ts, __tests__/app/groups-event-section.test.tsx, agent-server/checks/eventGroups.check.ts. Built (9 September 2026): §8 — the event-group photo wall, with the photo-encryption work.