Work the AI brainstorm screens

Programs has two AI screens: the AI brainstorm hub, reached from the sidebar under Programs → AI Studio, and a second copy inside a program's own tabs, which is not linked from anywhere. Both run the same seven tools.

They are the only Programs screens in this portal whose audience includes front-line staff, and they are also the only Programs surface where the word AI means an actual model call.

Who can do this

• Front-line staff
• Site director
• Regional director
• Organisation admin
• Super admin

none, neither page checks a role

The seven actions behind these screens are registered by the AI module, not by Programs, and they require a setting that admits staff, which every one of this module's own actions refuses.

The audience differs between the two screens; see Who can open which.

These actions are not part of the Programs module

Seven client functions sit in the Programs code under a heading naming them as brainstorming tools, and their paths begin with a shared prefix that belongs to the AI module instead of Programs. They are registered by the AI module, with the setting that admits staff and its own rate limit.

So they are counted against the AI module, not against Programs' own 122 actions. The screens belong to the Programs route list; their actions do not.

The seven tools

Both screens offer the same set.

Tool	What you give it
Program ideas	An age group and a list of interests
Curriculum outline	A program topic and duration
Goals and KPIs	A program description
Success criteria	A goal statement
Assessment design	What you want to measure
Partnership suggestions	A program description and locality
Compliance gap analysis	A program description

This is a real model call

Unlike the "AI" on the incident surfaces, these tools do what they say. Taking program ideas as the worked example, each request:

1. Requires an organisation context, refused otherwise.
2. Calls an outside AI model through PTRS's own pipeline, which routes it and applies the personal-information protections.
3. Checks that the reply is well-formed and in the expected shape, and returns "AI returned malformed output. Please try again." if not.
4. Writes a record of the exchange, including the model name, the request and response, token counts, timing, and whether anything sensitive was detected in the output.
5. Writes an entry to the tamper-evident log.
6. Returns the response with the model name and timing.

If the model cannot be reached, PTRS reports that plainly, rather than failing silently.

It needs a reachable model

The pipeline calls an outside model server. In an installed copy of PTRS where no model server can be reached, every tool on these screens reports the service as unavailable. That is correct behaviour, and it is worth knowing before concluding a screen is broken.

What these tools do not read

This is the part to be clear about before relying on an answer.

The tools read nothing from your program

Every input is text you type. PTRS builds the model's prompt from what you sent and nothing else; it queries no program, no enrolment, no budget and no compliance record.

Compliance gap analysis is the sharpest case. The only thing it saves is the record of the exchange itself. It does not read a program's recorded compliance requirements at all.

So compliance gap analysis is a general-purpose model answer about the description you typed. It is not an analysis of your program's recorded compliance position, and it has not seen one.

That record cannot be filled in anyway; the Compliance tab does not connect to PTRS at all. PTRS therefore offers AI analysis of a record it can neither read here nor write there.

The same applies to partnership suggestions: it does not read a program's actual partner organisations or existing partnerships. Where the screens offer a box for existing programme context, that is a field for you to fill in by hand, not a lookup.

The output is text, and it goes nowhere

Results are shown on the screen. There is no control that turns a suggested program into a real one, a suggested curriculum into a real curriculum, or a suggested KPI into a real goal. Nothing is saved except the record of the exchange itself.

Treat the screens as a drafting aid whose output you retype into the real forms.

Who can open which

The two screens have different audiences, because of where they sit.

Screen	Linked from	Effective audience
The AI brainstorm hub	Sidebar → Programs → AI Studio	Staff, site directors, regional directors, organisation administrators, super admins
The copy inside a program's tabs	nothing	Site directors, organisation administrators, super admins

The AI brainstorm hub is a top-level route with no layout gate. Neither the page nor the sidebar checks a role, so the link shows for everyone, and the actions behind it admit every one of the five roles the setting allows.

The copy inside a program's tabs sits inside the program's own layout, which loads the program's detail first. That check excludes regional directors; the module's own group setting excludes staff. So the effective audience narrows to the module's usual three, and none of them can find the page, because it is not in the program's own tab list and not in the navigation. It is reachable only by typing its address directly.

This is the first Programs page in the portal a staff member can use

Every one of this module's own 122 actions sits behind a setting that excludes staff. Until this page, the role had no Programs surface at all.

The AI brainstorm hub is the exception, and only because its actions belong to a different module with a different setting. A staff member who opens it will find all seven tools working, and will find every other Programs screen either refusing them or empty.

Related

• The AI pipeline, model routing, personal-information protection, and the record kept of each exchange.
• Work the partnerships, compliance and documents screens
• Who can do what with money and governance