Yesterday I posed the question of what my app should do when it doesn’t know something. Here’s the rule I wrote down, in one line:
If the app isn’t sure, it says so. It never quietly makes something up.
Why I care: a value an app invents about a person or a business is still information about them, and once it’s saved it looks just like the real thing. A wrong guess doesn’t stay put. It gets read, copied and relied on.
What the rule means in practice:
- A blank beats a guess. If a value can’t be read with confidence, it stays empty or gets marked uncertain.
- Uncertain stays visible. It’s flagged as uncertain, not blended in with the confirmed values.
- A person can correct it. Fixing an uncertain value is part of the normal flow, not a back-door chore.
- Nothing important runs on a guess. Anything that matters waits until a person has confirmed the value.
A written rule isn’t proof. I only count a safeguard as real once I’ve tested it, and I’m still testing whether this one holds when the input is messy. So this is what I’m building to, not a claim that it’s finished.
Here’s a ten-minute action. Pick one field in your app that can end up blank or unclear. Find out what actually happens when it does: does it stay blank, get flagged, or get filled in? Write down the answer. That’s your starting point.
Next week: nobody mapped how it actually works, and the check I run to find out.
This is general information, not legal advice.
Leave a Reply