A public QR page should be useful to a scanner without exposing internal or sensitive asset information.
This guide is written for practical use: it focuses on information that should remain understandable after installation, handover, maintenance or staff changes. The objective is not to collect the maximum possible data, but to keep the right data structured, traceable and easy to use at the physical object.
Assume anyone can scan it
A QR label in a physical location can be photographed or shared. Public fields should therefore be intentionally safe for an unknown visitor.
Separate public and private views
Basic identity, instructions or selected documents may be public while internal notes, personal information and sensitive operational details remain authenticated.
Use explicit visibility
Visibility should be controlled per attachment and lifecycle event rather than inferred from where the file happens to be stored.
Keep identifiers opaque
Public URLs should use non-sequential tokens so that knowing one object URL does not make neighbouring records easy to enumerate.
Practical focus
Design the public page on the assumption that anyone can scan the code or share its URL. Useful public information and strong privacy can coexist when visibility is explicit and internal data is never inferred to be public by default.
Separate identity from changing data
The identifier on the physical object should remain stable while descriptions, ownership, documents and lifecycle information evolve. This reduces relabelling and preserves continuity across years of use.
- Use one durable object identifier.
- Keep mutable information in the digital record.
- Retain a human-readable ID even when QR or NFC is present.
Control what different audiences can see
A person standing next to the object may need a simple public page, while staff need internal notes, evidence and history. Public and private information should be deliberate rather than an accidental consequence of where a file was uploaded.
- Review public fields as if an unknown person scanned the tag.
- Keep sensitive documents behind authenticated access.
- Use explicit visibility for attachments and lifecycle events.
Preserve lifecycle context
A current status is useful, but it does not explain how the object reached that state. Dated events for inspections, maintenance, replacements and important changes make the record far more useful for future decisions.
How to put this into practice
Start with a small, consistent structure and test it on real objects before scaling. Define the naming rules, required fields, ownership of updates and what should happen after a change. A short documented process is more sustainable than relying on memory.
- Pilot the structure on a handful of real examples.
- Use the same field names and identifiers across labels, exports and digital records.
- Review the process after the first handover or maintenance cycle.
What good implementation looks like
The finished workflow should be understandable by someone who did not create it. A person should be able to identify the object, see the current state, find relevant evidence and understand significant changes without reconstructing the story from filenames or messages.
A practical implementation workflow
Treat the first version as an operational baseline rather than a one-off document. Start with a small representative sample, check that another person can understand the identifiers and fields without verbal explanation, then apply the same structure consistently. The workflow should be simple enough to repeat during installation, handover and later maintenance, because a technically perfect record that nobody keeps updated quickly loses value.
- Pilot the structure on a few real objects before rolling it out in bulk.
- Define which fields are mandatory and which are optional before importing or printing labels.
- Test links, QR codes and exported files on the actual devices and materials used in the field.
- Record who owns the data quality and who is expected to update the record after a change.
Review the record as part of the lifecycle
Good documentation is not finished when the first record is created. Review it whenever the physical object changes, when responsibility is handed over, or when an inspection or maintenance event reveals new information. A short periodic review is usually more reliable than trying to reconstruct several years of undocumented changes later. The aim is to keep the current view accurate while preserving enough history to understand important decisions.
- Update the current state after material changes instead of adding contradictory notes.
- Keep dated evidence for changes that may matter during troubleshooting, audit or handover.
- Retire obsolete information deliberately rather than leaving several competing versions in circulation.
Common mistakes to avoid
Avoid using sequential public URLs, treating a QR code as the permanent identity, exposing internal notes by default or creating a new object record every time a label is replaced.
A sensible next step
Choose one real object, assign a stable human-readable ID, create its digital identity and decide which fields, attachments and lifecycle events should be public or private.