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.
A schema is the difference between a passport someone can read and a passport machines can use. If two teams record the same façade cassette with different names, units, identifiers, and confidence rules, the data may look complete while the asset remains hard to recover.
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 useful only when other systems can read it. The design model has to export quantities and classifications. Suppliers have to attach product evidence. Contractors have 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 transfer does not happen because a team agrees to “make a passport.” It happens because the passport has a schema: defined 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 cannot travel reliably.
This pattern sits below Material Passport, Building Resource Passport (BRP), and BIM-Linked Material Tracking. It is the data-model discipline 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 listing someone can trust.
If the passport schema is vague, these records do not 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 reconstruct the same component 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 stay maintainable. 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 cannot 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 cannot 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, and who owns each field. It should also define units, classifications, confidence rules, and mappings 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 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 updates the object ID link, product ID, material fractions, fire and acoustic evidence, EPD link, disassembly notes, and data-quality status. The change costs time, but it is 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 does not keep data current after handover unless responsibilities and triggers are assigned.
- Does not solve trust by itself. Product declarations, test evidence, condition assessments, hazardous-material checks, and valuation still need qualified review.
Related Articles
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.