Examples are fictional local conventions. Unless another location is shown, the scope is DC01 / H1. Keep that scope with shortened identifiers.
When to use
Use this guide for missing or outdated cable destinations. Follow the site's approved identification process; this documentation workflow does not authorize manipulating or disconnecting operational cables.
Corning's January 2015 labeling guide illustrates local and remote references on cable labels and identification at both cable ends. Its examples cite older standards; use the project's specified edition for requirements. Corning labeling and documentation
What to gather
Collect the cable ID, connection schedule, rack and panel identifiers, factory port references, accessible endpoint observations, and the record owner.
Method
- Copy the visible identifier exactly and find its connection record. Check that the lookup identifies the intended cable rather than several similar names or an old record.
- Record the local termination using the complete site, hall, rack, panel or device, and port context. Note which face or module matters for locating it.
- Establish the remote termination through the approved field process and reconcile it with the record. If the relationship remains uncertain, retain an unresolved entry for further authorized investigation.
- Prepare both label texts from the same worksheet row. Keep the cable ID unchanged while reversing HERE and THERE descriptions for the opposite end; use your approved format.
- Have a second reader compare the paired proof with the confirmed endpoint record. Complete authorized application and documentation together, preserving exceptions that prevent closure.
Identify which part of the endpoint relationship is missing
Begin with the cable, the two terminations, and the record connecting them. A legible cable ID does not necessarily provide a verified destination. A clear port reference does not necessarily identify the cable attached to it. Record which relationship is known and which is missing before choosing the next step.
If the local cable label is absent, establish whether an approved physical identification process can connect the cable to an existing record. Do not issue a second identity simply because the original sticker is hard to see. If the cable ID is visible but returns several records, use the duplicate-identifier process before preparing destination text. If the record is unique but the remote termination lacks evidence, keep that endpoint unresolved.
If both endpoint references are supported but the printed label is wrong, treat the problem as a label-to-record discrepancy. Prepare the corrected proof from the controlled row and account for any obsolete paired labels. If the record itself is stale, obtain the connection owner's correction before treating its text as a production source.
Record the access conditions and the approved identification method with the evidence. This guide organizes identity records and proof review. It does not supply permission or a procedure to unplug, move, manipulate, or test an operational connection.
Decide what the cable identity means
Write down whether the site's cable identifier names the physical cable, a connection relationship, or another locally defined object. The distinction matters when a cable is moved or replaced. A policy that retains physical-cable identity through a move needs location history; a connection-based scheme may handle that event differently. The record owner must define the meaning before anyone renames the cable to make its endpoints look correct.
Keep the cable ID distinct from endpoint equipment IDs and port references. A label can display all of them, but they answer different questions. The cable ID selects the cable record. The equipment or panel identity selects the terminating object. The port reference selects a termination within that object. Omitting one level can create ambiguity even when the remaining text is perfectly readable.
Check the uniqueness boundary of shortened identifiers. If a cable's full ID is unique only within a site or hall, retain that scope in the label, surrounding controlled reference, or supported lookup context according to policy. The worker should not have to guess which hall an otherwise identical record belongs to.
When a legacy format encodes endpoints into the identifier, preserve the issued value while the owner decides how changes are represented. Do not improvise a second naming rule in the label-printing worksheet.
Build a complete endpoint reference
Start with the actual hierarchy used by the terminating hardware and the site's records. Include site, hall, rack, panel or device, and port where those levels distinguish the endpoint. Add module, slot, cassette, or face context when the immediate port reference repeats. Copy factory references exactly, including letters, punctuation, and any meaningful leading zeros.
Do not assume that a bare number is a port. It may be a module, channel, row, or local staging sequence. Compare the observed reference with the equipment documentation or controlled endpoint map used by the site. Record the reference's object type so a label preparer does not place a module number in a port field.
Preserve the distinction between equipment identity and its current rack location. If an endpoint device moves, its equipment ID may stay constant under local policy while the location portion changes. The connection record needs enough information to resolve both the terminating object and where a technician can find it.
For cross-hall or cross-site records, write complete scope on both sides during review. A locally abbreviated proof should be derived only after the reviewer confirms how the receiving worker will recover the omitted context. An abbreviation that works at one rack may become ambiguous in a printed handoff used elsewhere.
Choose one label-reading convention
Two common editorial examples illustrate different semantics. A viewpoint-based layout uses terms such as HERE and THERE or LOCAL and REMOTE. At the opposite end, those descriptions reverse because the reader is standing at the other termination. The cable identity remains the same.
A fixed-end layout uses defined endpoint names such as A and Z. Those endpoint assignments remain fixed on both labels. The label at end Z still lists A as the same defined A endpoint. The site must explain how A and Z are assigned and how the local end is recognized. Neither convention should be inferred merely from the alphabetic order of device names.
Choose the convention required by the local policy and use it consistently throughout a batch. A reviewer should know whether a line changes with viewpoint or names a fixed endpoint. Mixing fixed A/Z records with HERE/THERE proofs without a documented mapping can produce labels that each look plausible while contradicting one another.
An ID-only label is a different choice. It relies on an accessible, controlled record for endpoint detail. Review whether the intended worker can retrieve that record where the cable is serviced, including any access restriction or offline work context. The nearby record must still identify which physical cable its information describes.
Establish evidence for both ends
Create a distinct evidence reference for each endpoint or a clearly documented observation that establishes both. State the full termination reference and the method permitted by the site. The reviewer needs to see why the observed cable is associated with those terminations, not simply that both ports exist somewhere in the hall.
Separate a planned destination from a confirmed relationship. A design schedule shows intent; it may not establish the installed result after changes. An old test or handoff record can support the investigation, but check its cable identity, scope, revision, and relationship to the current configuration. Record any event that may have changed the endpoints since that evidence was produced.
When the two observations conflict, preserve them as separate claims and assign the discrepancy to the connection owner. Do not overwrite the first observation with the second without recording why the second resolves the relationship. The cause may be a stale schedule, a mistaken cable selection, an incomplete port hierarchy, or an incorrect label.
If an endpoint cannot be confirmed within the approved access or work scope, keep the production destination text held. Record the candidate separately from the verified endpoint field. A proposed destination can guide further authorized investigation while remaining visibly unconfirmed.
Produce the pair from one controlled row
Prepare both label faces from the same released endpoint record. Review the cable identity once as the shared key, then review the local and remote lines under the chosen convention. For HERE/THERE layouts, end B should show end A's THERE value as HERE and end A's HERE value as THERE. For fixed A/Z layouts, the assigned A and Z values remain unchanged.
Keep the row's revision or connection reference with the proof set, even if that information is not printed on the physical cable label. A pair of labels separated from its governing row is difficult to reconcile after a change. Account for reprints and unused labels so a superseded destination cannot be returned to the active batch unnoticed.
Compare the complete strings before checking visual fit. A well-aligned proof with the wrong module is still wrong. Then inspect the longest actual text in the intended label layout and the approved placement context. A line that truncates only on longer rack or module names may escape a short sample review.
Record which proof version was accepted. If either endpoint changes before application, recheck both faces. The text at the unchanged end may still contain the old remote destination, so replacing only the changed-end sticker can leave the pair inconsistent.
Review reciprocal labels without relying on familiarity
Give a second reader the controlled row and the paired proofs. Ask them to read the cable ID, identify the local termination for each face, and state the opposite endpoint. Include the full hierarchy in their comparison rather than accepting a match on the final port number alone.
Use a deliberate pair check: shared cable identity, complete end A reference, complete end B reference, convention consistency, and proof revision. Then compare the actual installed result through the authorized work and review process. A proof check confirms proposed text; an installed review confirms what was actually applied and readable.
When the print batch includes similar consecutive cable IDs, review each pair against its own row. A correct total count does not prove correct pairing. A swapped pair can leave every expected identifier present somewhere in the batch while assigning the wrong relationship to individual cables.
Record limitations precisely. If only one installed end could be reviewed, mark the other as pending. Do not let a completed proof review stand in for missing installed evidence.
Scenario: a plausible remote switch name was wrong
In a separate fictional case, cable CAB-G06-301 has a visible local identity at DC01/H1/R301/PNL-G06-301/P03. A draft schedule lists DC01/H1/R302/SW-G06-301/E17 as the remote endpoint, but the schedule is marked preliminary. The local label preparer is asked to produce both faces to keep the work package moving.
The reviewer records the local observation and holds the unconfirmed remote text. Under the site's separate approved identification process, new evidence establishes the remote endpoint as DC01/H1/R303/SW-G06-302/E17. The same E17 suffix had made the draft look credible even though the terminating device and rack were different.
The connection owner corrects record CON-G06-301 and retains the rejected candidate in exception EX-G06-301. The issued cable ID remains CAB-G06-301 under this fictional policy. The new end-A proof identifies the panel as HERE and the confirmed switch as THERE; end B reverses those descriptions. Both carry the same cable ID.
The print owner removes the preliminary pair from the active pack and records its disposition. After authorized application, the reviewer checks the actual label pair against the revised record and the supporting endpoint evidence. Closure includes the record correction, proof revision, disposition of the old pair, and outcomes for both installed ends. The case is not closed merely because the two new labels agree with each other.
Scenario: fixed endpoints were mistaken for local endpoints
In another fictional case within DC01 / H1, CAB-G06-302 is documented with fixed endpoint A at DC01/H1/R304/PNL-G06-302/P11 and fixed endpoint Z at DC01/H1/R305/SW-G06-303/E09. Both labels list those same A and Z values correctly. A technician expects LOCAL and REMOTE semantics and reports the label at Z as reversed.
The review finds no disagreement about the physical endpoints. The issue is an unexplained reading convention. The record owner confirms that this work package uses fixed A/Z assignments and that both physical faces should retain them. The resolution is to clarify the approved label legend and work-pack instructions, not silently swap A and Z on one sticker.
Before closing the issue, a second reader uses the clarified legend to identify the local termination from each end. If the site decides to change conventions, that becomes an approved format change affecting both proofs and their generating template. The evidence distinguishes a communication problem from an incorrect connection record.
Handle patch cords, permanent runs, and intermediate connections explicitly
Describe the object your row represents. A patch cord between a panel and a switch, a permanent run between panels, and a multi-segment path are not automatically one cable identity. Follow the site's model for segment and connection records. Avoid stretching a two-end label across intermediate objects without explaining what relationship the ID actually names.
Where an intermediate panel or coupler is involved, retain the segment boundaries used by the controlled records. A destination beyond that intermediate point may be useful service context, but it should not erase the physical termination of the cable being labeled. The reviewer must be able to distinguish “this cable terminates here” from “this path ultimately reaches there.”
For removable modules or repeated port numbering, retain the hardware hierarchy that disambiguates the installed termination. If module identity and slot location are separately tracked, preserve their relationship instead of replacing one with the other. Refer the detailed panel or fiber mapping problem to the corresponding guide.
When a cable is replaced, consult the identifier policy before carrying its old ID forward. The correct handling depends on whether the ID represents the physical cable or the enduring connection relationship. Record the replacement event and its evidence either way.
Repair brownfield records and prepare new-build handoffs
In an existing facility, start with a bounded connection discrepancy and preserve the labels as observed. Do not convert an entire row of cables to a new convention before resolving the underlying endpoint evidence. Keep legacy abbreviations in a controlled crosswalk where active records still depend on them.
List any nearby printed schedules or reference cards that repeat the changed destination. Updating the central record and on-cable labels while leaving a current rack reference stale creates another disagreement. Assign each active representation an owner and a correction outcome.
For a new installation, keep design intent, staged label proofs, installed observations, and handoff acceptance distinct. A released design can authorize preparation under the project process, but the installed record should show the reviewed result. Account for changes made after the print batch was issued and before the receiving team accepts it.
Deliver the endpoint register in a form that preserves identifiers as text and retains its revision, scope, and exception references. The receiving team should be able to follow one cable ID from either label to the same complete relationship.
Troubleshoot recurring text and layout failures
If the same HERE value appears on both ends, inspect the proof-generation mapping and compare the two intended viewpoints. Correct the generating row or template rather than manually editing an isolated sticker without evidence.
If the final port numbers match but the selected equipment is wrong, expand the equipment and module hierarchy. If labels are readable on loose cables but disappear after dressing, use the dense-bundle visibility guide and record the actual service view. If text is clipped or shortened, use the fit and print-quality review with the longest actual identifier.
If a scan opens the wrong record, compare the encoded value with the human-readable cable ID and the record's lookup key. Keep the scan problem separate from endpoint verification. A successful scan proves neither that the cable is correctly labeled nor that the endpoint relationship is current.
Close recurring defects by recording which source, mapping, or physical condition caused them. The next batch should use the corrected input or reviewed placement, while the affected installed labels still receive their own documented correction.
Worked example
Fictional labels use HERE and THERE as an explicit local convention.
END 1 - CAB-0042
HERE DC01/H1/R014/PP01/07
THERE DC01/H1/R021/PP02/19
END 2 - CAB-0042
HERE DC01/H1/R021/PP02/19
THERE DC01/H1/R014/PP01/07
Connection record: DEMO-CON-0042
Both views describe one fictional relationship. Labels do not establish service state or permission to interrupt the connection.
Common mistakes
- Printing the expected remote endpoint as though it was observed.
- Copying the same HERE text onto both ends.
- Dropping the panel or device context when port numbers repeat.
Verification
Worksheet: Two-end cable label schedule
Fields define one row; sample values are fictional. Leave working-sheet dates blank until their recorded event occurs. Sample status: Example only.
| Field | Definition | Filled example |
|---|---|---|
| Cable ID | Identity shared by the paired labels. | CAB-0042 |
| Local endpoint | First complete termination reference. | DC01/H1/R014/PP01/07 |
| Remote endpoint | Second complete termination reference. | DC01/H1/R021/PP02/19 |
| Connection reference | Controlled record for this relationship. | DEMO-CON-0042 |
| End A text | First-end label proof. | CAB-0042; HERE DC01/H1/R014/PP01/07; THERE DC01/H1/R021/PP02/19 |
| End B text | Second-end label proof. | CAB-0042; HERE DC01/H1/R021/PP02/19; THERE DC01/H1/R014/PP01/07 |
| Exception | Unresolved discrepancy or stated outcome. | None in fictional example |
| Owner | Role responsible for the connection record. | Network records lead |
| Evidence | References confirming both terminations. | DEMO-ENDS-0042 |
| Verifier | Person comparing both endpoint references. | Example reviewer |
| Verification date | Date the endpoint comparison was made. | 2026-09-12 |
| Status | Identification review state. | Example only |
Frequently asked questions
Can the cable ID alone be enough?
Your policy may use an ID that resolves to endpoint records. Confirm that technicians can access the required record where they work.
What if the remote end cannot be confirmed?
Keep the destination unresolved and assign the investigation. A cleanly printed assumption is still an unverified relationship.
Which cable-labeling format is best?
Choose a format that preserves the site's identity meaning, distinguishes both endpoints, and can be interpreted at the service location. Compare HERE/THERE, fixed A/Z, and ID-only examples against actual work tasks. There is no format in this guide that overrides the project's adopted requirements.
Can we label only the end that changed?
Review both label texts and the connection record. Under a local/remote layout, the unchanged physical end may still display the former remote destination. Reissue and verify whichever faces became stale under the approved convention, accounting for superseded copies.
What should an unresolved destination label say?
Follow the site's approved exception and temporary-identification process. Keep the verified cable identity available and avoid presenting a guessed destination as confirmed. Record the candidate, missing evidence, owner, and release condition in the controlled exception record.
More worked label examples
Two additional ways to apply this guide. Keep the exact identifiers and relationships consistent with your own approved records.
GUIDE 06 / EXAMPLE 1
Print reciprocal local and remote cable faces
Each end carries the same cable ID, but its local and remote endpoint lines reverse with the viewing position.
SCOPE: DC01 / H1; connection CON-G06-101
END A LABEL FACE END B LABEL FACE
+---------------------------+ +---------------------------+
| CBL-G06-101 | | CBL-G06-101 |
| LOCAL PNL-G06-101 / P03 | | LOCAL SW-G06-101 / E17 |
| TO SW-G06-101 / E17 | | TO PNL-G06-101 / P03 |
+---------------------------+ +---------------------------+
PNL-G06-101 / P03 ===== CBL-G06-101 ===== SW-G06-101 / E17
ENDPOINT REGISTER
PNL-G06-101 -> R101 / U40 / front
SW-G06-101 -> R102 / U32 / front
End A observation: EV-G06-101-A
End B observation: EV-G06-101-B- Use the exact port identifiers printed on the actual panel and device, including any slot or module context. Expand abbreviated examples such as P03 or E17 when they are not unique within the object.
- If your policy uses fixed A/Z endpoints rather than local/remote text, keep A/Z fixed on both labels. Do not mix viewpoint-based and fixed-end conventions in one batch.
GUIDE 06 / EXAMPLE 2
Leave an unverified remote endpoint visibly unresolved
An incomplete connection is held for review instead of receiving a guessed destination label.
SCOPE: DC01 / H1; exception EX-G06-201
OBSERVED LOCAL END: PNL-G06-201 / P11
CURRENT ID FACE: [CBL-G06-201]
RECORD BEFORE
CBL-G06-201 | LOCAL PNL-G06-201/P11 | REMOTE UNKNOWN
Candidate note: SW-G06-201/E09; not verified
Production destination labels: HOLD
AFTER RECORDED ENDPOINT VERIFICATION, EXAMPLE FACES
+---------------------------+ +---------------------------+
| CBL-G06-201 | | CBL-G06-201 |
| LOCAL PNL-G06-201 / P11 | | LOCAL SW-G06-202 / E09 |
| TO SW-G06-202 / E09 | | TO PNL-G06-201 / P11 |
+---------------------------+ +---------------------------+
Evidence EV-G06-201 resolves candidate SW-G06-201 as wrong- Select an endpoint-verification method permitted for the installed service and access conditions. This example gives no instruction to disconnect or disturb a live connection.
- Preserve the rejected candidate and the evidence that resolved it in the exception record. Release the label pair only when the complete endpoint references have been checked.
Sources and applicability
- Corning: Labeling and documentation ↗
January 2015 historical local/remote label examples; does not authorize service interruption. The expanded triage, decision comparisons, scenarios, and closeout procedures are original editorial guidance.
Read scope and linked guides
Planning guides and companion documents
- Choose a label printer for the work you actually do
- Choose barcodes, RFID, or AIM for the evidence you need
- Create a cable-color legend people can use
- Plan a legacy-room relabeling program
- Move, add, change, and retirement ticket insert
- Remote-hands cabinet identification brief
- Panel and switch port relationship schedule
- Label printer selection and trial plan
- Barcode, RFID and AIM technology pilot plan
- Cable-color meaning and transition planning register
- Legacy-room baseline, wave, and uncertainty planning template