One thesis: capture and answer are different products, and the entire commercial scanning market sells only the first one. If your proposals treat a scan SDK as "the barcode part, handled," you are shipping deployments without a data layer — and the omission surfaces at commissioning, at the exact moment it is most expensive to fix.
If you write bids for scanning and RFID deployments, you have felt the shape of this without a name for it. The capture line items are easy: readers, SDK seats, mounting, middleware hours. Then the client's operations lead asks what happens when a code scans that isn't in their item master — a supplier substitution, a case-level GTIN nobody loaded, a serialized 2D mark from a vendor who moved early — and there is no line item for that. The SDK decoded it perfectly. Nobody bought an answer.
What SDK pricing actually buys
The commercial capture tier is genuinely good at what it sells. What money buys above open-source decoding is the last stretch of decode rate on hostile images — blur, glare, damage, distance, low light — plus multi-code AR workflows and device-fleet support. Those are real capabilities with real prices, and for a warehouse fleet scanning at arm's length all day they are worth paying for.
But look at where the flagship capture vendor's own product line points. Scandit sells Smart Data Capture SDKs and, since January 2022, ShelfView — fixed cameras and shelf analytics for retailers. ShelfView's insights derive from the retailer's own shelf imagery. That is the tell for the whole category: even the most sophisticated capture vendor generates intelligence from what its cameras see, not from a canonical registry of what the codes mean. A scan-SDK customer still needs someone else's data to answer "what is this product?" — the vendor's own architecture assumes it.
Stated plainly and fairly: the capture vendors are adjacencies, not adversaries. They own the photon-to-payload problem and own it well. The payload-to-fact problem was never their product. The trouble is only that proposals routinely assume it was.
The commissioning-day question
Every deployment has the same moment. The readers work. The payloads flow. And then a payload arrives that the client's systems cannot interpret, and the question lands on your engineer: what is this, is it real, whose is it? The SDK's job ended three milliseconds ago. What the deployment needs at that moment is:
- deterministic classification — which scheme, which check-digit verdict, from a pinned table, not a heuristic;
- licensed data — attributes the client may actually store, under terms someone can name;
- provenance on every value — because the client's QA and compliance teams will ask where an answer came from, and "the API said so" is not an answer that survives an audit.
None of that is capture. All of it is the answer layer, and it has been genuinely unavailable as a first-party product since the incumbent's exit — the history is in the previous post in this arc.
The SOW diff
Here is the practical artifact this post exists to hand you: the difference between a scope of work with and without an answer layer, stated the way a bid states it.
Without:
Contractor shall supply and commission barcode/RFID capture hardware and SDK integration. Decoded payloads shall be delivered to Client middleware. Interpretation of payload contents is the responsibility of Client systems.
That last sentence is where the account leaks. "Client systems" cannot interpret a GS1-128 AI stream they have never seen, and when that surfaces post-go-live, the vendor who can interpret it inherits the relationship.
With:
Decoded payloads shall be resolved to canonical identities (scheme, identifier, parsed application identifiers) against pinned, versioned registry data, with check-digit and structural validation results recorded per scan. Where enrichment is in scope, all attributes shall carry per-attribute source, license class, and dataset-version provenance suitable for Client audit. Payload classifications and validation rules shall be documented and citable to their normative sources.
Notice what that paragraph is. It is not a promise to build software — the resolution layer exists as a dependency, the way the SDK does. It is a defensible statement your proposal can make and your commissioning report can prove, which is precisely the deliverable a bid lead needs: a documentation need, not a software need. You attach the layer; you do not maintain it; the conformance language survives the client's diligence because every claim in it is checkable against pinned artifacts.
What an answer layer must be, to be worth naming in a bid
Four requirements, each of which disqualifies most of what a search for "barcode API" returns:
- Deterministic. Same payload, same answer, forever — classification from pinned registry data with published digests, so two sites commissioned a year apart agree.
- Licensed. Attributes from rails whose terms permit what the client will actually do with them — storage, display, redistribution are different rights, and the API must know which one it is granting.
- Provenance-carrying. Every value wrapped in source, license class, dataset version, and digest. If the layer cannot say where an attribute came from, it cannot say whether your client may keep it.
- Honest at the edges. Unknown payloads return typed refusals, not invented answers — because a wrong answer in a compliance workflow is worse than none, and your name is on the deployment.
That is the layer barcoding.dev is: resolve and verify pure and local for the deterministic half, enrich on license-clean rails with the provenance envelope for the data half. The linkset a resolved identity opens into — the typed list of doors a scan can lead to — is its own subject later in the arc.
Put the paragraph in the next bid before the deployment that needs it. The answer layer behind it is provisioned through the access list — get an API key, describe the deployments you commission, and provisioning follows the list in order.
Keys open the network half of the verb set. Get an API key — say what arrives at your door, and the provisioning order follows the list.
We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.