The Programmable Product: What Becomes Possible When Software Can Identify, Sense, Remember and Act on a Physical Product?
A programmable product combines persistent identity with resolution, sensing, memory, trust, context, decisions and actions. See the 11-layer capability stack.
The short answer
A physical product can become more than digitally addressable. Persistent identity can act as a join key to software capabilities that let the product resolve to services, become observable without a deliberate scan, gain spatial context, report physical condition, accumulate history, present stronger trust signals, sit behind explicit permissions, pull in external context, trigger decisions and connect to executable actions.
Those capabilities do not all live inside the product. Some live in the carrier, some in nearby readers or phones, some in cloud event systems and some in external data, credential, policy or service layers. A programmable product is therefore a system architecture, not a magic tag.
The useful question is not “what can we put in a QR code?”. It is: which capabilities have to compose around this product identity before the decision or action we care about becomes possible?
Navigate this page
- The short answer
- The 11-layer Programmable Product Stack
- Identity is usually the join key, not the container
- Why AUTHORISE has to be a separate layer
- What happens when identity meets location and time?
- What happens when a product can create events without a deli
- What happens when secure proximity meets entitlement and act
- What happens when an identified product can report condition
- External data can change the decision without becoming a pas
- Can identity resolve all the way to a machine action?
- Verification is useful, but it is not the same as truth
- What this does not mean
- The strongest design rule: start with the decision, then wor
- What would change this answer
- Keep exploring
- Sources
The 11-layer Programmable Product Stack
ActivateDigital uses an 11-layer model to separate the capabilities that are often bundled together under phrases such as connected product, digital twin or smart product.
| Layer | Capability | What it adds | What it does not establish by itself |
|---|---|---|---|
| IDENTIFY | Refer to the product persistently | A stable join key for product, batch or item data | Ownership, authenticity or current state |
| RESOLVE | Lead from identity to current resources or services | Dynamic destinations, APIs, documents or service links | Permission to use every discovered service |
| BROADCAST | Announce or expose presence without a deliberate optical scan | Ambient or bulk observation through radio systems | Precise position or trusted identity by itself |
| LOCATE / RANGE | Add spatial evidence | Zone, direction, position or distance depending on the architecture | Permission, ownership or proof that a web scanner and product were co-located |
| SENSE | Measure physical state | Temperature, humidity, shock, motion, tamper or other condition evidence | Whole-product condition beyond what was actually measured |
| REMEMBER | Carry events and state forward through time | Product history rather than a current snapshot | Complete or automatically truthful history |
| VERIFY | Check integrity, issuer, credential or secure-tag signals | Stronger evidence that a digital proof or response validates | Claim truth, legal sufficiency or physical genuineness in every threat model |
| AUTHORISE | Decide who may do what to this product now | Product-specific permission and entitlement | Physical proximity alone cannot substitute for it |
| CONTEXTUALISE | Join product state to outside information | Jurisdiction, market, weather, service, recall or channel context | Proof that the external context describes what the product actually experienced |
| DECIDE | Apply rules, models or anomaly logic | A reasoned outcome, score, recommendation or exception | Causal proof or a guaranteed correct decision |
| ACT | Invoke a digital or physical operation | Book, buy, hold, unlock, notify, route, update or transact | Safe authority unless the preceding identity, state and permission checks are satisfied |
A carrier is one part of this architecture, not the architecture itself. The existing guide on choosing a carrier that still works owns the QR, DataMatrix, NFC and related carrier decision. The mechanics between a deliberate scan and a digital destination belong with what happens when you scan.
The stack is also not a rule that every product needs all 11 layers. A care-information journey may need IDENTIFY and RESOLVE. A cold-chain decision may need IDENTIFY, SENSE, REMEMBER and DECIDE. A secure access system may need IDENTIFY, LOCATE / RANGE, VERIFY, AUTHORISE and ACT.
The point of the model is to make the missing dependency visible.
flowchart LR I[IDENTIFY] --> R[RESOLVE] I --> B[BROADCAST] I --> L[LOCATE / RANGE] I --> S[SENSE] B --> M[REMEMBER] L --> M S --> M I --> V[VERIFY] V --> A[AUTHORISE] M --> C[CONTEXTUALISE] A --> C C --> D[DECIDE] D --> X[ACT]
Identity is usually the join key, not the container
This is the architectural shift that matters most.
A product identifier does not need to contain the product's sensor history, market value, service inventory or access policy. It needs to let authorised systems reliably refer to the same product or product scope while those other capabilities live where they make sense.
The GS1-Conformant Resolver Standard 1.2.1 shows one part of this model. A GS1-identified entity can resolve to multiple typed resources rather than one fixed web page. EPCIS 2.0.1 shows another part: identified objects can participate in time-linked events that carry business context and sensor elements.
Neither standard turns the product into a self-contained computer. The product identity is the common reference that lets different systems join their own data and capabilities around the same object.
That distinction also protects the existing Knowledge architecture. EPCIS event data and product master data answer different questions. The choice between model, lot, serial and item identity belongs with the minimum operational identity level. If a use case needs history for one physical unit, item-level lifecycle identity becomes a separate design decision.
Why AUTHORISE has to be a separate layer
A system can know which product, verify which credential and measure how near a device is without knowing whether that actor may perform the requested action.
That is why AUTHORISE sits between trust signals and action.
The Car Connectivity Consortium's Digital Key architecture is a strong production example. Its published use cases separate several functions: BLE can support discovery and connectivity, UWB can provide secure ranging, NFC can provide a close-range path, credentials can be authenticated and the vehicle still checks whether the key is entitled to perform the requested operation before it unlocks or starts. The CCC reported 115 vehicle and module certifications in 2025.
This is a useful pattern far beyond cars because it kills a common shortcut: proximity is not permission.
The same distinction applies to software. A machine-readable tool can exist and be callable while a particular user or agent remains unauthorised to invoke it for this product. The broader permission chain for agent action belongs with what has to be true before an AI agent can act on a specific product.
What happens when identity meets location and time?
A serialised product observed repeatedly across location and time can become a node in a product observation graph.
A system can compare observations with expected routes, channel geography or plausible travel times. That can create useful signals such as:
- the same serial appearing in places that are implausibly far apart in the available time;
- a product appearing in an unexpected market or channel;
- repeated use of one serial across more observations than the expected physical population;
- movement that conflicts with the expected supply or service path.
The important word is signal. The W3C Geolocation specification exposes the location of the hosting device, with permission. If somebody scans a product with a phone and the website receives that location, the evidence is that the device reported a location. It is not automatic proof that the physical product was at those exact coordinates.
A facility RFID reader, engineered UWB interaction or controlled gateway can create stronger co-location evidence because the receiver-product relationship is part of the system design. Even then, anomaly does not automatically become proof of diversion or counterfeit. The narrower article on product identity, location and time anomaly signals owns that reasoning in depth.
Maturity check: identity + location + time
| Maturity test | Current evidence position |
|---|---|
| Technology exists | Yes. Serialised identity, event timestamps, facility/read-point locations and permissioned device geolocation are established capabilities. |
| Technically composable | Yes. EPCIS and other event systems can join identified objects to where/when observations. |
| System demonstrated | Yes, bounded. Serialised verification and traceability systems show the components working in real operating environments. |
| System deployed | Yes, bounded. Regulated and commerce ecosystems deploy serial verification and event capture, but observation confidence differs by source. |
| Commercial value measured | Partial. Brand-protection and traceability programmes exist, but the Lab found no portable cross-sector precision, recall or ROI benchmark for a generic product anomaly graph. |
What happens when a product can create events without a deliberate scan?
A QR code is interaction-triggered. Nothing happens until a person or machine deliberately scans it.
RAIN RFID and BLE-based systems can change the interaction model. RAIN RFID can identify many tagged products when readers interrogate a defined zone. BLE devices can advertise presence to nearby receivers. Apple Find My demonstrates how BLE observations can feed a privacy-engineered receiver network, while retail RFID deployments show the more controlled case of tagged products being observed inside stores or logistics environments.
That can turn a population of products from “objects that occasionally get scanned” into “objects that can generate operational observations as they move through instrumented space”.
The commercial evidence is real but bounded. Zebra's customer case for Boggi Milano reports inventory accuracy increasing from about 90% to 99%. Its Good American case reports counts of 6,000 units in 30 minutes or less. These are vendor-published customer cases, not universal RFID benchmarks.
The separate Lab article on ambient product events owns the deeper reader and infrastructure question. The key architectural point here is simpler: BROADCAST and REMEMBER can change the denominator because product events no longer depend entirely on deliberate human scans.
Maturity check: identity + ambient presence
| Maturity test | Current evidence position |
|---|---|
| Technology exists | Yes. RAIN RFID, BLE advertising and receiver infrastructure are established. |
| Technically composable | Yes. Identity observations can feed event stores and operational workflows. |
| System demonstrated | Yes. Retail inventory and asset-location systems demonstrate the pattern. |
| System deployed | Yes. Controlled-facility RFID deployments are established. |
| Commercial value measured | Yes in bounded cases. Individual customer cases report inventory and counting outcomes. They should not be treated as universal benchmarks. |
Ambient observation also raises a harder privacy boundary. Product observation should not quietly become covert person observation. Controlled facilities, owned assets, purpose limitation, rotating identifiers where appropriate and proportionate retention are safer design patterns than consumer movement tracking for its own sake.
What happens when secure proximity meets entitlement and action?
The Digital Key example shows a fuller stack:
IDENTIFY + LOCATE / RANGE + VERIFY + AUTHORISE + ACT
Bluetooth Channel Sounding and FiRa UWB show that fine ranging is a distinct technical capability. Bluetooth Channel Sounding combines phase-based ranging and round-trip time techniques inside the Bluetooth ecosystem. FiRa's UWB architecture supports secure fine ranging and anchor/tag positioning patterns.
The CCC deployment matters because it adds the missing permission layer. The system does not unlock a car simply because a radio is close. It checks a recognised credential and whether that credential has the required operation entitlement.
Maturity check: secure proximity + entitlement + action
| Maturity test | Current evidence position |
|---|---|
| Technology exists | Yes. BLE, UWB, NFC, secure credentials and access-control logic exist. |
| Technically composable | Yes. The components are designed to work together in secure access architectures. |
| System demonstrated | Yes. CCC Digital Key provides an end-to-end architecture. |
| System deployed | Yes in automotive. Certified vehicle and module products are in production. |
| Commercial value measured | Not established by the cited certification count. Certification counts show production adoption, not a general commercial-value or ROI measure. |
What happens when an identified product can report condition?
Once SENSE and REMEMBER are added, the product can carry a condition ledger rather than only a static description.
EPCIS 2.0.1 explicitly supports sensor elements alongside product events. That creates a standards substrate for associating time-linked measurements such as temperature or other telemetry with identified objects.
The decision then changes. Instead of asking only “what is this product supposed to be?”, software can ask “what has this identified item actually experienced, according to the available measurements?”.
Possible consequences include inspection, quality routing, warranty escalation, service priority or resale grading. But sensor placement, calibration, clock integrity, gaps and provenance travel with the evidence. A temperature sensor at one point does not prove every part of the product experienced the same conditions.
The detailed condition architecture belongs with what changes when a product can report its condition.
Maturity check: identity + sensor + history
| Maturity test | Current evidence position |
|---|---|
| Technology exists | Yes. Sensors, loggers and event stores are mature technologies. |
| Technically composable | Yes. EPCIS 2.0.1 provides a standard event model that can include sensor information. |
| System demonstrated | Yes. Cold-chain and industrial telemetry classes demonstrate identified assets carrying measured history. |
| System deployed | Yes in bounded sectors. The architecture is in production, though implementation details vary. |
| Commercial value measured | Partial and sector-specific. The Lab does not infer a generic return from adding sensors or history to a product identity. |
External data can change the decision without becoming a passport field
Some of the strongest programmable-product examples are not about putting more data inside the product record at all.
CARFAX is a useful proof. A vehicle's VIN acts as the join key to service, damage, ownership, recall, location and market information. CARFAX then uses that history and market context in its History-Based Value service. CARFAX for Lenders describes the result being used in lending and loan-to-value decisions.
The important architecture is:
identity + history + external market data → item-specific decision
The market data was never required to be a “field inside the VIN”. The VIN gives systems a stable referent through which multiple histories and datasets can be joined.
eBay exposes a different version of the same pattern. Its current developer documentation supports structured vehicle-parts compatibility so software can test whether a candidate part is compatible with a specified vehicle configuration. Again, the product identity or configuration is the join key. The compatibility graph and live commerce catalogue sit elsewhere.
Maturity check: identity + external data
| Maturity test | Current evidence position |
|---|---|
| Technology exists | Yes. Persistent identifiers, history databases, compatibility graphs and market datasets exist. |
| Technically composable | Yes. Stable identity can join product state to external datasets at decision time. |
| System demonstrated | Yes. CARFAX and eBay provide concrete vertical demonstrations. |
| System deployed | Yes in their bounded ecosystems. These are current production services. |
| Commercial value measured | Partial. CARFAX documents commercial lending/valuation use and eBay operates compatibility in live commerce, but the cited sources do not isolate a portable incremental-value measure for the combined identity-plus-external-data architecture. |
This is the basis of a broader Product Context Engine: stable product identity plus current product state plus external context, followed by an explicit decision and bounded action.
Can identity resolve all the way to a machine action?
We are now close to a more consequential architecture, but the bridge is not complete.
GS1 resolvers can expose machine-discoverable resources around an identifier. The Model Context Protocol tool specification allows software and models to discover structured tools and invoke them. Those are two adjacent capabilities.
What is not yet established as a universal cross-brand layer is the product-specific contract between them:
Which service applies to this exact product, what parameters does it accept, what evidence or entitlement does it require and may this caller invoke it now?
A resolver link does not grant service entitlement. An MCP tool does not understand product identity semantics by magic. Correct compatibility data does not prove warranty rights. A callable API does not mean an agent may call it for this user or product.
That is why the future object is not merely “an AI-ready passport”. It is closer to a Product Action Contract that binds product scope, service semantics, inputs, evidence requirements, entitlement, constraints, human confirmation, audit and revocation.
The existing article on AI agents acting on a specific product owns the generic authority and execution chain. The narrower Lab article on parts and service resolution owns the compatibility and service-discovery step.
Maturity check: product identity + compatibility + agent action
| Maturity test | Current evidence position |
|---|---|
| Technology exists | Yes. Product resolvers, compatibility APIs, agent tool protocols and authorisation systems all exist. |
| Technically composable | Yes. Nothing fundamental prevents an implementation from binding them inside one controlled ecosystem. |
| System demonstrated | Partly. Individual vertical systems demonstrate compatibility and individual agent frameworks demonstrate tool invocation. |
| System deployed | Not as a universal cross-brand product-to-service bridge. Bounded proprietary integrations can exist, but the common contract is missing. |
| Commercial value measured | Not for the general bridge. Measured value from adjacent commerce or service systems should not be re-labelled as evidence for universal product-agent interoperability. |
Verification is useful, but it is not the same as truth
The VERIFY layer also needs disciplined boundaries.
W3C Verifiable Credentials 2.0 provides standards for cryptographically secured credentials. Secure NFC products can provide authenticated responses and tamper signals. Amazon Transparency and the EU falsified-medicines system show serial verification being used inside bounded operational ecosystems.
Those are meaningful trust capabilities. They still do not collapse several different questions into one.
A credential can verify cryptographically while the underlying claim is wrong or out of scope. A secure tag can be genuine while physical binding remains weak against transplant or substitution. A valid identifier can refer to a real product class without proving this physical item is genuine or owned by the person presenting it.
The deeper trust boundaries belong with identity, authentication and ownership and what a machine-verifiable product certificate has actually verified.
What this does not mean
A programmable product is not shorthand for “put a smarter tag on it”. - A QR code is not a tracker. - A beacon is not a location system without receivers and processing. - Scanner location is not automatically product location. - An identifier is not authenticity or ownership. - A verified credential is not claim truth. - A secure tag is not absolute physical binding. - Proximity is not permission. - An API or MCP tool is not product entitlement. - Composability is not deployment. - Deployment is not measured commercial value.
These distinctions are not caveats around the edge of the model. They are what makes the model operationally useful.
The strongest design rule: start with the decision, then work backwards
The stack can tempt teams into technology shopping. That is the wrong direction.
Start with the decision or action that would change something meaningful. Then ask which capabilities are genuinely required.
If the job is to route somebody to the right care guide, IDENTIFY and RESOLVE may be enough. If the job is to stop a suspect shipment, you may need IDENTIFY, REMEMBER, CONTEXTUALISE, DECIDE and a governed ACT step. If the job is to unlock a vehicle, you need much stronger trust, ranging and authorisation.
The identity level should also match the decision. A use case that only varies by model should not be forced into item serialisation. A warranty or condition decision about one unit may need the opposite. Lot, serial and item identity should be chosen from the operational job, not from a desire to maximise data.
The same discipline applies to business outcomes. A system can create richer product events without proving those events caused sales, repair success or lower cost. Business-outcome testing and the denominator problem remain separate measurement questions.
What would change this answer
This framework should be revisited when any of the following changes materially:
- product identity and resolver standards begin to expose interoperable product-specific service contracts rather than links alone;
- portable entitlement becomes standard across brands and service providers;
- Bluetooth Channel Sounding or other ranging systems build a larger base of independently measured production deployments beyond current anchor verticals;
- cross-enterprise event systems publish stronger evidence on observation coverage, correction, anomaly precision and investigation yield;
- product-agent systems demonstrate repeatable multi-brand discovery, permission and action without bespoke pairwise integration;
- new evidence shows that a currently separate capability can safely and interoperably be collapsed into another layer.
Until then, the most useful model is deliberately modular: identify the product, add only the capabilities required by the decision and keep verification, permission, context, decision and action as separate objects.
Keep exploring
Three narrower questions follow directly from the stack:
Sources
Sources as at 4 September 2026.
-
Standards body
-
Standards body
Does this reach your products?
Give ActivateDigital one product and it works out which obligations apply from the product's own character, and says which it cannot decide.