A conventional inventory form tends to overwrite yesterday's value with today's. That works until someone asks why an item is marked missing, when its quantity changed, or whether a new expiration rule would have produced a better decision. The Inventory System keeps an append-only asset_events ledger so those questions can be answered from the history of actions rather than inferred from the latest row.

The architecture then derives operational views from that ledger. asset_state holds the current reconciled projection needed by scans, queues, and the browser UI. asset_state_history preserves prior projection versions for audit and experimentation. Read-oriented surfaces—action queues, exports, state comparisons, and the UI—form a final layer optimized for decisions rather than raw storage.

Projection happens synchronously when an event is written. That keeps a label scan or quick action immediately useful while preserving the ability to replay events later. Administrative tools can compare stored state with a fresh replay or rebuild projections from the ledger, which makes future changes to expiration, confidence, and queue logic safer to evaluate.

Idempotency protects that model at the interaction boundary. Quick-action forms and API writes can carry idempotency keys, preventing an accidental double-submit from becoming two ledger events. The result is a system that remains approachable at the shelf while retaining the auditability expected from a much more formal data platform.