← All privacy impact assessments

PIA: Ceremonies — the family scrum, facilitated by the assistant

Amended 28 October 2026: a settings history. A group's settings page can show who changed a setting, from what to what, and when. It reads only the notices already posted to the group's chat. Those notices have no time limit. A change is gone from the history once its notice is deleted (only the member who made the change can delete it), the group is deleted, or that member erases their account. Nothing new is stored. Changes made before notices existed weren't recorded, and the history says so. A member who has left the group shows as "a former member". Personal preferences are never listed.

Status: Built — shipped 8 September 2026. A further change, sealing a thread's posts, the facilitator's sentences and a ceremony's outcomes and name, was built on 30 September 2026 and has not yet been released; see the note below §3. Written: 2026-09-08 · Last revised: 2026-10-28 Nothing here is legal advice. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 Dec 2026).

This design was written before the code, on 8 September 2026, and the feature shipped the same day. The sections below describe that design and were revised against the shipped code on 9 September 2026.

As built, 30 September 2026. A thread's posts, the facilitator's sentences, what a ceremony agreed and a renamed ceremony's name will be sealed on the phone under the group's key before they reach us, as §3 below describes. This has been built and merged but not released: it takes effect once our next database release ships and a member's app has updated to the version that writes and reads the sealed form. Until then, and for anything written before that point, these stay exactly as they are today, readable at rest as the rest of this document describes.

1. Purpose and scope

A group runs a small set of bounded rituals — a weekly Huddle, an optional Morning minute, a weekly Wrap, and Show and tell — and the app carries the mental load of the meeting: remembering it exists, holding the agenda, keeping time, taking the turns in order, writing down what was agreed, and carrying that forward to next week. The family keeps the part that is worth keeping, which is the attention paid while somebody speaks.

In one sentence: the app runs the meeting so the family can be in it.

In scope: the ceremony thread (a third kind of conversation, distinct from the group chat and from the private assistant transcript), the facilitator's turns, the structured outcomes, the two modes (in thread / in person), the retention sweep, the home indicator, and what reaches a model from any of it.

Out of scope, assessed elsewhere:

• Intentions, beneficiaries, thanks and claims — assessed in our assessment of intentions, beneficiaries and claims. Ceremonies capture outcomes that post through that feature's own paths; this assessment owns none of those tables.
• Child accounts, the guardian invariant and the child-safe variant — see our assessment of child accounts. This assessment assumes children take part today as profiles answering through a guardian's device, and says what changes when they hold accounts.
• Whether the app is an age-restricted social media platform — assessed in our self-assessment against that test. §5 below records what this feature does not build so that assessment's §5 stays true.
• The group chat, which a ceremony thread deliberately does not touch.

2. Data involved

What is deliberately NOT collected, and could have been:

• No attendance. Nothing records who was in the room, who opened the thread, or who did not. A skipped week leaves no row, and next week's ceremony cannot mention it.
• No per-person counts of anything — not turns taken, not words written, not outcomes claimed, not ceremonies attended. There is no streak.
• No transcript beyond the window. The messages are deleted seven days after the thread closes (§3, §5). Outcomes persist; the words that produced them do not.
• No audio and no speech. The phone shows its prompts and never reads them aloud — a decision made on 8 September 2026. There is no TTS on this surface and no microphone use; the optional short sound that marks a turn or the end of the timer is a bundled tone, off by default.
• No read marks, no reactions, no "seen by". §5, and our self-assessment against the age-restricted platform test §5.3.
• No evaluation. Nothing stores or displays a judgement about a member's contribution, and the facilitator is forbidden from writing one (§5, §6).

Strictly necessary (s 38(2)(b)), per item. The free text in ceremony_messages.body is the ritual itself — a ceremony where nobody may say anything is not a ceremony — and it is the one item that is collected because the feature is it, not because it is convenient. Everything else is either a schedule (opens_at / closes_at / mode), an identifier needed to attribute a turn to the person who took it, or an outcome the group asked to keep. body is also the only item with a retention window, precisely because it is the only one whose necessity ends when the meeting does. author_user_id is nullable and empty for facilitator rows, so an unattributable turn is stored as unattributed rather than as somebody.

3. Flows and locations

Built 30 September 2026, not yet released. Posts, the facilitator's sentences, what a ceremony agreed and a renamed ceremony's name will be encrypted under the group's key before they are stored, as the content-encryption assessment describes. Once released, our assistant server will be able to open them only inside the request of a member who asks the helper for a sentence, and will record each time it does. Anything written before a member's phone begins encrypting, or by an older version of the app, will stay readable until a member encrypts it from the Devices & keys screen. The seven-day deletion of posts, and the rule that only outcomes carry forward, are unchanged.

The two modes have genuinely different disclosure, and that is the reason the setting exists rather than a default being chosen for everyone.

• In thread: people write into the thread over the day it is open. When a member's session triggers the facilitator's prose turn, everyone's free text in that thread is sent to the model, fenced as untrusted data. That is the honest description and it is what the setting's copy says.
• In person: the phone sits on the table. The facilitator posts its deterministic script into the same thread, and whoever holds the phone taps the outcomes in. The conversation itself never touches a server — nobody types it, nothing records it, and there is no microphone involved. The model receives, at most, the app's own script and the tapped outcomes: closed shapes and short text somebody chose to keep.

That asymmetry is why in person is the default for three of the four ceremonies (Huddle, Wrap, Show and tell) and why it is the better default where children take part. Morning minute defaults to thread because it is asynchronous by nature — its whole point is that people are not in the same room — and it is the shortest and least sensitive of the four.

What reaches a model at each step of the privacy ladder (the group's own privacy level; where that setting does not yet exist the predicate is stubbed to "not Device-only", and the ladder answer below is what it will return once the setting exists):

The deterministic script is the same text in every case, so a Device-only group loses prose polish and loses nothing else: the agenda, the turns, the timer, the prompt cards and every captured outcome are identical. That is the property that lets this feature exist at every rung of the ladder rather than being switched off at the bottom of it.

Logs. The endpoint logs outcomes and counts, never bodies — our rule that identifiers kept in logs are data an erasure cannot reach. A thread id is a group-scoped identifier and is logged; a member's post is not.

Group boundary. Nothing crosses one. A ceremony thread belongs to exactly one group and its policies are is_active_group_member(group_id); there is no cross-group surface here and none is planned.

Erasure. ceremony_messages.author_user_id and ceremony_outcomes.actor_user_id are on delete set null against public.users, so a departed member's account deletion leaves the thread coherent and the words unattributed rather than deleting a meeting other people took part in. This is a deliberate difference from chat_messages.user_id, which cascades because null there means "the assistant said it" (our rule that erasure has to be tried before it can be claimed). Here null means "we no longer say who", which is what an erasure should produce. The messages themselves are gone within seven days of the thread closing in any case.

4. Legal basis and consents

No new consent purpose, and that is a decision rather than an omission. The prose turn is the assistant writing sentences about the group's own data, which is the purpose assistant in the ledger's closed list already covers. Adding a ceremonies purpose would be a purpose with no separate question anybody could be asked — the disclosure that matters is mode, and mode is a group setting with its own copy, not a consent.

• Who decides. The per-ceremony mode is a group setting, attributed and announced through the same mechanism other group settings use (built with the database change of 7 September 2026), and any active member may change it. It is deliberately not consent-class: switching a ceremony from in person to in thread does not by itself send anything anywhere — nothing is sent until somebody writes free text into a thread and a facilitator turn is triggered — and gating a family ritual's format behind an admin would put an authority question where a scheduling question belongs. What makes it safe to leave open is that it is announced: the change writes a setting_changed system row into the group chat naming who made it, so a member cannot find the format changed under them with nothing able to say by whom. That is the same call groups.timezone already carries.
• What they are told at the moment they change it. The setting's copy states the disclosure difference in the words of §3: in thread the facilitator receives everyone's free text; in person it receives only its own script and the tapped outcomes, and the conversation never touches a server.
• Withdrawal is the same switch, and a per-instance override exists ("we are apart this week, do it in thread") because a ritual that cannot bend to one week away gets abandoned rather than adapted.
• Expiry. The assistant consent is subject to the twelve-month currency sweep (sweep_expired_consents) like every other; a group whose assistant consent lapses gets the deterministic script, which is the Device-only behaviour and is a working ceremony.

Where a guardian answers for a child (s 13): today a child takes part as a profile, so the guardian is holding the phone and the post is the guardian's own act — there is no separate consent to record because there is no separate account. What the child is told is §7. When child accounts ship, the child posts through the same policy as any member and this section is re-run: the guardian's consent to the assistant covers the model call, and the child's own understanding of who reads the thread becomes the s 33 question rather than a hypothetical.

5. Risks and mitigations

6. Structural versus conventional

Structural — the database or the absence of a grant proves it:

• A ceremony thread is readable and writable only by active members of its group. RLS on all three tables, is_active_group_member(group_id), with a second member of the same group used in the tests, because a stranger proves nothing (our own rule).
• No client can INSERT a facilitator row, and no stranger can reach the RPC that does. The INSERT policy requires author_kind = 'member' and author_user_id = auth.uid(); post_facilitator_message is SECURITY DEFINER, revoke execute ... from public, anon then granted to authenticated, and it checks the caller's active membership of the thread's group itself. The db suite asserts the denial message, not the bare 42501, because authenticated holds table grants underneath. What is NOT structural: the content. The RPC takes the sentence as an argument and any active member holds EXECUTE, so a member of the group can call it by hand and post as the facilitator. See §5's forgery row and §8.
• Messages of a thread closed more than seven days ago do not exist. sweep_ceremony_threads, pg_cron, idempotent, outcomes untouched.
• A member cannot write into a closed thread. The INSERT policy requires status = 'open'.
• Nothing crosses a group boundary. There is no policy arm that reaches another group, and no security definer function that takes a group id from a client without checking membership.
• The owns_chat_session policies and the group_messages policies are untouched. This is a third kind of conversation with its own tables. The private assistant transcript stays private and the group chat stays out of the assistant's reach.
• Device-only makes no model call. A branch, not an instruction.
• Spend is bounded. consume_agent_tokens on the caller's own client (so auth.uid() resolves), zero-delta pre-flight, billed outside the try, max_tokens always set, one generation per ceremony per trigger.
• The mode setting is attributed and announced. updated_by is written by a BEFORE trigger and is not in any client UPDATE grant; the announcement trigger writes a setting_changed system row that no client can forge.

Conventional — held by copy, a prompt, a source scan, or everyone remembering:

• The facilitator does not evaluate and does not name the absent. A prompt rule and a vocabulary scan. The context restriction (only posters are in the roster handed to the prompt) is stronger than a rule but is still a property of one function.
• Only outcomes carry forward. A property of the prompt builder, asserted by a check.
• Turn order is round-robin. A pure function with a test; nothing in the database enforces it.
• No scrum vocabulary in user-facing copy. A copy scan.
• In person is the default for three of four ceremonies. A default, changeable by any member.
• The private assistant only drafts. Discipline plus the AGENT_DRAFT card pattern.
• The host badge is decorative. Nothing tracks it because nothing stores it — arguably structural by absence, but it would take one column to change that, so it is listed here.

A test that pins a conventional property is not proof and does fail loudly; every one named above is written for that purpose and is named after its reason rather than its mechanism.

7. Best interests of the child

Required: children are participants, subjects and — once child accounts ship — authors.

What it gives a child. A predictable, bounded moment where they speak and are listened to, in their own family, with the adults' phones face-down rather than in hand. The family-rituals literature reports exactly this as the mechanism behind the effects (cohesion, fewer chore arguments, children who feel heard) — a repeated, time-boxed occasion where everyone gets a turn. Show and tell is child-led by design. The rotating host badge is a real role a small child can hold — they deal the prompt card and say "go" — and it is decorative on purpose: a role that is tracked becomes a performance.

What it costs them. Two things, and neither is nothing. In thread mode a child's words are sent to a model. And a child is talked about in a family meeting — that is what family meetings are, and it is the cost of being in one. Both are bounded rather than removed: the mode default for the ceremonies children are in is in person, so the ordinary case sends nothing; and the words are deleted seven days after the thread closes, so being talked about does not accumulate into a record.

The safer design, and why it was not chosen. The safest ceremony is one with no free text at all — taps only, closed shapes, no model. It was considered and rejected: a retro where nobody may say what could go better is not a retro, and a family that cannot write a sentence to each other will not use it. What was taken from that design instead is the part that carries the harm — the permanence. The words are transient; the outcomes, which are the group's own agreed plans, persist. That is the trade, stated so it can be argued with.

Where the child's and the parent's interests diverge, whose won. The parent's, once, and narrowly: a parent wants the meeting to work, which means being able to say what is not working, including about a child. The child's interest in not having that written down for ever won the retention question outright — our first draft kept threads for the facilitator's benefit and was reversed on 8 September 2026, on the reasoning that a record the subject cannot see but the service uses is the shape both the Code and the Privacy Act dislike. The model does not need it, and a retained retro a model can re-read is the grievance archive moved into its hands.

What the child is told. The thread header says the facilitator reads this thread — in those words, on the surface, in both modes, so a child who can read can find out. The in-person setup screen says the conversation stays in the room. Nothing tells a child that the app cannot read what they write, because it can; the copy tests assert the overclaims stay out (no "private", no "only you", no "we cannot read").

8. Residual risk we accept

• "3 of 4 answered" is a count, in a small group. In a group of four, knowing that three have answered and knowing three people is knowing the fourth. The rule is that the app never names who has not, and the count is a coordination fact of the same kind as an RSVP tally — which our self-assessment against the age-restricted platform test §4 already accepts as not a feedback feature, because it answers a question the group needs answered ("are we ready to close this?") rather than reporting how anybody responded to what somebody posted. Accepted, and the boundary is the naming, not the number.
• A child is talked about by adults, and nothing structural prevents it. §5's last row. The mitigations are the seven-day window and the absence of app-generated evaluation. Accepted; there is no design in which family members cannot discuss a child in a family meeting.
• A thread can be screenshotted while it is open. The retention window bounds what the service keeps, not what a person keeps. Accepted, and no copy claims otherwise.
• Most of the facilitator's restraint is conventional. Not naming the absent, not evaluating, only outcomes carrying forward — these are prompt properties with checks behind them, not CHECK constraints. The strongest available guard is that the absent members are not in the context at all, which is a property of one function that a future edit could widen. Accepted, and named in §9 as the review trigger most likely to be tripped by a change nobody thought of as a privacy change.
• In thread mode sends the whole thread, including other people's words, on one member's trigger. A member who posts and leaves has their text sent when somebody else opens the thread later. That is inherent to a shared conversation being summarised at all; it is disclosed in the mode copy rather than mitigated. Accepted.
• The group privacy ladder was not yet built. Closed 9 September 2026, with the database change of 8 September 2026. isDeviceOnlyGroup now reads groups.privacy_level through the caller's client on every facilitator request and fails TOWARDS the deterministic script: a Device-only group, or a level that cannot be read, gets no model call. The less-protective stub this entry recorded is gone.
• A member can forge a facilitator line in their own group's thread. post_facilitator_message is callable by any active member with any text, because our assistant server posts with the member's own token and holds no credential of its own. The audience is the member's own household, who can already read anything that member writes in their own voice. Accepted; the upgrade path is a facilitator secret in the mint-voice-token shape (a bootstrap-managed secret the RPC verifies), which is an infrastructure change we have not made yet.
• This is the app's own reasoning, not advice. Accepted; the register exists so a review starts from a draft.

9. Review trigger

Re-read this document when any of these becomes true:

1. The facilitator's context grows. Anything added to what the prose call is given — task completion data, a previous thread, the full roster rather than the posters, another group's outcomes. This is the one most likely to arrive as a helpful-looking improvement.
2. The retention window changes, or the sweep is disabled. The window is stated in user-facing copy; the claim and the job move together or not at all.
3. A ceremony surface displays anything about how members engaged — a count of who read it, a reaction, a streak, an attendance record, "you have not answered in three weeks". §5's features-step row, and our self-assessment against the age-restricted platform test §10 item 0.
4. Ordering by anything other than time or the round-robin. Turn order by who has spoken least is the specific temptation, and it is a characterisation of members.
5. Child accounts ship. Children become authors in their own right and §4's guardian reasoning is replaced rather than extended.
6. The group privacy ladder lands, so the stubbed Device-only predicate becomes real.
7. The private assistant gains the ability to post into a thread rather than to draft a card.
8. A facilitator proposes who might claim an unclaimed item. That is a fourth automated decision and goes on the disclosure page beside the other three, at the same time.
9. Envelope-sealing ships and the thread is sealed at Tier 2, or somebody proposes device-sealing it — which would make the facilitator unable to read a thread it is designed to read, so the answer is Tier 2 and the reason belongs here.

10. Checklist against exposure draft s 38(2) (verified 2026-09-08)

s 38(3): this assessment was written before the code, as a standalone document. s 39: the register is published on our public site, since 9 September 2026.

11. Sources

Primary — law and regulator. As cited in 2026-09-ban-self-assessment.md §14, which holds the verified copies: the Online Safety Act 2021 s 63C, the Online Safety (Age-Restricted Social Media Platforms) Rules 2025 s 4A, and eSafety's self-assessment guidance (saved under docs/sources/). The Children's Online Privacy Code exposure draft ss 10, 13, 14(3)(b), 15–17, 33, 38, 39 — section numbers may move on registration.

Design and evidence. Bruce Feiler's agile-family work is the origin of the four-ritual shape and of the wrap's three questions; the family-rituals literature is the basis for the claim in §7 about cohesion and children feeling heard. Neither is cited here as a legal proposition and neither has been re-verified against a primary text for this document — they inform the design, not the compliance argument.

In-repo.

• Our own rules: Check RLS Is ENABLED Before Writing Policies (the assistant transcript stays private; a card can be a household object; this thread is a third kind), A Household Setting Has A Named Author (systemhood is the column), Engagement Stays Inside The Message, The History Has To Visibly END, The Deal Counts. It Does Not Characterise, Untrusted Text Gets A Fence, Spending Money Needs A Ceiling, Ship The Retention JOB Before The Retention CLAIM.
• docs/pia/2026-09-ban-self-assessment.md §§4, 5.1–5.3, 10, 12.
• supabase/migrations/20260907232948_ws18_settings_attribution_and_announcements.sql — the attributed-and-announced settings primitive this feature's mode setting uses.
• The migration, the RLS suite __tests__/ceremonies_rls.test.ts, the script module lib/ceremonies/, the prompt check agent-server/checks/ceremonies.check.ts, and the copy scans — each named in §6 beside the property it pins.