Unknown is not zero.
An information architecture case study: how one rule about a missing value had to survive search, meal logging, AI, reports and VoiceOver.
Read the companion studyThe story begins with a zero
A missing value kept becoming zero. That sounds like a small data problem. In Low Ox Life, it could change a health decision.
Zero does not mean “we do not know.” Zero means the food was tested and no oxalate was found. An untested food is different: its value could be low, moderate or high, and the product cannot honestly say.
When those states collapse, uncertainty disappears. The interface looks cleaner while the information becomes less trustworthy.
This was not one formatting bug. The same mistake could travel through search, meal logging, daily totals, AI insights, reports and sharing. The design problem was larger than a question mark: we needed one meaning for “unknown” across the entire system.
The problem people bring
People use Low Ox Life to make everyday food choices. They also use it to notice patterns, and to discuss those patterns with clinicians. They need practical answers:
- How much oxalate have I logged today?
- Is this food within the range I am looking for?
- Which days should I compare?
- Can I trust this summary?
- What does this report actually prove?
An untested food complicates every answer. Imagine a meal with two foods: one contributes 12 milligrams, and the other has no tested figure. The meal does not total 12 milligrams. It contains at least 12 milligrams.
If nothing in the meal has a known figure, “at least zero” is technically true, and useless. The honest answer is a question mark. Nobody should need to understand database sentinels to get it right; the experience has to keep the distinction for them.
Three states, never two
We defined three information states. The third cannot borrow the presentation of either of the other two.
| State | Meaning | What the person sees |
|---|---|---|
| Tested, above zero | A source provides a known figure | The measured figure |
| Tested zero | A source provides a real zero | 0 mg |
| Untested or unknown | No defensible figure exists | ?, “untested”, or a qualified floor |
Unknown is never zero. A subtotal that excludes unknown values is a floor, never a complete total.
That rule became the information contract. Parts of the app’s older storage still hold a -1 for an untested food; the domain logic turns it into an unknown state, so no screen ever asks a person to interpret -1. Each surface uses language suited to the decision being made.
One rule, many interfaces
The architecture shows when the rule crosses a boundary.
Food discovery
A person can filter foods by a maximum oxalate value. An unknown value cannot pass that filter: it would present an unverified food as meeting a safety-related condition.
Untested foods stay findable through an explicit Unknown level. They never quietly rank among the lowest choices.
Meal recognition and review
Recognition can identify a likely food and amount. It cannot invent an oxalate figure, so a food it can’t match to the catalogue stays untested, and the review sums only known figures.
- 12 mg + 8 mg reads 20 mg.
- 12 mg + one untested food reads at least 12 mg.
- Two untested foods read ? mg.
AI confidence never becomes nutritional certainty.
The daily view
Daily totals follow the same rule. A complete day shows an exact total; a partial day shows a floor or an unknown state.
The app also names the missing evidence, “1 food untested” or “3 foods untested”, which gives the person a next step: review the food instead of trusting a false total.
AI-generated insights
Oscar, the app’s assistant, can explain patterns, but it does not calculate them. The app computes known totals, complete days, partial days and averages first, and hands untested values over as untested, never zero.
The model is told never to call an untested food low or safe, never to present a partial total as complete, and to say “at least” while unknowns remain. The model owns the wording. The system owns the math.
Reports for clinician visits
A precise-looking average can travel farther than the screen that produced it. So partial days are listed, but left out of every average, median, high, low, comparison and trend; including them would undercount intake every time.
The report states its denominator: how many days were tracked, and how many were fully tested.
Accessibility
A visual question mark is not enough. VoiceOver has to say “not tested”, and a floor has to be spoken as “at least”, never as an exact number.
That requirement belongs to the contract, not to a label added at the end. Everyone deserves the same uncertainty.
Sources and sharing
An untested value cannot claim a source. A shared food card credits a source only for a stated figure, so a published number and a person’s own entry never look alike.
The number, its state and its source travel together as one claim.
The artifact behind the screens
The central artifact is not a mockup. It is a state and wording model: what each state means, which calculations it may enter, and how each surface expresses it.
| Context | Complete | Partial | No known figure |
|---|---|---|---|
| Food value | 12 mg | Not applicable | ? or “untested” |
| Meal total | 20 mg | at least 12 mg | ? mg |
| Daily total | Exact total | Qualified floor | Unknown |
| Maximum-value filter | Eligible by value | Ineligible | Ineligible |
| Average or trend | Included | Excluded | Excluded |
| AI insight | May state the exact figure | Must qualify the floor | Must name the uncertainty |
| VoiceOver | Speaks the figure | Speaks “at least” | Speaks “not tested” |
| Source credit | Names the source | Names known sources only | Claims no testing source |
It gives design, engineering, content, AI, reporting and quality assurance the same contract, and every surface in the product becomes a test of it.
What the architect designed
The work was not limited to the visible interface. The architecture connected:
- the person’s need for an honest answer
- the meaning stored in the data
- the calculations that meaning permits
- the language shown and spoken
- the boundaries placed around AI
- the evidence allowed into reports
- the source attached to each claim
- the tests that protect the rule over time
That is the difference between designing a screen and designing an intelligent experience in operation.
The screen may show a question mark. The system must earn it.
The trade-off
Preserving uncertainty makes the product less tidy. Some totals need qualifiers. Some averages use fewer days. Some foods cannot appear in a “lowest” result. Some AI answers must admit the evidence is incomplete.
Those outcomes can feel less satisfying than a single confident number. They are also more honest.
The product chooses trustworthy incompleteness over false precision.
How the decision is verified
The production code expresses the rule across the experience:
- Unmatched meal items remain untested.
- Known meal subtotals become floors.
- Search bounds reject unknown values.
- AI summaries treat missing and sentinel values as unknown.
- Partial days are left out of averages and trends.
- Reports disclose their completeness rules.
- Product guidance says a question mark means untested, not zero.
Code and automated tests can verify consistent behavior. They cannot prove that every person understands the language; that takes usability and accessibility research. The questions we want answered:
- Can people explain the difference between 0 mg and a question mark?
- Do they read “at least 12 mg” as a minimum?
- Can they tell why a day was left out of an average?
- Does spoken output carry the same meaning as the screen?
- Do clinicians understand the report’s completeness statement?
The architecture is implemented. Comprehension remains a measured outcome.
What this case teaches
The original problem looked like a default value. The real problem was a meaning moving through a system.
Fixing one label would not have fixed search. Fixing search would not have fixed AI. Fixing AI would not have fixed the report. The work needed one decision to survive every handoff, which makes this an information architecture case study, and an AI experience architecture one too.
The AI could only behave responsibly after the system defined what it was allowed to know, calculate and say.
Unknown is not zero. That sentence became a product rule, a data rule, a language rule and a trust rule.
Want this kind of care on your back office?
The same rules apply to your setup: AI prepares the work, and you decide what counts.