This is TRG's real formula, scaled by the engine. The “Excel” columns are what the spreadsheet says. Change the unit count and watch the batch scale — fill weight and capsule count don't move, because they're properties of the recipe, not the batch.

Look at the % sum. Ours is exactly 1; the spreadsheet's is 0.999999999958937 — Excel just displays “1”. That's why we store grams and derive the percentage, never the reverse.

Capsules per serving = fill weight ÷ capsule capacity, rounded up. 40.0001022 ÷ 0.74 = 54.05 → 55. Rounding down would ship a serving under its label claim.

This is the only screen that crosses tenant boundaries — which makes it the one place a bug could show one manufacturer another's formulations. So it's read-mostly, it shows counts rather than contents, and every grant is written into that tenant's own audit chain.

That last part is the point. When a customer asks “can you see our formulations?”, “we wouldn't do that” is worthless. “Yes — and it's in your audit trail, which you can read, and which we cannot alter” is a real answer, and it's only true because of this.

A platform admin is not a tenant admin. Todd is admin on TRG — he runs it, and he must never see Acme. This screen is a separate identity check, not a role flag, so the two can't drift into each other.

A grant requires a reason. An admin write is audited harder than a user's — who, what, and why.

Try the red button. It runs UPDATE audit_entries… as the database owner — the most privileged role there is. Postgres refuses: a trigger binds every role, so history cannot be rewritten even with full database access. The hash chain proves a tamper; this prevents one.

“UPDATE with no reason” is refused — §11.10(e) says a changed record must say why, enforced in code and as a database constraint.

Switch tenants (top right): same page, same code, different data. Postgres row-level security enforces it — a query that forgot its WHERE clause still cannot leak.