← All privacy impact assessments

PIA: intentions, beneficiaries and the motivation layer

Status: Built and live since 8 September 2026, and revised on 10 September 2026 to cover changes made that day, on 29 September 2026 to record a defect in the brief's cache and a planned change to the brief, on 30 September 2026 to record that a member's plan will be encrypted on their own phone (§3, "Sealed on your phone"), and on 18 October 2026 to record that that encryption is withdrawn before it ever reached a phone, and what now keeps a shared goal's reasons from the group instead (§3, "Ordinary text again"). Written: 8 September 2026 · Last revised: 18 October 2026

As built, 18 October 2026. The encryption §3 describes is withdrawn by the third stage of content encryption (the third-stage assessment): from the app update released after 17 October 2026 a member's plan is stored as ordinary text again, and no phone encrypts a new plan item. A plan item written in the window between the two updates stays encrypted until a phone that holds the key opens it, and is written back as ordinary text from then on. The promise the encryption was carrying — "your notes and your reasons stay private" — is now carried by the database's own rules instead, as §3's "Ordinary text again" sets out. Nothing here is legal advice. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 Dec 2026).

The 10 September 2026 amendment changes three things this assessment asserted, and the changes are marked inline in §4, §5 and §8 rather than appended, so there is one current document and not a document plus a correction.

1. A model now writes the beneficiary question. §4 said the question bank had no gate because no model was involved. That remains true of the bank; a second surface now asks the same question with a sentence written for one specific task. The model writes prose and nothing else — the app picks the task, the member taps the answer, and a line naming anybody is dropped by code before it renders.
2. One answer is now visible to the group. A beneficiary answered from the home screen lands on the shared task list, where the household sees it. Every other answer this feature collects stays visible only to the person who gave it. The card says so before the tap.
3. A goal may be shared with the group, and owns the tasks it generated. Sharing is the member's own act on their own row; a day's or a week's plan can still never be shared, and the database refuses it rather than the app declining to offer it.

The 29 September 2026 amendment records one defect and one planned change, both from our home brief assessment, and marks them inline in §3, §4 and §8.

1. A defect: the brief's cache is readable by the whole group. §3 said the reader's own intentions in their brief created no new disclosure path, because the brief is cached per reader. The cache is per reader, but every active member of the group can read every row of it, so another member could read a sentence written from somebody else's plan. That is not an accepted risk; the planned fix makes each cached brief readable only by the member it was written for, and it ships with the brief's redesign.
2. A planned change: the brief stops receiving plans and beneficiaries. The redesigned brief is one paragraph for the whole group, written from group-shared records only. App versions carrying it send no member's plan, intention or beneficiary to our servers for the brief: the reader's own plan is shown as a line composed on their own phone, and the home screen's "who does this help?" card uses the question bank's own wording rather than a model-written line. Older app versions keep today's behaviour until they are updated.

A second 29 September 2026 amendment — a shared plan now follows the plan. When a member has posted their plan to the group chat and later ticks one of those items off, the line for it in that same message is struck through, and un-struck if they un-tick it. No new message is sent and nothing announces the change. Four limits hold it, each enforced by the database rather than by the app: only the member who wrote the message can change it; only while they are a member of the group; only a message one of their own plan items was shared as; and only by sending the new words encrypted under the group key, exactly as a new message is sent, so an edit can never put readable text where encrypted text was. What the database cannot check — because it cannot read the encrypted words — is that only the strike marks changed; the member could in principle rewrite their own shared plan message. It is their own message about their own plan, so that is accepted (§8). Nothing about this reports anybody's response to anything: the strike records the member's own progress, never who read the plan (§6).

This assessment is unusual in one respect and it is worth naming at the top. Every other PIA in this register is about data a household already produces — a feed, a photograph, a message — and asks who can see it. This feature asks people to type something the app has never held before: why they are doing something, and who for. That is a statement about a relationship, and about a child in a large share of cases. The interesting risks here are not access-control risks. They are the risks of holding a motive at all, and of a screen that reads a household's own answers back to it in the wrong voice.

1. Purpose and scope

What it is for, in one sentence. People do the work when they can see who it is for, so every task can carry a beneficiary and a reason, each member gets a private plan for today and tomorrow, and thanks travels as a message from one person to another.

What it is deliberately not. It is not a scoring system. Nothing in this feature writes a game_ledger row, awards a point, counts a streak, or ranks anybody. That is a design constraint taken from the psychological literature this feature is built on — extrinsic rewards for caring work reduce the caring (the crowding-out finding) — and it is also what keeps the feature clear of the line we draw around feedback features (§6, and our assessment of the ban on feedback features for under-16 accounts, §5.3).

In scope: the beneficiary and reason on a task; the private intentions table; the question bank; the rewritten daily brief; thanks as an addressed message; claiming an unclaimed need; the assistant check-in; the child's own record page; the monthly invisible-work prompt.

Out of scope, covered elsewhere: the child-account model itself (our assessment of child accounts, which gates that model and consumes the record page built here); the planned group privacy levels and Device-only mode (planned — §4 states what this feature owes them); planned Tier 1 encryption of intention text (§3); the games hub, which is a separate optional layer and is untouched.

2. Data involved

What is deliberately not collected, which is the more useful list:

• No count of anything. Not thanks received, not intentions kept, not tasks done for a person, not a rate, not a streak, not a "most thanked". There is no column that could hold one and no aggregate anywhere in the feature.
• No record of a decline. "Not this time" on a carry-over and "Not this time" on an assistant check-in both write nothing — not a row, not a flag, not a timestamp. This is the rule The Deal already keeps for a declined handoff, for the same reason: a refusal in a durable history is a receipt somebody can be shown later.
• No record of who was asked. The assistant check-in's round-robin cursor is a per-group position, not a per-member log of invitations and answers.
• No inferred motive. The why is only ever a member's own words or their tap on a fixed question. Nothing in the app derives, guesses, or proposes a reason a person does something for their family. §4 makes this structural.
• No cross-member visibility of intentions. Only the member who wrote an intention can read it; a second member of the same group reads nothing, and that is proven by an automated test rather than asserted here.

Strictly necessary (exposure draft s 38(2)(b)), per item. None of this is necessary to provide GroupApp, and the honest answer is that it is optional and inert until a member uses it:

• A task with no beneficiary is an ordinary task; the columns are nullable, no screen requires them, and a household that ignores the feature produces none of this data.
• user_intentions has no rows until a member taps "add to today". There is no backfill, no seeding, and no migration that writes one.
• The question bank asks at most one question a day, only about an item the member already created, and every question is skippable with no record of the skip.
• The monthly invisible-work prompt is opt-in and its answers become the member's own tasks.

So the strictly-necessary claim is not "we need this to run the service". It is that nothing is collected until the person it belongs to chooses to create it, which is the form of necessity available to an optional feature. Where a child is the subject rather than the author — a task "for Ada" — the data collected about Ada is a name already in the group and a line about what she needs, which is the minimum the feature can work on.

3. Flows and locations

One route was added on 2026-09-10, when this screen was released to members. The composer's "Add to the group's list too" switch turns a free-text goal into a group_tasks row as well as an intention — so the words a member typed privately can become something the household sees. Assessed and accepted, because it is the member's own act on their own goal and nothing else changes: the switch is off every time the sheet opens, its own line says what it does before it is used, and with it off the write is exactly one owner-private row. It is not the §9 trigger below ("another member's intentions become readable"): no intention becomes readable by anybody, the member creates an ordinary task. The user_intentions row then points at that task, so there is one title rather than two that can drift.

Three flow facts that carry the weight:

1. The brief is already a per-user generation. The system that builds it caches a separate copy for each reader, so adding the reader's own intentions to it does not create a new disclosure path — nobody else's copy of the brief can contain them. Adding another member's intentions to any brief would, and nothing does. Corrected 29 September 2026: that is true of writing and not of reading. Every active member can read every cached copy, so the reader's intentions in their own copy were readable by the rest of the group. The planned fix makes each copy readable only by its reader, and the redesigned brief stops sending intentions at all (see the amendment at the top).
2. The question bank never calls a model. It is a fixed list of questions whose answer buttons are the group's own roster. This is what lets a child, and a group using the planned Device-only mode once it exists, have the whole motivation layer with no inference in it at all.
3. Nothing here reaches a log. The feature writes no log line naming a member, a beneficiary or an intention — our own rule is that anything written to a log outlives an account deletion meant to erase it, so a log must never name anyone. user_intentions.user_id and group_id are foreign keys that cascade on account and group deletion, so an erasure reaches every row.

A note on the beneficiary's shape, because building it turned up something worth recording. The beneficiary is two foreign-keyed id columns rather than one polymorphic uuid, precisely so an erasure reaches it: a single untyped id could carry no key, and a departed member's id would have sat in group_tasks for ever. The first version then made the natural mistake of also requiring the id ("kind member implies a user id"), which makes on delete set null produce a row that violates its own constraint — so Postgres refuses the deletion, and a constraint written to describe the data blocks the erasure it was meant to enable. The constraint now says which column a kind may use and not that the subject still exists; a named kind with no id is the erased state, and the app renders no face for it. Caught by an automated test rather than by review, and the test that caught it is kept as the assertion.

Sealed on your phone (30 September 2026). Until this date intention text and the why were plaintext at rest. From the app version released after it, a member's phone encrypts the words of their own plan before saving them:

• A plan item's words, and every reason — why, what might get in the way, when, and a pet's name as who it is for — are encrypted under the member's own key, which only their phones hold. Our servers are never given it, so nothing on our side can open a private plan.
• A goal the member shows to the group has its own line encrypted under the group's key instead, so the members it was shown to can read it; showing it and taking it back re-encrypt that line in the same step. Its reasons stay under the member's own key even while it is shown. The sharing sheet has always said "your notes and your reasons stay private"; before this change the database let the group read a shown goal's whole row, reasons included, and that sentence was true of the screen only. It is now true of an encrypted row too.
• What the app shows is unchanged; the phone opens each item as the plan loads. Items saved before this change are encrypted by the member's own phone the next time it loads their plan. A phone that has not been given the member's key yet saves in plaintext, as before, and a phone that cannot open an item shows it as encrypted and does not let it be edited.
• An older app version on the member's other phone does not know about this and may save plaintext over an encrypted item. That edit is kept, and the member's current phone encrypts it again when it next loads the plan.
• What this does not do. A line the member chooses to send — a shared plan posted into the group chat, a goal made into a task on the group's list — becomes that message or task, and is protected the way that message or task is. What reaches a model is unchanged (§4), except that the goal breakdown now receives the goal's line from the member's phone rather than reading it from our database.

Ordinary text again, and the reasons held by the schema instead (18 October 2026). The encryption above is withdrawn by the third stage of content encryption (the third-stage assessment), which stops encrypting every everyday record on a phone. From the app update released after 17 October 2026 a member's plan is stored as ordinary text in our Australian database. That takes the key out of the sentence the bullet above rests on, so the sentence needed something else to rest on, and this is it.

• A plan is read by its owner and nobody else, and the database says so — one permissive SELECT policy on user_intentions (A member reads only their own intentions, user_id = auth.uid()), with no membership test in it, so a member who leaves a group still reads what they wrote. Nothing else about a plan is protected by a key any more.
• A shared goal's four reasons are now withheld by the SCHEMA, not by a key. The change that made a goal shareable gave the table a second permissive SELECT policy for a goal its author had shared (A member reads a goal shared with their group), and because RLS is row-level that policy returned the whole row — why, obstacle, when_text and beneficiary_label with it. What made "your notes and your reasons stay private" true of the stored row was the encryption above, which kept those four under the member's own key even while the goal was shown. So the policy goes with the encryption. The household now reads a shared goal through public.shared_goals, a view with no reason column in it: a reader who names why is told the column does not exist, and the row underneath the view admits only its owner. The view carries the household test and the two-step sign-in lock in its own predicate, and holds SELECT and nothing else.
• Nothing a member sees changes. The sharing sheet's wording is unchanged because it is still true, and the sharing control still moves one column in one tap, in each direction.
• What this costs. A copy of our database now yields a member's plan in the clear, which §8 of the third-stage assessment records as accepted. The reasons behind a shared goal are the one thing in this feature that fewer people can read after the change than before it.

4. What reaches a model, and when

The gate is the one that already exists. This feature adds no new consent purpose and no new switch.

Two absolute rules, both of which are the reason this section is short:

• The model never writes state. It receives a digest and returns prose. No answer it produces sets a beneficiary, a why, an intention, an assignment or a status. That is what makes "a wrong guess about why somebody does something for their family" structurally impossible rather than a prompt instruction. The 10 September 2026 amendment keeps this exactly. The ask's reply has one field and it is a sentence; the breakdown's reply is a list of titles and each one needs a tap on a button to become a task, the same way any other task is created. There is no field in either schema for a model to set a beneficiary with.
• The model never proposes a motive. The why in a prompt is text the member typed. The prompt's own rules forbid inventing one, and an automated test checks the wording it is allowed to use, but the load-bearing property is the first rule, not the prompt.

The 10 September 2026 amendment: how "never proposes a motive" survives a model writing the question. A question that names somebody has proposed the answer, whatever the question mark at the end says — "Ada's swim bag, who does this help?" is a suggestion wearing an interrogative. Three mechanisms, in order of how much they are relied on:

Children and Device-only groups still see no model, and still lose nothing. The ask falls back to the bank's own words; the goal, its tasks and its progress line involve no model at any point; the breakdown answers with no steps and a reason, for both, which the sheet renders as "add your own". The destination was built first here too.

Children and Device-only groups see no model. Today the first half is a property of child accounts, which do not yet exist, and the second is a property of the planned group privacy levels, which do not yet exist either (there is no group privacy level yet). What this feature owes them, and builds now, is the deterministic half: the question bank, the fallback brief in the same voice, the deterministic needs list and a deterministic check-in card. When child accounts and group privacy levels land, routing a child or a locked group to those paths is a routing decision with the destination already built. This document is the record that the destination was built first; if child accounts ship with a home screen that calls the model brief, that is this rule being broken.

5. Risks and mitigations

The first two rows are the ones this feature exists to be careful about. They are harms to a person's motivation and to their relationships, not to their data, and the Code asks about emotional and developmental impact (s 38(2)(f)) in exactly those terms.

6. The features-step rule, re-run for this feature

The app's position under the under-16 rule is settled at the features step: it has no recommender feature and no logged-in feature (Rules s 4A), so its purpose is never argued. This is the first feature since we removed read receipts, likes and reactions that plausibly touches 4A(5)(a) — displaying to a member information about the extent to which other end-users have engaged with material posted by them — so the test is re-run rather than assumed.

What would make one. A thanks count on a task; "you've been thanked 4 times this week"; a "most helpful" list; a reaction on a thanks; a viewer list on a shared plan; a streak of kept intentions. Each is a natural product idea and each changes what the app is in law. That is a conversation we would have openly, and a revision of our assessment of the feedback-feature ban, not a change we would make quietly — and an automated test is set to fail the moment a thanks count, a streak, or anything like them appears in the chat code.

The endless-feed and ranking limbs (s 4A(4), and the recommender limb) are untouched. The dashboard's intentions section is the member's own list, bounded by the horizon and ordered by time; the needs list is the group's own unclaimed tasks, ordered by when they are due. Nothing is ordered by predicted interest or by anything inferred about the reader.

The 10 September 2026 amendment and the recommender limb, which is the one worth being careful about. The goal breakdown is the closest thing this feature has to a recommender, and the argument is the one already made for the brief's quick-add suggestions (our assessment of the feedback-feature ban §5.1): what is proposed is derived from one line the member wrote about themselves, in that moment, at their own request — nothing is inferred about their preferences, nothing is ranked, nothing is retained, and the same goal asked twice is not refined by anything the app learned in between. The model is given the goal text and no other household data at all: no roster, no tasks, no calendar, no history. The task selection for the beneficiary ask is likewise not a ranking — it is the first task in the order already on screen that the reader is part of and that has an empty field, chosen deterministically by construction. If either of those stops being true, the features step is re-run, not patched.

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

Children appear here in two roles and they carry different arguments.

As beneficiaries — the common case. A task says it is for Ada. Ada's name and face are already in the group; what is new is a line about what she needs, written by a parent. What the child gets: work that is more likely to be done, by a household that can see who it is for. What it costs: a durable record, in a family app, of a child as the object of other people's effort — including during a period the child has no view about. The safer design was a beneficiary that is a role ("the youngest") rather than a person. It was not chosen because a role does not do the thing the feature is for: contact with a specific person is what raises effort, and a household that has to translate "the youngest" back into Ada every time gets neither the effect nor a clean record.

As authors — the case that arrives with child accounts. A child can set an intention, answer the question bank, claim a need and send a thanks. All four are good for a child: a plan they made themselves, a reason in their own words, a choice to help rather than an assignment, and an act of gratitude addressed to a person. Three properties protect them, and they are the reason the deterministic half of every surface exists:

1. No model touches a child's words. The question bank has no inference in it, the fallback brief is deterministic, and the check-in card for a child account is deterministic. Under the privacy ladder no under-16 account talks to a model at all; this feature's job was to make sure that costs the child nothing, and it does not — they get the same questions and the same plan.
2. Nothing a child does is scored. No points, no streak, no comparison with a sibling. A child learning that care is what you do for people you love is the entire design goal; a child learning that care is what earns points is the failure mode the crowding-out finding predicts.
3. The record page is the child's own. Own acts, own beneficiaries, no ranking. A guardian can see it, because a guardian can see the group's tasks; what a guardian cannot get anywhere is a number to compare one child with another.

Where the child's interest and the parent's diverge. A parent would find a "who is pulling their weight" view useful, and several of the components here are two lines from producing one. The child's interest won: per-person counts do not exist, and The Deal's balance view — which compares load between adults, from the last deal, never all time — stays the only comparison surface in the app.

What the child is told (the s 33 posture). On the intentions screen, in plain words: your plan is yours, the others in your group cannot see it unless you share it, and thanks is a message you send. On the record page: this is what you did, and only you and the grown-ups in your group can see it. The child-account work owns the wording of the child-facing variant; this document owns the requirement.

8. Residual risk we accept

• A sentence can shame without using a banned word. The vocabulary test is a floor, not a proof. Accepted, with the prompt's own rules and the deterministic fallback as the mitigation.
• Intention text, the why, and the free-text goals are plaintext at rest until we ship the planned encryption. Accepted and disclosed; no copy anywhere may imply otherwise. 18 October 2026: the encryption shipped on 30 September 2026 and is withdrawn again from the app update released after 17 October 2026, so this bullet is the standing position. The one thing that did not go back is the reasons behind a shared goal: they are withheld from the household by public.shared_goals having no column for them (§3, "Ordinary text again"), rather than by a key or by the app not asking.
• A why can carry health information about a child, and nothing filters it. Accepted — it is the information the parent needs — with the field's copy asking what will be better rather than what is wrong.
• A beneficiary name reaches the model in the reader's own brief, in whatever region the assistant runs in today, until the planned move of that processing to Australia. Accepted, gated by the existing assistant consent, and to be stated in the transparency copy rather than left to be discovered. 29 September 2026: the redesigned brief sends no beneficiary and no plan, so this narrows to older app versions until they are updated; the reading defect in §3 is being fixed, not accepted.
• A silence can be read as a decline. Accepted; the alternative is recording declines, which is worse.
• The no-counting property is mostly test-pinned rather than structural. There is no column to hold a thanks count today, which is the strongest available form, but nothing in the database stops a future change from adding one. Accepted, with the automated check described in §6 as the loud failure.
• A member's plan is forgotten by their own device, not by anything running on our servers. A step run locally deletes rows whose horizon has passed and which nothing will show again, on load, from the member's own phone. This is a UX property before it is a privacy one — the feature is built on it being all right not to have got to something, and a list that grows all year is a ledger of unfinished intentions whether or not anybody else can read it. Accepted with its gap stated: a member who stops opening the app keeps their rows, because nothing runs on their behalf. A server-side sweep (the same shape as our existing sweep_moderation_log / chat_retention_sweep) closes it and is separate work; until it lands, the app claims only what happens on the member's own device.
• The 10 September 2026 amendment — a beneficiary answered from the home screen is visible to the group, and the disclosure is a sentence rather than a step. The card says where the answer goes, above the skip, every time; it does not make the member confirm. Accepted: a confirmation on a one-tap optional question is how a helpful prompt becomes a form, which is the failure mode this whole surface is designed around. The answer itself is a fact the household can already infer from the task.
• The 10 September 2026 amendment — the question's line is written by a model, and a line can lead without naming anybody. The name check is structural and the evaluative-word scan applies, but neither can catch "who does this help — think about who has swimming on Thursday?". Accepted, on the same footing as the vocabulary residual above, and with the same mitigation: the fallback is a fixed question, so a household that never talks to a model is never led at all.
• The 10 September 2026 amendment — a shared goal cannot be un-seen. Taking a goal back is real and immediate at the database, and it does nothing about what somebody already read. Accepted and disclosed in the sharing copy. There is deliberately no notification in either direction, so sharing is not an announcement and un-sharing is not one either.
• The second 29 September 2026 amendment — the author can rewrite their own shared plan message. The database confirms who is editing, which message, and that the new words are encrypted, but it cannot read them, so it cannot confirm that only the strike marks moved. The app only ever moves the strike marks. Accepted: the message is the member's own, about their own plan, in a group they belong to, and the edit does not move the message, re-notify anybody or mark it as changed.
• The child-facing routing does not exist yet. This feature builds the deterministic destinations; child accounts and the planned group privacy levels do the routing. Until both land, a child using an adult's account on a shared phone gets the adult experience — which is the app's standing position on shared devices, not a new risk.

8A. A household streak on a chore tally, and why it is outside this document's ban (2026-09-10)

Status: a decision we took with the conflict in front of us. This section exists because the feature it describes trips a rule this document is the source of — our rule that nothing in the motivation layer is counted — and the rule says plainly that tripping it is a decision to be made and written down, not a rename.

What was built. A repetitive task — a tally, the thing the home screen counts "+1"s against — may now carry an optional target: three a day, or five a week. Its tile shows progress toward that target, and a badge showing how many periods in a row the target has been met. Meeting it drops a handful of mascots under parachutes across the screen.

Why it is not a feedback feature under Rules s 4A(5)(a). That limb asks whether the service can display to an end-user information about the extent to which OTHER end-users have engaged with material posted by that end-user. Three properties, each structural rather than conventional:

Why the crowding-out argument in §5 does not reach it either, and where the honest doubt is. §5's finding is that attaching a reward to CARING WORK reduces the caring, and it is the reason nothing in this feature is scored. A repetitive tally is a different object: it is the household counting nappies, dishes and dog walks, and the target is a number a member typed in themselves because they wanted to aim at it. The app already prices this trade in a bounded, opt-in place — the Games hub has points, ranks and celebrations over exactly this work.

The doubt is real and is recorded rather than argued away: the crowding-out finding is about the psychology, not about the schema, and a household that starts feeling watched by a flame badge on its nappy tally has been harmed whether or not the number is per-person. Two things bound it. The badge appears only from two periods up, so a single met day says nothing. And a target is off by default on every tally that exists and every tally created from here — a member has to choose it, which is the same consent shape §5 relies on everywhere else.

Residual risk we accept (10 September 2026): that a household experiences the run of met periods as pressure rather than as acknowledgement, and that the way out — turning the target off — is discoverable only by editing the task. Accepted on the basis that the target is opt-in, that nothing is comparative, and that the app carries no notification about a broken run: a run that ends is simply a badge that is no longer drawn, and nothing anywhere tells anybody it ended.

What would put it back inside this document's ban, and what the allowance in the test that pins the no-feedback-features rule deliberately does NOT cover:

• splitting the run, or the target, per member;
• ranking tallies, or members, by either;
• attaching either to this feature's own objects — an intention, a claim, a thanks, a beneficiary;
• any notification, copy or surface that remarks on a run ENDING.

Each of those is a change of what the feature is, and re-opens both arguments above.

Extended to routines, 14 October 2026. A routine's household run is now celebrated at milestones, on by default rather than chosen. It keeps all three properties above and none of the four things listed, and adds limits of its own: nothing shows the run between milestones, and each member has an off switch. The assessment and the accepted risk are in the Routines assessment, under "A household's run".

9. Review trigger

• Anything in this feature gains a count, a total, a rate, a streak or a ranking — the crowding-out and features-step arguments both turn on their absence.
• A model is given the ability to write state — a beneficiary, a why, an intention, an assignment. §4's first absolute rule.
• Another member's intentions become readable by anyone but their author, for any reason OTHER than a goal its owner shared. That one exception was introduced on 10 September 2026 and it is scoped by a database constraint to kind = 'goal'; a change that lets a day or a week carry visibility = 'group' re-opens this assessment. From 18 October 2026 the exception is also scoped by COLUMN: a reason column appearing in public.shared_goals, or a second permissive SELECT policy appearing on user_intentions, re-opens it just as widely, because either one hands the household a shared goal's whole row again.
• The beneficiary ask's prompt gains the roster, a list of tasks, or an id — every structural claim in the amendment's table in §4 rests on the model being unable to choose, because it is never shown the material a choice would need.
• A goal's progress becomes a stored number, a percentage, a target or a comparison. It is derived at render today, which is what keeps it out of §6's features step.
• Child accounts ship: re-read §7 against what was actually built, and check the deterministic routing.
• The group privacy levels ship: check that Device-only mode routes the brief and the check-in to the deterministic paths.
• The planned encryption of intention text ships: §3 and §8's second bullet stop being true, and the copy may change. It shipped on 30 September 2026 and was withdrawn on 18 October 2026, so this trigger has fired twice and §3 carries both.
• A thanks becomes anything other than a chat message.
• The repetitive-task target or its run of met periods gains any of the four properties listed at the end of §8A — per-member, ranked, attached to this feature's objects, or remarked on when it ends.

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

s 38(3): conducted before the feature is made available — this document was written before any of the feature's code. s 39: listed on our published register, live since 9 September 2026.

11. Sources

Primary: Children's Online Privacy Code exposure draft ss 10, 13, 14–17, 33, 38, 39 — via docs/privacy_posture.md §4.2; not independently re-read for this document, which is recorded here rather than left to be assumed. Online Safety (Age-Restricted Social Media Platforms) Rules 2025 s 4A — quoted and verified in 2026-09-ban-self-assessment.md §14.

The psychology this feature is built on is summarised in the specification for this feature (implementation intentions; the fresh-start effect; beneficiary contact; gratitude expressed from one person to another; autonomy over assignment; and the crowding-out finding). The individual studies were not retrieved or verified for this document. They are cited here as the design's stated rationale, not as established fact, and no user-facing copy anywhere in this feature makes a claim about them.

Also drawn from our own internal rules and code: our rule that The Deal may count contributions but must never characterise them or rank people by them (the no-comparison rule this feature inherits, and the copy-scan pattern it reuses); our rule that the app never shows anyone how others engaged with what they posted (§6); our internal rules governing what data the home brief and its model input may include (§4); our rule that a stored item's payload must always match its declared shape (why why goes in notes_meta and never into a new notes marker); our rule that row-level security must be switched on before we write access policies for it; our rule that background code must refuse to save data for a group the member has since switched away from; our rule that switching between groups happens as a single database write; lib/settingsScope.ts; lib/consents.ts; our assessment of child accounts; our assessment of the feedback-feature ban §5.3.

Planned, not built at the time of writing: everything in §§1–8 that this document assesses; child accounts; group privacy levels and Device-only mode; Tier 1 encryption of intention text; the consent ledger's use for a new purpose — this feature adds none.