Skip to content
Evidence & Trust

What Can Product Identity and Event History Flag as Suspicious?

See how serial product identity and event history can flag duplicate, route, timing and movement anomalies, and why alerts are evidence for investigation rather than proof of counterfeit.

Reading time
11 min
Last verified
Sources
10
Share article
LinkedIn X Email
A workbench heaped with crumpled papers and label cards with a magnifier and a canvas tote bag

Persistent serial identity plus a sufficiently trustworthy event history can flag duplicate identities, unexpected routes, odd timing, invalid state changes and implausible movement. The useful output is a risk signal for investigation, not automatic proof that a product is counterfeit or diverted. Sources as at 6 September 2026. Broad event-history anomaly alerting is deployed in regulated and commercial systems. Strict impossible-movement inference is a narrower composition and remains less mature because it depends on trustworthy time, location, event coverage and physical binding.

Direct answer

Yes. If the same product identity is observed across a sequence of events, software can compare that history with expected locations, timings, routes and state transitions and flag patterns that look wrong.

That capability is already deployed in bounded forms. The European medicines verification system uses serialised pack identity and product states to generate alerts. Avery Dennison's atma.io has documented anomaly callouts based on transfer time, processing time and item-state transitions. Motul and Scantrust provide a production example where secure product identity, traceability data and scan intelligence are combined to support counterfeit and grey-market investigation.

The boundary matters more than the headline. A duplicated serial can be caused by a copied legitimate code. An unexpected route can be a return or authorised rerouting. A late upload can make a normal journey look impossible. A valid digital signature can protect data integrity without proving that the physical object in front of you is genuine.

So the strongest general rule is simple: anomaly is evidence for investigation, not proof.

Within the ActivateLabs framework, this is the inference layer between product memory and observation. It assumes the underlying identity, events and evidence have already been governed well enough to compare.

Activatea Product.
Share
LinkedInXEmail
Navigate this page

What the system actually observes

An anomaly engine does not observe “counterfeit” or “diversion” directly. It observes data about an identified object and then derives a judgement from the sequence.

Five inputs do most of the work.

Identity. The system needs a serial or item-level identifier that is intended to refer to one object. Whether item-level continuity is justified in the first place is a separate design decision. The item-level lifecycle guide owns that threshold.

Event. Something has to be recorded about the item: commissioned, packed, shipped, received, decommissioned, returned, repaired or another defined business observation. EPCIS event data is one established way to represent event time, read point, business location, business step and disposition. EPCIS standardises the event structure. It does not guarantee that the event is true.

Time. The event needs a timestamp that is good enough for the inference being attempted. A five-minute clock error may be irrelevant for a week-long distribution route and decisive for a supposed two-minute journey between distant sites.

Read point or location. Controlled site or reader context is stronger than a location inferred from an ordinary browser scan. Web geolocation is permissioned device location with accuracy limits. A consumer QR scan does not, by itself, prove where the physical product is. The broader evidence boundary is covered in what a scan tells you.

State. Many useful anomalies are not geographic at all. A product can appear in a state that conflicts with its recorded history, such as being processed after it has already been decommissioned or moving through a transition that the operating model says should not occur.

The inference is only as strong as these inputs. A precise rule applied to weak observations produces precise-looking uncertainty.

Five useful anomaly classes

The same event history can support several different kinds of flag. They should not all be called “counterfeit detection”.

Anomaly classWhat can trigger itWhat it may suggestWhat else can cause it
Duplicate identityThe same serial appears in conflicting places, states or recordsCopied identifier, clone-like behaviour or duplicated dataReprinted legitimate carrier, duplicate read, replayed event or data duplication
Impossible or implausible movementTwo observations for the same identity are too far apart for the available timeClone-like use, false event or unusual movementWrong clock, late upload, wrong location, event replay or weak location evidence
Unexpected routeThe item appears outside an expected site, market or distribution pathDiversion, grey-market movement or process breachReturns, rework, authorised rerouting or stale route rules
Invalid state transitionThe next event conflicts with the item's previous stateProcess error, reused identity or suspicious activityBad master data, incorrect decommissioning or an unrecorded corrective event
Abnormal dwell or processing timeTransfer, processing or storage time falls outside an expected rangeBottleneck, loss, process deviation or suspicious handlingOperational disruption, incomplete event capture or a threshold that no longer matches reality

The value of the five classes is that they make the investigation question explicit. A duplicate identity asks a different question from abnormal dwell time. The corroborating evidence should be different too.

How the composition works

A practical anomaly system is a chain, not a single feature:

serial identity → event capture → time/location/state context → retained history → expected-route or transition model → rule, heuristic or model → risk signal → investigation → governed action

Each link can weaken the conclusion.

The serial identity must be stable enough to compare observations. Event capture must cover enough of the journey to make absence or presence meaningful. Time and location need assurance appropriate to the rule. The expected process model needs to reflect legitimate returns, rework and market differences. The anomaly rule needs measurable outcomes. The investigation team needs access to evidence that can confirm or reject the hypothesis.

This is also why automatically created observations and governed business events should not be collapsed into one thing. A reader, beacon or sensor can create an observation, but the separate question is when an observation should become a governed product event.

For strict impossible movement, the dependency chain becomes tighter. Two observations of the same identity are not enough. You need sufficiently trusted time at both observations, sufficiently trusted location or site context, a defensible minimum travel or transition constraint and a reason to believe the observations relate to the physical object rather than a copied carrier or replayed event.

That full composition is technically credible, but the accepted evidence does not support treating strict impossible movement as a broadly proven production counterfeit classifier.

What production systems already show

European medicines verification: alerts at regulated scale

The European Medicines Verification System has operated continuously since February 2019 across 28 national systems. It shows that serialised pack identity, state checking and alert workflows can run at very large production scale in a tightly governed sector.

It also supplies some of the best counterevidence against overclaiming. EMVO's August 2026 alert-prevention guidance describes avoidable alerts caused by issues such as missing uploads, casing mismatches, packs already being decommissioned and bulk-processing problems. A real production alert can therefore be created by a data or workflow problem rather than falsification.

That is exactly why an alert belongs in an investigation workflow.

atma.io: event-sequence anomaly callouts

Avery Dennison documented Anomaly Callouts in atma.io that analyse processing time, transfer time and item-state transitions using heuristics and machine learning. This is good evidence that commercial traceability software can derive suspicious patterns from item histories.

It is not independent evidence of a universal counterfeit-detection accuracy rate. The source demonstrates the feature and the kinds of sequence it evaluates. It does not provide independently verified precision, recall or a named customer's strict impossible-movement performance.

Motul and Scantrust: history works better with stronger physical assurance

Scantrust's Motul case combines tamper-evident secure QR codes, serialised identity, ERP and traceability integration and scan intelligence to support counterfeit and grey-market investigation.

This is useful because it shows the layers working together. It is also a warning against crediting the result to event history alone. The secure physical carrier and the operational process are part of the composition.

RFID clone-detection research goes one step further analytically. Published research has shown that distributed read histories can be used to detect clone-like spatiotemporal inconsistencies. But that evidence remains research, not broad production validation, and the same literature documents duplicate and missing reads as material complications.

Why an alert is not proof

Important distinction A suspicious history can justify investigation, quarantine, extra verification or another governed response. It does not, by itself, prove that the physical product is counterfeit, cloned or diverted.

Several failure modes can produce the same pattern as the thing you are trying to detect.

A legitimate identifier can be copied. GS1's digital-signature guidance explicitly preserves this physical-binding caveat. A serial-level carrier can be copied or reprinted. The digital record can still resolve correctly while the physical object carrying the copied identifier is wrong.

Events can be missing. Open supply chains rarely provide perfect observation coverage. If a product moves through an uninstrumented hand-off, the system may miss the event that would make the later location look normal.

Events can be duplicated. RFID and other reader systems can create repeated legitimate observations. Without deduplication and reader semantics, a duplicate can look like conflicting presence.

Uploads can be late or offline. EPCIS distinguishes event time from record time for a reason. A delayed upload can make the database sequence look impossible even when the physical movement was ordinary.

Returns and rerouting are real. An “unexpected” path may be a valid reverse-logistics, rework or market-routing path that the rule has not modelled.

Master data can be wrong. A backend that is missing expected serials or states can produce a large number of avoidable alerts. Medicines verification experience shows this is not theoretical.

Location can be weak. Browser geolocation is location of a user device as exposed by the user agent, not a trusted attestation that the product itself was physically present at that point.

The right operating language is therefore flag, signal, investigate and corroborate. “Proves counterfeit” is too strong for the general case.

Physical binding is a separate assurance layer

There are two different questions:

  1. Does this digital history consistently describe the same identifier?
  2. Is that identifier credibly bound to the physical object now in front of us?

The first is an event-history problem. The second belongs to identity, authentication and ownership and, where signatures are used, to what signing a record actually proves.

A signature can help establish who signed data and whether it has been altered. It does not stop a valid serial or signed data carrier being copied onto another physical object. Stronger physical assurance may come from tamper evidence, anti-copy features, controlled readers, secure hardware or another binding mechanism appropriate to the product and risk.

This separation prevents a common architecture mistake: asking anomaly logic to compensate for a weak physical identity mechanism and then treating the resulting score as authentication.

The economics are mostly in coverage and investigation

The anomaly rule is often the cheap part. The operating model around it is not.

You may need serialisation, readers or capture points, integrations, event storage, route and state models, partner data-sharing agreements, model or rule maintenance and an investigation process. Every additional observation point can improve coverage, but it also creates equipment, integration and data-quality work.

The strongest measured cost evidence in the accepted research comes from pharmaceutical serialisation. A 2024 study across 11 Irish pharmaceutical sites and 114 packaging lines reported material capital, line-efficiency and per-pack operating costs. Those figures should not be transferred mechanically to apparel, luxury or general logistics. They do show that persistent serial capture is not operationally free.

Alert quality affects the economics just as much as capture. A low-specificity rule that produces thousands of weak alerts can create more cost than value. Operators stop trusting noisy systems, investigations queue up and the strongest signals can be buried.

Before deployment, define what happens after each alert: who receives it, what evidence they can inspect, what action they may take and how the outcome feeds back into the rule. If the answer is simply “someone looks at it”, the operating burden has not been designed yet.

What is deployed, composable and not supported

CapabilityMaturity as at 6 September 2026Boundary
Serial identity + event history + rules, heuristics or ML producing anomaly/state alertsDEPLOYEDNamed regulated and commercial systems demonstrate the composition, but performance is use-case specific.
Strict impossible-movement signal using trusted time, location and movement constraintsCOMPOSABLEThe components fit and research supports the logic, but independently documented production performance for the strict composition is not established.
Cross-enterprise complete history for arbitrary productsEMERGINGEvent-history technology exists, but coverage, governance and interoperability are not settled across open ecosystems.
Browser QR scan as trusted product locationNOT SUPPORTEDBrowser geolocation is device/user-agent location with accuracy and spoofing limitations.
Valid signature or valid digital identity as proof the physical object is genuineNOT SUPPORTEDDigital integrity and physical binding are separate assurance problems.
Anomaly alert as automatic proof of counterfeit or diversionNOT SUPPORTEDAlerts can be caused by copied carriers, missing or duplicate events, late uploads, legitimate routing and bad data.

This maturity split is the safest way to use the opportunity. Build on the deployed parts. Treat stricter inference as a composition whose assurance has to be earned.

A decision checklist before you build it

1. What exact behaviour are you trying to flag? Duplicate identity, unexpected route, impossible movement, state conflict and abnormal dwell require different observations and thresholds.

2. Does the decision genuinely need item-level continuity? If batch or type identity is enough, serialising every object may add cost without improving the decision.

3. Which events are actually observable? Map the real capture points and the blind spots. Do not design a rule around a journey you cannot see.

4. How trustworthy are time and location? Distinguish controlled read points from user-device location and separate event time from upload time.

5. How strong is the physical binding? Decide what a copied code, moved label or replayed credential would do to the inference.

6. What legitimate exceptions exist? Model returns, rework, trans-shipment, market differences and offline operations before calling them suspicious.

7. What happens after the alert? Define investigation evidence, decision rights, escalation and any automatic action. If a signal will trigger software, keep detection separate from the product action and permission model. If proximity is also being used as a condition for action, when product proximity becomes a permission is a separate assurance question.

8. How will you measure whether the rule works? Track confirmed outcomes, false positives, false negatives where observable, investigation time and alert volume. A model that cannot be evaluated will eventually become a source of noise.

The useful starting point is not “Can we detect counterfeits with a serial number?” It is “Which suspicious pattern matters, what evidence would create it and what would we need to corroborate before acting?”

What would change this page

This answer should be revisited if:

  • independently documented production evidence shows strict impossible-movement detection using trusted event sources, explicit movement constraints and measured outcomes;
  • cross-enterprise event coverage becomes repeatable enough to materially reduce the current completeness problem;
  • evidence shows persistent high false-positive rates that make a currently useful anomaly class operationally weak;
  • stronger product-location attestation becomes common enough to change the current browser-location boundary;
  • new physical-binding approaches materially reduce the copied-carrier problem for relevant product classes.

Keep exploring

The questions this page usually raises next.

Sources

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.