Tamper Analysis

A Tamper Analysis compares a fresh scan of a DUST identifier against the reference captured when that identifier was bound, and reports what it measured: how much of the reference marker pattern the new scan accounts for, plus the visual evidence layers behind those numbers.

It stops there. DICE never states whether the identifier was tampered with. The only conclusion in the system is a Tamper Observation — a record you write, in your name, saying what you concluded from the evidence in front of you.

Why DICE reports measurements and leaves the conclusion to you

Whether an identifier has been tampered with is a judgment about a physical object — it depends on how the item was handled, how much wear is expected of it, how it was packaged, who held it and for how long, and what it is worth — and DICE can see none of that, so it reports only what it measured and leaves the conclusion to the person holding the item.

That single decision shapes the whole module:

There is no summary number for an Analysis, no rating, and no percentage that means “good” or “bad”.
There is no threshold. DICE never says a measurement is high, low, normal, or unusual, because any such line would be DICE deciding on your behalf where acceptable ends.
Color distinguishes the marker classes and nothing else. The legend in the viewer says so explicitly: no color in the module encodes severity, and none of them means “worse”.
The measurement labels describe what was counted, never what happened to the item. A marker missing from the new scan is reported as missing from the new scan — not as removed, altered, or damaged.
An Analysis is never described as passing or failing, and it is never reduced to a single current state. Every Analysis of an identifier is kept, and so is every Observation written from it.

Because of this, the module rewards a reader who knows the item and its handling history. Someone who cannot interpret marker coverage will not get an answer from DICE — by design.

Running a Tamper Analysis

A Tamper Analysis needs a DUST identifier that is already bound to a Thread; the other identifier types (QR, barcode, data matrix, NFC) have no marker pattern to compare, so the module does not apply to them.

Open the Thread and select the DUST identifier you want to analyze.
Start a tamper analysis and scan the physical identifier, exactly as you would to verify it. An ordinary DUST scan is valid input — there is no special capture mode to learn.
DICE compares that scan against the reference captured when the identifier was bound, and records the measurements as a permanent Analysis.

Each Analysis is immutable and attributed to whoever ran it. Running another one never replaces an earlier one: re-scanning an identifier a week later gives you two Analyses to compare, not an updated result.

An Analysis belongs to one identifier, so a Thread carrying more than one DUST identifier asks you to choose before the scanner opens. The identifier’s name, description, and DUST value are shown when you pick it, again in the scanner, and on the Analysis afterwards — identifiers are often unnamed, and the value is what tells two of them apart.

What the measurements tell you

DUST identifiers carry a pattern of microscopic markers. The Analysis reports how the markers in your new scan line up with the markers in the reference captured at Bind, as three coverage measurements:

Measurement	What it counts
Reference markers also found in this scan	Markers present in the Bind reference that the new scan accounts for
Reference markers not found in this scan	Markers present in the Bind reference that the new scan does not account for
Markers in this scan not in the reference	Markers the new scan shows that the Bind reference does not contain

Alongside them, DICE reports how many markers were considered on each side, so you can see how much evidence the measurements rest on.

These are coverage counts, not causes. Markers can go unaccounted for because a surface was dirty, worn, wet, partly obscured, or scanned at an awkward angle or in poor light, as well as because the surface itself changed. Nothing in the numbers distinguishes those situations, which is precisely why DICE does not draw the conclusion for you — and why re-scanning under better conditions is often the most useful next step.

Reading the evidence layers

The evidence viewer stacks the scan imagery and the marker classes so you can look at the measurements rather than take them on trust:

It opens on the measured markers. All three marker classes are drawn over the scan, with Surface difference behind them — where the two scans differ across the whole scanned area, not only at the markers — so an Analysis shows its evidence without you configuring anything first.
Markers and density toggle independently. Each marker class has its own marker overlay and its own Density wash, showing where that class’ markers concentrate. Show one class on its own, or compare two, without the others in the way. Alt-click a class in the legend to isolate it.
The base image switches between the two scans. The reference capture (taken at Bind) and the scan you just took are both shown in the same frame, so you can read the same overlays against either surface — or against none — and nothing moves when you switch. Older Analyses may have only the new scan recorded.
Marker positions are told apart by shape, not color: circles for the reference capture, diamonds for this scan. Each carries the number of coordinates it draws, so you can always tell which set you are looking at.
Zoom, pan, and rotation work across the whole composite, with every enabled layer staying in register — that is how you examine one area of the surface rather than a whole-surface average. Pinch to zoom and twist with two fingers to rotate on a touch screen; quarter turns snap, so a scan captured at an angle can be squared up.
Marker colors are yours to choose. Cool, Bright, and Deep suit different scan surfaces; Classic is the familiar green / red / yellow set, for the quickest separation between classes; and you can set your own three colors. Whichever you pick is a viewing preference stored on your device — it changes nothing that was measured, and no palette adds a ranking. Where the hues carry conventional meanings elsewhere, the viewer says so.
The legend states that color is categorical: it separates the marker classes and carries no severity.

The viewer shows evidence. It offers no ranking, sorting, or highlighting that would steer you towards one reading.

When the two scans can’t be compared

Before anything can be measured, the new scan and the Bind reference have to be brought into the same frame — aligned to each other. Sometimes they can’t be: too little of the surface was captured, the image is too blurred, or the scan is too poor to register.

When that happens, DICE tells you the two scans could not be compared, and treats the measurements as not comparable.

This is not a statement about the identifier. It says the comparison is unusable, nothing more, and it must not be read as either reassurance or concern. The honest thing to record in that situation is a Tamper Observation of Unknown — and, usually, to re-scan under better conditions.

Recording a Tamper Observation

A Tamper Observation is your conclusion, drawn from one Analysis, written in your name. It has exactly four possible results, and you choose one deliberately — there is no default and nothing is pre-selected:

Consistent — what you can see matches the reference captured at Bind; you see no evidence of tampering.
Expected — you see normal wear and tear, consistent with the identifier’s use case and substrate. An identifier that lives in the field accumulates honest degradation, and this result records exactly that without stretching either “consistent” or “inconsistent” to cover it.
Inconsistent — what you can see does not match the reference; you suspect tampering.
Unknown — the evidence does not support a conclusion, for example when the scans could not be compared or the scan is too poor to read.

Unknown carries the same weight as the other three. It is the correct answer for unusable evidence, not an admission of defeat, and it is offered on equal footing so that nobody feels pushed into guessing.

An Observation records the result, its author, and the time. Once written it is never edited or deleted, and it never replaces an earlier one — if you change your mind, or a colleague reads the same evidence differently, that is another Observation, and the Analysis keeps the whole series in order. What you see on an Analysis is therefore not “the answer” but the full record of who concluded what, and when.

Two consequences worth planning around:

An Observation is about the identifier surface — whether its markers still match what was captured at Bind. It is not a statement about the Thread, and not a statement about the goods the Thread represents. Draw those conclusions yourself, outside the record, with everything else you know.
Because the series is permanent, an Observation written in the field stands as that person’s read, and an expert’s later Observation sits beside it rather than overwriting it.

Who can do what

Anyone who can view the Thread and its identifier can run a Tamper Analysis and record a Tamper Observation. There is no separate reviewer role.

That is deliberate: the person holding the object is usually the only one who can see the thing being described, and locking authorship to a reviewer would leave the record carrying an opinion formed from a photograph. Attribution is what makes it safe — every Observation is permanently signed and dated, sits beside every other Observation on the same Analysis, and is never presented as DICE’s finding. Which reads to weigh, and whose, stays your organization’s decision.

What downstream teams see

A Tamper Analysis and its Observations travel downstream exactly as far as the identifier they concern:

Where you have disclosed that identifier to a downstream team through Fabric, they see its Analyses — the coverage measurements and whether the scans could be compared — together with the full Observation series and its authors.
Where the identifier is withheld, its Analyses and Observations do not appear downstream at all. Nothing is shown redacted, and nothing hints that an Analysis exists.

There is no separate tamper visibility setting to manage: disclosing the identifier is what carries its tamper record, and withholding the identifier is what keeps it back.

The evidence imagery does not travel. A downstream reader gets the measurements and the Observations; the scan layers themselves stay with the team that captured them.

Where Analyses appear afterwards

Analyses and Observations are recorded in the Thread’s transaction history alongside its bind, verify, and identify events, so a tamper record sits in the same timeline as everything else that happened to the item. See Activity and transaction history.

If the evidence imagery for an older Analysis is no longer available, DICE says so, and the recorded measurements and Observations are unaffected.

Identifiers and scanningBind, verify, and identify — where DUST scans come from.

Disclosures and updatesWhat downstream teams see of an identifier, and therefore of its tamper record.

ActivityThe Thread timeline where Analyses and Observations are recorded.

Was this page helpful? Report an issue or suggest an improvement.