Standard practice for a product blog is to publish the cases where the product worked. We publish the ones where it did not, and I want to argue that this is not humility or transparency theatre — it is the only thing that makes the output usable.
The specific limitation
The tool reads text for structure: which sentences are verifiable claims, which are opinions in factual clothing, which claims lack attribution, what is missing.
Its most significant limitation is input sensitivity. The assessment depends heavily on how much text you provide.
Submit three paragraphs and you get an assessment of three paragraphs. Submit the full article and the reading can change substantially — because context that appeared absent was present later, or because a ratio that looked alarming was an artefact of where the excerpt was cut.
This is not a defect awaiting a fix. Structure is a property of a whole document. A fragment is a different document. Any method that reads structure has this property, and the ones that do not advertise it have it anyway.
Why hiding it would be worse than the limitation
A tool that always produces a confident number teaches its users that confident assessment is available. That lesson is false, and it is more damaging than any individual wrong assessment.
Consider what a user does with a score they cannot calibrate. They either accept it, in which case they have outsourced a judgement to a system whose failure modes they cannot see, or they reject it the first time it disagrees with them, in which case the tool was never doing anything.
Neither user is reading better. Both have replaced their own judgement with a relationship to a black box — acceptance in one case, dismissal in the other.
A user who knows that excerpt length changes the reading does something different: they check the input before trusting the output. That is a transferable skill. It applies to every other analytical tool they will ever use.
The credibility argument
There is also a straightforwardly instrumental case, which I make without embarrassment: stating limitations builds more trust than claiming their absence.
The audience for this kind of tool is people who are already suspicious of confident claims about truth. That is the whole premise — they distrust fact-checkers, they distrust media, and a system that arrives claiming to have solved assessment reads as one more entity making claims.
To that audience, "here is where this fails" is the only credible opening. It demonstrates that the thing was built by someone who looked for failures rather than someone who avoided finding them.
This is the same reason unattributed confidence lowers an article's assessment. A text that acknowledges its own uncertainty is more informative than one that does not, even when the conclusions are identical — because the acknowledgement tells you something about the process that produced them.
Applying that standard to a text and not to the tool that applies it would be incoherent.
What we publish and why
We publish individual analyses at faktoskop.pl, including cases where the assessment is arguable and cases where the method performed poorly.
The most useful of these are the boundary cases: sentences where the classification is genuinely contestable, where a reasonable reader would categorise differently. Those show what the tool is actually doing, in a way that clean cases never do. Clean cases show that a system can handle the parts a reader did not need help with.
We also publish the case that scored 3.5 despite containing no false statements — a promotional article in news format. It scored low on structure and would pass any fact-check. That case argues against verdict-based approaches generally, including any temptation to reduce our own output to a verdict.
The cost, stated honestly
This has a real cost and I would not pretend otherwise.
Some users want a number and reading about input sensitivity is not what they came for. Some proportion of them will use a tool that gives them the number instead. Publishing weak cases gives a competitor material and gives a hostile reader a headline.
I think the trade is correct for this category of product specifically. A tool whose entire proposition is "we show you structure so you can judge for yourself" cannot coherently ask to be accepted on trust. But I would not generalise it to products where the user does not need to calibrate the output — most software should just work, and enumerating its failure modes to users would be noise.
Question for the community
For those shipping tools where users need to calibrate the output rather than simply trust it: where do you put the failure modes?
Documentation gets read by nobody. In-product warnings get dismissed. Blog posts reach people who were already interested. I have not found a placement that reaches the user at the moment the limitation is relevant, which is the only moment it matters.
Top comments (0)