The Missing Field Is a Button
A field on a screen tells you one of two things: here's a value, or here's nothing. Everything else about that value, how sure anyone is it's correct, whether the blank next to it could be fixed by the person looking at it, gets thrown out before it reaches the screen.
Split any data field along two axes, whether the value exists and whether it can be trusted, and four states fall out, not two. A value can be present and verified. It can be present and only half-verified, scraped from somewhere, aggregated, self-reported, stale. It can be absent because nobody has it and never will. Or it can be absent because the person looking at the screen happens to have it in their head and nobody ever asked.
Interfaces render the first two states identically and the second two states identically. A number that came from a checked source and a number that came from a scraper both show up in the same font, no asterisk. An empty field with no possible answer and an empty field the viewer could fill in thirty seconds both show up as the same gray dash. The rendering pipeline only ever checks one thing: does the variable hold a value. Everything downstream inherits that one branch.
That's a schema problem before it's a design problem. Most fields are typed as a string or null, with no third property recording where the string came from or how sure anyone was when they wrote it. Confidence and fixability get dropped at ingestion, the moment the data is gathered, and nothing later in the pipeline can put back what was never captured. By the time a value reaches a screen, there's only the value and its absence to render, because that's all the schema kept.
The fix for the first collapse doesn't need a disclaimer footer nobody reads. It needs the label at the field itself to carry the confidence, not just the value. "Private" and "likely private" cost the same number of characters to render; the difference is a lookup on where the claim came from and a second string somewhere in the code. Skipping that lookup grants borrowed data silent parity with checked data, a guess and a fact sitting in identical type where nobody downstream can tell which is which.
The fix for the second collapse is stranger, because it means treating some blanks as bait. A missing phone number a visitor might actually know is not the same kind of missing as a field with no possible source, ever. One is a dead blank, permanently empty, nothing to do about it. The other only looks dead, and rendering it as a gray dash throws away the one moment someone holding the missing piece was standing right there, looking at a hole shaped exactly like their answer.
None of this is expensive to build. A confidence tag on a value and a click handler on a blank are both small. Neither ships by default because "has a value" and "has no value" are the only two branches most systems actually check, and every other property of the data gets funneled through whichever branch is nearest instead of getting one of its own.
The two collapses don't cost the same people the same thing. A flat claim rendered as fact costs whoever trusts it and turns out wrong. A dead-looking blank that was actually fillable costs whoever had the answer and was never asked for it. Different failures, same missing state underneath both, the seat uncertainty should have had and instead got folded into whichever box was already sitting there.
A blank isn't neutral. Somebody decided it wasn't worth asking about, whether they meant to or not.