The practical answer
Link the applied cable label to the original test-result identifier and the verified endpoints. Preserve the original result and document the identity crosswalk instead of silently renaming it. Resolving the cable's identity and accepting its technical result are separate decisions; keep both statuses visible until the responsible reviewers close them.
The method, examples, and sources below explain the scope and checks.
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 a report lists temporary test names, cable labels changed after testing, an expected result is absent, or several files appear to describe the same link.
What to gather#
Collect the approved cable schedule, observed endpoint labels, original result files, report exports, test-session references, and documented naming changes. Preserve the received result package before preparing a reconciliation copy.
Source context#
Fluke's February 2016 article explains that the installed link label must correspond to its test documentation. Its cited TIA-606-A edition is historical; use the edition and acceptance criteria specified for the project. Fluke documentation guidance.
Suggested method#
This is an editorial workflow to adapt to your site's approved process.
Inventory planned links and received test records separately. Define the project, building, and test scope so identical short names from different jobs do not become false matches.
Compare exact planned IDs, applied labels, and original test IDs. Put missing results, extra results, duplicate IDs, and unexplained aliases into separate exception groups.
Resolve a mismatch using documented endpoint and test-session evidence. Similar names or adjacent sequence numbers can suggest a question but cannot establish that two records describe the same link.
Record an accepted old-to-new ID relationship with its supporting evidence and reviewer. Preserve the original result identifier and source file; make any authorized report corrections traceable.
Review identity matching and technical test acceptance separately. If identity remains uncertain, refer it to the responsible test reviewer for a decision, including whether additional verification is needed.
Decide which evidence is missing#
Start by distinguishing an absent result from an uncertain result association. An expected cable may have no received test record, a record with a temporary name, several records with the same name, or a clear identity match awaiting technical review. Those states require different follow-up. A single "not passed" column can obscure whether the issue concerns identity, missing documentation, or the actual performance result.
Define the population from the approved installation scope. Record the project, site, hall, link type, schedule revision, and any excluded or deferred links. Inventory received results independently, retaining original filenames and internal test identifiers. Equal counts do not establish correspondence: an extra result for one cable can offset a missing result for another while making the totals look complete.
If the installed cable ID is itself disputed, resolve that identity question before associating test evidence with it. If the ID is established but a result uses another name, investigate an evidenced mapping. If several results claim the same link, distinguish duplicate exports from separate test events. If the applicable test scope or acceptance criteria are unclear, refer that technical decision to the responsible reviewer rather than deriving it from label content.
Preserve the received evidence and its internal names#
Keep the original result package separate from a working reconciliation copy. Record the source, receipt reference, package revision, and available session context. Retain native evidence when provided along with exported reports, because an export and an original test record may expose different information. This workflow does not assert that a particular file format is universally required; follow the project's deliverable requirements and document what was actually received.
Give each received record a stable reference in the reconciliation index. Include the original test ID and enough location within the package to retrieve it. A filename by itself can be inadequate when multiple sessions use the same filename in different folders. Likewise, a displayed test ID can recur across projects. Keep the session and project context with the identifier so a short temporary name does not become a false global match.
Preserve original values when a corrected report arrives. Record the new package and which records it supersedes or supplements, then retain the prior association history. Do not silently replace a failed or disputed record with a revised PDF bearing the desired cable name. The reviewer needs to understand whether the revision corrected presentation, established identity, or documented a new test event.
Fluke's historical documentation article supports correspondence between installed link labels and their test records. Its reference to an older TIA edition does not establish the edition governing today's project. The inventory, exception groups, and crosswalk decisions below are Rackstamp's editorial method; technical acceptance remains against the actual specified test scope and criteria. Fluke test-documentation guidance.
Build a defensible correspondence#
Compare planned ID, observed applied ID, original test ID, and recorded endpoints. Keep each in its own field even when they match. This makes a later naming change visible and prevents the working index from erasing the original test name. Add the evidence supporting any relationship, such as contemporaneous installer records or documented test-session mapping, and name the reviewer who accepted it.
Use endpoint evidence at the appropriate level of detail. A pair of rack names is less discriminating than the relevant panel and port references when many links join those racks. If the available evidence cannot distinguish the proposed cable from others, record the unresolved ambiguity. A neat sequence of temporary numbers may suggest a question for the installer, but it cannot establish which individual link produced a result.
Where names changed after testing, identify the approved naming event and its scope. Determine whether the change affected a displayed alias, the issued cable identity, or a mapping error in the report. Keep the original name in the archive and record the approved relationship to the current name. Do not assume that a broad instruction to rename a project authorizes arbitrary one-to-one matches between two differently ordered lists.
Check for conflicts in the proposed crosswalk. One original record associated with two different installed links needs explanation. Two original records associated with one link may reflect a retest, separate required tests, duplicate exports, or a mistaken match. Record the actual relationship rather than forcing a single-row structure that hides additional evidence. Ask the technical reviewer which accepted result or result set fulfills the applicable requirement.
Field case: identical temporary names in two sessions#
This fictional case occurs in DC01 / H1. Two received test sessions both contain a record named TEMP-01. Session SES-G27-301 was associated with panel PNL-G27-301; session SES-G27-302 was associated with panel PNL-G27-302. The proposed handoff index links both TEMP-01 records to cable CBL-G27-301 because its creator matched only the short test name. Finding TST-G27-301 retains that proposed association as unresolved.
The reviewer separates the two received records by package and session reference, then compares their recorded endpoint context with the approved cable schedule and available installer logs. Evidence supports the first session's TEMP-01 as the result for CBL-G27-301. The second session's record relates to CBL-G27-302. The mapping decision cites the specific supporting records; the repeated temporary name remains unchanged within each original package.
The corrected index therefore uses the combination of session reference and original test ID to retrieve each result. It records the approved installed cable ID in a separate column and names the identity reviewer. The technical reviewer then assesses the appropriate result for each cable against the actual project requirements. An accepted identity mapping does not automatically accept either result's technical content.
Closure includes retrieval of both original records through the corrected index. Another reviewer starts from each installed ID and reaches the intended session evidence without guessing which TEMP-01 to open. The finding retains the original mistaken mapping, the discriminating endpoint evidence, and both separate review outcomes. No result is renamed merely to make the index unique.
Handle retests and revised reports without losing chronology#
For a retest, retain the prior event, the reason for additional testing when documented, and the new event reference. Separate "newer" from "applicable." A later test may cover a different configuration or scope, so the technical reviewer needs to establish which evidence applies to the installed link being handed over. Record that decision and any remaining dependency rather than automatically selecting the last modified file.
For multiple required results on one link, describe the required result set in the index according to the actual project scope. Do not delete apparent duplicates simply because the cable ID repeats. Identify what each record represents and how it contributes to the technical review. Where the received records do not explain their relationship, keep a documentation exception open for the test owner.
For a revised report that changes only displayed names, retain the original result reference and the authorization for the name correspondence. For a revision that changes result content, ask the responsible reviewer to explain whether it represents corrected reporting or a new test event. Those different histories should remain visible to the owner receiving the evidence.
For a missing record, state the exact in-scope cable and evidence sought. A useful request identifies the expected endpoints, known installation or test session, and the received packages already searched. Avoid a vague request to "send the missing tests," which can produce another unindexed export. Keep the missing row in the population until the owner records its final disposition.
Close identity and technical review separately#
Record identity acceptance with its basis, reviewer, and date. Record technical acceptance with its own responsible reviewer and applicable criteria reference. If one is complete and the other pending, show both states. A passing result associated with an uncertain link is not accepted evidence for that link; a correct identity match can still carry a technical finding.
Reconcile the planned population against dispositions rather than against a single count of files. Every in-scope link should have a clear state, while extra received records should have an explanation or remain under review. Distinguish excluded work from missing evidence. Exclusion needs a scope decision, not merely a blank result cell that was filtered out before reporting.
Test retrieval from the operational starting point: the installed cable ID. Have a reviewer use the index to find the original evidence, its mapping decision where needed, and the separate technical outcome. If that path depends on private knowledge of temporary names or folder order, improve the cross-reference before closure. The purpose is usable correspondence after the installation team leaves.
Retain unresolved cases with an owner and next decision. Additional verification or retesting may be appropriate, but the test owner decides under the authorized process. Do not perform speculative physical tracing or substitute a convenient passing file. A clear unresolved record is more useful than an unsupported association that will later be mistaken for accepted installation evidence.
Worked example (fictional)#
Unless another site is named, the example scope is DC01 / H1.
PLANNED APPLIED ORIGINAL TEST ID DECISION
CAB-0042 CAB-0042 CAB-0042 Identity match
CAB-0043 CAB-0043 TEST-019 Review alias
CAB-0044 CAB-0044 No result found Missing evidence
A passing TEST-019 does not establish which cable was tested.
The fictional rows illustrate reconciliation states. None is a claim that a cable meets a performance specification.
Common mistakes#
- Renaming files until the counts match.
- Treating a passing result as proof of link identity.
- Discarding earlier results when a revised report arrives.
Verification checklist#
Worksheet field dictionary#
Cable-label and test-result reconciliation sheet. The example-value column shows one fictional worksheet row vertically.
| Field | Meaning | Filled example value |
|---|---|---|
| Planned ID | Approved cable-schedule identifier. | CAB-0043 |
| Applied ID | Observed installed label text. | CAB-0043 |
| Original test ID | Identifier retained in original evidence. | TEST-019 |
| Result reference | Original file and record location. | EX-Job7 native package / 019 |
| Endpoints | Evidence identifying the tested link. | R014/08 to R021/20; unconfirmed |
| Identity status | Matched, missing, duplicate, or unresolved. | Unresolved alias |
| Technical review | Separate performance-review outcome. | Pending test-owner review |
| Decision evidence | Basis for an approved correspondence. | EX-session-log-7; review open |
| Reviewer | Person responsible for reconciliation. | Example test owner |
| Verification date | Completed identity-review date. | Pending |
Frequently asked questions#
Can an old test name remain in the archive?#
Yes. Preserve it and record an evidenced relationship to the approved cable ID.
Must every mismatch lead to retesting?#
No. The test owner decides whether available evidence establishes identity or further verification is required.
Are two records with the same test ID duplicates?#
Not necessarily. Compare project, session, endpoints, and test-event context. Preserve both until their relationship is established; repeated short names can belong to different links or separate events.
Should the newest result always be accepted?#
No. The technical reviewer must determine which result applies to the installed link and required scope. Retain chronology and the decision basis, including any earlier or additional evidence still relevant.
What if the installer can only remember the mapping?#
Record the statement as such and seek supporting contemporaneous or endpoint evidence. Do not present recollection as an established correspondence when it cannot distinguish the link. Keep the identity review open for the responsible owner's decision.
More worked label examples
Two additional ways to apply this guide. Keep the exact identifiers and relationships consistent with your own approved records.
GUIDE 27 / EXAMPLE 1
Cross-reference a tester alias to the applied cable ID
A documented mapping joins the original test identifier to the installed label without renaming the original test file.
SCOPE: DC01 / H1; cable CBL-G27-101
APPLIED LABEL FACE
[CBL-G27-101 | PNL-G27-101/P03 <-> PNL-G27-102/P09]
PLANNED ID: CBL-G27-101
ORIGINAL TEST ID: TESTLINK-G27-101
ORIGINAL RESULT: RES-G27-101
RECORDED ENDPOINTS: PNL-G27-101/P03 to PNL-G27-102/P09
IDENTITY CROSSWALK
TESTLINK-G27-101 -> CBL-G27-101 -> RES-G27-101
Support: installer map MAP-G27-101 + endpoint check EV-G27-101
Identity review: matched under DEC-G27-101
Technical result review: separately recorded TECH-G27-101- Use contemporaneous installer records and endpoint evidence to support the alias relationship. A similar test filename or a convenient sequential number is not enough to establish identity.
- Retain the original result and its original identifier. Record technical acceptance against the applicable test scope and criteria separately from the fact that the cable IDs have been reconciled.
GUIDE 27 / EXAMPLE 2
Hold a result when its endpoints identify a different cable
The proposed test-to-label match is rejected because the documented endpoint pair differs from the observed installation.
SCOPE: DC01 / H1; review TST-G27-201
APPLIED FACE: [CBL-G27-201]
INSTALLED PAIR: PNL-G27-201/P01 <-> PNL-G27-202/P01
PROPOSED RESULT RES-G27-201
Original ID TESTLINK-G27-201
Result pair: PNL-G27-201/P02 <-> PNL-G27-202/P02
COMPARE
Installed: P01 <-> P01
Result: P02 <-> P02 -> endpoints do not match
Identity status: UNRESOLVED
Action owner: test records lead
Next evidence: correct original result or approved retest record
Do not rename RES-G27-201 to CBL-G27-201 as a repair- Check whether the mismatch comes from an incorrect label, a mapping error, or a different tested cable. Preserve all original values until evidence distinguishes those possibilities.
- If a new test is required, use the site's authorized test process and acceptance criteria. Record the new result separately and retain the unresolved or rejected original association in history.
Sources and applicability
- Fluke Networks: Test and labeling documentation ↗
Published February 16, 2016; supports label/document correspondence, not current-edition or technical acceptance claims.
Read scope and linked guides