Skip to content
Ritesh FirodiyaGet in touch

Work / AskCal / Wiki / Surfaces

correct-dish

Surfacecanonicalverified 2026-09-26

SURFACE.MOBILE.SCAN.CORRECT-DISH

Summary

The whole plate is something else.

Raw wireframe

  • .context/designs/mobile/scan/correct-dish.html

Why it is drawn this way

Split out of correct-item. One screen was serving both corrections through a segmented control whose answer the caller had already supplied. Two entry points, two screens, no setting.

It says that every row will be replaced, before the button rather than after it. Naming the dish re-derives the whole plate — four items go away and are replaced by whatever carrot cake is made of. That is the entire value of the correction and also the thing a user would be annoyed to discover afterwards.

The user wins. Their identification is a fact, not a hint to be weighed against the photograph; the server asserts it rather than trusting the model to have complied.

It costs nothing. No image is sent, so it is the same shape of call as /clarify. A correction that spends a scan is a correction nobody makes, and then the log is wrong and the user is out of pocket. See metering.

No look-alike suggestions, and that is a deliberate cut. There is no source for "foods commonly mistaken for this one": generating them is a second billed call to guess at what the model already got wrong, and hard-coding a table is a list that is right for the five dishes somebody thought of and silently absent for everything else.

Related

Departure from the app — one route, two renderings

The two wireframes stay separate files because they draw genuinely different screens: the dish face warns that every row is re-derived, and the item face offers Remove. Neither is a state in the closed set (empty · loading · error · offline · locked), so by the one-screen-per-file rule each keeps its own file and its own node in the chart.

The APP now serves both from a single route. app/scan/correct.tsx takes an optional component param: present names a row, absent means the dish. There is still no control to choose between them — the scope comes from the route, which is what made the original segmented version dangerous and is the part that must never come back.

Recorded here rather than fixed in the wireframes because the JOURNEY is unchanged: the user still taps "wrong dish?" and sees the dish face, or taps a row and sees the item face. The chart is a diagram of what the user does, and what the user does did not change.

Sources

  • .context/designs/mobile/scan/correct-dish.html

Every project of mine is written down like this.

Read the résumé