A recent article on LinkedIn examined the gap between AI research environments and clinical trial systems of record. Its subject was clinical trials, but one sentence in it is bigger than any single domain: the hard part is not getting good reasoning out of a model, it is getting the same reasoning twice.
At Ariv Health we live on the other side of healthcare: not the science of who joins a trial, but the money and membership data that runs value-based care. Claims files, CMS data, payer extracts, enrollment rosters. We hit the same wall that article describes, in a different building. This is the claims-side companion to that clinical-side story.
Data that arrives with no memory
Healthcare’s operational data arrives as files. A monthly claims extract lands, and it carries no memory of anything: not why a field is shaped the way it is, not which delivery superseded which, not what anyone decided last month about the rows that looked wrong. The institutions that produce these files are excellent at producing them and silent about interpreting them.
So every organization that consumes them builds interpretation, and almost every one builds it the same way: as knowledge in people’s heads, encoded in scripts nobody dares touch. The analyst who knows why duplicate claim rows are collapsed a particular way leaves, and the organization now runs on a decision it can no longer explain. When a model enters this picture, it makes the problem faster, not better. A model will happily interpret a claims file for you. It will also happily interpret it differently tomorrow.
The same file, two defensible answers
Here is our version of the two-answers problem, and neither answer is wrong.
When a claim is canceled, there are two established ways to handle it. One school of thought excludes canceled claims from the analytic record entirely. The official CMS guidance for one major file format instead says to negate the canceled claim’s dollars and sum, so the cancellation shows up as negative money. Same file, same rows, two defensible readings, and real dollars move between them. A widely used open-source pipeline follows the guidance for institutional claims and the exclusion approach for professional claims, which means the divergence is not even consistent within one codebase.
A model asked to process these files will pick one. Asked again, it may pick the other. Both answers are fluent. Both cite something real. And if the choice is not recorded anywhere with a name attached, your revenue numbers just became a function of which day you ran the pipeline.
The fix is not better prompting. The fix is a durable record of what has been decided, living in the system that does the work.
What we built
Four things.
Every interpretation is a named rule with a named ratifier. Nothing in our pipelines cleans, collapses, or excludes data as a side effect of code. Each behavior is a rule with an identifier, a written rationale, and a status: ratified by a named domain expert, or proposed and awaiting one. The canceled-claims question above is a rule in proposed status right now, sitting in front of the actuary who owns it. Until a human rules, the system applies the documented default and says so. It does not quietly decide.
New data sources are on probation until they earn trust. Every new feed starts human-gated: each delivery is held for review. After a streak of clean runs it graduates to automatic processing, and any red finding sends it straight back to probation. This one mechanism reconciled two things we refused to trade off: every drop reviewed by a human, and no human in the loop forever.
Identity is derived from content, not declared in a field. Every output we produce is stamped with an identity computed from everything that produced it: the exact input files, the exact rules, the exact engine. Two runs with the same identity must produce identical output, byte for byte, and we test that by destroying outputs and rebuilding them. When a number changes, the first question is never who changed it. The identity stamp answers that before anyone asks.
Everything that happens is a ledger entry, including the failures. Every run, every hold, every quarantine, every human ruling is an append-only record. There is no delete. Our failed runs sit in the ledger next to the successful ones, and that is the point: an audit trail that only contains successes is not an audit trail.
What the system refuses to do
We have come to believe the refusals are the product.
Claims files do not carry certain things. One format carries only what the patient paid, not what the plan paid. Popular tooling fills that gap by copying the patient’s payment into the plan-paid column, which produces a complete-looking dataset that is quietly wrong. Ours leaves the field empty, flags the gap, and routes the question to the human who owns it. Another example: enrollment periods cannot be derived from claims alone, and tooling that fabricates them from indirect signals is manufacturing membership data. Our pipeline declines to build that table at all until a real enrollment source is connected, and it fails loudly, with a message that says what to connect, rather than producing an empty table that under-reports in silence.
AI that fails closed is a feature. In a data pipeline, that means the system is allowed to say “I do not know, and here is specifically what I am missing,” and that answer is treated as a success, not an error.
The proof run
Discipline is easy to claim, so we set a test with no wiggle room. We took an interpretation pipeline that had already been certified the hard way, by matching a healthcare organization’s own trusted numbers, and rebuilt it from scratch under the new discipline: every behavior a named rule, every run ledgered, every output identity-stamped. Then we required the rebuild to reproduce the certified results exactly. Not approximately. The same row counts, the same distinct claims, the same dollars to the cent, in every table, in every year, across tens of millions of claim lines and billions of dollars.
It did not pass on the first run, and the miss was the best part of the exercise. The gap traced to exactly one rule, one we had marked as needing a human ruling on which reference data resolves ambiguous patient identities. With the reference connected, exact equivalence. The discipline did not just reproduce the numbers. It predicted, in advance, the one place the numbers could diverge, because that place was already flagged as an open ruling in the register. That is what a decision record is for.
What changes for a team
Questions that used to be archaeology become queries. Why is this claim excluded: rule, rationale, ratifier, three clicks. What changed between last month’s numbers and this month’s: an identity diff, not a meeting. Which of our behaviors are still unratified conventions inherited from somebody’s old script: that is a report now. And when the answer moves, you know whether the data moved, a rule moved, or the engine moved, because those are three different lines in the record.
Limits
Three. Human rulings are still the bottleneck, by design: the system marks what needs a decision, it does not make the decision, and the count of open rulings is higher than a demo would suggest. The refusals require organizational patience: an empty column with a flag is better than a fabricated one, but it looks worse in a screenshot, and someone has to defend that trade every time. And none of this removes the need for the domain expert. It concentrates their time on the questions that need them, which is a different thing from needing them less.
The handshake
The clinical-side article closed by publishing an interchange schema for the handoff between AI-derived trial reasoning and clinical operations systems, because that handoff had no standard form. The claims world has the same missing artifact: the decisions layer between a raw healthcare file and an analytic system, the rules, their rationale, their evidence, their ratifier, has no standard form either. That schema deserves a claims-side response in kind, and that is a conversation we would like to have with anyone building on either side of this.
Two regulated domains, two teams, no coordination, same architecture. When that happens, it is usually not a coincidence. It is the shape of the problem.
The clinical-side article that prompted this note is on LinkedIn and worth your time. Murali Rajendran is co-founder and CTO of Ariv Health.