The physical label and system record disagree

Examples are fictional local conventions. Unless another location is shown, the scope is DC01 / H1. Keep that scope with shortened identifiers.

When to use this guide#

Use this guide when an asset is found in another rack, labels disagree with endpoint records, or DCIM and CMDB return different values. The immediate output is a discrepancy register with decisions that can be followed through to completion.

What to gather#

Gather object IDs, relevant system record references, timestamped observations, approved changes, field-ownership rules, and earlier aliases. Capture only the evidence needed to distinguish the objects and disputed fields.

Source context#

ServiceNow separates identification rules, which address duplicate records, from reconciliation rules, which control attribute-update authority. That distinction supports resolving identity before deciding which value should prevail. ServiceNow identification and reconciliation.

Suggested method#

This is an editorial workflow to adapt to your site's approved process.

1. Establish that the observations refer to the same object. Compare the stable asset or cable ID and supporting references; treat a collision as an identity issue before reviewing location.

2. Create one discrepancy per disputed field or clearly linked group. Preserve the observed value, each system value, source timestamp, and relevant change reference without silently overwriting anything.

3. Assign the person responsible for the field. A system that owns financial status may not own rack position; document the authority used for this particular decision.

4. Compare evidence and classify the cause: delayed closeout, wrong label, wrong record, duplicate object, or unresolved observation. Have the owner specify the correction and any related systems or labels affected.

5. After the approved correction process, compare the physical identification and relevant records again. Record the final value, verification evidence, and remaining exceptions; worksheet completion does not itself update a system.

Resolve identity before choosing a winning value#

Begin with the question "Do these observations describe the same object?" Compare the stable identifier and the supporting evidence appropriate to that object, such as an equipment serial or a cable's verified endpoints. If two physical objects claim one stable ID, route the issue to the collision process. If two system records appear to describe one object, keep their record keys and source histories distinct while the records owner investigates. A location update cannot settle either identity problem.

Once identity is established, name the disputed field precisely. "Records wrong" is too broad to assign or verify. Rack position, operational owner, lifecycle status, and remote endpoint can have different evidence and decision owners. Create separate linked findings when they can close independently. A correct serial does not establish a correct rack position, and a verified location does not settle who owns the service running on the equipment.

If an observation itself is uncertain, record its limitation before proposing a value. A partially hidden marker, an ambiguous character, and a photograph without location context are different evidence gaps. Arrange an approved observation method or request existing work evidence that can resolve the gap. Do not replace an uncertain field with a confident-looking value copied from whichever system is easiest to edit.

Capture the disagreement without destroying its history#

Record the observed value, each relevant system value, and the source reference for each. Include the observation time and the source timestamp where available, while noting what that timestamp actually means. A record's last-edited time might reflect an unrelated attribute. A recent timestamp is useful context but does not by itself prove that the disputed location was checked recently.

Keep historical, planned, and current values separate. A target rack in an approved change describes intent until the relevant completion evidence establishes the actual outcome. A former rack retained in history is not a current-location defect merely because it differs from today's observation. Read the field meaning and status before marking a disagreement. The register should capture a true conflict between equivalent claims, not flatten every location reference into one column.

Attach approved work references that bear on the field. Identify whether the work was planned, started, completed, reversed, or partially closed according to its actual record. Do not treat the existence of a change number as evidence that the intended move occurred. Where the change record is incomplete, ask its owner for the relevant completion evidence and keep that dependency visible.

ServiceNow's distinction between identification and reconciliation provides product-specific context for resolving object identity and attribute update authority. The cross-system investigation and closure method here is Rackstamp's editorial workflow; it does not configure a reconciliation engine or establish authority in your environment. Use the actual field ownership and update rules that your systems owners maintain. ServiceNow identification and reconciliation configuration.

Decide the correction at field level#

Assign a decision owner for the disputed attribute, then identify who can execute changes in each affected system. Those may be different people. A location owner can establish the intended correction while an application administrator implements the approved update. Record both responsibilities when needed. "IT to fix" leaves the finding without a clear decision path or a person accountable for verifying its result.

Compare the evidence with the field's meaning and authority rules. State the decision basis in concrete terms: the approved completed move and subsequent physical observation support the new location; the serial photograph supports a character correction; or evidence remains insufficient to choose between two owner values. Preserve the rejected values and reason for the decision. The worksheet should let another reviewer follow the conclusion without reconstructing an oral discussion.

List the affected representations before execution. A location discrepancy may involve a physical location legend, rack occupancy, an asset record, and an operations view fed from another system. A connection discrepancy may affect two endpoint legends and the connection record. Avoid assuming that changing the most visible field updates all the others. State which representations are current records, derived views, historical references, or out of scope.

Where automated imports or reconciliation rules participate, ask the relevant owner how the approved correction should enter the normal update path. A manual value can appear correct briefly and later be replaced by another source. Record the actual authoritative update reference and the downstream observations needed for closure. Do not disable a shared integration or change field authority merely to make a single discrepancy stop reappearing.

Field case: a corrected value returns to its old state#

This fictional case takes place in DC01 / H1 for asset AST-G26-301. The established identity matches the equipment and the asset records. Finding REC-G26-301 concerns the cabinet field: a completed work record and subsequent field observation support R301, while the operations view shows R302. A records editor changes that view to R301, and an immediate screenshot appears to close the issue.

At the next agreed review event, the view again shows R302. The verifier reopens the finding and retains both screenshots with their timestamps. The source owner identifies an upstream location record that still contains R302 and supplies the view through its normal update process. The cause is recorded as an incomplete correction path, rather than accusing the physical label or assuming that another undocumented move occurred.

The location owner approves R301 against the existing completion and observation evidence. The authorized system owners update the appropriate source through their approved process and identify the downstream view that must be checked. The physical identifier remains AST-G26-301 throughout. No new asset ID is created to escape the conflict, and no shared integration is switched off.

Closure follows a later recorded refresh event. The source record and operations view both show the approved cabinet, and the physical observation still supports that location. The finding retains its original value, temporary manual correction, recurrence, authoritative correction reference, and final verification. This history explains why the first screenshot was insufficient and gives future reviewers a concrete place to investigate if the same field drifts again.

Variations for connections, rack occupancy, and aliases#

For a connection field, establish the cable identity and both endpoint references at the required level of detail. A matching cable ID with one disputed destination should remain a relationship finding, not a reason to invent another cable record. Use the site's authorized tracing or existing completion evidence to settle the relationship. Record which physical faces contain destination text, including an unchanged end that still names an obsolete remote endpoint.

For rack occupancy, preserve the position convention used by the observation and each record. A starting U position, an occupied span, and a mounting face are not equivalent values. Confirm that the apparent disagreement is not caused by comparing different representations. If a true occupancy conflict remains, record the relevant neighboring objects without overwriting their locations merely to make the rack elevation look consistent.

For aliases, distinguish a supported old name from a second active identity. A search result may legitimately expose a historical label when its relationship to the stable object is recorded. Check which field is supposed to carry the current identifier and whether the alias leads unambiguously to that object. Preserve legitimate history while correcting an incorrect current value or unexplained duplicate association.

For ownership or lifecycle fields, physical observation may establish presence but not the approved organizational or disposition state. Route the decision to the field owner and relevant evidence. An asset absent from a rack might be in transit, storage, or an unresolved location; absence alone does not establish retirement. Keep those possible states as questions until the responsible records process decides them.

Avoid a tidy register with unfinished corrections#

Separate "decision approved," "update requested," "update executed," and "verified" in the finding's history. These stages can occur at different times and involve different people. A worksheet entry giving the approved value is not evidence that a system now holds it. Link the actual update reference and then capture the post-update observation needed to support closure.

Verify each affected representation at a meaningful point in its normal update process. Record the source or view inspected and the actual value returned. If one system remains pending while another is corrected, leave that part open and name its owner. Avoid a blanket "asset verified" status when only a single disputed attribute has been resolved.

Retain enough evidence to reproduce the decision without collecting unrelated records. A focused photograph, relevant record references, the approved work event, and the field-owner decision can be more useful than a large unindexed export. Test that evidence links can be retrieved by the intended reviewer. A closure reference that only exists in the original investigator's private folder cannot support a later review.

When responsibility is disputed, assign an owner for resolving authority and state the next evidence or decision needed. This keeps the finding actionable without granting unilateral authority to whichever team discovered it. Review recurring causes across completed findings: late move closeout, incorrect import mapping, stale labels, and unclear field ownership suggest different process repairs. Link those repairs without rewriting the original observations.

Make a DCIM export repeatable before using it as label evidence#

Treat an export as a defined representation of records, with its own field meanings and selection scope. It can omit context even when the underlying system contains that context correctly. NetBox's versioned documentation distinguishes CSV exports of a current view from broader available data, and supports custom templates associated with particular object types. Those capabilities do not guarantee that a chosen export contains everything a label review needs. NetBox 4.4 customization, NetBox 4.4 export templates.

Before comparing the export with physical labels, define a small output schema in plain language. For an asset feed, a useful proposed contract distinguishes stable object ID, source-system record key, site and hall context, current location, lifecycle state, and evidence or source revision. A cable feed additionally needs complete endpoint relationships and explicit end roles. These are suggested output fields, not a claim that every DCIM or NetBox installation exposes identically named built-in properties. Have the system owner map each required output to its actual source field or documented transformation.

Save the system/version context, export-template name and revision, selected object type, filters or explicit object list, extraction event, and field mapping together. Where a template comes from another controlled source, retain that revision reference too. A file's save time identifies one event; it does not establish when each source field was physically verified. Preserve field observation or change evidence separately when the reconciliation depends on it.

Define missing-data handling before export. A blank rack might indicate an unlocated item, an intentionally unmounted asset, unavailable data, or an omitted column. Keep those meanings distinct in the prepared review set. Do not fill blanks with a previous row's location or manufacture an UNKNOWN identifier that could later be printed as though it were issued identity. Give each excluded or incomplete row a reason and owner, and preserve it in the selected-population reconciliation.

In fictional DC01 / H1, export EXP-G26-401 lists AST-G26-401 with an empty location. The reviewer compares its schema with the source and finds that the export template omitted the location field, while the record itself contains the approved value. The correction belongs to the export representation. The system owner issues a revised template, and the reviewer compares the resulting stable ID, record key, context, and location against the controlled source. No physical label or asset location is changed to match the incomplete file.

Before release, compare complete records and count selected, exported, excluded, and unresolved objects. Retain a known difficult row with repeated short names or missing optional data so later template revisions can be checked against the intended contract. Link the accepted export revision to guide 24's import and physical-proof process. A repeatable export establishes what was transferred; final installed correspondence still requires the relevant field evidence.

Worked example (fictional)#

Unless another site is named, the example scope is DC01 / H1.

OBJECT      FIELD     OBSERVED  DCIM       CMDB
AST-008421  Location  R014/U23  R006/U18   R006/U18

Change CH-026 supports R014/U23.
Owner decision: reconcile location; retain the stable asset ID.

The fictional change reference supplies a reason to investigate. An observation alone is not an approval to move equipment or change its record.

Common mistakes#

• Assuming the most recently edited system is authoritative.
• Replacing a stable ID to make a location mismatch disappear.
• Closing the issue after correcting only one affected record.

Verification checklist#

• The object identity is established.
• Old and proposed values remain distinguishable.
• The field owner and decision basis are named.
• Affected labels and records are covered.
• Post-correction evidence supports each closed discrepancy.

Worksheet field dictionary#

Label-to-record reconciliation register. The example-value column shows one fictional worksheet row vertically.

Frequently asked questions#

Should the physical label always win?#

No. A label can be wrong or stale. Compare it with identity evidence and approved work.

What if ownership is unclear?#

Keep the discrepancy open and assign responsibility for deciding field authority before issuing a correction.

Can the newest system timestamp settle the dispute?#

No. Determine what changed at that time and whether that source owns the disputed field. Compare relevant completion and observation evidence before approving a value.

What if the value becomes wrong again after correction?#

Retain the recurrence and inspect the approved update path with the system owners. A downstream manual edit may not resolve an upstream conflict. Reverify the relevant source and views after the authorized correction.

Can one finding close while another stays open for the same asset?#

Yes. Track independent fields with their own decisions and evidence. Name the completed checks precisely so a corrected location is not mistaken for acceptance of unresolved ownership, connection, or lifecycle information.

More worked label examples

Two additional ways to apply this guide. Keep the exact identifiers and relationships consistent with your own approved records.

SCOPE: DC01 / H1; discrepancy REC-G26-101
PHYSICAL FACE: [AST-G26-101 | LOC R101 / U14]
DISPUTED FIELD: current rack position

SOURCE                    VALUE             EVIDENCE
Field observation         R101 / U14         EV-G26-101
DCIM                      R101 / U10         DCIM-G26-101
CMDB                      R102 / U14         CMDB-G26-101
Completed move record     R101 / U14         MOV-G26-101

OWNER DECISION EXAMPLE: approved R101 / U14
DCIM current location -> R101 / U14
CMDB current location -> R101 / U14
Physical face -> retained after check EV-G26-102
Previous values -> retained in discrepancy history

SCOPE: DC01 / H1; asset AST-G26-201
PHYSICAL ID FACE: [AST-G26-201]
OBSERVED SERIAL: DEMO-G26-S201

FIELD       SYSTEM VALUE       APPROVED VALUE      STATE
Serial      DEMO-G26-5201      DEMO-G26-S201      Corrected
Team owner  Compute team A    UNKNOWN            Open

Serial evidence EV-G26-201 -> decision DEC-G26-201
Owner conflict: work order says team B; system says team A
Owner finding REC-G26-202 -> accountable records lead

RECORD STATUS
Identity label: matched
Serial field: corrected and checked
Ownership field: unresolved; no silent overwrite

Sources and applicability

• ServiceNow: Identification and reconciliation configuration ↗

  Product-specific identification and update-authority concepts; this register does not connect to or modify CMDB/DCIM.

  Read scope and linked guides
• NetBox Labs: NetBox 4.4 customization ↗

  Versioned export-capability context; proposed output schema and reconciliation controls are editorial.

  Read scope and linked guides
• NetBox Labs: NetBox 4.4 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.

  Read scope and linked guides

Planning guides and companion documents

• Choose barcodes, RFID, or AIM for the evidence you need
• Plan a legacy-room relabeling program
• Build a labeling budget and business case
• Move, add, change, and retirement ticket insert
• Remote-hands cabinet identification brief
• Panel and switch port relationship schedule
• Barcode, RFID and AIM technology pilot plan
• Legacy-room baseline, wave, and uncertainty planning template
• Measured labeling cost and benefit planning template

Related guides