An app tells you to eat 1,650 calories a day. Where did that number come from? In most apps, you can't find out. The number is on the screen, and you are expected to trust it.
We think that is the wrong default for AI products. If a product shows a person a number, a score, or a claim, the person should be able to see where it came from. This post shows how three of our products do that, with the real code and rules behind them.
AI that shows its work starts with one rule
The rule is simple: no output without its source. Every product we ship has to answer the question "why this?" on the screen, not in a support email.
The rule costs us time. It adds screens, tests, and storage. But it changes how we build. If we can't explain a number to the user, we don't show the number.
Nourished by Mira puts the formula on the screen
Nourished by Mira sets daily calorie and protein targets for people on GLP-1 medications. A calorie target that is too low is a real risk for these users. The medication already cuts appetite, and a large deficit on top of that can cost muscle.
So the app does not use a fixed default. It uses published equations. When the user has a measured lean mass reading, it uses Katch-McArdle. When it doesn't, it uses Mifflin-St Jeor. This is the code:
/// Katch-McArdle: RMR = 370 + (21.6 x lean body mass in kg).
370 + 21.6 * (max(0, leanMassLbs) * lbsPerKg)
/// Mifflin-St Jeor. The sex constant is +5 for male and -161 for female.
let base = 10 * kg + 6.25 * cm - 5 * Double(max(0, age))
Then the app applies a floor. This line makes sure that no user is told to eat less than their body burns at rest:
var value = max(target, resting)
The comment above it in our code says it is "the single most important line in this file." We agree.
The user sees all of this in Settings, step by step: resting burn, maintenance, the adjustment, and the final target. The explanation is generated from the same result the app stores. If the math changes and the explanation does not, our tests fail. If the app doesn't have enough data, it doesn't guess. It shows "Not yet calculated" and tells the user which detail to add.
Motium links every score to a moment in the interview
Motium runs live AI video interviews for hiring teams. A hiring score has real effects on real people, so this is where the rule matters most.
Each report scores six pillars on a scale of 1 to 5. There is no overall score. Each pillar links to the moment in the recording that the score is based on, and the full transcript is part of the report. A reviewer can play the clip and decide if they agree.
Two more rules apply:
- Insufficient evidence is not a low score. If the interview did not test a pillar fairly, Motium flags it. It does not mark the candidate down.
- A person makes every decision. The hiring team advances or declines each candidate and records a reason.
Under the report, each interview has a signed record. Every turn, every tool call, and the end of the call is signed with Ed25519 and chained to the record before it. If someone changes one record, the chain breaks. The candidate's own words are not stored in the chain. The chain stores a salted BLAKE3 digest, and the text stays in a separate store that can be erased. A deletion request erases the text, and the signatures stay valid.
Caelia traces every line of the script to the product page
Caelia turns a product link into a video ad. An AI that writes ad copy can easily invent a claim. A false claim in an ad is a problem for the brand that runs it.
So Caelia reads the product page first. It writes the script, then checks each claim against the page before anything renders. Each claim in the script is shown with the line on the product page that it came from. You can read the source before you approve the script.
What showing the work does not fix
This approach has limits, and we want to be clear about them.
- A visible formula can still be the wrong formula for you. Mifflin-St Jeor is an estimate built from population data. Mira shows the equation so that you and your doctor can question it. Your doctor knows things the app does not.
- A linked clip shows the evidence. It does not prove the score is fair. That is why a person makes the decision in Motium, and why weak evidence gets a flag instead of a low score.
- A source line proves the claim is on the product page. It does not prove the product page is true. The brand is still responsible for its own page.
- It is slower to build. Every number needs an explanation screen, and every explanation needs a test that keeps it matched to the math.
We accept that cost. An AI product that can't explain itself asks for trust it has not earned.
Check it yourself
You don't have to take our word for any of this.
- In Nourished by Mira, open Settings and look at how your targets were calculated.
- On motium.io, try a sample interview and see what a candidate sees.
- The signed records in Motium use Project AIR, an open-source SDK from our medical sister company, Vindicara. It needs Python 3.10 or later. Install it and run the demo:
pip install projectair
air demo
The demo records a simulated AI agent attack, signs every step, then changes one byte in the record. Verification fails at the exact record that changed. It runs on your own machine in under 30 seconds. That is the standard we want for every AI product: you can check the work yourself.
Read why we build what we build in Building for the overlooked, or see all of our products.