Headless IRT: Where Does Authority Live?

Every IRT conversation eventually reaches the same question, usually late and usually framed as a question about a screen: who is allowed to do this, and where is that rule actually written down? In a lot of systems the rule lives in several places at once. Part of it is in the role configuration, part of it is in which buttons a given user can see, and part of it is in a study-specific instruction sheet nobody has opened since go-live.

A headless architecture answers the question in one place. Authorization, the trial rules, blinding, and the audit record sit behind the API, inside the engine. Everything that a person or a machine touches is a client of that engine. A website is a client. A middleware integration is a client. An AI agent is a client. Each one presents a credential, and each one receives exactly what that credential permits.

I recorded a proof of concept to show what that looks like in practice, using OpenRTSM as the demonstration vehicle and fictional subjects throughout. It is a demonstration of an architectural idea, not a validated production system.

Using a screen to demonstrate a system that has no screen

The first objection I get is that a video of a user interface is a strange way to argue for headless architecture. It is the right instinct and it points at the wrong conclusion. Headless does not mean there is no screen. It means the screen holds no authority. The web interface in the recording calls the same API a script would call, with a credential of its own, and it can do nothing that credential does not allow. Take the interface away and the engine is unchanged. Take the engine away and the interface can do nothing at all.

ChatGPT is a second client, not a second system

In the recording I also reach the same engine from ChatGPT through MCP tools, using a scoped credential issued for that purpose. The agent has no privileged path. It calls the same endpoints, under the same authorization checks, and its actions land in the same audit record as everything else. If the credential is blinded, the agent is blinded, whatever it has been asked to do.

Be accurate about what the recording proves and what it does not. I screened ten fictional subjects through ordinary API calls, and I read the same subject twice, once with a blinded credential and once with an unblinded one. Part of the planned workflow progression stopped partway through when a ChatGPT safety check interrupted it. So the boundary held and the calls worked; unattended end-to-end operation is not something this recording demonstrates.

Omitting the field beats hiding the column

The blinded read is the part I would ask you to watch twice. The restricted fields are not greyed out, and they are not present in the response and styled away. They are absent from the payload the server returns.

A hidden column is a presentation decision, and presentation decisions are reversible by anyone who can open the browser tools, read the network tab, or call the endpoint directly with the same session. A field the server never sends cannot be recovered by any of that. The blind is enforced at the point where the data is assembled, which means every client inherits it, including the ones nobody has written yet.

AI is optional to this

None of this depends on an agent. The same engine serves a scheduled integration, a depot's inventory system, a CRO's portal, or one clinical supply manager with a browser. AI is one more client, useful when the work is conversational and exploratory. What the architecture buys you is that a new client is cheap and safe to add. If the authority lives behind the API, adding an interface is an integration problem. If it lives in the interface, adding one is a revalidation problem and a risk decision.

What this does not settle

A cleaner boundary does not remove the work. The shared core still has to be validated, and so does each integration that reaches it, because a correct engine called incorrectly still produces a wrong randomization. Accountability needs a named human behind every credential, including the ones issued to agents, so the audit record answers who as well as what. Credential management becomes the control surface, which makes issuing, scoping, rotating, and revoking credentials a study start-up activity with an owner. And a new interface has to earn its place. If a conversational client does not make a real workflow faster or less error-prone, it is a demonstration, not a deliverable.

Three questions to put to your own stack this quarter. If your front end disappeared, what trial logic would disappear with it? When a blinded user's screen hides a treatment arm, is that value absent from the API response, or only from the page? And for each integration that writes to your IRT today, whose credential is it using, and could you revoke it this afternoon without a support ticket?