A system says there are twelve units in the network.
Is the product available?
Maybe.
That answer sounds evasive until a customer tries to buy it.
The twelve units may be in the wrong facility. Some may already be allocated. A lot may fail the customer’s shelf-life requirement. The shipping window may have closed. Another commitment may outrank the new request. The inventory record may be twenty minutes old in a market where twenty minutes matters.
The number can be accurate and the promise can still be wrong.
On hand is only one state
Mature companies often compress several different states into one word: available.
A more useful chain looks something like this:
On hand → potentially available → allocatable → committed → fulfillable.
Each transition adds context.
Inventory becomes relevant to a customer only after location, condition, contract rules, timing, existing commitments, operational capacity, and confidence are applied.
That is why a customer-facing product cannot simply expose an internal quantity and call it availability. The product is making a promise. The rest of the Stack has to be capable of keeping it.
The seam between promise and fulfillment
In Product Path, SupplyStar Distribution learns this through a constrained order.
The buying surface showed inventory. The comparison logic considered an alternative viable. The order entered normally. By the time fulfillment reached the line, the remaining quantity could not satisfy the customer’s delivery and usable-life requirements.
No single system had necessarily lied.
One system represented physical inventory. Operations understood allocatable inventory. The order system represented an accepted request. The customer heard a promise.
Those states had been treated as though they were the same thing.
This is the seam between Promise and Fulfillment.
The Promise side tells the customer what is available, what it costs, what can substitute, when it will arrive, and what happens next. Fulfillment has to convert those statements into operational reality.
When the Promise layer becomes more sophisticated than the Fulfillment layer can reliably support, the company becomes fulfillment-constrained.
Time changes the truth
Availability is not a static attribute. It is temporary.
A recommendation that was valid at 10:02 can be wrong at 10:17. Capacity disappears. Inventory is allocated. A cutoff passes. An upstream signal changes. The product itself can age.
That means the useful question is not merely “Is it available?”
It is:
Available to whom, under which rules, for how long, and with what level of confidence?
This is where enterprise product work becomes more than interface design. The experience needs a coherent operating truth underneath it.
Correct rules are not enough
There is another problem. Suppose the recommendation was wrong. Can the company explain why it happened?
Can it show which inputs were current at the moment of decision? Which rules actually ran? Whether an override changed the result? Who had authority to make the change? When the recommendation became a commitment?
If the answer is no, the company does not merely have a data problem. It has an assurance problem.
The customer should not be the monitoring system that discovers reality diverged from the promise.
Good enterprise products therefore need more than accurate data. They need state, timing, commitment, authority, observability, and recovery.
Inventory is a component.
Availability is a capability.
And a customer promise is only as credible as the Stack that can fulfill it.
Adapted from PRODUCT PATH: How to Build What Your Company Isn’t Ready to Build by Alex Vale, published by Interoperability Press. Read Product Path.