ServiceNow Dynamic IRE: A UK CMDB Production Gate for Hardware Identification

Dynamic IRE is a Hardware identification gate — not a toggle you flip on Friday

ServiceNow's Australia family (and Zurich Patch 11+) ships Dynamic Identification and Reconciliation Engine (Dynamic IRE): a parallel-scoring identification engine for Hardware [cmdb_ci_hardware] and its descendants. It auto-updates identification rules during payload ingestion, and you cannot hand-edit its algorithms.

For UK CMDB owners, Discovery / Service Graph leads and CAB chairs, this is a data-quality and change-window moment. Static (legacy) IRE with mature manual rules can look "fine" until Dynamic IRE simulation shows insert/update/incomplete deltas you never budgeted for — or until a zBooted instance arrives already in committed mode.

Enterprise infrastructure and CMDB

What Dynamic IRE is — and what it is not

ServiceNow's stated benefits are higher match accuracy (fewer duplicates) and the end of continuous manual IRE rule maintenance. That is only true for UK production if simulation parity and Discovery cadence have been evidenced first.

Two modes you must keep separate

Simulation mode

Dynamic IRE and Static IRE both process payloads. Differences land in CMDB IRE Output Comparison Items [cmdb_ire_output_comparison_item]. After a meaningful Discovery / Service Graph window, compare effectiveness and performance.

Committed mode

Only Dynamic IRE runs; Static IRE is off. Property: glide.identification_engine.dynamic_ire_enabled=true. You can still Change to IRE (Static) later from CI Class Manager.

UK rule: never jump straight to committed on production. Simulate on a non-production instance that sees representative Hardware payloads.

UK pre-commit gate (do this before production)

1. Patch and class baseline

1. Confirm instance family / patch: Dynamic IRE guidance applies from Zurich Patch 11 (and later family releases such as Australia).
2. Inventory Hardware descendants with custom identification attributes.
3. Decide exclude-class candidates before simulation (custom class + custom attributes with Static rules that Dynamic cannot honour).

2. Simulation order of operations (non-prod)

Role: sn_cmdb_user (minimum for the UI path).

1. CI Class Manager → Hierarchy → Hardware → Identification Rule → Dynamic IRE → Simulate Dynamic IRE.
2. Run simulation without ticking the production-commit attestation.
3. Let Discovery / Service Graph / import sets run for a representative window (UK estates often need a full weekday Discovery cycle, not a lunchtime sample).
4. Review comparison charts: inserts, updates, incomplete CIs.
5. Drill into cmdb_ire_output_comparison_item JSON; use Summarize (Otto for CMDB IRE comparison skill) for CAB-readable notes.
6. Record the parity score (% identical outcomes). Mature Static estates should show high parity — that is expected, not a reason to skip review of the deltas.

3. Commit only after evidence

On production, only after non-prod simulation:

1. Return to Hardware Identification Rule → Simulate Dynamic IRE.
2. Tick the attestation that non-prod simulation is complete.
3. Select Commit to Dynamic IRE — or set glide.identification_engine.dynamic_ire_enabled=true with change control.

4. Configuration scenario matrix

GDPR, ops and UK language

Dynamic IRE does not invent a new personal-data path by itself — but Hardware CIs often carry location, owner anew of cmdb_ire_output_comparison_item deltas? 5. What parity score and residual mismatch rate do we accept before commit? 6. Is the Change to IRE rollback path tested? 7. How do Service Mapping / CSDM owners get notified of Hardware identity shifts?d asset fields that DPOs care about when duplicate merges change.

CAB checklist (print this)

1. Patch / family confirmed (Zurich P11+ or Australia+).
2. Hardware descendant custom-class exclusions decided.
3. Non-prod simulation completed over a representative Discovery window.
4. Parity score + insert/update/incomplete deltas reviewed from cmdb_ire_output_comparison_item.
5. Top residual mismatches owned (data quality vs engine behaviour).
6. Production commit window booked; property / UI path named.
7. Rollback (Change to IRE) tested in non-prod.
8. CMDB steward + Discovery owner named on the change.

Risks if you skip the gate

Closing

Dynamic IRE is a Hardware identification programme, not a one-click platform surprise. zBooted Zurich P11+ estates may already be committed; upgraded UK estates should simulate, compare, exclude where needed, then commit with CAB evidence. Static IRE remains available as a controlled rollback.

If you want a structured Dynamic IRE readiness pass against your UK CMDB — simulation design, exclusion list and CAB language — AIATS offers a Free Evaluation: practical, UK-enterprise, no theatre.

Questions for the CMDB steward / CAB agenda

1. Are we on Zurich P11+ / Australia, and is Dynamic IRE already committed?
2. Which Hardware child classes have custom identification attributes?
3. What Discovery window counts as "representative" for simulation?
4. Who owns revi