Technology That Isn't Ordinary

The idea

At the core of CRC-Hub is a domain-specific language that specifies how a trial is run at a site: the periods, the visits, the tasks and steps inside them, what each one requires, and when each one happens.

Timing is where the language earns its keep. When a visit happens is a single expression, written as a sentence:

First scheduled when Cycle 1 Day 1 completed + 14 dayswith a window of 3 day(s) before and 3 day(s) afterrepeats biweekly up to 12 times until End of Treatment completed

That is not a description of the schedule. It is the schedule: one expression in a formal language, with words for visits, arms, windows and repeats, and rules about how they fit together. The rest of the study design is written the same way, and written that completely it can be executed rather than merely stored.

Everything else rests on that: an engine that runs the specification per patient, an editor a coordinator can write it in, and a language model that is unusually good at writing it.

1. Why a language

Scheduling is where a language differs most plainly from how this is usually done. Systems that hold a study’s schedule do it one of two ways, and both give something up. Conditional visits show it most sharply, so they are worth following through each.

The simpler of the two stores timing as values: an anchor, an offset, a window either side, with anything conditional written out as text for a person to read and apply. The industry’s own machine-readable protocol standard works this way.¹ That is enough to produce dates, including from a patient’s actual visits. What it cannot do is decide anything conditional. Whether this patient needs the extra visit at all, or what stops a cycle repeating, never reaches the system: it stays a sentence in the protocol document, and applying it to each patient falls to the coordinator.

Tools that go further usually add an escape hatch: the conditional part is written as a snippet of code or SQL. That is executable, and it is the right instinct. But it moves the protocol’s logic out of the specification and into a general-purpose language. Whoever writes it has to be able to program, so the coordinator running the trial cannot read it, let alone change it. Nothing checks it against the study either, so a mistake surfaces as a wrong date on someone’s calendar rather than as an error when it is written.

So the choice on offer is readable by the site or executable by the software. A domain-specific language is how you get both. It runs, so conditions are decided rather than left for someone to apply. And its vocabulary is the domain, so it can only name events, states, arms and periods that exist in this study, which is what keeps it readable, and changeable, by the site running the trial.

That is what makes the specification executable, and everything below follows from it.

2. Executing the specification, one patient at a time

A calendar can hold each patient’s dates and move them when a visit slips. What it cannot work out is which visits a patient should have when that depends on what has already happened to them. That takes two pieces working together: an interpreter that evaluates the language’s expressions,² and a discrete-event simulator that advances one patient through the study event by event.³

Each is a serious piece of engineering in its own right, and putting the two in a loop that a language drives is rarer still. The simulator cannot decide what happens next without asking the interpreter to evaluate an expression; the interpreter cannot evaluate that expression without the state the simulator has reached, since when Cycle 1 Day 1 completed is a question about how far this patient has got. Take the language away and there are no expressions to evaluate, so the loop has nothing to turn on. The specification is not read off in one pass; it is executed step by step, each answer changing the state the next expression meets.

That loop is why the awkward cases need no special handling. A visit that slips drags the visits anchored to it; a visit that exists only when an earlier one was missed appears only for the patients who missed it. Neither is coded as a rule. Both are what falls out when the same expressions meet a different history.

A good deal follows from that. The timeline, the calendar and tomorrow’s checklist are one answer shown three ways rather than three features that have to agree. An amendment can be migrated one patient at a time, because each patient’s schedule is worked out separately anyway. And a history the engine is given need not be a real one, so a site can walk a visit through before anyone is enrolled.

3. Guided editing, so a coordinator can write it

An executable specification is worth little to a site if writing one takes a programmer. And this is a formal language: formal languages are usually typed as text, where every character is a chance to get the syntax wrong.

A coordinator never sees that. What they read is a projection of the specification, the language rendered as a sentence about a visit, and editing happens on the language underneath, not on the words on screen.⁴ At each point the editor offers what the language allows there and nothing else: an event where the expression expects an event, a state where it expects a state. Call it guided editing.

The schedule at the top of this note is one line of it as a coordinator sees it: the underlined parts are the choices, the numbers are typed, the rest is fixed. That holds all the way up. Adding a period, an event inside it, a task or a step is the same act of choosing what the language allows there, so it is not only the values that come out valid but the shape of the study, and whole categories of error never have to be caught because they cannot be expressed in the first place.

And it runs in a browser. Editors of this kind, built on a language rather than on forms, have mostly been desktop software, reaching the organisations that can install and support them rather than the ones that just sign up. Every other tool a site uses arrives as a web application; this kind rarely does. Getting one into a browser is not a matter of trimming the desktop version down: it is the harder piece of engineering, and it is what puts the editor in front of a coordinator who has nothing to install and nobody to call.

4. Not prose, not code: what an expert can actually check

Almost everything anyone does with an LLM comes out as prose or as code, and for someone who knows a domain but does not write software, neither can be checked. Prose is readable but imprecise, and cannot be run. Code is precise and runnable, but the expert cannot review it, so they describe what they want and take the model’s word for what came back.

The current generation of AI tooling offers a third pattern: the model emits structured data against a schema, which the application validates and renders on its own screens. That helps the application, which now has something predictable to work with, but it leaves the expert where they were. A schema checks the shape of an answer, not whether the answer is right, and the expert never sees it in any case: they review a rendering while the system executes the data behind it.

A domain-specific language closes both gaps. To a language model it is code, which is what these systems are trained hardest on and improved fastest at, so the model is working on its strongest ground. To the coordinator it reads back as a sentence about a visit. And because guided editing works on the specification itself, there is no second version of it: the coordinator is not reviewing a screen built to represent what the AI wrote, they are reading what will run, and correcting it in place.

And they can run it, on the spot. Reading catches what looks wrong; running catches what a reading cannot: a repeat with no stop condition that never terminates, or an anchor chain that yields an absurd date once a visit slips. The coordinator applies the change and sees the resulting schedule immediately, for a patient real or hypothetical, and can keep changing it and re-running until it is right.

Immediacy is the point. A specification this expressive, with conditional visits, repeats that stop on an event, windows and arms, would normally be something you submit and wait on, because working out its consequences is a job for whoever configured the system. Here the engine simply runs it again, so a change and its consequences arrive together rather than a change request and a wait. That is what makes the loop of describe, generate, read, correct and simulate something a coordinator does in a sitting rather than over a week of emails.

At every point in that loop, the AI’s work is held to the same rules as the coordinator’s own edits, and nothing it proposes takes effect until they accept it, so the AI does the volume, and the coordinator’s attention goes to what needs judgment.

And this gets more valuable as models improve, not less. Reading a protocol well is already close to a commodity, and every year it will be done better. What a better model does not give you is somewhere for the result to live. Generation gets cheaper; what stays scarce is a medium expressive enough to hold a real protocol, with its conditional visits and repeats and arms, that a coordinator can still read, change and run.

So the durable question is not whether an AI can draft a study, but what the draft is good for once it exists. Landing in a language means it can be run: every patient’s schedule computed from it, every conditional visit decided, a change on Wednesday reflected in Thursday’s calendar and Friday’s checklist. That is the difference between an AI that produces a document about the trial and one that produces the trial’s executable specification.

Why this is rare

The four pieces we have built are ours, but the approach is not: another team could design a language of their own along the same lines. What stands in the way is that the public material is a body of academic work and a handful of frameworks that assume you already know the theory behind them, which is why most software teams regard building a language as something between very hard and out of the question. And a language you design yourself comes with no interpreter: you write that too, along with the simulator that drives it. Few projects would put that on the list of options in the first place.

The people who do build this way are correspondingly few. Subject Matter First is their manifesto: give the expert a tool to capture and validate their own knowledge, rather than leaving it in Word documents for a developer to translate. Its signatory list, a fair sample of the field, is not a long one. Almost none of them have aimed this at clinical research.

Then there is the domain itself. Plenty of vendors have modelled how trials run: visit schedules, windows, amendments. What a language demands is that the model be complete, because anything a protocol can require has to be expressible in it, and whatever the language cannot say is something the engine cannot decide. The gaps only show up against real protocols, and closing them is language work rather than a feature. Years of it are already in the language, and that is the part a competitor cannot start from.

Which leaves the question you are better placed to answer than we are. We cannot see inside the products a site is offered, so we will not claim nobody else has done this. What we can say is that everything we have seen takes a substantially different approach: the rules of the trial live in the vendor’s code, and configuration adjusts them from outside. Here they live in the specification, and the code’s job is to evaluate it. That is the thing to test in anything you are shown, and it is not hard to test: ask what happens to the schedule when a patient misses a visit, and ask who can change the answer.

A language that a coordinator can read, and an engine that runs it, is what makes the schedule per-patient, the checklist current, the amendment migratable and the AI worth having. So we think this is the differentiator itself, not a technical detail sitting behind one. None of that is worth much as a claim, though, so we would rather you used it and judged for yourself.

This note covers what is different about how CRC-Hub is built. Two companion papers take up the other questions: The Layer Nobody Owns on the gap in what a site’s systems cover and what it costs, and Experience Is Not Enough on what all of this produces for a coordinator day to day.

The fastest way to judge any of it is against a real protocol. Send us what defines a study and we will build the schedule and the checklists for it: CRCHub@triradial.com.