# The Programmable Product: What Becomes Possible When Software Can Read One

Source: https://activatedigital.ai/knowledge/guides/programmable-product-stack
Last verified: 4 September 2026
Summary: A programmable product combines persistent identity with resolution, sensing, memory, trust, context, decisions and actions. See what each decision needs.

## In 60 seconds

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.

- Not every product needs every capability, from identification to permissioned action.
- CCC Digital Key checks operation entitlement before unlock or start. The CCC reported 115 vehicle and module certifications in 2025. Proximity is not permission.
- Zebra's Boggi Milano case reports inventory accuracy rising from about 90% to 99%. That is a vendor-published case, not a universal benchmark.
- Browser geolocation exposes the hosting device's location, not proven product location.
- A universal cross-brand product-to-service bridge is not deployed. A common contract for product actions is missing.
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. So a programmable product is **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?**

## The capabilities that get bundled together

Phrases such as connected product, digital twin or smart product often bundle separate capabilities together, from identity and resolution to sensing, history, verification, permission and action. Each adds something, and none establishes the others by itself: identity doesn't prove ownership, proximity doesn't grant permission and a callable service isn't safe to call just because it exists.

A carrier is one part of this architecture, not the architecture itself. The existing guide on [choosing a carrier that still works](https://activatedigital.ai/knowledge/passport/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](https://activatedigital.ai/knowledge/passport/what-happens-when-you-scan).

Not every product needs all of them. A care-information journey may only need identity and resolution. A cold-chain decision may need identity, sensing, history and a decision rule. A secure access system may need identity, ranging, verification, permission and action.

## Identity is usually the join key, not the container

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](https://ref.gs1.org/standards/resolver/) 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](https://ref.gs1.org/standards/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.

[EPCIS event data and product master data answer different questions](https://activatedigital.ai/knowledge/product-data/epcis-events-vs-product-master-data). The choice between model, lot, serial and item identity belongs with [the minimum operational identity level](https://activatedigital.ai/knowledge/product-data/lot-serial-item-operational-identity). If a use case needs history for one physical unit, [item-level lifecycle identity](https://activatedigital.ai/knowledge/guides/when-lifecycle-data-needs-item-level-identity) becomes a separate design decision.

## Why permission has to be checked separately

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.

So the permission check sits between trust signals and action.

The Car Connectivity Consortium's Digital Key is a strong production example: BLE, UWB and NFC can handle discovery and connectivity, secure ranging and a close-range path, and the vehicle still checks that an authenticated key is entitled to the requested operation before it unlocks or starts, a flow worked through in [can a product act as an API endpoint?](https://activatedigital.ai/knowledge/guides/product-identity-api-endpoint). The CCC reported [115 vehicle and module certifications in 2025](https://carconnectivity.org/ccc-digital-key-certifications-surged-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](https://activatedigital.ai/knowledge/guides/ai-agent-act-on-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](https://www.w3.org/TR/geolocation/) 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](https://activatedigital.ai/knowledge/labs/product-identity-event-history-anomalies) 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](https://www.zebra.com/gb/en/resource-library/success-stories/boggi-milano-enhances-stock-accuracy-with-zebras-advanced-rfid-solutions.html) reports inventory accuracy increasing from about 90% to 99%. Its [Good American](https://www.zebra.com/us/en/resource-library/success-stories/good-american-optimizes-retail-inventory-management-from-source-to-store.html) 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 point here is simpler: **ambient observation and event history 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 combines identity, ranging, verification, permission and action.

Bluetooth Channel Sounding and FiRa UWB show that fine ranging is a distinct technical capability. [Bluetooth Channel Sounding](https://www.bluetooth.com/learn-about-bluetooth/feature-enhancements/channel-sounding/) combines phase-based ranging and round-trip time techniques inside the Bluetooth ecosystem. [FiRa's UWB architecture](https://www.firaconsortium.org/resource-hub/technical-faq) supports secure fine ranging and anchor/tag positioning patterns.

The CCC deployment adds the missing permission layer: a close radio isn't enough, so the car checks a recognised credential and whether it 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 sensing and history are added, the product can carry a measured condition history 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](https://activatedigital.ai/knowledge/guides/product-condition-sensor-history).

### 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 is the join key to the service, damage, ownership, recall, location and market information behind its [History-Based Value](https://www.carfax.com/value/) service, an [item-specific valuation](https://activatedigital.ai/knowledge/guides/product-history-value) that CARFAX for Lenders describes being used in lending and loan-to-value decisions.

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 shows the same pattern for parts: its current developer documentation lets software test a candidate part against a specified vehicle configuration, so the product identity or configuration is the join key while the [compatibility graph](https://activatedigital.ai/knowledge/guides/product-parts-services-resolver) 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. |

## 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](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/server/tools.mdx) allows software and models to discover structured tools and invoke them. Those are two adjacent capabilities.

What isn't yet established as a universal cross-brand layer is the product-specific contract between them. [The API endpoint guide](https://activatedigital.ai/knowledge/guides/product-identity-api-endpoint) covers what that has to settle before software may act.

The existing article on [AI agents acting on a specific product](https://activatedigital.ai/knowledge/guides/ai-agent-act-on-specific-product) owns the generic authority and execution chain. The narrower Lab article on [parts and service resolution](https://activatedigital.ai/knowledge/guides/product-parts-services-resolver) 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

Verification also needs disciplined boundaries.

[W3C Verifiable Credentials 2.0](https://www.w3.org/news/2025/the-verifiable-credentials-2-0-family-of-specifications-is-now-a-w3c-recommendation/) 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](https://activatedigital.ai/knowledge/passport/identity-authentication-and-ownership) and [what a machine-verifiable product certificate has actually verified](https://activatedigital.ai/knowledge/evidence/verifiable-credentials).

## 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. They are what makes the idea operationally useful.

## The strongest design rule: start with the decision, then work backwards

The idea 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 required.

If the job is to route somebody to the right care guide, identity and resolution may be enough. If the job is to stop a suspect shipment, you may need identity, event history, outside context, a decision rule and a governed action 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](https://activatedigital.ai/knowledge/product-data/lot-serial-item-operational-identity), 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](https://activatedigital.ai/knowledge/guides/testing-product-information-business-outcomes) and [the denominator problem](https://activatedigital.ai/knowledge/guides/measurement-denominators-scans-repairs-recalls-resale) remain separate measurement questions.

## What would change this answer

This answer 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.
Until then, the most useful approach 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 this page:

- [Evidence behind thisNext questionCan product identity detect clones, diversion or impossible movement?→](https://activatedigital.ai/knowledge/labs/product-identity-event-history-anomalies)
- [CompareNext questionWhat changes when a product can report its condition?→](https://activatedigital.ai/knowledge/guides/product-condition-sensor-history)
- [CompareNext questionCan a product tell software which parts and services it needs?→](https://activatedigital.ai/knowledge/guides/product-parts-services-resolver)
- [CompareNext questionThe economics behind a programmable product→](https://activatedigital.ai/knowledge/guides/connected-product-business-models-who-pays)

## Sources

**Sources as at 4 September 2026.**

- [GS1: GS1-Conformant Resolver Standard 1.2.1, August 2026. Used for product identity resolving to multiple machine-discoverable resources.](https://ref.gs1.org/standards/resolver/) Standards body
- [GS1: Digital Link URI Syntax 1.7.0, August 2026. Used for product identifiers represented in web-resolvable form.](https://ref.gs1.org/standards/digital-link/uri-syntax/1.7.0/) Standards body
- [GS1: EPCIS 2.0.1, current specification. Used for identified event history, where/when context and sensor elements.](https://ref.gs1.org/standards/epcis/2.0.1/)
- [GS1: EPCIS and CBV overview, accessed 4 September 2026. Supporting source for visibility, sensor and event-memory capabilities.](https://www.gs1.org/standards/epcis)
- [Bluetooth SIG: Channel Sounding, accessed 4 September 2026. Used for secure fine-ranging capability and its limits.](https://www.bluetooth.com/learn-about-bluetooth/feature-enhancements/channel-sounding/)
- [Bluetooth SIG: Direction Finding, accessed 4 September 2026. Used to distinguish direction/positioning from ordinary BLE presence.](https://www.bluetooth.com/learn-about-bluetooth/feature-enhancements/direction-finding/)
- [FiRa Consortium: UWB Technical FAQ, accessed 4 September 2026. Used for secure fine ranging and positioning architecture.](https://www.firaconsortium.org/resource-hub/technical-faq)
- [Car Connectivity Consortium: Digital Key certifications surged in 2025, 6 January 2026. Used for bounded production adoption evidence.](https://carconnectivity.org/ccc-digital-key-certifications-surged-in-2025/)
- [Car Connectivity Consortium: Digital Key use cases, accessed 4 September 2026. Used for the separation between credential, ranging, entitlement and action.](https://carconnectivity.org/digital-key-use-cases/)
- [Apple: Find My and Privacy, 15 September 2025. Used as a bounded example of BLE observations operating through receiver/platform infrastructure with explicit privacy design.](https://www.apple.com/uk/legal/privacy/data/en/find-my/)
- [W3C: Geolocation, 2026 Candidate Recommendation. Used for the boundary that web geolocation exposes the hosting device's location, not proven product location.](https://www.w3.org/TR/geolocation/)
- [W3C: Verifiable Credentials 2.0, 15 May 2025. Used for machine-verifiable credential capability and verification boundaries.](https://www.w3.org/news/2025/the-verifiable-credentials-2-0-family-of-specifications-is-now-a-w3c-recommendation/)
- [Amazon: Transparency, accessed 4 September 2026. Used as a bounded serial-verification deployment example.](https://sell.amazon.com/brand-registry/transparency/)
- [European Commission: Falsified Medicines, accessed 4 September 2026. Used as a regulated serial verification and repository-state example.](https://health.ec.europa.eu/medicinal-products/falsified-medicines_en)
- [Zebra Technologies: Boggi Milano RFID case study, accessed 4 September 2026. Vendor-published customer evidence used only for bounded measured RFID outcomes.](https://www.zebra.com/gb/en/resource-library/success-stories/boggi-milano-enhances-stock-accuracy-with-zebras-advanced-rfid-solutions.html)
- [Zebra Technologies: Good American RFID case study, accessed 4 September 2026. Vendor-published customer evidence used only for bounded counting and inventory outcomes.](https://www.zebra.com/us/en/resource-library/success-stories/good-american-optimizes-retail-inventory-management-from-source-to-store.html)
- [CARFAX: History-Based Value, accessed 4 September 2026. Used for identity plus item history plus market context producing an item-specific valuation.](https://www.carfax.com/value/)
- [CARFAX for Lenders: History-Based Value, accessed 4 September 2026. Used for lending and loan-to-value application of item-specific history-based valuation.](https://www.carfaxforlenders.com/products/history-based-value/)
- [eBay Developers: Compatible parts API support, accessed 4 September 2026. Used for machine-operable vehicle/part compatibility.](https://developer.ebay.com/api-docs/user-guides/static/trading-user-guide/compatible-parts-api-support.html)
- [eBay Developers: Browse API compatibility, accessed 4 September 2026. Used for candidate-part compatibility status in machine commerce.](https://www.edp.ebay.com/api-docs/buy/static/api-browse.html)
- [Model Context Protocol: Tools, 2026-07-28. Used for discoverable machine-invokable tools and their boundaries.](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/server/tools.mdx)
- [Model Context Protocol: July 2026 release, 28 July 2026. Used for current MCP maturity and authorisation-hardening context.](https://blog.modelcontextprotocol.io/posts/2026-07-28/)