# Label-to-record reconciliation register

> Compare observed and system values by disputed field, record owner, approved decision, and evidence in the editable reconciliation register.

Canonical page: https://datacenterlabeling.com/templates/label-record-reconciliation

Download: https://datacenterlabeling.com/assets/downloads/rackstamp-worksheets.xlsx

Workbook tab: 26 Record reconciliation. The workbook includes all 30 registers.

Rackstamp provides editorial field guidance. IDs, cases, and worksheet entries are fictional examples unless identified otherwise. Distinguish local conventions from adopted standards. Source notes describe the evidence scope; a linked overview is not the full standard or a project approval.

## Before you start

1. Gather stable IDs, supporting identity evidence, relevant system record keys, and the actual disputed field definitions.
2. Retain timestamped observations and system values before any correction overwrites the disagreement.
3. Collect approved work and completion references, distinguishing planned destinations from verified current states.
4. Identify field-decision authority, authorized system editors, and any normal upstream/downstream update relationships.

## Complete the register

1. Create a Discrepancy ID and establish Object ID before deciding which location or other attribute should prevail.
2. Name the Disputed field precisely; create linked findings for independent attributes with different evidence or owners.
3. Enter Observed value and System values separately with their relevant source records, times, and observation limitations.
4. Record Approved value only after the field owner's evidenced decision, otherwise retain an explicit unresolved state.
5. Use Decision/status to distinguish approved, requested, executed, and verified corrections, listing all affected labels and records.
6. Link Evidence and Field owner to the actual decision and update path; leave Verification date pending until post-correction checks finish.

## Walk through the example

In fictional DC01 / H1, discrepancy D-026 concerns AST-008421. Establish that the observed equipment and both system records describe that same stable asset. Enter rack position as the disputed field, observed R014/U23 as the field observation, and R006/U18 as the retained DCIM and CMDB values. Link EX-D026 and examine what change CH-026 actually demonstrates, including its completion evidence. The location owner decides the approved value and identifies the authorized update path for each affected record. Do not change the asset ID to make the location match, and do not mark the issue verified when the approved value is merely written into the worksheet. Record each completed update and inspect the relevant current system values at the appropriate point in their normal refresh process. Compare the established physical location again as required. Close only when the evidence supports R014/U23 across the stated correction scope; otherwise keep the remaining update or verification pending.

## Handle common exceptions

### Two physical objects claim the same stable ID.

Route the collision for identity resolution before selecting a location value or merging system records.

### A manually corrected value is overwritten by an upstream source.

Retain the recurrence, resolve the authoritative update path with system owners, and reverify relevant sources and views.

### Location is resolved but operational ownership remains disputed.

Close the supported location finding and retain a separate ownership decision with its own owner, evidence, and status.

## Review and close

1. Confirm that identity collisions or duplicate-object questions were not hidden by a convenient location update.
2. Check that old, planned, observed, approved, and current values remain distinguishable in the evidence history.
3. Verify each affected current label or record after the relevant authorized update or refresh event.
4. Keep independently unresolved fields open and avoid applying a blanket verified status to the entire asset.
5. Retrieve the decision and final evidence from the intended reviewer context and assign any recurring integration issue separately.

## Fields and fictional filled example

| Field | What to record | Fictional example |
| --- | --- | --- |
| Discrepancy ID | Unique review reference. | D-026 |
| Object ID | Established stable identity. | AST-008421 |
| Disputed field | Attribute under review. | Rack position |
| Observed value | Field observation and date. | R014/U23; 2026-09-12 |
| System values | Values with source record references. | DCIM/CMDB: R006/U18 |
| Approved value | Owner-decided value or unresolved. | R014/U23 per CH-026 |
| Decision/status | Correction and verification state. | Record update pending; open |
| Evidence | Observation and decision references. | EX-D026; CH-026 |
| Field owner | Person responsible for this attribute. | Example location owner |
| Verification date | Final check date; pending if incomplete. | Pending |

## Sources

- [ServiceNow: Identification and reconciliation configuration](https://www.servicenow.com/docs/r/servicenow-platform/configuration-management-database-cmdb/configuring-ire.html?contentId=Qy3dDh~jSw5JICJGU2x7zg): Product-specific identification and update-authority concepts; this register does not connect to or modify CMDB/DCIM.
- [NetBox Labs: NetBox 4.4 customization](https://netboxlabs.com/docs/netbox/v4.4/features/customization/): Versioned export-capability context; proposed output schema and reconciliation controls are editorial.
- [NetBox Labs: NetBox 4.4 export templates](https://netboxlabs.com/docs/netbox/v4.4/customization/export-templates/): Object-type-specific export templates and rendering context. Local field names, template revisions, and required-data handling must be mapped to the actual installation.