Material-Passport Schema and Interoperability
Define the material passport as a layered, machine-readable schema before collecting data, so BIM models, product passports, owner systems, certification tools, and reuse marketplaces can exchange the record without reinterpreting it by hand.
Also known as: Material Passport Data Model; Material Passport Schema; Building Material Data Template; Circular Building Data Schema
Understand This First
- Material Passport — the record whose fields this pattern structures.
- Digital Product Passport (DPP) for Construction Products — the product-level evidence the schema may reference.
- BIM-Linked Material Tracking — the model-side workflow that authors and maintains many schema fields.
This entry describes a recurring information-management pattern. It isn’t BIM execution, product-compliance, engineering, legal, procurement, valuation, or software-architecture advice. A qualified professional has to define the binding information requirements for a specific project, owner, platform, and jurisdiction.
Context
A material passport is only useful if other systems can read it. The design model needs to export quantities and classifications. Suppliers need to attach product evidence. Contractors need to update installed products. Owners need the record in an asset system. Certifiers, lenders, deconstruction contractors, and reuse marketplaces need enough consistency to compare one component with another.
That doesn’t happen because a team agrees to “make a passport.” It happens because the passport has a schema: a defined set of fields, identifiers, units, classifications, evidence links, quality states, and access rules. Without that field discipline, every passport becomes a bespoke dossier. A human can still read it, but the information can’t travel reliably.
This pattern sits below Material Passport, Building Resource Passport (BRP), and BIM-Linked Material Tracking. It is the quiet data-model work that decides whether those records become infrastructure or one-off reports.
Problem
Circular construction asks many actors to coordinate around the same physical material stock, but each actor speaks a different data language. The architect has object types and specifications. The contractor has procurement records and substitutions. The manufacturer has product declarations and batch identifiers. The BIM manager has IFC exports. The owner has asset registers. The reuse marketplace needs a sellable listing.
If the passport schema is vague, these records don’t align. A wall panel may have a product name in one file, a generic material label in another, an IFC classification in the model, a declaration of performance in a PDF, and a circularity score in a platform field. A future recovery team then has to reconcile the same component again from scratch.
Forces
- Different systems need different granularity. A product passport may identify a product model or batch, while a building passport may care about installed location, condition, and recoverable quantity.
- The schema must be detailed but not impossible. Every required field raises the cost of data collection, checking, and stewardship.
- Identifiers carry the chain of custody. Without stable object, product, document, and asset identifiers, the record can’t prove which evidence belongs to which component.
- Standards overlap. IFC, ISO 19650 information management, product data templates, DPP standards, classification systems, and platform fields all cover part of the territory.
- Bad interoperability creates manual translation work. Teams fall back to spreadsheets when the schema can’t move cleanly between model, platform, and owner system.
Solution
Define the material passport as a layered schema before data collection starts. The schema should say which fields are required, which are optional, who owns each field, what unit and classification each field uses, how confidence is recorded, and how the field maps to BIM, product-passport, owner, certification, and marketplace systems.
A practical schema usually has eight layers.
| Layer | Typical fields | Interoperability test |
|---|---|---|
| Identity | Passport ID, asset ID, object GUID, product ID, manufacturer, model, batch, serial number, and document IDs. | Can another system tell which physical item or product family the record describes? |
| Classification | IFC type, Uniclass, OmniClass, eBKP, local cost code, building layer, system, and material group. | Can the record be grouped consistently across design, cost, facility, and recovery systems? |
| Geometry and quantity | Count, area, volume, length, mass, dimensions, room, floor, grid, and coordinate or zone. | Can the quantity be checked against the model or survey without remeasurement? |
| Composition | Material fractions, coatings, additives, hazardous substances, recycled content, reused content, renewable content, and separability. | Can reuse, recycling, health, and waste routes be evaluated from the record? |
| Evidence | EPDs, declarations of performance, certificates, test reports, warranties, maintenance records, and inspection history. | Can a reviewer open the source evidence and see its date, scope, and issuer? |
| Circularity and recovery | R-strategy route, detachability, access condition, connection type, expected life, take-back terms, reuse restrictions, and likely recovery route. | Can a future team distinguish reusable components from material destined for lower-value processing? |
| Data quality | Source type, measured or estimated flag, completeness, confidence score, update date, reviewer, and unresolved assumptions. | Can the passport admit weakness rather than presenting every field as equally reliable? |
| Access and governance | Field owner, access rights, confidentiality class, update responsibility, API or export format, and version history. | Can the data move while protecting legitimate commercial, safety, and privacy constraints? |
Do not treat this as a universal checklist. A small interior fit-out won’t need the same field depth as a long-life structural frame, and a concept-stage resource estimate won’t deserve the same confidence as an as-built record. The schema should define levels of information need by stage and component value.
The important move is to bind the schema to exchange formats early. If the project uses IFC, test whether GUIDs, base quantities, material descriptions, classifications, and custom property sets survive export. If suppliers provide digital product passports or product data templates, map their identifiers and documents to the installed object records. If the owner uses a building resource passport or asset register, map the same fields upward rather than rekeying them later.
Don’t make the schema a dumping ground for every field anyone can imagine. A bloated passport collapses under its own data burden. Require the fields that change future decisions, then mark optional or stage-specific fields honestly.
How It Plays Out
A new office project wants material passports for the structure, façade, raised floors, ceilings, lighting, and major plant. The team starts by defining information requirements by building layer. Structural steel needs grade, section size, connection notes, coating, inspection evidence, and future testing route. Lighting needs product identifiers, warranty, take-back terms, maintenance records, and replacement cycles. Gypsum board may need mass, recycled content, hazardous-substance status, and likely recycling route, but not serial-level identity. The schema lets each component carry the right amount of evidence.
A contractor substitutes a façade panel after tender. In a weak passport, the product name changes in a submittal folder while the model and circularity record keep the old description. In a schema-governed workflow, the substitution has to update the object ID link, product ID, material fractions, fire and acoustic evidence, EPD link, disassembly notes, and data-quality status. The change is annoying, but it’s visible.
A platform imports an IFC file and creates a building passport. The import only works because the model has stable GUIDs, base quantities, material descriptions, and classification coding. Where those fields are missing, the platform should not silently infer a complete record. It should mark the gap, ask for correction, or downgrade confidence. Interoperability is not the absence of errors; it is the ability to preserve meaning and uncertainty across systems.
A reuse marketplace receives a future listing for demounted ceiling panels. The marketplace needs product identity, dimensions, quantity, location, condition, fire performance evidence, acoustic rating, contamination status, and photographs. If the original passport schema treated those as optional notes, the listing may be impossible to trust. If the fields were structured, the marketplace can still inspect the panels, but it starts from comparable evidence.
Consequences
Benefits
- Makes passport data searchable, comparable, and transferable instead of a project-specific dossier.
- Reduces manual re-entry between BIM, supplier records, DPPs, building resource passports, certification tools, and reuse marketplaces.
- Exposes missing evidence early, especially product identity, material composition, location, quantity, recovery route, and confidence level.
- Supports asset-level aggregation because the BRP can read consistent fields from many component records.
- Gives owners a stewardship frame for updates after substitution, maintenance, tenant works, retrofit, and deconstruction.
Liabilities
- Adds information-design work before visible circularity benefits appear.
- Requires agreement between teams that may have different software, classification habits, commercial incentives, and data-quality standards.
- Can become too thin if the schema only records generic material mass, or too heavy if it demands fields nobody will maintain.
- Depends on active governance. A schema document doesn’t keep data current after handover unless responsibilities and triggers are assigned.
- Doesn’t solve trust by itself. Product declarations, test evidence, condition assessments, hazardous-material checks, and valuation still need qualified review.
Related Patterns
| Note | ||
|---|---|---|
| Complements | Digital Product Passport (DPP) for Construction Products | Product-passport data can feed building records only when identifiers, documents, and lifecycle fields can be mapped. |
| Complements | Disassembly-Ready Documentation Set | The schema records what a component is and where it sits; the documentation set records how to remove it. |
| Enabled by | BIM-Linked Material Tracking | BIM-linked tracking needs a schema that tells model objects which material, product, circularity, and evidence properties to carry. |
| Implements | Material Passport | The schema turns the material passport from a narrative record into comparable, queryable fields. |
| Mitigates | Disassembly-in-Theory | A usable schema reduces the risk that circularity claims survive only as project rhetoric. |
| Supports | Building Resource Passport (BRP) | Asset-level resource passports depend on consistent fields and data-quality rules from the records underneath. |
| Supports | Buildings as Material Banks (BAMB) | A material bank needs comparable inventory data before stored resources can be searched, valued, or recovered. |
| Upstream of | Salvaged Building Components Marketplace | Reuse marketplaces need comparable product identity, quantity, condition, location, and evidence fields. |
Sources
- Meliha Honic, Iva Kovacic, Goran Sibenik, and Helmut Rechberger’s 2019 Journal of Building Engineering article, “Data- and stakeholder management framework for the implementation of BIM-based Material Passports”, reports that BIM-supported material passports are possible but require stakeholder collaboration and life-cycle data platforms.
- Islam Atta, Emad S. Bakhoum, and Mohamed M. Marzouk’s 2021 Journal of Building Engineering article, “Digitizing material passport for sustainable construction projects using BIM”, presents a BIM-incorporated passport framework using deconstructability, recovery, and environmental indicators.
- Madaster’s Preparing BIM IFC source files documentation lists practical IFC import requirements, including unique GUIDs, base quantities, material descriptions, classification coding, product identifiers, detachability fields, reuse percentage, condition, and waste codes.
- buildingSMART International’s Industry Foundation Classes page describes IFC as an open, vendor-neutral ISO 16739 standard for machine-interpretable built-asset information.
- ISO’s ISO 19650-1:2018 standard page frames BIM information management across the whole built-asset life cycle, including design, construction, operation, maintenance, refurbishment, repair, and end-of-life.
- CEN-CENELEC’s 2024 note on the CircThread Digital Product Passport workshop describes DPP design questions around data carriers, information portals, information exchanges, lifecycle updates, and interoperability inside broader circular-economy information systems.