A four-pixel bar filled to 62% is making a claim. The design question is what claim, and whether the system is in any position to make it.
InsightLabyrinth takes raw, unstructured files and turns them into structured business outputs. An invoice, a contract, a scanned report goes in; named fields come out, mapped to a schema something downstream can use.
Extraction is never clean. Some fields are read with near-certainty, some are inferred from context, some are guesses the model is willing to make and a person should not accept. The starting prototype hid all of that behind previews that looked identical regardless of what you uploaded. The work was building an interface that shows the difference.
The Confident Preview: A static preview that renders the same way for a clean PDF and a bad phone photograph teaches the user that the output is always fine.
Extraction Without a Source: A field showing a value and nothing else cannot be checked. The reviewer either trusts it or reopens the original document, and reopening the original is the work the tool was meant to remove.
Uniform Presentation of Uneven Data: Ten fields displayed identically imply ten fields of equal reliability, which is never what actually happened.
One value, four signals
Every extracted field carries a confidence value between 0 and 100. In the interface that single number drives four things at once: an icon, the colour of a bar, the length of that bar, and a numeric percentage.
The reasoning was that different people read a screen differently, and reliability is the thing you least want someone to miss. Colour is caught before anything else. Length is comparable down a column without reading. The icon survives being colour-blind. The number is there for anyone who wants to be exact.
The counter-argument is that four channels for one value is redundancy, and redundancy is noise. A table of ten fields where each row shouts its reliability in four ways may be harder to scan than one that whispers it in a single way. I do not know which of those is true here, and the honest position is that it is a reasoned bet rather than a validated pattern.
The thresholds are the part that deserves scrutiny
The colour scale turns on two numbers. Above 85 the bar is green. Between 60 and 84 it is amber. Below 60 it is red.
Those cutoffs are inventions. They are the numbers that looked right against the sample data during a build that took about a week, and nothing about the underlying extraction model justifies them. A model whose 70% is well calibrated would deserve different boundaries from one that is systematically overconfident, and the interface has no way of knowing which it is sitting on top of.
This matters more than a colour choice normally would, because the threshold is where the design stops describing and starts advising. Green tells a reviewer to move on. Red tells them to stop. Two arbitrary numbers are deciding which fields get human attention, and a badly placed boundary either wastes review time or quietly waves through the errors.
Expanding a row is where the claim gets substantiated
A confidence value on its own is a summary of a judgement. Clicking a field opens the evidence: the snippet of source text the value was read from, the schema field it was mapped to, and where relevant an anomaly note explaining what looked wrong.
That accordion is the part I would defend hardest. Without it, the bar asks for trust. With it, the bar becomes a pointer to something checkable, and a reviewer can disagree with the system using the same evidence the system used. The confidence value stops being a verdict and becomes an index into the document.
The same logic runs through the entity graph, where nodes are drawn from what is actually in the uploaded file rather than from a fixed diagram, and the processing view, which names the phases of extraction rather than showing a spinner. In both cases the intent is that the interface reports on a specific document instead of performing competence in general.
Where it stands
InsightLabyrinth runs at flowify-docs.vercel.app. It was built in roughly a week, which was fast enough to prove the interface and nowhere near long enough to test it. Every confidence value on screen is a fixture rather than a model output.
So the central idea of this piece is also its main untested claim. I believe an extraction tool should show how sure it is and let people check the working. Whether four simultaneous signals help or crowd, and whether 85 and 60 are anywhere near the right lines to draw, needs real documents and a real reviewer. Both are the sort of thing that looks obviously right on a portfolio page and turns out differently in front of somebody doing the job.