PIA: Everyday records go back to ordinary text, and chat and photos keep their keys

Amended 1 November 2026 — Device-only retired (privacy-levels §3E). A Device-only group's everyday records were already ordinary text under this change, so its move to Standard changes how none of them are stored. What it sealed under the keys it used while Device-only stays sealed: our server is never given those keys, and nothing moves that content onto one it holds.

Status: Draft, written on 17 October 2026 before any of the code, because the change makes a group's everyday records less protected at rest than the previous design made them, and that is a decision to take with the reasoning in front of us rather than after. It assesses one change: from the app update released after 17 October 2026, the everyday records a group keeps — its tasks, its calendar, its shopping lists, its meal plans, the words in its baby tracker, its ceremonies, its games, its daily brief and each member's own plan — are stored as ordinary text in our Australian database, protected by the access rules on that database, by encryption in transit and by encryption of the disks and backups underneath it. Group chat, photos, captions, album names and comments, each member's own assistant conversation, forwarded email and the cards the assistant raises are not part of this change and stay encrypted exactly as they are today. Written: 17 October 2026 · Last revised: 17 October 2026 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 supersedes "Sealing the rest of a group's free text" (the second stage, written and built on 30 September 2026), which is kept in this register as the record of what was built then and why. Where the two disagree about what is encrypted, this one is the current design. The key design the second stage depended on is unchanged and is assessed separately: the split between the key our assistant server may be given and the key it is never given still exists, and chat and photos still use the key it is never given.

The claim to be careful with, stated before anything else. After this change, somebody who obtained a copy of our database would find a family's task titles, calendar, shopping lists, baby notes, ceremony posts and personal plans in the clear. Between 30 September 2026 and this change they would have found ciphertext for most of that. What protects those words from that moment on is not cryptography on a phone: it is who is allowed to run a query, enforced per group inside the database; the disks and backups being encrypted; and our own rule that nobody here reads a group's content. Two of those three are controls the database proves. The third is a promise. No copy anywhere in the app may say those records are encrypted on your phones, and the privacy policy, the promise register and the Privacy screen move in the same release as the code.

1. Purpose and scope

Why: so that a group can read its own records on any phone, on the first day, without a key ceremony — and so that the app stops showing a family the word "Encrypted" where a task's name should be.

The second stage sealed almost every word a group types. In use, three costs turned up that the design had treated as edge cases, and they are not edge cases in a two-phone household:

A phone that does not hold the group's key cannot read the group's records at all. A new phone, a reinstall, a member admitted while nobody else was online: the calendar, the tasks and the baby tracker show a placeholder until another member's phone admits it.
A group that loses every phone holding the key loses its own words, unless somebody wrote down a recovery phrase. For chat and photos that is a trade worth making. For the shopping list it is not.
The protection it bought was already partial. In any group that is not Device-only, a copy of the key that opens those words is held for our assistant server, so that the assistant, the daily brief and search can use them. The honest description of the second stage was never "we cannot read your records"; it was "they are ciphertext in our database, and the key that opens them sits with a different provider".

Set against that, the protection given up is real and §8 records it. The decision is that for everyday records the balance now favours a family that can always read its own records, with the words protected by access control rather than by a key on a phone; and that the records where the balance goes the other way — a group's private conversation and its photographs — keep their keys and get a better way to hold them, assessed separately.

In scope (the records that go back to ordinary text):

Tasks: a task's name, its notes, the "why" line, what it is blocked on, a pet named as who it is for, the frozen copy of its name in completion history, and custom category names.
Calendar: an event's name at every level, its notes and its place.
Shopping: a list's name and an item's words.
Meals: the name, title and description of a plan a group made for itself. The published catalogue was never a group's content and is unaffected.
Baby tracker: a log's note and its free-text details (a medicine's name, a food, what an immunisation was), a baby's profile notes, a book's title, a care note's subject and where the advice came from, the stored summary sentence, and the handover notes kept from before handovers were removed.
Ceremonies: members' posts, the outcomes a group agreed, and a renamed ceremony's own name.
Games: the cards a group wrote for The Deal, what "done" means on each, deal names, prize lists, and the words kept in game history.
The daily brief: the sentences of each stored edition.
A member's own plan: the plan's line, the reason for it, what might get in the way, when, and who it is for. A goal the member chose to show the group is read by the group as ordinary text, as it was read through the group's key before; the four reasons behind it are not, and §6 says what holds that now that no key does.

Out of scope, and covered elsewhere:

Group chat, photos, their captions, album names and comments. They stay encrypted under the key our servers are never given. The separate change that gives a group a Group Password to hold that key, and makes encryption something a group switches on rather than something it inherits, has its own assessment.
Each member's own assistant conversation, which stays encrypted under that member's own key.
Forwarded email in the group inbox, which stays encrypted to the group's own inbox key from the moment it arrives.
The cards the assistant and the inbox raise, whose words stay encrypted under the group's key and which are deleted 30 days after they were raised.
The key design itself — the root key per group version, the derived key our server may be given and the derived key it may not — which is unchanged and assessed separately.
Names, structured facts and public reviews, which were readable before and after, and the reasons they are, which the second stage set out and this change does not reopen.
Removing the now-unused encrypted columns from the database. They stay where they are until a later release; §3.5 says why.

2. Data involved

2.1 What goes back to ordinary text

Kind	Whose	Children's?	Sensitive?	Free text?
`group_tasks` name, notes, the "why" line, `blocked_reason`, a pet as `beneficiary_label`	the member who wrote it, often about another member or a child	often ("Ada's physio forms")	can be: health, school, money	yes
`task_completions.title` — the frozen copy in history	the same	often	as above	copy
`group_task_categories.label`	the group	rarely	rarely	yes
`group_schedule_events` name, `notes`, `location`	the member who wrote it	often (a clinic, a school, a party)	a place a child will be, at a time	yes
`shopping_lists` and `shopping_items` words	the group	sometimes	can reveal a medicine, a diet or an allergy	yes
`meal_plans` name, title and introduction for a plan a group made	the group	rarely	can reveal diet or allergy	yes
`baby_logs.notes` and the free-text details inside a log; `group_babies.notes`; `baby_shift_handoffs.note`; `baby_books.title`; `baby_care_guidance.subject` and `.source`	the household, about a baby	always	health information	yes
`baby_recent_summaries.summary` and `.cues`	written by a model from the notes above	always	as above	model-written
`ceremony_messages.body`, `ceremony_outcomes.text`, a ceremony's display name	members, including children	often a child is an author	family feelings, complaints	yes
`deal_cards` and the words kept in `game_ledger` and `deal_proposals`; a group's prize list	the group	sometimes (a child's chores)	no	yes
`group_brief_editions` sentences	written by a model from the records above	often	as their sources	model-written
`user_intentions` text, reason, obstacle, timing and who it is for	one member	sometimes	can be deeply personal	yes

Strict necessity (s 38(2)(b)). This change collects nothing new and discloses nothing to anyone new. Every field above already exists, is already stored, and is already readable by the other members of the group; what changes is the form it is stored in and therefore who else could read it. No new column, table, provider or model call is added by it.

Not collected, and could have been: nothing is added. The change removes a wrapped data key and a key version from each record rather than adding anything to it.

2.2 What does not change

Who can read a record inside the app is exactly who could read it before: the active members of that group, through the database's own per-group rules, and for a member's own plan only that member. Ordinary text does not widen a group's membership. One record is read by fewer people than before: a goal a member shows the group, whose reasons the second stage kept from the group with a key and this change keeps from them with the schema — §6 sets out how.
Names and structured facts — people, groups and babies by name, times, dates, amounts, doses, measurements, who does what, whether something is done — were readable before this change and are readable after it, for the reasons the second stage gave.
Chat, photos, the assistant conversation, forwarded email and the assistant's cards keep the arrangement they have.
What goes to a model is unchanged. A request already carried the words themselves; encryption at rest was never a statement about what a request discloses.

3. Flows and locations

Data	Device	Our database (Sydney)	Our assistant server (Sydney)	Model provider	Region
An everyday record, written	typed on the phone, saved as ordinary text	stored as ordinary text; disks and backups encrypted	not involved in a phone's write	—	Australia
An everyday record, read	read as ordinary text by any signed-in member's phone	per-group access rules decide who may select it	reads it with the asking member's own access, inside their request	—	Australia
An everyday record, written by the assistant	—	stored as ordinary text	writes it inside one member's request	the words of the request go to the model as before	model at the provider's global location
A record encrypted before this change	a phone holding the key opens it as it does today, and writes the words back as ordinary text	the record becomes ordinary text at that moment	can still open it with the key copy it holds, inside a request	as above	Australia
Chat, photos, captions, albums, comments	encrypted on the phone before they are sent	ciphertext	holds no key for them once a group's phones have moved them	never read by our servers	Australia
Logs	—	—	outcomes, not words	—	—

3.1 The pattern an everyday record now follows

Step	Where	What happens
A member writes	their phone	the words are saved as ordinary text in the record's own columns. No data key is made, nothing is wrapped, and the record is marked as not encrypted
Another member reads	their phone	the words are there. A phone with no group key reads them like any other phone — the case that used to show a placeholder
The assistant reads or writes	our assistant server	inside one member's request, through that member's own access, as before. For a record that is ordinary text there is no key to open and so no key-use record; §6 and §8 say what that costs
A record encrypted earlier is opened	the phone that holds the key	the phone writes the words back into the ordinary columns and clears the encryption marks in the same step, so the record satisfies the database's own shape rules. It is a background pass over records a member was already reading: nothing is fetched for its own sake, and a failure is retried the next time that screen loads
Nothing re-encrypts	—	the jobs that used to encrypt older everyday records are removed, with the screens that started them, so an everyday record cannot become ciphertext again. The two jobs for chat and photos stay
Our database's own functions	the database	hold no key, as before. They can now compose a notice from a record's own words again, which the second stage had to stop them doing; nothing in this change asks them to

3.2 What our servers can read, and what records it

Before this change, our assistant server could open an everyday record only by unwrapping the group's key, which it did inside one member's request, after writing a record of the attempt, with an hourly ceiling. After it, an everyday record needs no key, so none of those three controls applies to it: the server reads the words the same way it reads a date. What remains is the access rule on the table (it reads with the asking member's own access, so it can reach only what that member can reach), our own code keeping those reads inside a request, and our rule that nobody here reads a group's content. The key-use record still exists and still covers what is still encrypted: chat and photos where a copy of the key is held, forwarded email, the assistant's cards.

3.3 Records encrypted before the change

Eleven groups hold encrypted everyday records today. Nothing of theirs becomes unreadable:

Every reader keeps the step that opens an encrypted record, so an encrypted task, event, baby log or ceremony post reads exactly as it does now on a phone that holds the key.
As each one is opened, it is written back as ordinary text, so over ordinary use a group's encrypted everyday records disappear without anybody being asked to run anything.
A group with no phone holding the key keeps records it could not read before and still cannot. This change does not fix that, and it no longer offers a way to encrypt more. The remaining route for such a group is the same as today: a member's phone that still holds the key, or the key reaching a phone through the ordinary admission flow.
We do not touch anybody's records from our side. There is no bulk conversion, and no server-side pass over a group's rows: the words are written back by the phone that opened them, with that member's own access.

3.4 Device-only groups

Device-only still means: no assistant, no daily brief, no voice, no model call of any kind, and no copy of the group's key for our servers. It no longer means that a group's everyday words are unreadable to us at rest, because they are no longer encrypted. For a Device-only group this is the largest change in this document, and §8 records it as accepted. The copy that describes the level moves in the same release.

3.5 The encrypted columns stay for now

The columns the second stage added — the sealed copy of each field, the wrapped data key, the key version — stay in the database, unused for new records, until a later release removes them. Two reasons: a record encrypted before this change still needs them until a phone opens it, and an app version from before this change still writes them. They hold ciphertext, not words, and nothing reads them for a record that is ordinary text.

4. Legal basis and consents

No new consent purpose, and no new disclosure. Nothing is collected that was not collected, and nothing goes anywhere it did not go. The consent purposes the app relies on — the assistant, the baby summary, the inbox, voice, the improvement records — keep their meaning exactly.
This is an APP 11 question, not an APP 6 one. The Privacy Act requires us to take reasonable steps to protect the personal information we hold, in the circumstances. The reasoning for why the remaining steps are reasonable for these records in this service is §§5–6, and the places we think a reader might disagree are §8.
A member cannot opt out of it, and we say so. There is no switch that keeps a group's everyday records encrypted after this change, and Device-only is not one: it governs models and the key copy, not the storage of everyday words. The only member-side controls over these records remain the ones that already existed — do not write it, delete it, or leave the group — plus Device-only for everything to do with models. Our standing principle is to prefer a useful feature with a clear disclosure and a real choice; here the useful default is being chosen for every group without a choice, which is why it is written down in §8 as accepted rather than presented as a trade a member makes.
Members are told, once, in the product. The privacy policy moves a version in the same release, with the change named in the list every member is shown once, and the Privacy screen's promises change with it. A promise register row that said a group's other writing is encrypted on its phones is replaced, not softened. A member aged 13 to 17 has their own privacy policy, which moves its own version in the same release; §7 says what it now says about a ceremony post.
Children. A child account's own records are covered by the same change and the same disclosure; a guardian is the person told, through the policy notice, for a child who holds an account. §7 is the reasoning.

5. Risks and mitigations

Risk	Who is harmed	Mitigation	Structural or conventional?	Residual
Somebody obtains a copy of our database — a breach, a mistaken query, a backup — and reads a family's task titles, calendar, shopping lists, baby notes, ceremony posts and plans in the clear	every member; every child named in a record	per-group access rules inside the database rather than in application code; disks and backups encrypted, with the backup key held outside our cloud providers; no public role on any of these tables; our rule that nobody here reads a group's content	structural as to access and storage; conventional as to anybody with legitimate database access	the words themselves. Before this change the same copy yielded ciphertext for most of them. This is the risk the change accepts, and §8 states it in those words
A member of our own team reads a group's records in production because nothing cryptographic stops them	every member of that group	our rule that nobody reads group content in production, which is written down and applies to diagnosis as well as curiosity; metadata-only diagnosis; the register of permitted queries against member tables	conventional, with a written record	a person with production access can read everyday records. The key copy made this true for most records already, inside a request; it is now true without one
Our assistant server reads more than the request needed, and no key-use record marks it	the group	it reads with the asking member's own access, so it cannot reach another group; our own code keeps the reads inside the request; the reads that still open a key are still recorded	conventional for everyday records, structural as to another group's records	an everyday read leaves no key-use trace at all. The nightly comparison of key use covers what is still encrypted
A group with no phone holding its key is left with records it cannot read, and we have removed the way to encrypt more	that group	every reader keeps the step that opens an encrypted record; the key still reaches a new phone through the ordinary admission flow; the write-back makes the problem shrink rather than grow	conventional (the readers are code)	a group that lost every keyed phone keeps unreadable records; nothing in this change recovers them
The write-back leaves a record half-converted — words restored but still marked encrypted, or the reverse	the group	the database's own shape rules refuse a half-done record for the tables that can express it, and the write-back writes the words and clears every encryption mark in one statement; the records with no shape rule are written the same way	structural where the shape rule exists; conventional elsewhere	a record whose write-back failed stays encrypted and is retried; it is never left readable-but-marked
A record a member deleted is still in a backup made while it was ciphertext, and in one made after	the member	backups expire on their schedule, at most 90 days for our own nightly copy	structural as to expiry	up to 90 days, as before, except that the newer copies hold words rather than ciphertext
Copy somewhere in the app still tells a member their everyday records are encrypted on their phones	every member reading it	the promise register, the privacy policy and the per-surface privacy copy move in the same release; the scan that refuses overclaiming privacy copy runs over every one of those modules	conventional, test-pinned	a module nobody noticed. The release lists the surfaces it changed, and the scan fails a new module that is not in it
A later change quietly encrypts an everyday record again, and a phone without the key sees a placeholder	the group	the jobs that encrypted older everyday records are removed with their screens, and the write path no longer has a sealing step to reinstate	conventional (code and its tests)	a future change could add one back; this document is the reason not to

6. Structural versus conventional

The useful way to read this section is as a before-and-after, because the change moves one property from the first column to the second.

Structural, after this change

Only the active members of a group can read that group's everyday records, enforced inside the database per table rather than by application code: tasks, their completion history and the group's own category names (Active group members can manage group_tasks, Active group members can view task_completions, Active members manage their group's task categories), the calendar (Active group members can manage group_schedule_events), shopping (Active members read their group's shopping lists, Active members read their group's shopping items, with the rules that only a person — never the shared display — writes one), a group's own meal plans (Catalogue plans follow the group library, Groups write only their own custom plans), the baby tracker (Group members read and correct their babies' logs, Group members manage their babies), ceremonies (Active members read their group's ceremony thread, Active members read their group's ceremony outcomes), the games (Active members read their household's deck), and the daily brief (An active adult member reads their group's brief).
A member's own plan is readable only by that member (A member reads only their own intentions, the one permissive SELECT policy left on user_intentions, and the matching write rules), and that is now the only thing protecting a plan from the rest of the group.
A goal a member chose to show the group opens the goal and not the reasons behind it, by schema. user_intentions carried a second permissive SELECT policy for a shared goal (A member reads a goal shared with their group, added when a goal first became shareable in September 2026), and because RLS is row-level that policy returned the whole row — the member's why, obstacle, when_text and beneficiary_label with it. The second stage made the sharing sheet's "your notes and your reasons stay private" true anyway, by sealing those four under the member's own key and leaving them there while the goal was shared. This change removes that seal, so it also removes the policy. The group now reads a shared goal through public.shared_goals, a view that does not have the four reason columns, their four sealed counterparts or the key that opens them; a reader who names one is told the column does not exist. The view runs with its own rights rather than the reader's, because the table beneath it now admits nobody but the member whose plan it is — so the view's own where clause carries the household test and the two-step sign-in lock, and it is granted the right to read and nothing else, because a view that could be written through would reach the table with those rules skipped. This is the one property the change moves towards structural: before the second stage the group could read a shared goal's reasons, and from this change it cannot, whatever the app asks for.
An archived group's records cannot be written (An archived group is read-only), and a shared display cannot write where a person is required.
Everything is encrypted in transit, and at rest on encrypted disks with encrypted backups in Australia; our own nightly copy is encrypted to a key held outside our cloud providers.
Chat, photos, captions, album names and comments remain under the key our servers are never given, and our assistant server cannot be given one: the wrap it may hold is derived for the other purpose, and the module that opens records refuses a chat or photo key outright.
A member's own assistant conversation remains under that member's own key, and our assistant server is structurally unable to read the table at all.
Forwarded email remains encrypted to the group's own inbox key, which our mail server can lock but not unlock.
The record of each use of the key our server may hold is append-only by privilege.

Conventional, and pinned by automated checks where we can

"We don't read your group's content." For everyday records this is now the main thing standing between us and the words, together with the access rules above. It is a commitment in the privacy policy and a rule we keep, not a property the database proves.
Our assistant server reads a group's records only inside a request one of its members made. For what is still encrypted this is pinned by the single reader and the checks around it; for everyday records it is ordinary code with ordinary tests.
No log line carries a group's words; the checks that scan our server's log paths still run.
The write-back pass, the removal of the encrypting jobs, and the honesty of the copy.

What moved, said plainly: before this change, "somebody with a copy of our database cannot read a family's everyday words" was a property cryptography held. After it, the equivalent sentence is "somebody who can run a query as a member of that group can read them, and nobody else should be able to run one" — which access control holds, and which a key does not. Both are legitimate designs. Confusing the two is the mistake this register exists to catch, so: after this change the app's at-rest protection for everyday records is access control, not encryption on a phone.

7. Best interests of the child

Children are plainly involved: the baby tracker is a record about a child, a child's own posts appear in a ceremony, a child's chores appear in the games, and a child who holds an account writes tasks and reads the calendar.

What it gives a child. The adults caring for them can read the records about them, on the phone they have with them, on the first day, without a key ceremony. The failure this change removes is not theoretical: a phone that does not hold the group's key shows a placeholder where a medicine's name should be, and the people most likely to be holding that phone are a new carer, a second parent, or a grandparent who has just been added to the group. A child also benefits from the records being complete: a parent who cannot read what the app shows writes it somewhere else instead, and that somewhere else has no access rules at all.
What it costs a child. A copy of our database now yields a baby's health notes, a child's ceremony posts and the record of their chores in the clear. These are the records most likely to follow a child into adulthood, and a database copy is the likeliest way they would leak. The cost is borne by the child and the benefit is taken mostly by the adults around them, which is the standing tension in this register and is not resolved by saying the adults are well-meaning.
The safer design, and why it was not chosen. The obvious middle course is to keep the baby tracker's words and children's ceremony posts encrypted while the rest goes back to ordinary text. It was considered and not chosen, for two reasons: the lock-out it causes bites hardest exactly there — a carer at a clinic with a phone that cannot open a medicine's name is the worst case of the problem this change exists to fix — and a per-table exception keeps all of the complexity the change removes while protecting a subset of a group's records, with the rest of the group's words in the clear beside them. If that trade should be made the other way for the baby tracker and for children's ceremony posts, this is the document to say so in, before the code lands. The conclusion here is that it should not, and §8 accepts the consequence.
Where the child's interest and the parent's diverge, the parent's won: the parent can read the record more easily, and the child's record is less protected at rest. The reasoning above is why, and it is open to disagreement.
What a child is told, and it is corrected in this release. The child-facing privacy page describes what the adults in their group can see, which does not change. The sentence it gained from the second stage — that what they post in a ceremony is locked with their group's key, and that our servers open it only while somebody asks the app to help with a ceremony — stopped being true, so it is withdrawn rather than re-dated, in the child's own words: what they write in a ceremony is saved as ordinary words, everyone in their group can read it the way they read a task, our rule is that nobody who works on the app reads it, and the app itself reads it when somebody in their group asks it to help with a ceremony. A post written before the change stays locked until a phone that holds the key opens it, and the page says that too. The child's own privacy policy moves a version for it, because a document a child has already been shown may not be edited quietly; moving it asks nobody for anything again, since a child's "I have read this" is a record that they read the page and not a consent, and the guardian's own consent covers what is collected, which this change does not touch.

8. Residual risk we accept

A copy of our database yields a family's everyday words in the clear, including a baby's health notes, a child's ceremony posts, a calendar that says where a child will be, and a member's own plan. This is the risk the change accepts, in exchange for a group that can always read its own records.
Device-only no longer keeps a group's everyday words from us. It still means no assistant, no daily brief, no voice, no model call, and no copy of the group's key for our servers — and chat and photos keep their key. A group that chose the level for at-rest confidentiality of its tasks and calendar has lost that, and is told.
No group and no member can opt out of this change. There is no per-group switch for it, and we are not building one.
Anybody with legitimate access to our production database can read everyday records, with no key to unwrap and therefore no key-use record of having done it. Our rule against reading group content in production, the register of permitted queries, and the access controls on production are what stand in the way.
Our assistant server reads everyday records with no key-use record. The nightly comparison of key use, and the ceiling on key use, now cover only what is still encrypted.
Backups made after this change hold words where older ones held ciphertext, for up to 90 days on our own copy and on our host's own schedule.
A group with no phone holding its key keeps records it cannot read, and we have removed the way to encrypt more of them.
The unused encrypted columns stay in the database until a later release removes them.
Names and structured facts stay readable, as they always were, including a baby's name.
Everything in the second stage's own accepted list that this change does not touch still stands: email passing through our mail provider as it was sent, a spoken request going to the model, opened words sitting in each phone's own cache, and the plaintext in backups taken before any of this.

9. Review trigger

A new everyday record type is added that a person types or a model writes.
Anybody proposes sending everyday records to a provider, a model or a surface they do not reach today, or proposes a server-side read that is not inside one member's request.
The separate change that makes chat and photo encryption something a group switches on is assessed or built, because it moves the line this document draws.
A proposal to remove the unused encrypted columns, which is the point at which records encrypted before this change stop being openable.
A breach, a mistaken disclosure, or any evidence that production access was used to read group content.
The Children's Code is registered, or sign-up stops being invite-only — the two triggers that apply to every assessment in this register.
Any copy, anywhere, starts saying again that a group's everyday records are encrypted on its phones.

10. Checklist against exposure draft s 38(2)

s 38(2)	Requires	Answered in
(a)	the nature, scope, context, flow and purposes of the handling of children's personal information	§§1–3
(b)	why the collection is strictly necessary	§2.1 — nothing new is collected
(c)	how the collection is lawful and fair	§4
(d)	whether the handling is consistent with the best interests of the child, with reasoning	§7
(e)	how the entity complies with this Code and the Act	§§4 and 6
(f)	the risk of harm to children	§§5 and 7

s 38(3): this assessment was written before the change was built. s 39: it is listed on the published register.

11. Sources

The assessment this supersedes: docs/pia/content-encryption-v2.md, and the key design it relies on, docs/pia/key-architecture-v2.md.
The assessments this amends, each of which describes a surface whose words go back to ordinary text: docs/pia/baby-tracker.md, docs/pia/intentions.md, docs/pia/ceremonies.md, docs/pia/home-brief-editions.md, docs/pia/shopping-pilot.md, docs/pia/privacy-levels.md, docs/pia/tier2-kms.md, docs/pia/child-accounts.md.
The access rules named in §6 are the row-level security policies created by the migrations under supabase/migrations/; the content-sealing migrations of 30 September 2026 and the shopping migrations of October 2026 are where the encrypted columns, their shape constraints and their guard triggers are defined.
The promise register and the privacy policy that move with this change: constants/privacyPromises.ts, constants/legalTexts.ts, constants/contentSealing.ts, and the copy tests beside them under lib/__tests__/.
What is still encrypted, and the single module that opens it inside a request: agent-server/src/tier2.ts, agent-server/src/sealedFields.ts, lib/sealedFields.ts, and the per-surface readers under lib/.
The facts behind this document's description of the current design: docs/reference/encryption.md.
Our own written rule that nobody here reads group content in production, and the register in which a permitted query against a member table is recorded, both kept with our engineering rules.