Tare-Verified Weighing

Tare-verified weighing is the contract that every regulated weighment — dispense charge, IPC sample, retain sample, gross-yield reading, scrap reconciliation, finished-unit fill check — captures and proves three values, not one: tare (the balance reading with the empty container in place), gross (the reading with the material added), and net (gross − tare). The 'verified' qualifier means each value carries its own audit-trail event with timestamp, operator, balance ID, container ID, and a stability + drift check around the tare event itself. A bare 'net 12.450 kg' on a BMR line is not a tare-verified weighment; it is a number a regulator cannot reconstruct.

The discipline is older than computerised balances — every paper batch record in the world has a 'tare / gross / net' triplet column — but the failure modes have evolved. Modern balances autotare in milliseconds, send three readings per second over RS-232 / USB / Ethernet, and the kiosk has to decide which reading is the tare, when it was captured, and whether the container that was zeroed is still the container on the pan when the operator presses 'Capture'. Drift between the tare event and the gross event is the silent killer: a balance that drifts 0.005 g per minute will read 0.150 g high on a 30-minute charge, which is fine on a 12 kg dispense but catastrophic on a 0.500 g potent-API micro-charge.

The single most common tare failure is container substitution: an operator zeros container A, places container A on the pan, dispenses into it, then realises container A is the wrong size and swaps to container B without re-taring. Net becomes gross_B − tare_A, which is wrong by exactly (tare_B − tare_A). A 1.230 kg tare-A swapped for a 1.250 kg tare-B silently over-charges by 20 g. On a potent API at 1% w/w that is a 200% relative error and a guaranteed OOS.

• Every container in a regulated workspace has a unique scannable ID (barcode / QR / RFID). The kiosk binds the tare event to that ID at capture time.
• A re-tare is required — and enforced as a hard block, not a soft warning — any time the container ID changes, the lid is removed and replaced (open-and-close cycle), or the operator session is interrupted (logout, idle timeout, shift change).
• Reusable containers carry a 'last verified tare' value, but the kiosk does not trust it across sessions — a fresh tare event is always captured on the actual balance the actual charge will use, because temperature, humidity, residue, and gasket-state can shift the empty mass enough to matter.
• Disposable single-use containers (weigh boats, paper-lined trays) get a tare event each time; their nominal mass is recorded only as a sanity-check against gross outlier detection.

A balance is not 'stable' the moment the reading on the display stops moving — analytical balances have an internal averaging window and the displayed value is already a smoothed projection. 'Stable' means the variation between readings is inside the readability (d) of the balance for a defined dwell time, captured from the live data feed not the display. USP <1251> and OIML R 76 both treat dwell-time as an OQ-defined parameter per balance: ≥3 s for analytical balances in laminar-flow rooms, ≥10 s for top-pan balances in production areas, longer in environments with airflow or vibration.

Drift envelope is the second half of the contract — what change between pre-tare zero, tare, and post-tare zero is acceptable. The envelope is balance-specific (defined at OQ) and weighment-specific (a 5 mg envelope on a 12 kg dispense is meaningless; a 5 mg envelope on a 0.500 g micro-charge is the entire charge). V5 enforces drift relative to the weighment, not just the balance: drift > max(d × 3, charge × 0.001) invalidates the weighment.

Every tare event must carry a 'calibration valid until' value. A balance whose external calibration has expired cannot produce a defensible tare regardless of how clean the zero check looked. V5 reads the calibration-valid-until from the balance qualification record (IQ/OQ/PQ closure → calibration cadence) and blocks weighments past that window with a hard stop, not a soft warning. The block is balance-specific not operator-specific — an operator with admin rights cannot override an out-of-cal balance, because the §211.68 audit-trail event would record an out-of-cal weighment that the §211.192 reviewer would have to investigate.

• External calibration (traceable to NIST / national metrology institute) is the primary validity window — typical cadence 6-12 months depending on use intensity + accuracy class.
• Internal calibration (autocal with the balance's built-in reference mass) is a daily / per-shift drift check — it does not extend the external calibration window, but it gates whether the balance is fit-for-use today.
• Eccentricity check (corner load) and linearity check (multiple load points across the operating range) are typically weekly or per-shift depending on USP <41>-based PQ. A failed check immediately invalidates the balance until requalification.
• Out-of-cal escalation is automatic: the balance row goes red on the kiosk + the Quality dashboard + the maintenance queue; any in-flight weighment on that balance is rolled back; pending dispenses are redirected to an alternate qualified balance.

A defensible regulated weighment is not 'press tare, add material, press net'. It is a structured event sequence — captured on the BMR line, in the audit trail, and on the data warehouse for downstream review:

1. Operator scan: kiosk records operator_id, current training-status (block if expired training docs on this SOP), session_id.
2. Balance selection: operator scans balance_id; kiosk fetches calibration_valid_until, current_cal_state, last_internal_autocal, last_external_cal; hard block if any gate fails.
3. Min-weight + max-load gate: kiosk checks the target charge against the balance's min-weight (USP <41>) + max-load; rejects unfit balances before the operator wastes a tare.
4. Container scan: kiosk records container_id, container_tare_class, last_known_tare (sanity-check only — never used as the actual tare value).
5. Pre-tare zero check: balance must read 0 ± d for the stability dwell; the live data feed (not the display) is what's checked.
6. Tare capture: balance reading written as tare_value with a UTC timestamp; container_id + balance_id + operator_id + calibration_valid_until + session_id all bound to this event.
7. Material addition: operator dispenses; kiosk shows live progress against the target with the min-weight floor + tolerance band visible.
8. Stability dwell on gross: balance reading must be stable inside d for the dwell time before the operator can capture.
9. Gross capture: written as gross_value with its own UTC timestamp; container removed from pan.
10. Post-tare drift check: balance must return to 0 ± drift_envelope (computed against weighment + balance class); fail invalidates the weighment and opens a re-weigh.
11. Net calculation: net = gross − tare; tolerance check fired against the §211.101 charge target; in/out of tolerance routed accordingly.
12. E-sig: operator signs the weighment (Part 11 e-sig with full four-element manifestation); witness sign-off required for critical charges (typically actives + master-data flagged 'two-person-required').
13. Audit-trail write: the complete event chain is committed as an atomic transaction; partial chains are rolled back; no orphan tare events.

1. Container substitution — operator zeros container A, swaps to container B without re-taring; net is gross_B − tare_A; can over- or under-charge by tens to hundreds of grams; binding container_id to the tare event is the only structural defence.
2. Stale tare across sessions — kiosk re-uses last session's tare value when the same container is scanned again next morning; thermal drift, residual material, gasket creep all shift the empty mass; fresh tare per session is mandatory.
3. Display-only stability — operator sees the display stop moving and presses capture; the balance was still settling internally; the live data feed (not the display) is what the kiosk must check for stability.
4. No post-tare drift check — kiosk captures tare and gross but never re-checks zero; a 30-minute charge with 0.005 g/min drift produces a 0.150 g overcharge that nobody catches.
5. Out-of-cal weighment — internal autocal looks fine but external calibration has lapsed; the §211.192 reviewer surfaces the calibration_valid_until violation; every weighment in the lapsed window comes under investigation.
6. Open-and-close cycle without re-tare — operator removes the lid mid-charge to add powder, replaces the lid, continues; tare changes (lid residue, condensation, static); without a forced re-tare the net is wrong by the lid-state delta.
7. Operator-bypass via 'manual entry' — kiosk allows an operator to type a tare or net value when the balance is offline; this defeats the entire chain; the only acceptable manual path is a deviation-gated re-weigh on a qualified backup balance, never typed entry.
8. Cross-balance net — gross captured on one balance, tare captured on another; even if both balances are in-cal the readability + tare-class are different; net is meaningless; same-balance binding on the tare event is mandatory.

• Five-event completeness % — fraction of weighments with all five events (pre-zero, tare, stability, gross, post-drift) captured; target 100% (any miss is an audit-trail gap).
• Container-binding integrity % — fraction of weighments where container_id at tare = container_id at gross; target 100% (a structural DB constraint).
• Stability-dwell-met % — fraction of tare and gross events where the live data feed met the dwell-time stability criterion before capture; target ≥99% (sub-99 indicates training / environmental issue).
• Post-tare drift breach rate — fraction of weighments where post-tare zero exceeded the envelope; target ≤0.5% (drift is normal noise; chronic high-rate is a balance-PQ issue or environmental issue).
• Out-of-cal block rate — count of attempted weighments on balances past their external calibration window; target 0 (any non-zero is a scheduling gap in calibration management).
• Re-tare event rate per dispense — average count of forced re-tares per dispense weighment; tracked as a process-health signal (high rate = chronic interruption; low rate = clean execution).
• Manual-entry bypass attempts (count per quarter) — kiosk records every attempted manual tare / net entry; target 0; non-zero requires an investigation into operator training + procedural compliance.
• Retain-sample re-weigh delta — for a sample of dispenses each quarter, retain samples are re-weighed on a qualified analytical balance; delta from BMR-recorded net is trended; sustained drift indicates a balance + tare-discipline gap upstream.

1. Balance integration is first-class: every qualified balance is registered in a balance master with class (micro / analytical / top-pan / bench / floor), readability d, max load, calibration_valid_until, last_internal_autocal, dwell_seconds, drift_envelope_per_minute, and the SOP that governs it. The kiosk reads live values via a dedicated balance bridge (RS-232 / USB / Ethernet / OPC-UA) and never trusts the display.
2. Weighment widget is a structured state machine: operator scan → balance scan → min-weight + max-load gate → container scan → pre-tare zero check → tare capture → material add → stability dwell on gross → gross capture → post-tare drift check → net calc + tolerance check → e-sig → atomic audit-trail commit. No state can be skipped; partial chains are rolled back.
3. Container master ties every reusable container to a barcode + tare-class + last-known-tare; the last-known-tare is a sanity-check only — the actual tare is always captured fresh on the balance the charge will use.
4. Calibration gate is RLS-backed: weighments on a balance whose calibration_valid_until is in the past are refused at the database layer, not just the UI; service-role-key writes are not exempt; the maintenance queue surfaces approaching expirations 30 / 14 / 7 days out.
5. Stability dwell + drift envelope are balance-class defaults overlaid with per-balance OQ values; deviations from the default require change-control approval, not a config-flag toggle.
6. Two-person witness sign-off is automatic for any material flagged 'requires-witness' in the material master (typically all actives + any high-potency excipient) per 21 CFR 211.101(c); the witness e-sig is distinct-user-enforced at the DB level.
7. Cross-balance prohibition is enforced: the gross event is rejected if balance_id does not match the tare event's balance_id; an attempted cross-balance weighment opens an immediate deviation.
8. Open-and-close re-tare: any lid-removal event reported by a sensor-equipped container (or any session-interruption / idle-timeout) fires a forced re-tare prompt; the operator cannot capture a gross until the new tare is captured.
9. Manual entry is not exposed in the kiosk; the only path past a failed balance is a deviation-gated re-weigh on a qualified backup balance, fully audit-trailed, with QA approval to redirect the dispense.
10. Retain-sample re-weigh program: every quarter, V5 surfaces a random sample of dispenses for retain-sample re-weigh on the QC analytical balance; deltas are computed against the BMR net + trended on the Quality dashboard; sustained drift triggers a focused investigation into the originating balance + operator + product.