An RFID inventory platform for several stores
Across several stores, the quantity in the system and the quantity on the shelf are two different quantities, and how far apart they run has been measured.
Measured in other people's stores, by other people
65% of store-SKU records did not match the physical count. DeHoratius and Raman, Management Science, nearly 370,000 records across 37 stores of one multi-store retailer, 2008. Only 51% of SKUs matched exactly, and the best store still matched 70 to 75%. Kang and Gershwin, MIT Auto-ID Center, 2004.
The stockroom number is an estimate, and the reorder still has to be signed against it. Replenishment, markdowns and promotions all inherit that estimate. This is the work behind a cloud RFID inventory platform for small and mid-size retailers running several stores, and what our own result does not cover.
How a platform like this is put together
1
Tag reads and hardware
Antennas, readers and tags across the sales floor and the stockroom, reporting what they see, which is never everything that is there.
Hands upward
A stream of reads, with no guarantee everything present was seen.
2
Count reconciliation, per location
Between a stream of reads and a number anyone can act on, something must decide what those reads amount to, per location.
Hands upward
A count for one location, carrying the confidence it deserves.
3
SKU and GTIN validation
Smart SKU validation, so that what was read maps to one physical product rather than to one of several competing records for it.
Hands upward
One identifier the ordering layer can safely key on.
4
Automated vendor reordering
Multi-store inventory tracking across locations, ending in an order raised against a vendor without anyone retyping it into a second system.
Hands upward
A purchase order that can leave the building unattended.
These are real boundaries, not diagram furniture. Each layer can be replaced without rewriting the one above it, as long as the fact it hands upward still holds.
Three of those layers are delivered facts about the work: multi-store inventory tracking, smart SKU validation and automated vendor reordering, on a multi-tenant architecture. The reconciliation boundary is stated as what work of this kind requires, because nothing above a count can be trusted further than the count itself. Map the four onto your own POS and vendor systems first.
Jeffery, Garofalakis and Franklin, Adaptive Cleaning for RFID Data Streams, VLDB 2006.
Same study, VLDB 2006.
Same study, VLDB 2006.
Every figure in this band was measured and published by other people. None of it is ours, and none of it describes the estate we worked on.
The distance between in range and reliably readable is geometry, and session choice moves it too. Under Gen2 a tag that has answered sets an inventoried flag and stops answering until that flag decays. For S1 the decay is 0.5 to 5 seconds. For S2, S3 and SL it can run above a minute at room temperature, per the RAIN Alliance System Design Guidelines V2, 2023. So the honest question to put to any vendor is about antenna placement and session flags, not about dashboards.
Negative inference
Nothing reports that an item is missing
Infer absence
Absence is inferred, never reported
An item is never reported missing; it is missing because a read did not happen. A store that drops connectivity mid-count produces no gap in the data. It produces a phantom shortage, and every layer above acts on it.
What the software has to work with A partial count and a real shortage look identical to the software unless the count carries its own confidence.
Re-read, do not replay
Reconcile by re-reading the location
The safe reconciliation is a full re-read of a location rather than a replay of the differences. A re-read is a state you can converge on; a delta stream is operations, and operations cannot be safely replayed. This is our argument, cited to nobody.
The reconciliation, as an operation Re-read the location. Converge on what the location says now.
Trust, then detect
A trustworthy count makes a drop meaningful
Once a location count is trustworthy, an unexplained drop between two reads is a signal instead of noise. Untrustworthy counts make every drop ambiguous, so the safe response is to ignore them and count by hand. Trustworthy counts make the drop worth acting on.
What the signal is made of The difference between two reads of one location, with the confidence of both attached.
That is the whole difficulty, stated plainly. Everything else on a system like this arranges matters so that a count is either trustworthy or openly marked as not trustworthy. Never quietly somewhere in between.
Show data table
| Stage | Share of demand lost to stockouts |
|---|---|
| 0% stock loss | 0.5% |
| 1% stock loss | 17% |
| 2.4% stock loss | 52% |
The 0.5% point is the target the simulation was configured to hold, not an observation.
When loss goes unrecorded, the record stays above the reorder point, so no order is placed. The study calls that freezing of replenishment, and notes it leads to extremely high lost sales. The empty shelf then reads as weak demand and confirms the decision not to order. Buying your way out is expensive. In the same model, accurate records hold that stockout target at a reorder point of 41 units. At 3 percent stock loss it takes at least 145.
Why each layer needs the one beneath it
Dependency, not chronology. None of this is a record of the order the work was done in.
- Reads you can reason about, because a count cannot hold without them
An RFID reader reports a fraction of what is in front of it, so the estate is designed for what it misses.
- A count reconciled per location, because a usable identifier has nothing to attach to without one
A stream of reads is not a number, so something must decide what they amount to and how much confidence it deserves.
- A validated identifier, because a purchase order cannot hold without one
The order has to name one physical product, never one of several catalogue records that all happen to describe it.
- An order raised without a person, because it is the layer with the least room for a wrong count
It is the only layer that spends money on its own, so everything beneath it has to be trustworthy first.
Tenancy belongs in the same argument. Designed in ahead of the second tenant, it makes a new tenant a configuration in any system of this class. In PostgreSQL a table owner is not subject to row-level security unless row security is forced on the table. That is documented and by design, and it is why saying we use row-level security is not on its own an isolation story. What we built runs on a multi-tenant architecture and is deployed across three industries.
Two things this does not establish. We publish no date, no duration and no go-live, so nothing here says how fast any of it happened. And where one layer depends on another, that is what a system of this kind requires, not the order the work was done in.
Show data table
| Item | % of records |
|---|---|
| Duplicate records | 60% |
| Inconsistent case and pack sizes | 10% |
Duplication, not spelling, is the dominant catalogue defect.
Validating a SKU is not spell-checking a field. It is deciding which of several records for the same physical product the reordering layer is allowed to key on. In that same study, fewer than 25 percent of retailer records matched the supplier's own data. An EPC resolves to a GTIN through SGTIN-96 encoding. The GS1 non-reuse rule, General Specifications 4.3.5, makes an identifier a commitment rather than a label. Expect the catalogue to be the surprise on any project of this shape.
What an unattended order needs
Feeds in
Store readers
Tag reads for each location, with the confidence they were read at.
Feeds in
The POS
What left the shelf legitimately, so a sale is not read as a shortage.
Feeds in
The product catalogue
The validated identifier that the outgoing purchase order has to name.
The centre
The reordering layer
It turns a count into a purchase order raised against a vendor. It is the only part of a system of this kind that spends money without anybody touching it.
Sends to
The vendor, over EDI
The purchase order, and the acknowledgement that comes back against it.
Three things are needed before that arrow out is safe, and needed is the verb. A duplicate-suppression story, so a network drop partway through a write cannot raise the same order twice. An acknowledgement worth waiting for: the EDI 855 exists precisely because a sent order is not a placed order. And a human who can still stop it. That last one is our stance rather than a standard. We do not consider fully autonomous reordering finished without a gate a person can hold. The rest of the vocabulary is public. 850 for the order, 855 for the acknowledgement, 856 for the shipment, 810 for the invoice. ORDERS under UN/EDIFACT outside the US.
Atyantik capability corpus, delivered outcomes.
Atyantik capability corpus, delivered outcomes.
Atyantik capability corpus, delivered outcomes.
Every cell in this band is ours, from the deployment we built. No outside measurement appears in it, and none of it may be added to a figure published by anybody else.
Ninety percent fewer inventory audits, at the deployment we built. Continuous reads replaced the walk-the-aisles cycle. Here is exactly what that counts: audit events at that one deployment. It is not an inventory-accuracy figure, it is not a measure of labour hours, and it is not a rate we promise anyone else. One deployment is not a rate anyone can promise. Audits can fall in frequency while the ones that remain absorb work. Nothing about hours follows from the number above, and we do not claim it does.
Show data table
| Item | Hours to count |
|---|---|
| By barcode | 53 hours |
| With RFID | 2 hours |
Independent measurement of what counting the same shelf costs.
That is a measurement of elapsed counting time. Ours is a count of audit events. They are different quantities over different populations, so they are never combined. The published one is useful only for plausibility: independent researchers measured a change of that size in counting effort.
Questions that would otherwise be the first call
Answered as mechanism and as design stance, so they can be checked against any vendor.
What makes items hard to read?
- Metal reflects and detunes, liquid absorbs, and a tight stack means tags shadow each other.
- A design of this kind absorbs that through antenna geometry, placement and session choice.
- It also treats a read that did not happen as missing information rather than as an absent item.
- It cannot be absorbed by software alone, which is why the read environment is a design input and not a support ticket.
Two sites and the cloud disagree about the same location. What resolves it?
- It re-reads the location and converges on what that read says, rather than replaying the difference between two views.
- A stale view loses to a fresh read of the same location.
- A count that could not be completed is marked incomplete, never published as a lower number.
The network drops halfway through a write. What stops a duplicate purchase order?
How are exceptions meant to be handled?
What does adding a tenant require?
What does a system of this kind not do?
When this is the wrong build
Where this fits
Several sites, where a count has to be right because something automated is going to act on it.
Goods that read well, and a supplier or a process that can put a tag on them.
A unit price that carries the cost of a tag comfortably on your own catalogue.
A business ready to change what happens on the shop floor once the count can be trusted.
Where it is the wrong call
One site, where counting on a schedule is genuinely enough, and the money would do more against whatever is actually constraining the operation.
Goods that are mostly metal or liquid, where the read environment fights you and no platform rescues physics that does not clear on its own.
Nobody to apply the tags and no upstream vendor willing to, which leaves everything downstream theoretical until tagging is settled with your suppliers.
Tag cost is a serious fraction of the unit price, and the ratio of cost per tag to price per unit is not comfortable.
Three industries is not every industry, and a platform proven across three is not proof it fits a fourth. If yours is one of the hard ones, walking away is the right call, and we would rather you made it now.
Talk it through against your own estate
One conversation about what you have, and whether this is worth building for it.
Tell us what the estate looks like: how many sites and what the goods are. Then what would have to be true before you would let an order leave without a person.
What gets decided in that conversation is whether this is worth building for you at all. Being told it is not is a normal outcome, and we say so when it is the answer.
- Everything you share stays private.
- No obligation to take it further.