IFC Digital Twin: IFC 4.3 and openBIM Connecting BIM Models to Live IoT Data (2026)

Most building digital twins fail at the same unglamorous joint: the sensor says AHU-03/SAT and the model says nothing of the sort. An IFC digital twin is supposed to fuse a geometric, semantic building model with live telemetry, yet in practice teams spend months hand-matching spreadsheet rows to model objects, and the mapping rots the first time someone renovates a floor. The model is rich and static; the data is poor and fast; the join between them is where projects bleed budget.

This matters now because the openBIM stack has finally matured enough to make that join systematic. IFC 4.3 is an ISO standard (ISO 16739-1:2024), the Information Delivery Specification (IDS) became an official buildingSMART standard in 2024, and BCF gives you a vendor-neutral issue loop. This article argues that the winning pattern is a thin, explicit binding layer keyed on stable IFC identifiers, guarded by machine-checked requirements, rather than loading telemetry into the BIM file.

What this covers: the standards landscape, a reference architecture, the binding table mechanics with worked numbers, validation with IDS, the BCF feedback loop, failure modes, and a practical checklist.

Context and Background

Building Information Modelling (BIM) produces a structured description of a facility: spaces, walls, ducts, air handling units, the relationships between them, and the properties that describe them. The Industry Foundation Classes (IFC) schema is the open, vendor-neutral way to express that description. The buildingSMART organisation maintains IFC and the family of “openBIM” standards around it, so that a model authored in one tool can be read in another without a proprietary converter.

The current official version is IFC 4.3 (4.3.2.0 on the buildingSMART standards page), also published by ISO as ISO 16739-1:2024. The earlier IFC 4 (4.0.2.1) and IFC 2×3 (2.3.0.1) are still official and still widely exported, which matters because your twin will meet all three in the wild. The recommended exchange encoding for these versions is the STEP Physical File format (SPFF), the familiar .ifc text file. IFC is also undergoing a major refactor under the working title IFC 5, which buildingSMART describes as in development with an alpha released; no final date is published, so this article treats IFC 5 as something to watch, not to build on. Source: buildingSMART IFC overview.

IFC 4.3 is notable because it extended the schema beyond buildings to infrastructure. The ISO announcement was reported in January 2024 (buildingSMART announcement). For a digital twin practitioner, the relevant part is that one schema now spans a hospital’s HVAC and the road or rail alignment outside it, which makes campus and portfolio twins plausible on a single semantic backbone. I am deliberately not listing the infrastructure entity names here beyond what I verified; check the IFC 4.3 documentation for the exact classes your project needs.

The other half of the picture is the IoT side. Building systems speak BACnet, Modbus, OPC UA and increasingly MQTT. They emit point names assigned by a controls contractor, usually with a local convention. Those names rarely carry the IFC GlobalId, because the controls engineer never opened the model. The industry’s older answer was “put it all in COBie spreadsheets”; the modern answer is to treat the BIM model as the authoritative asset register and build a deliberate bridge. For context on how geometry formats travel alongside IFC in a twin, see our comparison of lightweight CAD formats for digital twins, which covers why glTF-style delivery is often used for the viewer while IFC remains the semantic source.

It is worth being precise about what a “digital twin” is in this setting, because the term is overloaded. A twin that simply shows a 3D model with a colour overlay is a visualisation. A twin that supports questions such as “which zones will exceed 26 degrees Celsius if chiller 2 trips, and which tenants are affected” needs topology (what feeds what), semantics (what kind of thing is this), and live state. IFC supplies the first two; IoT supplies the third; the binding layer is what makes them one system.

Reference Architecture: Model as Registry, Telemetry as Stream

The central design decision is where each kind of data lives. The model holds slow-changing, high-structure facts: element identity, type, location in the spatial tree, system membership, and nominal properties such as design airflow. The telemetry store holds fast-changing, low-structure facts: timestamped numeric samples. The binding layer is a small, explicit table that maps telemetry points to model elements and properties. The reasons are practical, and the rest of this article is a defence of them.

Figure 1: Reference architecture for an IFC digital twin. The IFC model and the telemetry stream stay separate and meet only in the binding layer.

The diagram shows two pipelines that converge. On the left, authoring tools export IFC 4.3, an IDS gate checks it, and an index of elements by GlobalId is built. On the right, building-management-system (BMS) and IoT data flow through an ingest and tag-mapping stage into a time series store. The binding layer joins them, and viewers and analytics sit on top. A BCF loop returns problems to the authors.

Direct answer: an ifc digital twin works by keeping the openBIM model as the asset registry and joining live IoT data to it through a binding table keyed on IFC GlobalId, with IDS validating the model and BCF returning defects to authors. Telemetry is not stored in the IFC file.

Why not write telemetry into the IFC file

It is tempting to stuff live values into property sets, because IFC can express properties. Do not. A STEP file is rewritten as a whole when exported, there is no concurrency model, and a single temperature sample per minute for one sensor is 1,440 values per day. Even a modest twin with 5,000 points sampled every 60 seconds produces 7.2 million samples per day (5,000 x 1,440). The arithmetic is illustrative, but the conclusion is robust: no file-based exchange format is designed for that write rate.

What belongs in IFC is the definition of the point, not its stream: that this air terminal has a supply air temperature sensor, what unit it uses, what its design range is. The stream belongs in a time series database, and the key that connects them is the IFC GlobalId, a 22-character compressed form of a 128-bit GUID that every rooted IFC entity carries.

The spatial and system skeleton

IFC organises a facility as a tree of spatial elements: project, site, building, storey, space. Physical elements are contained in that tree. Separately, elements join systems (for example a supply air system) via grouping relationships, and distribution elements connect through ports. Both views matter to a twin: the spatial tree answers “what is on level 3”, the system and port graph answers “what feeds this room”.

Figure 2: A slice of the IFC 4.3 entity graph a twin uses: spatial containment, port connectivity, property sets and system grouping.

Figure 2 is a simplification, but each relationship exists in IFC: spatial structure uses aggregation and containment relationships, property sets are attached through IfcRelDefinesByProperties, ports connect through IfcRelConnectsPorts, and system membership uses group assignment. When you build the twin’s graph, you are essentially flattening these relationships into a queryable structure, commonly a property graph or an RDF graph.

Choosing the graph representation

You have three realistic options for the semantic index, and the trade-off is about query shape, not fashion.

In-memory object model through a library such as IfcOpenShell. Fastest to prototype, good for batch jobs, poor for multi-user serving.
Property graph (nodes for elements, edges for relationships). Natural for “what is downstream of this chiller” traversals.
RDF/OWL graph. Good when you must align with other ontologies and run SPARQL, at the cost of tooling weight.

The choice does not change the binding contract. Whichever you pick, the unique key is the GlobalId and the graph must be rebuilt, or incrementally updated, when a new IFC revision lands. I recommend treating the graph as a derived, disposable projection of the IFC file: if you can rebuild it in minutes, you never have to defend it as a source of truth.

The Binding Layer: From Point Names to GlobalIds

The binding table is where an IFC digital twin is won or lost. Each row says: telemetry point P describes property X of element E. Concretely, a row carries the point identifier from the BMS or IoT platform, the element’s GlobalId, the target property set and property name, the unit, and a confidence or provenance flag.

Figure 3: Runtime path for one sample. The binding table is a lookup, not a transformation, so ingest stays fast and the model is never touched.

Anatomy of a binding row

A minimal row, expressed as JSON for clarity, looks like this:

{
  "point_id": "bacnet://10.2.4.17/AV/203",
  "ifc_global_id": "2O2Fr$t4X7Zf8NOew3FNr2",
  "ifc_class": "IfcAirTerminal",
  "pset": "Pset_AirTerminalTypeCommon",
  "property": "SupplyAirTemperature",
  "unit": "degC",
  "source": "name-match-v3",
  "confidence": 0.94,
  "valid_from": "2026-03-01T00:00:00Z"
}

Note the valid_from field. Buildings change, and a binding is only true for a period. If a controller is replaced and its point renumbered, the old row must be closed, not overwritten, or historical analytics will attribute last year’s data to the wrong element. This bitemporal habit is cheap to adopt on day one and miserable to retrofit.

The GlobalId in the example is a placeholder in the correct 22-character style; it is not a real element.

How rows get created

There are three sources, in descending order of quality.

Designed-in. The model contains the sensor or point as an element (for example an IfcSensor with a predefined type) and the controls submittal references its GlobalId. This is the ideal and requires coordination before construction.
Rule-based matching. A script matches point names to elements using tag conventions, equipment schedules and spatial hints. Typically you can auto-bind a large majority of points, and a human reviews the rest. The exact auto-bind rate varies enormously with how disciplined the naming convention was; I do not cite a universal figure because I have none that is verifiable.
Manual. A commissioning engineer clicks a point and an element. Accurate, slow, and the source of most orphaned bindings when nobody updates it after changes.

Worked example: sizing a binding effort

Take an illustrative 40,000 square metre office with a single BMS. Suppose it has 120 air handling or fan coil units and 1,800 BMS points (illustrative numbers, not a measured project). If rule-based matching binds 80 percent automatically, 360 points remain for review. At an assumed three minutes per manual decision, that is 1,080 minutes, or 18 hours of engineering time. If the matching rate were 50 percent, the manual pile becomes 900 points and 45 hours. The point is not the specific figures but the sensitivity: each ten-point improvement in automatic matching saves roughly 180 points of manual review at this scale, so investing in naming discipline during construction pays back during every future renovation.

Keeping the join stable: GlobalId discipline

The whole design assumes GlobalIds survive. They do not always. Authoring tools may regenerate identifiers when an element is deleted and redrawn, when a model is split or merged, or when a file passes through a lossy converter. Some round-trips preserve them; some do not. The mitigation is procedural and technical:

Require, through IDS, that every element in the delivered model carries a GlobalId and a stable asset tag in a named property.
Store the asset tag in the binding table too, so a changed GlobalId can be re-resolved by tag rather than orphaned.
Diff each new IFC revision against the previous one (by GlobalId and by tag) and alert on disappearances of bound elements.

That last step turns silent drift into a ticket, which is where BCF comes in.

Validation and the Feedback Loop: IDS and BCF in Practice

A binding layer is only as good as the model it binds to. The traditional weakness of BIM handover is that “the model is delivered” and “the model is usable” are different statements. IDS exists to make the second statement testable.

What IDS actually checks

The Information Delivery Specification became an official buildingSMART standard on 1 June 2024, as IDS 1.0; buildingSMART lists IDS 1.1 and 2.0 as planned. It is an XML file defined by an XML Schema. An info block carries title, version, author and date. A specifications container holds one or more specification elements, each declaring the IFC version it targets. Each specification has an applicability section that selects objects (for example all IFCAIRTERMINAL entities) and a requirements section that states what must be true of them: a property in a named property set, a data type, allowed values, a classification, and cardinality. Source: buildingSMART IDS page.

For a twin, the highest-value IDS rules are not about geometry. They are:

Every monitored equipment class must carry a stable asset tag property.
Every such element must be contained in a space or storey, so spatial queries work.
Every element in a controlled system must be assigned to an IfcSystem group with a name matching the controls scheme.
Property units and enumerations must come from an agreed list so that the binding table’s unit conversions are deterministic.

The key insight is that IDS turns the owner’s information requirement into an executable gate. Instead of a PDF stating “assets shall be tagged”, you supply an XML file that fails the model if they are not. This shifts defect discovery from commissioning, where fixing is expensive, to design milestones, where it is cheap.

Worked example: an IDS rule in spirit

Conceptually, a rule for supply air sensors reads: applicability is every IFCAIRTERMINAL; requirements are that property AssetTag in a project property set exists as a string, matches an agreed pattern, and occurs exactly once. The XML is verbose; most teams author it in a tool rather than by hand. I do not reproduce the XML here because I have not run it against a validator in this session, and an untested schema snippet is worse than none. The official documentation and the test suite on the buildingSMART IDS page are the right references.

If an audit run reports, say, 47 of 320 air terminals missing a tag, you now have a number, a list of GlobalIds and a clear owner. That is a measurable acceptance criterion, which procurement documents rarely achieve.

BCF: closing the loop in a vendor-neutral way

The BIM Collaboration Format (BCF) carries issues: a title, a description, a viewpoint (camera position, visible and selected components referenced by GlobalId), a status and comments. buildingSMART publishes both a file-based form (BCF-XML) and an API form. I could not confirm the current version numbers from the buildingSMART page I fetched, so check the BCF documentation for the version your tools support before committing to a contract.

For a twin, BCF is the return channel. Consider three event types:

IDS failure creates a BCF topic addressed to the model author, with the failing GlobalIds attached.
Orphaned binding (a bound element disappears from a new revision) creates a topic addressed to the BIM coordinator.
Telemetry anomaly with no model explanation (a sensor stream has no element, or an element should have a sensor and has none) creates a topic for the controls contractor.

Because BCF viewpoints reference elements by GlobalId, the same key that underpins the binding table, the issue lands in the authoring tool already zoomed to the right object. That is the practical value of a shared identifier discipline: one key, three workflows.

Figure 4: The handover loop. Failed IDS audits and orphaned points both route back to authors as BCF issues until the twin is operational.

The bSDD link

buildingSMART also maintains the Data Dictionary (bSDD), which lets classifications and properties from outside IFC be linked to IFC content. For twins it is useful as a shared vocabulary for property names and units, so that the BMS vendor and the BIM author do not each invent their own words for “supply air temperature”. I could not verify a current version number, so I treat it here as a vocabulary service you reference by URI rather than a fixed artefact.

Deeper Analysis: Implementation, Serialization and Scale

Reading IFC in code

For prototyping, IfcOpenShell is the commonly used open-source toolkit. The sketch below shows the pattern of indexing elements by GlobalId and reading a property. It follows the library’s documented API shape, but I have not executed it in this run, so treat it as untested and check it against the version you install (IfcOpenShell docs).

# Untested sketch: index IFC elements for a twin binding layer
import ifcopenshell
import ifcopenshell.util.element as el

model = ifcopenshell.open("handover.ifc")
index = {}
for e in model.by_type("IfcAirTerminal"):
    psets = el.get_psets(e)
    tag = psets.get("Pset_Project", {}).get("AssetTag")
    index[e.GlobalId] = {"tag": tag, "name": e.Name}

# Re-resolve a binding whose GlobalId vanished
def resolve(binding, index):
    if binding["gid"] in index:
        return binding["gid"]
    for gid, row in index.items():
        if row["tag"] == binding["tag"]:
            return gid
    return None  # raise a BCF topic: orphaned binding

The Pset_Project name is a placeholder for whichever project-specific property set your IDS mandates. The design point is the fallback: resolve by GlobalId first, by asset tag second, and escalate when both fail.

Serialization choices

The recommended exchange encoding for IFC 2×3, IFC 4 and IFC 4.3 is the STEP-based .ifc file. buildingSMART’s overview notes IFC can be encoded in other formats without naming them in the page I fetched. In practice, teams also meet XML and JSON encodings, and the web-friendly route for twins is often to convert the semantic content into a graph or JSON structure server-side and send the viewer a lightweight geometry format. I have not verified current specification status for the JSON serialization, so the guidance here is architectural: use STEP IFC as the interchange artefact of record, and treat any JSON or graph form as a derived projection that you can regenerate.

Why does that matter? Because the derived forms are where optimisation lives. A viewer does not need 3,000 property sets per wall; it needs geometry, names and a handful of properties. Splitting “interchange truth” from “serving projection” lets you tune the latter for latency without compromising the former.

Sizing the serving path

Consider an illustrative twin with 5,000 bound points and one-minute sampling, as before. At 7.2 million samples per day, with an assumed 40 bytes per sample in a compressed time series store (a plausible but unmeasured figure), raw daily ingest is about 288 MB, or roughly 105 GB per year before downsampling. Retaining one-minute data for 30 days and 15-minute rollups for the rest cuts long-term storage by an order of magnitude, since 15-minute rollups are one fifteenth the sample count. The takeaway: telemetry volume dwarfs model size, which supports keeping them in separate systems with separate retention policies.

The read path matters as much. A viewer colouring 800 visible elements by current value needs 800 latest-values, not 800 histories. Cache “latest value by GlobalId” in a key-value store updated on ingest. A cold query then costs one batched lookup instead of 800 range scans, and the model viewer stays interactive.

Time alignment and units

Two subtler issues bite in practice. First, clocks: BMS timestamps, gateway timestamps and cloud ingest timestamps differ, and a 90 second skew will wreck cause-and-effect analysis between a damper command and a temperature response. Record both source time and ingest time and prefer source time for analytics. Second, units: IFC stores values with units declared in the project’s unit assignment, whereas BMS points may report Fahrenheit, kilopascal or percent open without saying so. Normalise at the binding layer, using the unit column in the binding row, and reject samples outside physical plausibility bounds (for example supply air temperature far outside the equipment’s declared range) instead of storing them silently.

Where MPC and analytics plug in

Once points are bound to elements and elements are connected through systems, higher-level control becomes tractable. A model-predictive controller needs a plant model: which zone is served by which air handler, thermal capacities, and constraints. The IFC system and port graph supplies the topology and nominal parameters; live telemetry supplies the state. We cover the control side in our article on model predictive control for digital twins, including constraints and horizon choice. The IFC contribution is not the controller; it is the guarantee that “zone 4.12” in the optimiser is the same object as “zone 4.12” in the model and the BMS.

A related pattern appears in robotics, where a learned policy needs a faithful world model of the cell it operates in. Our overview of ACT and action chunking for imitation learning covers the policy side; the shared lesson is that a trustworthy semantic model of the environment is what lets learning-based systems transfer between sites.

Comparison: ways to join BIM and IoT

Approach	Strength	Weakness	Best when
Telemetry inside IFC properties	Single artefact	Write rate, no concurrency, file rewrites	Never for live data
Spreadsheet (COBie style) mapping	Familiar, auditable	Rots after changes, no relationships	Small static handover
Binding table keyed on GlobalId	Explicit, versioned, fast	Needs identifier discipline	Most operational twins
Ontology-first graph with live links	Rich queries, interoperable	Heavy tooling, skills gap	Portfolio or campus twins
Vendor platform proprietary mapping	Quick start	Lock-in, opaque	Pilot with exit plan

The table is a judgement, not a benchmark. The ranking reflects my view of operational cost over a ten-year asset life, where the dominant cost is keeping mappings correct through change.

Infrastructure and campus scale

Because IFC 4.3 extends coverage to infrastructure, the same binding approach scales outward: a campus twin can hold buildings, roads and utility corridors under one project and key sensor streams to elements in any of them. The caveat is that tool support for the infrastructure entities is uneven across vendors, so verify what your authoring and viewing software actually exports and imports before you design around it. A schema that can express a thing and a toolchain that can round-trip it are different claims.

Versioning the model without breaking the twin

Models change monthly during construction and sporadically afterward. A sound revision policy has four rules. Each delivered IFC gets an immutable revision identifier. The graph projection is rebuilt per revision, and the binding table is evaluated against the new graph before the revision is promoted. Promotion is blocked, or at least flagged, when bound elements vanish. Finally, the operational twin pins a specific revision, so analytics are reproducible. The trade-off is operational overhead, but it is much smaller than the cost of chasing phantom sensor faults that are really renamed elements.

A useful diff has three categories: elements added (candidate new bindings, needing a point), elements removed (binding orphans), and elements modified in a way that changes meaning (class change, relocation to another space, system reassignment). The third category is the dangerous one, because bindings still resolve technically while meaning has shifted. A temperature sensor bound to a duct that has been re-routed to serve a different zone will report faithfully and mislead completely. Detect it by comparing the spatial container and system membership of every bound element between revisions, and open a BCF topic for any change.

Trade-offs, Gotchas, and What Goes Wrong

Identifier loss. The most common failure is GlobalId churn across tool round-trips. Mitigate with asset tags, IDS rules and revision diffs, as above. Never assume that two exports of “the same” model share identifiers; test it on your toolchain early.

Over-modelled, under-instrumented. Teams model every bolt and bind four sensors. The bind cost is per point, not per element, so focus modelling effort on the equipment that will carry telemetry or drive decisions. Level of detail in geometry and level of information in properties are different dials, and the twin cares mostly about the second.

Schema coverage versus tool coverage. IFC 4.3 can express more than many applications export. Before relying on a class or property set, run a round-trip test with your actual authoring and viewing tools, and write the results down.

IDS gives false confidence. A passing IDS audit means the checked requirements are met, not that the model is correct. A tag can be present and wrong, or unique and assigned to the wrong element. Combine IDS with commissioning checks that compare live behaviour to the model: if the “supply air temperature” of an element never changes while its fan runs, the binding is suspect.

Semantic drift in naming. Controls contractors rename points during tuning. If your rule-based matcher relies on names, every rename silently breaks bindings. Prefer binding on stable controller addresses or object identifiers, with names as hints only.

Security and safety. Linking an IFC model to live systems exposes a map of the building to whoever can read the twin. Treat the binding layer and graph as sensitive, apply least privilege, and keep the twin read-only with respect to control networks unless a deliberate, reviewed write path exists. Do not let a twin command actuators on the strength of an unvalidated binding; a wrong GlobalId is a wrong actuator.

IFC 5 uncertainty. IFC 5 is in development with an alpha announced, and no firm date is published. Building a production twin tightly on alpha material is a risk. The defence is architectural: because the graph is a disposable projection of the interchange file and the binding table is keyed on identifiers, migrating the interchange format later means regenerating the projection and re-resolving identifiers, not rewriting the twin. Keep that seam clean and the future version becomes an upgrade rather than a rebuild.

Anti-pattern: the monolith viewer. Some teams load the full IFC into the browser and compute everything client-side. It works for demos and fails at scale because parsing, memory and security all sit on the client. Serve a trimmed projection instead.

Practical Recommendations

Start from the requirement, not the tool. Write down the five questions the twin must answer, derive the minimum set of element classes and properties needed to answer them, and encode those as IDS rules before design progresses. This keeps modelling effort aimed at operations rather than at completeness.

Make identity a first-class deliverable. Demand a stable asset tag and a GlobalId on every monitored element, test that identifiers survive a round-trip between your authoring and viewing tools, and store both in the binding table. Version the binding table with validity periods so history stays truthful through change.

Keep the architecture boring. Interchange in STEP IFC, a rebuildable graph projection for queries, a time series store for samples, a key-value cache for latest values, and a narrow binding service between them. Resist writing telemetry into the model. Wire BCF to your audit and diff jobs so defects reach authors in their own tools.

A short checklist you can adopt today:

[ ] IDS file covers asset tag, spatial containment, system assignment and unit enumerations.
[ ] Every delivered IFC revision is immutable and audited before promotion.
[ ] Binding rows carry GlobalId, asset tag, unit, source, confidence and validity period.
[ ] A revision diff flags removed elements, reclassified elements and changed system or space membership.
[ ] Orphaned bindings and IDS failures open BCF topics automatically.
[ ] Latest-value cache keyed by GlobalId serves the viewer.
[ ] The twin is read-only toward control networks unless a reviewed write path exists.
[ ] A round-trip test documents which IFC 4.3 classes your tools really support.

Frequently Asked Questions

What is an IFC digital twin?

An IFC digital twin is a digital twin whose semantic backbone is an IFC building model, linked to live data from sensors and building systems. The IFC file supplies identity, type, location and relationships for each element; a separate time series store supplies current and historical values; and a binding layer keyed on IFC GlobalId joins the two so applications can query live state by model element.

Is IFC 4.3 an official standard?

Yes. IFC 4.3 (listed as 4.3.2.0 on the buildingSMART standards page) is published by ISO as ISO 16739-1:2024. IFC 4 (4.0.2.1) and IFC 2×3 (2.3.0.1) remain official versions and are still common in exported models, so a practical twin must be able to ingest all three, with the recommended exchange format being the STEP-based .ifc file.

Should I store sensor data inside the IFC file?

No. IFC files are exchanged and rewritten as whole documents, have no concurrency model, and are not built for high write rates. A modest 5,000-point twin sampled each minute yields about 7.2 million samples per day. Store the definition of each point in the model if useful, keep the stream in a time series database, and join them through GlobalId-keyed bindings.

What are IDS and BCF, and how do they differ?

IDS (Information Delivery Specification, official as IDS 1.0 since 1 June 2024) is an XML-defined set of machine-checkable requirements telling authors what information a model must contain. BCF (BIM Collaboration Format) carries issues with viewpoints referencing elements. Put simply, IDS says what must be true and checks it, while BCF communicates the defects and tasks that result.

Is IFC 5 ready to build a twin on?

Not for production. buildingSMART describes IFC 5 as a major refactor in development, with an alpha released and no published final date. Build on IFC 4.3 now, keep your graph projection and binding table decoupled from the interchange encoding, and monitor the IFC 5 development repository so a later migration is a regeneration step rather than a redesign.

How do I keep sensor bindings from breaking when the model changes?

Version bindings with validity periods, store a stable asset tag alongside the GlobalId, and diff every new IFC revision against the previous one before promoting it. Flag removed elements, reclassified elements and changed system or space membership, and open a BCF topic for each. Resolve bindings by GlobalId first, then asset tag, and escalate when neither matches.