Open oversight
There is no private thread to find
Not because private threads are switched off, but because the platform has no way to make one. Who may read a conversation is worked out at the moment somebody reads it, from the organization’s own structure, rather than from a list anybody has to keep up to date.
- 0
- kinds of private conversation the schema can express
- 0
- lists of who-watches-whom to maintain
- 1
- moment access is decided: the moment it is read
- 0
- hidden threads to discover afterwards
- Enforced by the schema — there is no private kind to create
- Who may read is resolved live, from the organization’s structure
- A young person can see who holds access to their conversations
Nothing to switch off
A private conversation is not disabled here. It is absent
Most products would express this as a permission. Expressing it as a permission means somebody, one day, can hold the permission.
Not a setting
There is no configuration anywhere — not for an organization, not for the platform — that produces a conversation only its two participants can read. No screen offers it, because there is nothing behind the screen to offer.
Not a mode either
A conversation has a kind: one-to-one, group, or announcement. Every one of them is readable by the leaders who oversee the young person in it. There is no fourth kind, and adding one would be adding a concept rather than relaxing a check.
So there is nothing to find later
The question “were there private messages we did not know about” has the same answer before and after any incident, and it is not a matter of trusting the answer.
This is the difference between a product that keeps a promise and a product that cannot break one. Only the second survives a busy quarter and a new developer.
How access is decided
Worked out as somebody reads, not written down in advance
A list of who may see whom is right on the day it is made and wrong shortly afterwards. People move, roles change, and nobody remembers the list.
At the moment of reading
When a leader opens a conversation, the platform resolves their position in the organization and the young person’s, right then, and answers. Nothing was cached, so nothing can be stale.
So there is no roster to keep
Nobody maintains a mapping of leaders to young people. It falls out of the structure the organization already has and already keeps accurate for its own reasons.
And it is one rule, in one place
The same rule answers for every screen, every export and every route, because it lives in the database rather than in the code that happens to be asking. A new screen cannot forget it.
The young person is not left guessing either: a line at the top of every thread says who is reading it and on what basis.
The decision your organization makes
Whose section pulls their leaders into a thread
This is the one genuinely difficult question in the module, and the answer that sounds most thorough is the wrong one.
The default: the young person’s
Only a young person’s own section pulls their local leaders into a conversation. The adults closest to that child — the ones who see them every week — can read the threads they are in.
The alternative: everybody’s
Available where a jurisdiction permits it. Every participant’s section pulls in that participant’s supervisors, so a thread is readable by the leaders of everyone in it.
Why that is not the default
Because it means an adult’s own supervisors gain sight of a child’s conversation merely because that adult is in it. That is oversight following the grown-up, which is the opposite of what this exists to do — and it quietly widens who can read a young person’s words for a reason that has nothing to do with the young person.
Both are defensible and your jurisdiction may decide it for you. What the product will not do is pick the wider one quietly because it reads better in a feature list.
When somebody moves
A young person changing section changes who can read them
Resolving at read time has a consequence worth stating rather than discovering.
Their new leaders can read them
From the moment a young person joins a section, the leaders of that section can read the group conversations they are in — as they must, since those are the adults now responsible for them.
Including what was said before they arrived
Deliberately. A leader who can see only the half of a conversation that happened on their watch is reading the least useful half, and reviewing part of a thread is worse than not reviewing it — it produces confident conclusions from missing context.
A one-to-one thread keeps its own section
Direct conversations are anchored to the section they were created in, and that anchor does not move. So a leader does not lose sight of a one-to-one thread they were supervising because the young person transferred.
Stated here because a safeguarding lead will ask, and because the answer is different for group threads and direct ones — which is exactly the kind of detail a feature list flattens and a real deployment does not.
In short
What to tell your board
Three sentences, all of them checkable.
- There is no private conversation in this product, because the schema has no way to express one.
- Who may read a thread is resolved from the organization’s structure at the moment of reading, so no list can go stale.
- Your organization chooses whether oversight follows the young person alone or every participant, and the default is the young person.