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.

The 1000–8000 series is TRG's, not ours. Raw materials, components, labels, formulations, capsules, finished goods, jobs, shipments — the numbering Todd already uses.

Click a manufactured item (4000/5000/6000) to explode its bill of materials. ProBasic Choc (6023) is the real one: a bottle contains 770 capsules, each capsule is a blend plus an empty shell, and the blend is 52 raw materials.

A capsule is its own tier, independently stocked and lotted — not a step inside "make the finished good". Todd called that crucial, and it is why the tree has four levels rather than two.

Read only, deliberately. Editing an item or a formula needs the lot decision (NERPAI-17) and a signing story. This is here to be argued with, not typed into.

A lot cannot be released without a CoA and a named approver — and that is a database trigger, not just this screen. Approving records who released it and when; the DS-prefixed released form (DS26-0001) is a rendering of the internal lot plus the approved state, never a second identifier.

Receiving is an operator action; releasing is QC's. A viewer sees the queue and can do neither — the server enforces the role, this screen only reflects it.

Rejected is terminal. A rejected lot can never be approved, and the material does not enter production.

This is the build sheet, not the run. It scales the blend to your batch size — the same engine, the same maths proven to the gram — and checks it against the lots QC has released. Green means you can weigh it; red means you cannot, and says which ingredient is short.

Only released (DS) lots count. A quarantined or rejected lot is not weighable, so it does not close a shortfall — the same SOP-042 gate as intake, one tier up.

What this does not do yet, on purpose: it commits nothing — no blend lot is minted, no quantity deducted, no BPR generated. That step needs two decisions (does a blend lot carry the job number or its own lot, and the consumption ledger), which are Todd's to make. Until then, “on hand” is the approved received quantity.

A run is a job, and the job number IS the blend lot. Weigh released (DS) lots into it by the exact kilograms taken — a bag is opened, drawn from, resealed and reused on the next job, so each lot carries a running balance. The database refuses weighing a quarantined lot, or more than a lot has left.

Both directions. A run shows the lots that went into its blend; a lot shows the jobs that drew it down. That is the recall spine — raw material to blend, and blend back to raw material.

Next: packaging the blend into capsules and finished goods (the next consumption step), and the BPR document + wiring the run into the audit trail (NERPAI-19).

Stage 2: the intermediate. A capsule run draws a completed blend (4000) through the encapsulator and yields a counted 5000 capsule lot — the job number IS the capsule lot. The blend is drawn by exact kilograms and carries a running balance, the same model as a raw-material lot one tier down. The database refuses drawing an uncompleted blend, or more than a blend produced.

Recall crosses the tier both ways: a capsule lot shows the blend it came from (and thus its raw materials); a blend shows the capsule runs that drew it. Open the Traceability module on any job to walk the whole chain.

Not yet: deducting the empty vegetable capsule shells (a count) — waiting on how they are received/counted at intake (question posted to Todd) — and the packaging tier (5000 → 6000, Stage 3) plus the IMR/BPR document (NERPAI-19).

Stage 3: the finished good. A finished-good run bottles a completed capsule lot (5000) — drawn by the each against the capsule lot's running count — and yields a counted 6000 finished-good lot, the job number being the FG lot. The database refuses bottling an uncompleted capsule lot, or more capsules than the lot produced.

The chain is whole now: raw material → blend → capsule → finished good, every tier its own job/lot and its own consumption ledger, traceable in both directions. Open Traceability on any job to walk it end to end.

Not yet: deducting the packaging components — bottles, lids, labels, neck bands (a count) — on the same NERPAI-41 intake-count question as the capsule shells; and the MMR/IMR/BPR documents (NERPAI-19).

A live snapshot over what's recorded — stock, the QC queue, production, and lots needing attention. Click any receipt or run to open it in Traceability. Numbers come straight from the append-only ledger.

Released is what a batch can be weighed from — received minus everything the ledger has consumed, summed across a lot's approved receipts. Quarantine is received but not yet passed by QC, so it is on hand but not weighable. A rejected lot is not stock at all.

To trace any single lot — where it came from, where it went, its mass balance — open it in Traceability. QR labels and camera scanning at intake are still to come (NERPAI-3).

Recall, both directions. From a raw-material lot: every job that weighed from it. From a job (blend lot): every raw-material lot that went in, with the vendor's lot and CoA. Click any lot or job in the result to pivot to it — that is the recall walk.

The genealogy sits next to the record. Each result carries the audit history of the thing — received, released, weighed, completed, and by whom — read from the append-only chain.

The key flips at the make step: a received lot is a DS lot, a made batch is its job number. The chain today spans raw material ↔ blend, and extends through capsule and finished good as packaging lands.

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.