A site owner was explaining to me why he hates the eSource platform he is using. Before every monitoring visit, he wants to be sure the source is right before the monitor arrives.
So he opens the eSource audit log for a single subject and starts clicking.
Year of birth. Expand. Read. Collapse. Age at consent. Expand. Read. Collapse. Sex at birth. Ethnicity. Race. Multi-racial. One field at a time, one row at a time.
Nothing is wrong. That is the point of this story. He is not chasing an error. He is doing the work the system asks of him before anyone will accept that the data is what it says it is.
What the log tells you, and what it does not
The audit log is honest about what it records. For each value it shows who entered it, the action they took, when they took it and the IP address they took it from.
What it does not show, for an entry like this, is why.
Why was this value entered this way? What document did it come from? What did the person entering it look at when they made the call? If it changed, what prompted the change, and who decided it was right?
That context lives in someone's head, in a paper chart, in a note on a different screen. The log gives you the footprints. It does not give you the reasoning. So before a monitoring visit, a careful coordinator walks the footprints back, field by field, and rebuilds the reasoning from memory and from the chart.
That is archaeology. And it happens at sites running current eSource, not just at sites still on paper.
One value, many logs
And the eSource log is only one of them. The story a site has to confirm before the monitor arrives runs through several logs that do not talk to each other. Take a lab value from the same visit.
Was the person who drew the sample on the delegation log for that task? Was the phlebotomist credentialed and trained on this version of the protocol before the draw? Did the person who packed the blood for transport have a current IATA dangerous goods training certificate on file? Each answer sits in its own log, in its own system or binder, and each is about as cumbersome to inspect as the first.
Then there is the equipment. Was the centrifuge in calibration on the day of the spin? Which temperature sensor rode with the shipment, which model and firmware version, and does its log cover the whole trip?
At most sites, none of these logs points to the others. The person checking joins them by hand, by name and by date, and hopes the dates line up.
We traded the swivel chair for something worse
Sites adopted eSource for a good reason. They wanted to end double entry: the swivel chair of reading a value off one system and typing it into another. Capture it once, at the source, and let it flow.
That part largely worked. The copying went away.
But the checking did not. It got heavier. Now, instead of copying data once, coordinators check it again before every monitoring visit, digging through a log that was built to prove that something happened, not to explain it. Double entry was a cost you paid once per value. Double-checking is a cost you pay every time someone needs to look.
Even a site with the latest eSource does not escape this. Newer software has not changed the shape of the problem, because the problem is not the software's age. It is what the value carries with it.
A nicer screen only moves the problem
An eSource vendor could fix the interface tomorrow. Expand all fields at once. Put the source document beside the value. Add a free text box for the reason. That would make the routine I described shorter, and it would be worth doing.
It would not solve the problem. It would still be one well-designed log among many disconnected ones.
The moment that value leaves eSource, it moves on to the EDC, then to the sponsor, then into the submission. None of the provenance travels with it. Not the who, not the when, and certainly not the why. Each downstream system receives a bare value and starts its own fresh round of questions. The monitor asks. The data manager asks. The reviewer asks. Each of them rebuilds the history again, from wherever they can find it.
A better screen at the site makes one stop on that journey pleasanter. Every other stop still has to dig.
An agent that clicks faster is still a switchboard
There is an obvious modern answer: put an AI agent on it. Let it open the log, click every row, read every value and run the checks overnight.
It could do that. And it would save someone hours before every visit.
But look at what it is actually doing. It is a faster operator plugging the same cables into the same switchboard. The work of reconstruction is still there. We have just hired a machine to do it. We have written before about how clinical trials are still in the switchboard era, and automating the operator does not end that era. It extends it.
The question is not who does the reconstruction. It is why reconstruction is needed at all.
The history has to travel with the value
This is the same point we made in our public comment to FDA on real-time clinical trials. Real-time review only works if a value's history travels with it. We also suggested the pilot measure something people rarely measure: not only how fast a result arrives, but how long it takes to reconstruct how that result came to be. You can read what we told FDA.
That routine is the same measure, at the smallest scale. One subject, a handful of fields, and a person rebuilding history that should have been there already.
When the evidence is attached to the value, nobody has to go looking for it.
How we think about it at ScientixAI
We are building ScientixAI so that each value carries its source, its reason and the decision behind it, from the moment it is captured to the moment it is reviewed. The goal is that when a person makes a call, that act is attested by that person, and when a machine produces an output, it is recorded as machine output.
Then when a monitor, a sponsor, a reviewer or an agent needs to look at a value, they could check it against the record instead of reconstructing it. Nobody would have to rebuild the why the day before a visit, because the why was kept when it happened.
That is the difference between automating the archaeology and making it unnecessary.
If you run sites, monitor studies or sponsor trials and this sounds familiar, we would like to build this with you. Become a design partner.