Who can do what with the AI Assistant

Who is admitted

Two groups of actions, and one shared rule between them.

Group	Actions	Who the shared rule admits
The chat and the everyday actions	20	Staff, a site director, a regional director, an organisation administrator or a super admin
The seven program-planning actions	7	the same five

27 actions in total, counted by walking every registration in the module directly rather than carrying a figure forward from an earlier count.

The three narrower or wider rules

Most of the 27 rely on nothing but the shared rule above. A handful are narrowed or widened further, on top of it:

	Count	Where
Rely on the shared rule alone	22	15 of the 20 everyday actions, and all 7 program-planning actions
Narrowed further	3	the three regulation-library actions, to your organisation's super admin alone
Widened to admit anyone, signed in or not	2	the model status screen's two reads

The narrowing is the sharpest in PTRS. Loading, listing or removing a regulation document is limited to your organisation's super admin, against a shared rule that admits five roles including Staff. Four of the five roles that can use the assistant cannot touch what it reads from.

The two actions anyone can reach, signed in or not

The model status screen's two reads check nothing at all: no sign-in, no organisation. This is the fourth and fifth time in PTRS that an action has been left open like this; the earlier three were a training catalog listing, an enrolment application form, and a file-import template.

What they expose: one read returns the model provider's name, the names of the models in use, and three feature settings, to anyone who can reach the address. The other returns the same four names plus whether each model can currently be reached.

And the reachability check does real work. Checking the model your organisation's own equipment runs is a simple, harmless check. Checking the outside service, when that is the one selected, is a genuine small request to that service, using a fixed model name rather than whichever one your organisation has actually configured. Every visitor who has not signed in shares one allowance of twenty checks a minute, so one anonymous visitor running the check repeatedly can use up the whole allowance for everyone else.

The 27 actions

The chat and the everyday actions, 20 in total

Shared rule: Staff, a site director, a regional director, an organisation administrator or a super admin.

Action	What it does	Reachable by
List your own conversations	Your conversations, newest first	Nothing today
Read one conversation	One conversation with its messages	Nothing today
Start a conversation	Creates one with a title	Nothing today
Remove a conversation	Retires it	Nothing today
Send a message into a conversation	Answers, saves both sides, and keeps a record of the exchange	Nothing today, and the one screen built to try sends it to an address that does not exist
Read the suggested questions	A short, role-based list built from live figures	The chat's sidebar
Structure a free-text incident description	Turns loose notes into a structured description	Nothing today, no screen even offers it
Classify an incident description	Suggests a type and severity	Nothing today, no screen even offers it
Build a full incident report	Builds a report from an incident's id	Nothing today, no screen even offers it
The chat itself	Answers as text arriving word by word, then one chart, table or set of cards, built separately	Ask the assistant a question
The data question box	Turns plain English into an instruction it runs directly	The Data Query screen
Translate text	Translates to English, Spanish or Haitian Creole	Nothing today; built, and no screen offers it
Draft a note to a guardian	Drafts a message from an incident summary	Nothing today; built, and no screen offers it
Sort a meal description	Maps it to the federal meal-program categories	Nothing today; built, and no screen offers it
Summarise attendance	A narrative summary for a date, optionally one site	Nothing today; built, and no screen offers it
Read model status	Provider names and two reachability checks	The model status screen, reachable by anyone signed in or not
Read model configuration	Provider names and three feature settings	The model status screen, reachable by anyone signed in or not
Load a regulation document	Splits, fingerprints and stores it	The regulation library, your organisation's super admin only
Read regulation library statistics	Passage counts and last-loaded times per source	The regulation library, super admin only
Remove a regulation source	Retires every passage for that name	The regulation library, super admin only

The seven program-planning actions

Shared rule only, admitting the same five roles.

Action	What it does	Reachable by
Suggest program ideas	Concepts from a theme and an age range	Both program screens
Suggest a curriculum outline	A session-by-session outline	Both
Suggest goals and measures	Suggested goals and how to measure them	Both
Suggest success criteria	Suggested outcome criteria	Both
Suggest an assessment design	An assessment instrument	Both
Suggest community partners	Partner ideas	Both
Suggest a compliance gap analysis	A written analysis "against DELACARE and OCCL requirements"	Both

All seven build their answer from the words typed into the form. Not one reads an actual program, an enrolment, a credential or a compliance record. The clearest case is the compliance gap analysis: it keeps its own record of having run, and reads nothing else.

Summary

	The chat and the everyday actions	The program-planning actions	Total
Reachable from a screen	8	7	15
Not reachable from any screen	12	0	12
Total actions	20	7	27

The twelve unreachable ones fall into three groups.

The whole conversation model accounts for five actions. The screens they would need are built and nothing on the chat screen calls them. The chat keeps its conversations in your browser instead, so a conversation started there is never actually saved to a record anyone else could ever read.

Three more are for working with an incident description, with no button anywhere that calls them. The Incidents module has its own, separate way of building a structured report, and that is what the incident screens themselves use.

The last four are purpose-built and nothing calls them. Translating text, drafting a note to a guardian, sorting a meal description and summarising attendance are each complete, and nothing on any screen sends one. Three of the four are named in the chat's own suggested questions, which route to a general answer instead of the purpose-built one.

Answers you cannot rely on

Five of the fifteen reachable actions answer normally, with nothing that looks like an error, and still cannot be trusted.

What you ask for	What comes back	Why
Anything about attendance over more than today, in the chat	A confident sentence containing zero	Every attendance figure in words comes from a summary table nothing fills in
A funder or grant report, in the chat	The panel shows "Total served 0" with no rows	Built from the same empty summary table
A regulation question with nothing loaded	An answer from the model's own general knowledge	The instruction to the model, when nothing is loaded, is to answer from general knowledge and say so; nothing checks that it actually does
A compliance gap analysis	Gaps "found" in a program the action never actually read	See above
A plain-English data question, on a copy of PTRS shared by more than one organisation	Records from every organisation	Below

The data question box runs outside the boundary that keeps every other screen inside your own organisation

The action checks that you belong to an organisation and then never uses that fact again. What your question turns into runs directly, and the boundary that keeps every other screen in PTRS inside your own organisation's records does not apply to a direct instruction like that one.

What the safety check in front of it does enforce: the instruction must be a plain read, never a change; a short list of dangerous words is blocked; and so is anything that tries to chain more than one instruction together.

What it does not enforce: the approved list of record types, for the exact phrasing the model is told to use. The way the model is told to quote a record type's name happens to slip past the part of the check meant to catch an unapproved one, so in practice nothing is actually checked against that list.

What comes back is shown exactly as it arrived: not checked again for personal details, and not limited to your own organisation.

The shared rule admits Staff, and the screen itself checks nothing further.

The three checks, one screen at a time

Screen	The wider, first check	The screen's own check	The rule behind the save	Who actually gets through
The chat	Four administrator roles plus Staff and read-only	The same five roles as the chat's action	The same five	The five. An exact match
The data question box	The same wider check	None	The same five	The five, by the underlying rule alone
The model status screen	The four administrator roles	Two of the four	Nobody is checked; both reads are open to anyone	The two administrator roles, by the screen alone
The regulation library	The same four	Two of the four	Your organisation's super admin alone	Super admin only. An organisation administrator passes both screen checks and every save still fails

Two of the four are worth naming on their own.

The chat is the one screen in PTRS whose own check is an exact match for the rule behind it, no wider and no narrower.

The regulation library is a screen that looks more open than it is. An organisation administrator sees the heading, an empty list of loaded sources, since the read behind that list fails the same way, and a form whose every submission fails.

What is checked before a save runs

There are 20 checks for 27 actions. The seven without one take no information at all to start: listing conversations, reading suggested questions, reading model status and configuration, reading regulation library statistics, or the chat itself, which checks its one input, a non-empty question, inline rather than through a separate check, and is also the one action a person actually reaches.

Two rules are enforced in the same way on the screen and on the save behind it, which is unusual in this product:

Rule	Where enforced
Regulation text must be at least 100 characters	Both the form and the save
A source name may only contain letters, numbers, hyphens and the mark _	Both the form and the save

Choices that always match what PTRS accepts

The module offers three choices to pick from, and all three agree completely between what the screen offers and what PTRS accepts:

Choice	What the screen offers	What PTRS accepts
Translation target language	English, Spanish or Haitian Creole	The same three
Draft-a-note language	The same three, defaulting to English	The same
Regulation source name	Letters, numbers, hyphens and the mark _	The identical pattern

This is the fourth module in a row with no mismatch here, after Analytics, the Parent Portal and Administration.

Messages this module could show and does not

Seven ready-made messages exist for specific failures: a missing conversation, a missing incident, a missing organisation, the AI service being unreachable, a missing question, a missing title, a missing description. None of them is actually used anywhere. Every action writes its own failure message inline instead, so a message that names one of those seven never actually appears on screen; what you see is a plain sentence describing the same problem in different words each time.

What gets written, and when

Action	What it writes
The 16 non-chat actions that produce an answer	one record of the exchange and one activity entry, together
Sending a message into a conversation	additionally, one message for the question and one for the answer
The chat itself	nothing
Loading a regulation document	one record per passage; retires the previous set for that name first
Removing a regulation source	retires every matching passage
Everything else	nothing

Two things about the record of an exchange matter to anyone who might read one.

The text going in usually is not shortened to placeholders first. Only two of the sixteen actions that keep this record replace personal details with placeholders before saving the question. The other fourteen save exactly what was typed, including a free-text incident description.

The text coming back never is shortened to placeholders. All sixteen save the answer after personal details have already been restored to it.

The record's own description says the opposite of both of these. The table it lives in is also not limited to your own organisation, and it is one of the record types the data question box can reach.

Limits

Limit	Applies to	Allowance	Counted per
The everyday limit	Every action in both groups	20 a minute, 5 more waiting	The signed-in account, or one shared allowance for anyone not signed in
The streaming limit	The chat only	5 answers arriving at once, 2 more waiting	The same

The chat is the only action in PTRS with two limits stacked on top of each other, and the streaming one limits how many answers can be arriving at once rather than how many can start per minute, which suits a slow, resource-heavy answer better than a plain rate would.

Everyone who is not signed in shares one allowance, so the two open reads share a single twenty-a-minute allowance across everyone on the internet who finds the address.