If the website disappears, the vendor shuts down, or the software stack changes, what is supposed to happen to the physical product?
We spend a lot of time thinking about how connected products begin. What happens when somebody taps them? What information appears? What does the customer see? How does the product get registered? What can the manufacturer update?
Those are important questions. But building State of Stick has pushed us toward a harder one: How should a connected product end?
Not the physical product. The software around it.
Physical things routinely outlive the digital systems created for them. A commercial building may stand for 70 years. Industrial equipment can stay in service for decades. A collectible may move between owners for generations. A piece of furniture might survive three companies, five websites, and an entire generation of software architecture.
Even an ordinary bottle, vehicle component, appliance, plaque, or recognition piece can remain in the world far longer than the marketing campaign originally attached to it.
And yet connected-product systems are often designed as though the company, domain, application, hosting provider, database, and software architecture behind them will exist forever. They will not.
That has led us to a design principle we increasingly think belongs alongside identity, security, lifecycle management, and interoperability:
A physical product with a digital life needs a credible plan for surviving digital change.
That means thinking about failure before the first product ships.
We discovered the problem by trying to make physical things persistent
State of Stick started with a relatively simple premise: give a physical object a useful digital layer.
An emblem could open a story. A connected package could lead to instructions or a reorder path. A collectible could maintain an evolving record. A manufacturing asset could connect someone standing beside it to the appropriate service information.
Then the architecture became more sophisticated. The physical object needed identity. The identity needed lifecycle state. Different audiences needed different experiences. Some applications needed stronger verification. AI introduced another layer of governed information and context.
And eventually an uncomfortable question appeared: What happens if the system behind the object changes?
That question is unavoidable once you describe an identity as persistent. Persistent compared with what? A campaign? A URL? A software release? A company?
Our Connected Product Intelligence model describes a durable digital relationship that stays with products through their useful life, connecting physical identity, lifecycle context, approved knowledge, experiences, and useful actions.
If we take that idea seriously, then persistence cannot merely mean the link still works next Tuesday. It has to mean the architecture anticipates change.
Physical products and software have completely different clocks
Software is ephemeral by design. We replace it, deploy new versions, migrate databases, change APIs, retire frameworks, move infrastructure, rename brands, merge companies, and shut services down. That flexibility is one of software’s strengths.
Physical manufacturing works on another clock. A component produced in 2026 may still be installed somewhere in 2041. A recognition piece may stay on someone’s wall after the organization that commissioned it has reorganized twice. An industrial asset may survive the software company originally hired to manage it.
A connected product therefore lives across two timelines: the physical lifecycle and the digital lifecycle. Those timelines will eventually diverge. A credible connected-product architecture needs to expect that divergence rather than treating it as an edge case.
Illustrative timeline: the services change while the object remains.
Europe has started designing for exactly this problem
One of the most interesting details in Europe’s Digital Product Passport framework has received much less attention than QR codes, recyclability data, or compliance deadlines. The EU is explicitly thinking about data survival.
The European Commission’s DPP FAQ explains that the framework requires a third-party backup so passport information can remain available if the responsible business stops operating. DPP obligations are introduced through product-specific rules; this is not a blanket requirement for every connected product today.
That is remarkable. The framework acknowledges something every long-lived connected product eventually has to confront: The company may die before the product does.
The Commission’s DPP Registry documentation describes a shared index of identifiers and registration metadata. Detailed passport information remains decentralized, hosted by the responsible businesses or their providers.
In other words, Europe’s emerging product-identity infrastructure is not simply asking how we attach data to products. It is also asking how we prevent the disappearance of one organization from erasing the useful digital life of those products.
That is a much more mature question. It also extends the argument in our earlier field note on Digital Product Passports as physical-product infrastructure: infrastructure has to survive organizational change.
A dead link attached to a durable product is a design failure
Everyone has encountered this. An old QR code opens a dead domain. A manufacturer’s support site has vanished. The company was acquired and the original product pages disappeared. Documentation now exists only on an archive site. An app required to operate a product is no longer supported.
The physical product works perfectly. Its digital layer is dead.
That failure becomes increasingly serious as we ask digital systems to carry more responsibility. If the connected experience is simply a promotional video, losing it is annoying. If it contains repair information, that matters more.
If it carries safety documentation, provenance, ownership state, configuration details, service history, regulatory information, or instructions needed to keep an asset operating, disappearance becomes consequential.
A connected product therefore needs something software developers already understand very well: graceful degradation. If one layer disappears, the entire product relationship should not necessarily collapse with it.
As we explain in Connected Is Not the Same as Verified, a working connection and a stronger trust claim are different things. Continuity planning needs to preserve those distinctions too.
This is why we separate the object from the destination
A recurring theme in our work has been separating things that initially look identical:
- The NFC tag is not the product.
- The URL is not the identity.
- The digital experience is not the authoritative record.
- The AI is not the source of truth.
Those distinctions sound architectural because they are. Our ALTstatic™ model separates the physical signal from the destinations and experiences behind it, allowing one connected physical identity to route toward different approved actions over time.
That separation becomes especially important when thinking about long-term resilience. If the physical carrier permanently encodes one fragile campaign URL, the physical object inherits the lifespan of that URL. If the carrier instead participates in a managed identity system, the destination can change while the physical object remains the same.
This is one reason resolver architecture is so interesting. The GS1-Conformant Resolver Standard, release 1.2.1 ratified in August 2026, describes how GS1 identifiers can lead to multiple related resources and services.
That is more than web plumbing. It is a resilience pattern: Keep the identity stable. Allow the services around it to evolve.
The current experience can be replaced without replacing the physical object.
We think connected products need a continuity layer
The more we work through this problem, the more we think manufacturers should distinguish between experience continuity and data continuity.
Experience continuity asks: Can this physical product still lead somebody somewhere useful?
Data continuity asks: Does the information associated with the product still exist, remain interpretable, and retain enough context to be useful?
You can have one without the other. A company could keep redirecting an old identifier to a generic homepage. Technically, the interaction still works. But the product’s useful history is gone.
The reverse is also possible. A database backup could preserve every record while the physical product has no functioning way to reach it.
A durable connected-product system needs both. That means thinking beyond uptime. It means thinking about portability, resolvability, migration, stewardship, and recovery.
What happens when the customer changes vendors?
This is another uncomfortable question. Connected-product platforms naturally want customers to remain customers. That is business.
But a manufacturer deploying thousands or millions of physical identities should have a different concern: What happens if we eventually want to leave?
If changing providers means abandoning every identity already attached to physical products, then the manufacturer’s products have effectively become hostages to infrastructure. That is not a healthy foundation for a long-lived identity system.
There may be legitimate proprietary layers around analytics, workflow, management tools, verification techniques, or experience orchestration. But the customer should still understand what is portable:
- What identifiers belong to the manufacturer?
- What records can be exported?
- Which mappings can be migrated?
- What happens to public experiences after contract termination?
- Who controls the domain or resolver?
- How long does archival access remain available?
Those questions may sound like procurement details. For a physical identity expected to survive ten years, they are product-design questions.
The simplest connected product should still fail well
Not every State of Stick deployment needs enterprise continuity architecture. That would defeat one of our core principles: use the simplest credible system for the job.
A promotional retail emblem does not need the continuity requirements of industrial equipment. A temporary event activation should be allowed to end. A collectible needs different protections than a restaurant menu.
But even simple deployments can be designed with failure in mind. A discontinued experience can route to an archival page rather than an error. A retired product can explain that it has reached the end of support. A replaced identity can direct someone to its successor. A transferred asset can preserve enough history to explain what changed.
A campaign can end while the object remains understandable. Dead does not have to mean broken. Sometimes a graceful ending is the correct experience.
A product should be able to explain its own retirement
This becomes especially important as connected products accumulate lifecycle states. Our Connected Product Intelligence model treats installation, activation, warranty, recall, service, replacement, transfer, and retirement as potentially meaningful product states.
Retirement deserves more attention. Software products have end-of-life policies. Operating systems have support windows. APIs get deprecation notices. Enterprise hardware has end-of-service dates. Physical connected products need analogous thinking.
Imagine interacting with an old product and receiving:
- This product is no longer supported. Here is the final documentation.
- This component was superseded by this replacement.
- This product’s original manufacturer is no longer operating. Archived information remains available here.
- This object’s connected experience has concluded, but its historical record has been preserved.
That is dramatically better than 404 Not Found.
AI makes continuity even more important
There is another reason this problem matters now. We increasingly expect AI systems to help people navigate product information. That works only when the underlying information remains available and trustworthy.
Imagine a technician interacting with a 12-year-old component. An AI assistant could potentially help locate the relevant service documentation, explain approved procedures, identify replacement information, or surface historical configuration data. But only if those records survived the software transitions that occurred during the previous 12 years.
AI cannot reason over information that vanished. And it should not improvise missing authoritative product information.
This means the quality of future physical AI systems may depend less on increasingly clever models and more on something far less glamorous: whether manufacturers preserved durable, structured product context in the first place.
That is infrastructure work.
Security has the same lifecycle problem
Europe is beginning to impose lifecycle obligations in another adjacent area as well. The EU Cyber Resilience Act introduces cybersecurity duties for products with digital elements. Reporting requirements began applying on September 11, 2026; the main obligations apply from December 11, 2027.
The details and scope differ substantially from Digital Product Passports, but the larger direction is worth noticing. Digital responsibility is increasingly being treated as something that continues after the product ships.
That is the same conceptual transition we keep encountering from a different direction. Manufacturing used to have a relatively clear boundary: make → sell → support.
Connected products blur that boundary. The digital relationship can remain active throughout the physical lifecycle. That creates opportunity. It also creates responsibility.
“Built to last” has to apply to the digital architecture too
Our physical work makes this particularly difficult to ignore. We make objects intended to be kept: emblems, displays, recognition pieces, connected packaging, collectibles, and physical identity layers.
The State of Stick platform brings physical manufacturing together with persistent identity, governed software, and lifecycle intelligence. Made to be kept. Built to keep working. That idea creates a standard for the software too.
It would be strange to manufacture a weather-resistant physical product expected to survive years and connect it to digital infrastructure designed only around the next marketing quarter.
The lifespan of the digital architecture does not have to equal the lifespan of every physical object. But the difference should be intentional. If the digital layer ends, we should know what happens next.
We are beginning to think in three endings
The connected-product industry talks constantly about activation. We think it should also talk about endings. A connected physical identity can eventually reach one of three broad states:
The product continues its digital life somewhere else. Infrastructure changes, but identity and useful records survive.
Active experiences end, but important information remains available in a stable, understandable form.
The digital relationship legitimately ends, and the product clearly communicates that state rather than failing mysteriously.
Those outcomes are very different from abandonment. Abandonment is what happens when nobody designed the ending.
The real test of persistent identity happens years later
Almost every connected-product system looks impressive during a demonstration. The tag is new. The database is populated. The server is running. The marketing team is excited. The phone taps. The experience opens. Success.
But that proves almost nothing about persistence.
The real test may occur seven years later. The original developer is gone. The brand has changed. The product changed owners. The website was rebuilt. The cloud architecture was migrated. The marketing program ended. The physical carrier has survived.
Someone interacts with it. What happens then?
That is the moment persistent identity either means something or it does not.
What should happen if someone taps this ten years from now?
We used to begin primarily with: What should happen when someone taps this? We still ask that. But another question now belongs beside it: What should happen if someone taps this ten years from now?
We may not know what the experience will look like. We probably should not. Trying to predict ten years of software would be absurd. But we can decide what should remain true:
- The object should still be identifiable when that matters.
- Important records should have a continuity strategy.
- The manufacturer should understand which parts of the system it controls.
- Critical information should not depend entirely on one fragile destination.
- The physical carrier should not unnecessarily imprison the product inside today’s software architecture.
- When the digital relationship legitimately ends, the product should fail deliberately rather than accidentally.
That is a different way of thinking about connected products. It is less flashy than the tap. But it may be much closer to what persistent actually means.
Because the goal is not merely to connect a physical product to software. The goal is to create a relationship capable of surviving change.
The company may change. The infrastructure may change. The experience will change. The physical thing may still be here.
Connected-product architecture should be ready for that.
Persistent doesn’t mean nothing changes. It means change doesn’t break the identity.