Half of this report is not decided by an AI — and we will tell you which half
Here are two sentences from the end of a debt collection call.
"Fine — twelve thousand, I'll pay you as soon as I can."
"Fine — twelve thousand, I'll pay you on the 15th."
In a transcript they look almost identical. Same tone, same agreement, same number. One of them gets collected. The other one is the reason someone calls again in six weeks.
If you ask a language model to read that call and tell you whether a payment date was committed, it will usually be right. Usually. And the times it is wrong, nothing tells you. The report reads exactly as confidently as when it was right.
That is the failure we built around.
The problem with asking a model to count
Most AI training tools work the same way: put the transcript in a prompt, ask the model to produce a report, print what comes back. Every line of that report — the observations, the judgments, and the counts — has the same provenance and the same reliability, which is to say: probably fine, occasionally wrong, never checkable.
Counting is the part where this hurts most, because counting is the part where you can be exactly right or exactly wrong, and where being wrong is invisible. Did they state a figure with a currency attached? Did they commit to a specific date, or to "soon"? Did they say one of the three things legal told them not to say? Those are not matters of interpretation. They either happened or they did not, and a regular expression will tell you correctly one hundred times out of a hundred.
There is no reason to pay a model to count badly what an if statement counts well.
So we split the report in two
Part of a post-session debrief is genuinely judgment. Why did the counterpart harden after turn nine? Was that concession a good trade or a reflex? Which sentence, rewritten, would have changed the trajectory? That work needs a model, and we use one.
The other part is measurement, and it runs in code, over the transcript, with no model involved and no latency added:
- Was a figure with a currency stated at all?
- Was a concrete date committed? "By the 15th" counts. "Soon" does not — deliberately, because that distinction is the whole conversation in a collections call.
- Did they hedge? Counted against a closed, published list of hedging phrases.
- Did they state a number that is not in the figures they declared before the session? The reference is the brief they filled in themselves.
- Did they say one of the phrases they told us they could not say?
Every line of the final report carries which half produced it. Not as a footnote — as a property of the data.
The measurement wins the argument
When the code and the model disagree, the code wins.
We learned to make that explicit the hard way. In an early real report, the code detected "300 euros" in the transcript and marked the price anchor as present. The model, in the same report, listed the missing price anchor among the things that went wrong. Both statements, in the same document, contradicting each other.
Now the measured facts are computed first and handed to the model already counted, with an instruction not to recount them. They are not in its output schema at all — because the day they were, it would return its own version and we would be back to two numbers for one fact.
Where the line is, and why we say it out loud
The interesting part of this design is not what we moved into code. It is what we refused to.
"Did they state as confirmed something that was not confirmed?" is the single most expensive mistake in a crisis conversation — the one that becomes the second news story, which is always worse than the first. We would love to count it. We do not, because counting it requires understanding the sentence, and a keyword detector would get it wrong in both directions: flagging careful statements and missing reckless ones.
So that stays with the model, labelled as judgment.
A weak detector is worse than no detector. It gives you confidence without giving you grounds for it — which is precisely the failure this product exists to fix in the conversations it rehearses. We are not going to reproduce it in the report about them.
The same measurement, read the opposite way
One detail we like, because it only makes sense if you take the arenas seriously.
Hedging — "possibly", "we're looking into it", "I can't confirm that yet" — is measured by one detector. But whether hedging is a defect or a virtue depends entirely on the conversation you are in.
Delivering a dismissal, hedging is the defect. If the employee walks out unsure whether they were fired, warned, or reassured, the conversation failed no matter how kind it felt, and you now have to hold it again with the relationship already damaged.
Facing a journalist, hedging is the correct move. "I can't confirm that yet" is the right answer; the polished, confident sentence about something still unverified is the one that costs you.
Same detector. Opposite reading. Each arena declares which one applies to it, so the report never praises in a press interview what it penalises in an HR conversation.
Why this matters if you are evaluating tools
Every vendor in this category can tell you their synthetic person is psychologically grounded. Increasingly, that is true, and increasingly it does not distinguish anyone — the underlying psychometric frameworks are published and widely used.
Here is a question that does distinguish: which parts of your report were not decided by a language model, and how would I check?
We can answer that with the code open. Most of the tools you are comparing us against cannot, because for them the honest answer is "all of it was, and you cannot."
That is not a claim about being smarter. It is a claim about which parts of a report you should be allowed to verify — and we think the answer is: the parts that are verifiable.