PamaOS

PamaOS began with a shared runtime that made it quick to give modules the same offline and synchronization behavior. As Products, Inventory and Kitchen became more sophisticated, that convenience started hiding domain-specific rules inside a generic engine.

Products became the first deliberate move toward module ownership. Its runtime now owns pending-write replay, its sync contract, permission resolution and reconciliation instead of outsourcing those decisions to a shared black box.

For business data such as stock, optimistic local truth becomes dangerous while connected. Two terminals can both believe the last unit exists. A rejected write can look successful locally. A lost acknowledgement can produce a duplicate if the retry receives a new identity.

The newer PamaOS modules send online writes to the server first, commit canonical results after acceptance, and only queue durable local intent when the device is genuinely offline or loses connectivity mid-write.

Kitchen usage and waste can mutate raw stock, so validation has to complete before stock moves. Duplicate usage lines targeting the same raw stock are aggregated. Insufficient stock rejects the transaction. Deleting a usage event restores the exact quantity that was deducted.

Offline reconnect settlement reconciles temporary IDs to canonical IDs and forces authoritative recovery when queued writes are rejected or conflicted. Ghost rows and rejected local stock projections are not allowed to survive reconnect.

Role permissions and branch scope are enforced in the read projections themselves. Staff Feeding exposed why that matters: branch pricing must be narrowed to the selected authorized branch, and deleted deltas must not accidentally carry fields that bypass redaction.

The RBAC work aligned navigation permissions with the backend data contract so a user cannot gain organization-wide setup or stock visibility just because a screen is hidden.