Our uncertainty is a field on the rule set, not a sentence in the copy deck

Munchable tells people with digestive conditions whether a packaged food suits them. The riskiest thing an app like that ships is not a wrong verdict, it is a confident tone, because tone is what decides whether somebody double checks.

Copy drifts optimistic. It drifts gradually, through a hundred small edits where "may help you follow" becomes "helps you follow" because the shorter line fits the card better. Nothing in a normal review process catches that, because each edit is defensible on its own.

So the hedging is not copy. It is a field.

Every rule set is stamped

The engine holds one rule set per condition, and each of them carries this:

/** Metadata stamped on every rule set. */
export interface RuleSetMeta {
  condition: ConditionId;
  version: string;
  sources: string[];
  /** The evidence caveat this condition carries. */
  evidenceCaveat: string;
}

Four fields, one of which is an admission. It is not optional, so a new condition cannot be added without writing one, and it lives next to the rules rather than in a content file, so the person changing a threshold is looking at the sentence that describes how much the threshold is worth.

The most honest object in the repository

Here is the SIBO rule set's metadata, in full:

meta: {
  condition: 'sibo',
  version: '0.1.0-draft',
  sources: ['Mapped to the low FODMAP rule set; no SIBO specific diet evidence base'],
  evidenceCaveat:
    'No specific SIBO diet has strong evidence; low FODMAP is applied as a commonly used approximation.',
},

A product decision is encoded there. SIBO is in the app because people with SIBO are told to change how they eat and then left to work out what that means at the shelf. There is no well evidenced SIBO diet to encode, so the rule set borrows the low FODMAP rules and says so, in a string that ships to users rather than in a comment that ships to developers.

The alternative was leaving SIBO out, which helps nobody, or quietly treating it as IBS, which is the same engineering with a dishonest label on it.

You can read that sentence on the live page: munchable.app/conditions/sibo, under a heading that asks the question in the reader's own words rather than ours.

The heading is "How certain is this?"

Not "Disclaimer". Not "Important information". Each of the seven condition guides has a section with that heading, and it prints three things straight out of the production rule set: the caveat, the version, and the sources.

IBS and low FODMAP:

FODMAP content is serving size dependent and not fully inferable from labels; surfaced as an estimate.

The rule set behind this page is versioned (0.1.0-draft) and cites its basis: Varney et al. 2017 (per-serve FODMAP cutoffs); Monash FODMAP diet (methodology only, no data copied). Every verdict is produced by those fixed rules, never by a language model.

Gastroparesis:

Assessed as packaged; blending or eating with liquids changes tolerability.

And bile acid malabsorption, which is the bluntest of the seven:

Very low certainty; per serving fat thresholds are placeholders an RD must finalize. Where a label gives no fat figure the verdict is inferred from how fat-dense the ingredients are.

The gastroparesis line is a sentence about physics rather than evidence. The engine reads a label, and a label describes a food in the state it was sold in. Somebody who blends their meals has a different product in front of them, and no amount of label reading will know that, so the page says it instead of implying otherwise.

Two details in there that were deliberate. The versions still carry -draft in public, and we did not round them up to 1.0 before launch, because the number is true and a reader who notices it has learned something real about how finished this is. And the last line rules out a language model by name, because "AI powered" is the default assumption now, and for a verdict on food it is the wrong one. Every verdict comes out of fixed rules, which is also why the same scan gives the same answer tomorrow.

Inside the app, the caveat sits next to the claim

A footer disclaimer is a legal artifact. It is read once, by nobody.

So in the app the hedging rides on the findings themselves. A reason can carry an evidenceNote, rendered as a caption directly under the line it qualifies, and a condition can carry a banner for something true of the whole rule set rather than of one ingredient. Expand a flagged condition on a result and the qualification is in the same expansion as the claim, three millimetres away, in the moment where somebody is deciding whether to put the box in the trolley.

The exception proves the shape. The healthy shopping filter, which flags additives and nutrients you would rather avoid, carries no evidence notes at all. It is not making a claim that needs one: it says what is in the product and stops. We wrote about why that filter stays quiet and about keeping a preference from arguing with a verdict. A rule set makes a claim about your body and needs a caveat. A filter makes a claim about an ingredient list and does not.

What this actually prevents

Three things, all of them mundane and all of them things that have gone wrong in products like this.

Copy cannot outrun the engine, because the copy is the engine's own string. A page that wanted to sound more certain would have to edit the rule set to do it, in a diff that sits next to the thresholds, in front of whoever reviews it.

A rule change that outruns its evidence has somewhere to be recorded. Widening a threshold without being able to cite why means editing sources, which is a much harder thing to do carelessly than shipping the threshold alone.

And "how do you know?" has an answer at the point of asking. The public page cites its basis, the ingredient pages underneath it each answer one question by running the engine, and nothing in that chain requires the reader to trust the tone of a landing page.

Read it yourself

The seven guides are at munchable.app/conditions, and the honest ones are the interesting ones: SIBO admitting it is an approximation, bile acid malabsorption and gastroparesis each qualifying what a label can tell you.

Underneath each guide is a list of the ingredients that rule set flags, each one its own page produced by running the engine rather than by writing an answer: is onion low FODMAP, and a few hundred more indexed at munchable.app/answers.

The app itself is at app.munchable.app and the whole onboarding, including the wellness-app framing that sits on the second screen rather than in a settings page, runs before you make an account.