Public Pages

A Public Page is a public, unauthenticated web view of a Thread — the digital product passport a customer reaches by scanning an Identifier or following a printed link. What a page shows is decided by a reusable Public Page Design that you build once and apply to as many Threads as you like, so publishing a whole product line takes the same effort as publishing one item.

Nothing is ever public by accident. A page’s address can be reserved — and its QR code printed — before there is anything behind it, and until you publish, a visitor reaches nothing but a notice that the page is registered. Once published, a page shows only the data its design explicitly pulls, and its content changes only when you publish again.

Who can do what

Access follows your role in the active Team:

Publishers (and Team admins, who always include publisher access) build Page Designs, publish Design Versions and roll them out, publish and unpublish pages, and run Publish Waves. Making data public is the authority this role exists to control.
All team members can view designs, their version history, published pages, and page activity, but cannot change or publish anything.

Page Designs

A Page Design is owned by a Team and determines both the content and the appearance of every page published with it. It is a stack of blocks in the order visitors read them:

Hero — the product media at the top of the page. Images, video, and audio all appear here; video and audio play inline and never autoplay, so a visitor on mobile data chooses when to load them. You can narrow it to images or videos alone (see Choosing what the Hero shows).
Identity — the Thread’s name and description.
Specifications — the product attributes you want public, drawn from Thread fields.
Documents — public files such as spec sheets, warranties, and certificates. Images, video, and audio are left to the Hero, so nothing is listed twice.
Text — your own copy: provenance stories, care instructions, sustainability notes.
Link list — outbound links such as repair, recycling, or your brand site.
Verification — the DUST scan-verification panel. Verification starts from a button, so visitors are never asked for camera access just for opening the page. Inside the DUST Go app that button launches the scanner directly; in a phone browser it offers to open the page in DUST Go instead, with code and manual entry available as alternatives.
Provenance — the item’s story as a timeline. By default a page shows the history your team has recorded about the item’s life and the times the item itself was scanned and verified; everything else the record holds is opt-in, chosen per design (see What the timeline shows). Internal operations never appear on a public page: who a record was shared with, and which folders it has been filed in, are excluded whatever the design says.

Blocks can be reordered, configured, and removed. Two things are always present and cannot be removed: the page chrome (the header carrying your logo alongside the platform’s “Powered by” mark, a sign-in link, and the footer) and the record strip showing the date the page’s data was last published — the marks that make a page recognizable as a genuine DUST record. The chrome carries no language or theme controls, and the record strip carries no code: a visitor holding the object is owed how current the record is, not a serial number to check.

The Verification block is included in every new design and may be removed if a page is purely a brand story.

What the timeline shows

The Provenance block is configured by choosing which parts of the item’s history the page publishes. Each choice is named by what it puts on the page:

Recorded history — entries your team recorded about the item’s life: sales, inspections, repairs (see Recording past events).
Verified scans — times the item itself was physically scanned and checked.
Ownership changes — shipments and handovers between organizations.
Parts and installation — parts installed into or removed from a larger assembly.
Certificates and validations — certificates issued and documents validated for the item.
Record activity — edits to the record itself: details, documents, and identifiers changing.

A new design starts with Recorded history and Verified scans — the story of the item leads, and the record’s own bookkeeping stays off the page unless you choose it. The designer’s live preview shows exactly what each choice publishes.

Recorded entries appear as what they are: your organization’s attributed statement, marked Declared, never presented as something the platform verified. The date shows at the precision you actually claimed — “1968–1970”, “Circa 1835” — never a fabricated exact day, and the entry names the place you wrote, if you gave one. An entry you have retracted stays on the page struck through and marked Withdrawn: published provenance is never silently rewritten, so a visitor who saw a claim can also see that it was withdrawn.

The only places a page ever shows are ones a publisher wrote into a recorded entry. Device positions — where a scan or an edit physically happened — are never published, at any precision.

How designs find your data

Specification, hero, and document blocks pull values by field name, not by a fixed template. A binding names the field it wants — for example Metal — with optional alternative names to try, and a type it must be. Applied across a product line, each Thread fills the same design with its own values.

This is the same name-matching model Certificate Forms use, and it has the same practical consequence: the field names you use across a product line should be consistent, and renaming a field stops its binding from resolving on the next publish.

Bindings are optional by default — if a Thread has no Metal field, that row is simply left off its page and everything else still publishes. Mark a binding required when its absence would break the page (a missing hero image, say); a Thread that cannot satisfy a required binding is reported rather than published with a hole in it.

Because a design pulls only what it names, attaching a new file or field to a Thread never changes its published page on its own. A documents or hero block can instead be set to include all eligible public files, which is convenient for teams whose files are loose attachments — with the trade-off that new uploads then do appear the next time that page publishes.

Choosing what the Hero shows

The Hero block’s media source decides which of a Thread’s public media reaches the top of the page:

Every public image, video, and audio file — all public media on the Thread, images first. It names no fields, so it works across a product line whose files are simply attached rather than named consistently. Audio is included here because the Documents block leaves media to the Hero: if the Hero excluded it, a public audio file would appear nowhere on the page.
Images only — public images in Thread order, so a video attached to the Thread never leads the page.
Videos only — public videos in Thread order.
One named media field — exactly the image or video held by the field you name, for a design that must show a specific shot.

The first option follows whatever is attached, which is what most teams want. The kind-narrowed options exist for when that is not a preference but a requirement: a product line where a walkthrough video is attached to some Threads and not others would otherwise lead with a video on exactly those items, and choosing Images only guarantees it never does. Whichever you pick, video and audio play inline and never autoplay.

Appearance

Each design carries its own logo and accent colour, so a Team running two product lines simply keeps two designs. Upload a logo directly in the designer, or pick an image your Team already has — it is not attached to any Thread. The logo appears in the page header, where the page is co-branded: your mark leads and the platform credits itself alongside it. The header sizes the logo for you, so it behaves the same on a phone and a desktop.

You can also set the page background, the header and footer bar colours, and pick a typeface for the page. A published page has one appearance — it does not follow the visitor’s device theme — so you lay it out once and every visitor sees that. Text is chosen for you so it stays readable on whatever colours you pick — a dark page gets light body text, labels and rules automatically — and accent colour is applied to page detailing only. Pages are shown in the visitor’s own language where the platform has one; your own content appears exactly as you wrote it.

Previewing while you design

The designer shows a live device-frame preview, and you can switch it between mobile and desktop to check both widths. Choose any Thread as a design context and the preview resolves that Thread’s real values through exactly the same machinery a real publish uses — what you see is what publishing produces. The preview also lists any bindings that do not resolve against the chosen Thread, so gaps are visible before you commit.

Publishing a page for one Thread

Reserving the link before you publish

A Public Page’s address is created before its content. Opening the Public Page action on a Thread that has none offers to create a stable product link: “Reserve a permanent URL and bind it to this thread. You can download or print its QR code before publishing any product data.”

That order is deliberate — labels, engravings, and packaging are usually produced long before the product record is finished. A reserved link works from the moment it exists: a visitor who scans the printed code reaches a page saying the product page is registered but its information has not been published yet. A printed QR code is therefore never dead, and the address never changes. Publishing later fills in that same page.

Publishing the data

Open the Thread and choose the Public Page action.
Pick the Page Design to publish with.
Review the preflight summary. It lists every binding that resolved and every one that did not; required bindings that cannot resolve block publishing and say why.
Publish. The page becomes reachable at its permanent link, which you can copy, open, or print as a QR code.

A Thread has at most one Public Page, and its link is permanent — republishing updates the content behind the same address, and the address survives unpublishing.

The same action also states what is live right now as three separate facts: the design the page uses, the Design Version it is pinned to, and the date its data was last published. When the design has a newer version, the action says so and names the version it would move the page to — publishing one page always uses the design’s newest version, so correcting a single item also carries it forward.

Publishing a product line

To publish many Threads at once, start a Publish Wave: choose a design and a scope — a Folder, a Category, a Thread Template, or an explicit selection — and the wave creates and publishes a page for every Thread in it. Waves run in the background and are built for entire product lines, so you can start one and leave it.

While a wave is running you can watch its progress and its published and failed counts. Publishing does not depend on you staying on the page: you can close it and come back later, and the wave screen tells you where it got to. A wave keeps expanding its scope as it works, so early on the queued total is still growing — the progress display says so rather than implying a total it does not yet know.

When a wave finishes, it says so plainly and confirms how many pages are live. Threads that could not publish — usually a required binding that does not resolve — are listed individually with the reason, and you can retry just those once you have fixed the underlying data. That list appears only when there is something in it.

A wave publishes through one version of the design, fixed when the wave starts, and every wave screen names that version. If someone publishes a newer version of the design while you are setting a wave up, DICE stops and asks you to review rather than quietly starting a wave on a version you never saw.

Stopping a wave that is going wrong

A wave that has not finished can be cancelled, which is a publisher action. Cancelling stops every page the wave has not reached yet: the remaining work is retired and the run is recorded as cancelled.

Cancelling is not an undo. Pages the wave already published keep the Design Version and the data it gave them, because rollout is forward-only — nothing is ever moved back. If those pages are wrong, correct the underlying design or data and publish forward again, either one page at a time or as a new wave. A wave that has already finished cannot be cancelled, for the same reason.

Keeping pages current

A published page serves the data it was published with, so a page goes out of date as soon as its record moves on — a repair recorded, a field corrected, a document attached. This is separate from the design being out of date: a page can be sitting on the newest Design Version and still be showing older data than its record now holds.

DICE tracks that for you. The designs list shows how many pages are behind their records, lists them, and offers Republish all, which is a publisher action. It covers every published page your Team owns, whatever design each one uses. Republishing refreshes the data without changing any page’s Design Version — it never rolls a design change out as a side effect, so clearing this list is always safe.

A page is skipped rather than republished when its design no longer resolves against the record — a required binding whose field was renamed, say. A skipped page keeps serving its current publication and stays on the list, because a stale page is better than a broken one. Fix the underlying data and republish again.

Living passports

A design can be set to keep its pages current by itself. Turn on Living passport in the designs list and every page published with that design republishes automatically when new history is recorded on its Thread — a declared entry, or a retraction of one. It is the setting to use for a passport meant to read as the item’s live story rather than a snapshot of one moment.

Automatic republishing is deliberately narrow:

It moves the data only. The page’s Design Version never changes, so a design still in progress cannot reach the public as a side effect of someone recording an event.
It is bounded per action. A large bulk recording republishes up to a few hundred pages inline; anything beyond that keeps serving its existing publication and appears in the behind-their-records list, where Republish all finishes the job.
It never breaks a live page. A page whose design no longer resolves is skipped, exactly as above.
It never publishes anything the design would not. The design’s timeline choices, private fields, and excluded documents all still apply — automatic republishing changes when a page updates, never what it may show.

With Living passport off, pages stay frozen until someone republishes them, which is the right default for a certificate-like page that should change only when a person decides it should.

Editing a design after pages are live

Published pages never change underneath you. A design’s edits are saved as a draft that affects nothing public until you publish the design.

Publishing a design freezes a version

Publishing a design freezes its saved draft as a numbered Design Version — v1, v2, v3 — and that version never changes again. Publishing on its own changes nothing the public sees: every live page stays on the version it is already using until you roll the new one out. So you can publish a version as soon as it is ready and decide separately when your pages should move to it.

Within Public Pages, “version” names exactly this and nothing else. A page’s own publishing history is dated rather than numbered.

Rolling out a version

Roll out is the single action that moves a design’s pages onto its newest version. You choose the design and, if you want, narrow it to a scope; DICE does whichever of these the change requires:

Appearance and wording only — reordering blocks, changing text, labels, colour, or logo. Rolling out is instant: pages move to the new version without republishing any page data.
What the page pulls — adding or changing bindings, changing a block’s file source, or changing which history a page shows. Rolling out re-publishes each page from its Thread’s current data, as a Publish Wave you can watch.

DICE tells you which of the two you are looking at when you publish the design, so you know what rolling out will involve before you start it. You never pick the mechanism — you pick the version and the scope.

Rolling out is a publisher action, and it is a fleet-scale one: it belongs to the design, not to an individual page.

Versions and history

Each page keeps its five most recent publications — plus whichever one is currently live, however old it is — so you can see what it showed previously; the most recent publication is what visitors see. The trimming happens as part of publishing: each time a page publishes, anything older than that is discarded there and then, so a page republished by every wave never grows without bound. A publication is identified by the date and time it was published, never by a number — numbers belong to Design Versions alone.

Latest and in use

A design’s latest version is simply the newest one published. The versions in use are the ones live pages are actually on. These are different facts, and DICE labels them separately wherever a version appears, so a version number is never mistaken for “what the public sees”.

Because rolling out is a deliberate act and waves can be scoped, one design is normally in use on several versions at once — one product line still on v2 while a newer line sits on v3. That is the expected steady state rather than a problem to fix, and the designs list flags a design whose pages have not all moved to the latest version, so you can finish the rollout when you choose to.

A design’s version history lists every version it has published, who published it, when, and how many pages are on each, and lets you read any version’s frozen contents. It exists for audit and diagnosis, so every team member can open it; publishing and rolling out stay with publishers.

Version history is a record

Version history is a record of what happened, not a set of save points. A published version is never brought back, and a page is never returned to older data. If a version is wrong, correct the design, publish a newer version, and roll that one out — which is always available and takes the same two steps as any other change.

This is deliberate. Pages are published from Thread data as it stands at that moment, so returning to an older Design Version would reproduce that version’s layout filled with today’s data — never the page that was actually live. Moving forward is the only action that means what it says, so it is the only one offered.

Unpublishing

Archiving a Public Page stops serving it immediately. The page’s link keeps existing but returns a generic not-found response — the same response an unknown link gets, so nothing is revealed about the item. Its configuration and design assignment are kept, so republishing later is a single action.

Unpublishing is also the way to take one item’s page down when its history or data should not be public: pages are produced by a shared design, so the control for one page is whether it is published at all.

What visitors can and cannot see

Visitors see only what the design pulls, and only for a published page.
Files are delivered so that they can never run as code in a visitor’s browser, and a file the page does not display cannot be fetched through it.
Making a file private or archiving it stops it being served straight away — without waiting for a republish. Its entry can still be listed on the page until the next publish, where it will no longer resolve.
Making a field private, or hiding an event, takes effect on the next publish. The same is true of retracting a recorded entry: the published page keeps showing the claim as it stood until you publish again, after which it appears struck through and marked Withdrawn. A published page serves the snapshot it was published with, so use Unpublish if something needs to come down immediately.
Public pages are not indexed by search engines.
Page views and verification scans are recorded for you as page activity. The public page never shows visitor information to anyone, and no visitor identity is collected.

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