A QR Code Is Not a Product Passport: Build the Evidence Chain

The revised EU Construction Products Regulation defines a future construction digital product passport around more than a scannable carrier. It calls for accurate, complete, and current information; persistent identifiers; open, interoperable and machine-readable data; differentiated access; integrity and security; and continued availability. The European Commission’s central DPP registry became operational on 20 July 2026, while its published timeline identifies construction-product and service-provider requirements for a still-indicative Q2 2027 delegated act. [1][2]

This is not an instruction to import EU compliance into an Iranian contract. It is a useful design signal: a QR code only opens a location. If the destination can disappear, the product identity is ambiguous, the file has no revision status, or nobody records where the accepted item was installed, the project has a shortcut—not a passport. OlbrichCo’s operating view is to build the evidence chain first and choose the carrier second.

ISO 22095 provides general chain-of-custody terminology, models, and management requirements for materials and products. It also makes an important limitation explicit: a chain-of-custody system can improve transparency, but its existence alone does not verify a product claim or describe the conditions under which the product was made. Traceability must therefore connect to technical acceptance evidence; it cannot replace it. [5]

Do not start by tagging every fastener. Rank product families by consequence, substitution risk, concealment, replacement lead time, maintenance dependency, and value of later retrieval. A project may prioritise waterproofing systems, fire-stopping assemblies, façade fixings, structural connectors, safety-critical finishes, valves, drives, controls, electrical protection, and maintainable equipment. The responsible designers and contract team should decide the list; the software vendor should not.

ISO 23386 sets rules for defining, governing, and maintaining construction properties in interconnected data dictionaries. ISO 23387:2025 supplies a standardised structure for machine-interpretable data templates across an asset’s life cycle. buildingSMART’s bSDD shows the practical semantic layer: classes, properties, definitions, units, allowed values, relations, versions, and translations can be shared so that the same field does not acquire a different meaning in every spreadsheet. [3][4][6]

For an Iranian project, the minimum record should be small enough to complete under real procurement and site conditions. Define Persian display names and, where needed, English technical terms; state the unit and calendar convention; distinguish required, optional, supplier-declared, laboratory-verified, designer-approved, and site-observed values. Keep the original supplier document beside structured fields. A translated value helps use; it must not silently replace the language and revision of the source evidence.

GS1 EPCIS is a cross-industry visibility standard for sharing the what, when, where, why, and how of products and other assets. Its event logic is useful to construction even when a project never implements EPCIS software: identity alone is static; traceability comes from controlled events that change location, condition, custody, or status in a defined business context. [7]

Write the event chain into the inspection and procurement plan. An approved submittal does not prove that the delivered batch is the same product. A delivery photograph does not prove that the item reached the correct zone. An as-built model does not prove that the concealed installation passed its hold point. Each gate needs an accountable actor, required evidence, a pass or quarantine status, and a rule for correction.

The EU construction-passport framework separates a product type and its unique identification code, connects the passport to a data carrier, and requires open, transferable data without vendor lock-in. That architecture helps clarify three different identities on a project: the specified product type, the supplier’s batch or serial identity, and the installed asset or location identity. Collapsing them into one code makes substitutions and split deliveries difficult to audit. [1]

Assign project identifiers before mobilisation and never recycle them. Preserve supplier identifiers rather than rewriting them; relate them to the project code. When connectivity is unreliable, let the site capture a controlled offline event with device time, user, location, and pending status, then synchronise without overwriting the earlier record. Require an open export—such as structured CSV or JSON plus the native source documents—and test restoration on a machine that does not depend on the original platform account.

Regulation (EU) 2024/3110 anticipates role-based access, authorised updates, data integrity, security, protection of sensitive commercial information, and availability after the originating economic operator ceases activity. ISO 22095 separately cautions that custody information does not itself establish the truth of a product claim. These safeguards explain why a mutable supplier webpage or a folder of undated PDFs is not enough for project acceptance. [1][5]

Retain the file actually reviewed, its issuer, date, revision, received filename, checksum or other integrity reference, reviewer, status, and supersession link. Give site staff only the fields needed to receive and install; protect commercial rates and sensitive layouts; preserve an auditable correction route. A proposed substitute starts a new comparison and approval record. It must not inherit the accepted status of the product it replaces merely because both records share a category.

Choose one high-consequence package with repeated deliveries and concealed work—for example a waterproofing system, fire-stopping zone, façade attachment family, or maintainable equipment set. During a 30-day pilot, define the minimum record, load one accepted product, receive two real deliveries, record a permitted and a rejected variation, link installations to locations, close one inspection, export the data, and ask someone outside the implementation team to retrieve the evidence.

Use a small scorecard: percentage of priority product types with an approved record before order; deliveries matched to an approved identity before release; installed quantities linked to a location; concealed work with closed inspection evidence; substitutions with completed technical comparison; orphaned or inaccessible source files; unresolved high-consequence deviations by age; and median time for an operator to retrieve the current instruction and installed identity. Always show the denominator beside a percentage.

The point of view is firm: the passport is a quality-control process expressed in data, not a QR-code campaign. It does not prove compliance, authenticity, fitness for purpose, or correct installation by itself. Final product approval, sampling, testing, statutory documentation, installation acceptance, retention, privacy, and access must follow applicable Iranian requirements, the signed contract, manufacturer instructions, actual site conditions, and review by the responsible professionals.