The register the browser cannot rewrite.

The browser is a read model.

Firestore security rules let clinic members read the register and deny every client write. There is no “save” path in the browser that can change a bottle balance, a log row, or an audit entry.

The only write path is a callable Cloud Function. It checks authentication, membership, the role’s capability, the staff PIN session, a rate limit, and an idempotency key before it loads the affected rows and hands them to the shared business-rule engine. The engine returns the mutated register; only the documents that actually changed are committed.

That architecture is the reason a balance can be trusted: it is computed from the register on the server, not typed into a field on a web page.

Corrections, not erasures.

Rows are never hard-deleted. Voiding an entry writes a reversing correction row and flags the original. The original stays visible in the trail, and the correction explains what changed. This is how a register should handle a mistake — not by making the mistake disappear.

Secrets stay off the client.

PIN hashes, staff sessions, idempotency records, and rate-limit records are denied to browser clients. The client never receives a PIN hash or a session secret; it receives the result of an authorized action.

Your record stays portable.

The register can be filtered and downloaded as a portable record. That matters for two reasons: an inspection may ask for a period, and a clinic should never be trapped in a vendor to read its own history.

Attachments — invoices, Form 222 copies, PMP files, incident evidence — are stored server-side and readable by clinic members. Storage writes also go through the function, not the browser.

What we will tell you if it changes.

If the architecture, subprocessors, or access model changes materially, this page and the privacy policy will be updated before the change is described anywhere else. A security page that quietly goes stale is worse than no page.