A finance auditor sits across the table from your operations director and asks a deceptively simple question. The question is whether the company can prove that the 4,820 kilograms of resin shown in the system on the last day of the quarter actually existed and was actually that quantity. The director opens the inventory tool and points at the number. The auditor does not want the number. The auditor wants the chain of evidence behind it. Where did the last receipt come from. What was consumed against which production order. Who authorized the adjustment that lowered the balance by 312 kilograms three weeks earlier. The director scrolls through the screen looking for an answer the system was never built to give. The current quantity is right there, glowing in green, but nothing behind it explains how it got there. This is the moment when an architectural decision made years earlier, probably by a developer the company no longer employs, becomes a material problem for the business. The decision was whether stock is stored or derived.
The Two Models
In a mutable model, stock is a column on a row. There is a record for resin at the central warehouse, and that record contains a number representing how much resin is on hand. When something happens, a receipt, a consumption, a transfer, a cycle count adjustment, the number changes. The previous value is overwritten and gone. Whatever logging the application chooses to write happens around the edges, in audit tables that may or may not be consistent with the actual change, in event streams that may or may not have been listening at the moment, in user activity logs that may capture the action but not the resulting quantity. The number itself is the source of truth, and the number itself has no memory.
In a derived stock architecture, stock is not stored at all in the conventional sense. It is the computed sum of every event that has ever affected it. The data model contains an append-only sequence of movements, each one capturing the item, the location, the delta, the actor, the timestamp, and the source event that triggered it. The current quantity is a derived value, calculated from the ledger. Nothing is overwritten because nothing is mutable. To reduce the resin balance by 312 kilograms, you do not change a number. You append an adjustment movement of negative 312, signed by the person who approved it, referencing the cycle count that revealed the discrepancy. The new balance is derived. The history is intact.
Why the Mutable Field Always Loses
Defenders of the mutable approach often argue that as long as the application writes to an audit log alongside every stock change, the result is functionally equivalent. It is not. The audit log is a side effect. The stock field is the actual state. If the two ever diverge, and they will, the system has no way to reconcile them because the field is authoritative and the log is descriptive. A bug in a transfer endpoint that writes to the stock column without writing to the log creates a permanent gap. A direct database fix during a production incident, performed by an engineer to unblock operations, leaves no trace. A migration that bulk-updates quantities to correct an integration error vanishes the moment it completes. None of these are hypothetical. They happen in every operation that runs long enough.
An event sourced inventory model removes the possibility of divergence by removing the field. There is no separate place where the current quantity lives. There is only the ledger, and the ledger is the system of record. A bug in a transfer endpoint cannot mutate stock without writing a movement, because writing a movement is the only mechanism by which stock changes. A direct database intervention has to take the form of an inserted movement, which is itself visible in the ledger. The architectural constraint forces honesty in a way that policy and process never can. An immutable ledger is not a logging strategy bolted onto a mutable system. It is the system.
The Atomic Guarantee
Derived stock only works if the act of recording a movement and the act of computing the new balance are inseparable. If a movement can be written without a corresponding update to derived state, the system has the same integrity gap as the mutable model. If derived state can be updated without a movement, the same gap reappears in the opposite direction. The two have to happen together or not at all. This is why FalOrb performs every stock change inside an atomic transaction that writes the movement and updates the derived projection in a single commit. There is no window during which the ledger and the available balance are out of sync. There is no path through the code that can change one without the other. If the transaction fails, neither happens. If it succeeds, both happen. The guarantee is structural, not procedural.
This is also why the movement record carries the quantity before and after each event. Recomputing balances from the entire ledger every time someone opens a screen would be too slow at scale, so derived projections are maintained for performance, but the ledger remains the source of truth and the projections can be rebuilt from it at any time. The before and after values inside each movement record give auditors and engineers a way to verify that the projections match the ledger, line by line, without trust. The math has to add up because the math is exposed.
What This Looks Like to an Auditor
When the auditor asks for evidence behind the resin balance, the operations director can hand over a filtered export of every movement against that item at that location for the period in question. Each row carries the date, the actor, the type of movement, the quantity change, the resulting balance, and a reference to the source document. The receipt of 5,000 kilograms on the third of the month traces to a specific purchase order line and a specific receiving event. The consumption of 1,847 kilograms across the next six weeks traces to specific production runs against specific BOM versions. The adjustment of negative 312 kilograms traces to a cycle count document with a manager signature. The auditor reads the rows, ties each one to its source document, and concludes that the balance is supported. The conversation is over in twenty minutes instead of three weeks.
This is the difference an audit trail integrity model makes. The reason a derived stock architecture supports audit readiness is not that it produces nicer reports. It is that the underlying data model makes the reports possible to generate in the first place. We have written before about why a spreadsheet inventory practice fails at scale, and the deeper reason is the same. Spreadsheets are mutable by nature, and the entire history of mutation is lost the moment it happens. Replacing a spreadsheet with a system that has a mutable stock field replaces one untrustworthy data model with a slightly faster untrustworthy data model. The architectural problem persists.
The Compounding Value of an Immutable Ledger
Once you have an immutable ledger as the foundation, every layer above it inherits the same trustworthiness. Available-to-promise calculations become reliable because the inputs are reliable. Material requirements planning becomes deterministic because the on-hand figures it consumes are anchored in real events. Consumption analytics produce honest variance numbers because the consumption side of the equation is captured at the run level, not estimated from before-and-after snapshots. Alerts fire on real conditions because the conditions reflect real state. We have explored the compound benefits of this approach in earlier writing on why every movement matters in an immutable audit ledger, and the pattern holds across every operational capability that depends on knowing what is actually in the building.
The business case for derived stock is rarely framed in architectural terms because the people who feel the pain of the alternative are not the same people who choose the inventory system. The buyer evaluates demos. The auditor lives with the consequences. The operator chases discrepancies that have no traceable origin. The CFO writes off shrinkage that nobody can explain. The engineer hot-fixes a quantity at three in the morning and crosses their fingers that nothing downstream notices. Each of these people is paying the cost of a decision made by someone who never had to absorb it.
Choosing the Honest Architecture
The choice between a mutable stock field and a derived stock architecture is not a preference. It is a commitment about what kind of system you are building. A mutable system optimizes for the simplest possible representation of the present moment and accepts that the past will be lost. A derived system accepts the cost of recording every event and earns, in exchange, the ability to answer any question about how the present came to be. Manufacturing operations that take traceability seriously, whether for regulatory reasons, financial reasons, or operational reasons, cannot afford the first model. The second model is not new, the principles behind event sourced inventory have been understood for decades, but it is still the exception in commercial inventory software because it requires a discipline that most products were not built to enforce. Where it exists, it changes the nature of every conversation about stock from one of belief to one of evidence. That shift, more than any feature on a comparison sheet, is what determines whether a system earns trust or quietly erodes it.
FalOrb is built on a derived stock architecture with an immutable ledger at the core. Every quantity is the sum of every movement, every movement carries its actor and its source. Book a 30-minute walkthrough or email us at [email protected] to see how it applies to your operation.