Data Center Naming Convention: Racks and Rows

The practical answer

A data center naming convention names positions, not hosts or services. Derive the cabinet address from the grid the room already has, as a row plus a position along it or as the floor tile it stands on, then fix the digit width, the character set, and the boundary the value is unique within. Keep anything that changes more often than the cabinet itself out of the identifier and in the record.

The method, examples, and sources below explain the scope and checks.

Identifier DC01-H1-R014-U21 broken into its site, hall, rack, and position segments, with rack R014 highlighted in a row of cabinets. The complete method and examples follow in text.

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

Three different things get called a naming convention#

Use the identifier builder to preview your chosen segments and export a fictional trial range before producing the approved identifiers.

Search for a data center naming convention and you get three unrelated answers, because three different problems share the phrase. Separating them is the first decision, and most of the arguments that follow are really disagreements about which one is being solved.

The first is host naming: what to call a server in DNS, in configuration management, and in a monitoring dashboard. It is the oldest of the three and by far the most written about, and its advice is close to the opposite of what a physical label needs. A host name should be short, memorable and arbitrary, and should not describe the machine's job, its owner or its project, because all of those change while the name stays. The classic statement of this is RFC 1178, which observes that it is impossible to choose generic names that stay appropriate for long, and that names are in practice arbitrary tags.

The second is facility naming: what to call the building. Most organizations encode a region or the nearest airport, sometimes an operator. It is a one-time decision that rarely produces field problems, and it is not what a technician is stuck on.

The third is position naming: what to call the cabinet, the row, the panel and the port that somebody has to physically walk to. This is the one that appears in a work order at two in the morning, and the one the other two have almost nothing useful to say about. This guide is about the third.

What is being named	What a good name does	What breaks it
A host or service	Stays short, arbitrary and memorable	Encoding a role or owner that changes without the name changing
A facility	Stays stable and is issued once	Reusing a retired site code for a different building
A physical position	Can be derived from the room and read off a label	Encoding anything a move or a re-lay-out changes
An asset	Survives moves, repairs and re-racking	Being used as a location, or printed where a location is needed

Mixing them is the usual failure, and it is legible in the identifier itself. A cabinet called web-prod-03 is a host name doing a position's job: it does not tell anyone where to walk, and it becomes false the first time that workload moves. A host called DC01-H1-R014 is a position doing a host's job: it has to be renamed every time the machine is re-racked, and the rename will be missed somewhere.

The industrial convention for keeping these apart is older than any of the three. IEC 81346-1:2022 establishes principles for structuring a system and for formulating unambiguous reference designations for the objects in it, with the designation acting as the key that retrieves information about an object rather than as a description of it. IEC's own committee material puts the same idea as an object identified in more than one aspect at once. You do not have to adopt any particular notation to use the idea: give each aspect its own field, and let the record do the joining.

Which document answers this labeling question?#

A standards question and a local naming decision can appear in the same work order. Separate them before selecting a pattern. The TIA FOTC overview describes TIA-606 administration using identifiers, records, relationships, and reports; it is not a complete local dictionary. TIA FOTC scope overview.

Question in the work package	Record that should answer it	What remains to decide
Which requirement and edition govern this project?	Adopted project documents and the responsible reviewer's applicability decision	The exact requirement affecting this work
What does each field in our identifier mean?	Local naming dictionary	Object meaning, uniqueness scope, permitted values
Who may issue the next value?	Allocation policy and issued/reserved register	Issuer, release state, collision check
What changes when an asset moves?	Identity policy and asset-to-location crosswalk	Persistent identity, changed location, historical aliases
Can the approved text be read on the object?	Actual-size label proof and installed reading check	Format, layout, placement and record access

Use one linked decision record: question, controlling reference, local decision, owner, revision, and verification evidence. Keep a missing requirement decision separate from an unfinished formatting choice. This lets unaffected examples proceed while the responsible reviewer resolves the actual gap.

For example, a local pattern such as SITE-HALL-RACK can be understandable without being official TIA syntax. Record it as the site's chosen implementation, test it against the project requirements, and preserve the accepted examples. The traceable output is a dictionary plus an issuance process, not a label that merely contains the name of a standard.

When to use#

Use this guide when teams describe the same objects differently. Start with the objects in your next work package: racks, panels, cables, and assets.

TIA FOTC describes telecommunications administration through identifiers, records, relationships, and reports. Its public overview is not the complete standard or a ready-made site naming policy. Confirm the edition specified by your project. TIA FOTC overview

What to gather#

Collect existing labels, representative work orders, the location map, current inventory fields, and the person responsible for issuing identifiers.

Method#

List the object types being named. For each, decide whether its label identifies a physical object, a location, or a connection. Keep these meanings explicit.
Define the scope of uniqueness and each field in the identifier. Record separators, case, padding, permitted characters, and how unknown values are represented.
Choose who allocates new identifiers. Describe how an identifier is reserved, issued, corrected, and retired so separate teams cannot issue from competing lists.
Draft examples for a normal object, a moved object, and an expansion. Try the longest expected identifier in the intended label area and work-order field.
Give the dictionary and examples to a second person. Resolve any differing interpretations, record the policy revision, and approve the first issuance list before printing.

An axonometric view of lettered rows of cabinets standing on a numbered tile grid. Row letters A and B are painted on the floor beside the rows and tile column numbers run along the aisle. One cabinet in row A is tinted pale blue and labeled H1-R014, and a callout reads DC01 / H1 / R014 with the words site, hall, number in hall. — Fictional example; scope DC01. Schematic teaching model: the hall is shortened, and every identifier, row letter and tile number is fictional. Open diagram at full size ↗

Derive the address from the grid the room already has#

Most halls already contain a coordinate system, and most naming trouble comes from inventing a second one next to it.

A raised floor is a grid of tiles. A slab room usually still carries a design grid on the drawings. Either way the room has rows, and positions along those rows, and those two facts are enough to generate every cabinet address in the hall without anybody consulting a lookup table. ANSI/TIA-942-C, revision C published May 2024, specifies infrastructure requirements for data centers and computer rooms and states a topology intended to apply at any size; the grid and the names you hang on it are still a local decision.

Two patterns dominate, and the choice between them is not a matter of taste.

Sequential position. Rows take letters or numbers, and cabinets are numbered along the row from a stated origin. DC01-H1-R014 is the fourteenth position in hall H1. It reads easily, it sorts correctly, and it is short. It has one weakness, and the weakness is structural: insert a cabinet between 07 and 08 and you either renumber the rest of the row or you invent 07A.

Grid coordinate. The cabinet takes the tile it stands on — row C, tile 21. Nothing ever renumbers, because the coordinate belongs to the floor rather than to the equipment. Its weakness is that the values are sparse and unfamiliar: a hall may run from tile 04 to tile 63 with gaps where the cooling units sit, and a technician cannot guess what comes next without the floor plan.

	Sequential position	Grid coordinate
Where the number comes from	Order of cabinets along the row	The floor tile the cabinet stands on
Adding a cabinet mid-row	Renumber the row, or add a suffix	Nothing changes
Removing a cabinet	A gap, or a renumber	Nothing changes
Guessing the next value	Easy from the last one	Needs the floor plan
Typical density	Dense: 01, 02, 03	Sparse, with gaps at plant
Suits	A hall built out once	A hall that will be re-laid out

Choose the one that matches how the room will actually change, and write down which one you chose and why. The failure mode is not picking wrong; it is picking sequential, re-laying out the hall three years later, and ending up with R014, R014A and R014B that are not next to each other on the floor.

Whichever you pick, put the origin and the direction in the policy rather than in somebody's memory: which end of the row holds position 01, and which way the numbers run from there. A row signed at both ends with its range and direction makes that decision visible to the person standing in the aisle, which is the subject of the aisle and row signage guide. A policy that states the origin and a room that never shows it is a policy only the author can apply.

Row identifiers deserve the same care. Letters are easier to say over a phone than a second set of numbers, which is why row C cabinet 14 is easier to relay than row 3 cabinet 14. Skipping letters that are misread on a worn label or in a hurried hand — I and 1, O and 0, and often S, Z, and Q — costs nothing at design time and removes a recurring class of mistake later. Record which letters you skipped so the next person does not fill the gaps back in.

The same floor from the same viewpoint, with every cabinet now carrying its tile coordinate instead of its number in the hall. The tinted cabinet in row A reads H1-A21 rather than H1-R014, and the callout reads DC01 / H1 / A21 with the words row letter and tile column. — Fictional example; scope DC01. Schematic teaching model: the hall is shortened, and every identifier, row letter and tile number is fictional. Open diagram at full size ↗

Decide the digit width before you decide the pattern#

Digit width looks like a formatting detail and behaves like a schema change.

Pad too narrow and you run out. A hall numbered R1 to R99 has no room for the hundredth cabinet, and the fix is not to add R100: that value sorts between R1 and R2 in every plain text sort your site will ever do, including the one inside a label printer's merge file. Pad too wide and every label and every work order carries leading zeros nobody reads, and the identifier eats label area that the readable part needed.

Decision	Ask	Consequence of getting it wrong
Digits per field	What is the largest count this field will ever hold, including the expansion nobody has approved yet?	A renumber of every label in the affected scope
Zero padding	Does anything sort these as text — an export, a printer merge, a file name?	Rows appear in the wrong order in exactly the documents used under pressure
Fixed or variable width	Do the labels have to line up in a column on a printed sheet?	Ragged sheets, and a reader who cannot scan down a column
Separator	Does every consumer keep it, and does any of them split on it?	A three-column mess on import, or a value silently joined

Fixed width with zero padding is the safer default for anything that will be sorted or printed in a column, which is nearly everything physical. Set the width from the largest plausible count rather than the current one, and state the rule in the dictionary so the next issuer does not quietly switch to two digits when the register looks small.

The same question applies to the site and hall fields. A two-character site code is enough until the organization buys a company with a site whose obvious abbreviation is already taken. Deciding in advance how a collision is resolved — a suffix, a registry, an arbitration owner — is cheaper than doing it during a migration.

Pick characters that survive the whole toolchain#

An identifier is not finished when it reads well on paper. It has to pass through a label printer, a spreadsheet, a scanner, an inventory system and an export, and each of those has its own opinion about characters.

Test the intended pattern in each place before approving it, using the longest value the policy permits rather than a short demonstration.

Where the identifier has to survive	The constraint worth checking
The label print path	Whether spreadsheet preparation preserves identifier text before it reaches the label template; Microsoft's Excel text-import guidance explains why leading zeros and long codes need deliberate handling
A barcode or scan path	Which symbologies the scanner is configured to decode at all, and how decoded data is delivered to the receiving field; Zebra's scanner input documentation shows how much of that is configuration rather than a property of the code
The inventory record	Whether the field is free text or constrained, and what the system considers a duplicate
An export or report	What a template emits for the field, and whether a separator survives it; NetBox's export templates are an example of that being an explicit, editable step
A host name or URL, if the value is ever reused there	The preferred syntax in RFC 1035 allows letters, digits and hyphen, requires a label to start with a letter and end with a letter or digit, caps a label at 63 characters, and treats two spellings differing only in case as identical

That last row is the one that catches people, because it is where an underscore goes to die and where R014 and r014 stop being two things. If an identifier will only ever live on a label and in a record, its character set is your choice. The moment somebody reuses it as a host name, a DNS label, a file name or a URL fragment, a narrower set applies and it was not negotiated with you.

A safe default for a position identifier is uppercase letters, digits, and a single separator character used consistently. Decide whether case is meaningful, and prefer that it is not: a policy where R014 and R014 differ only in a way a human eye cannot resolve is a policy that will produce two records for one cabinet.

A close view looking down on the tops of neighbouring cabinets in one row, labeled H1-R016, H1-R015, H1-R014, H1-R013 and H1-R012, with the tile numbers painted on the floor beside them. The middle cabinet is tinted pale blue. Each label carries a position and nothing else: no service name, tenant or owner. — Fictional example; scope DC01. Schematic teaching model: the hall is shortened, and every identifier, row letter and tile number is fictional. Open diagram at full size ↗

Say what the identifier must never carry#

A naming policy is easier to apply when it states its exclusions as plainly as its fields.

The rule is one sentence: an identifier must not encode anything that changes more often than the identifier itself. Everything else follows from it.

A service name changes when the workload moves. A tenant name changes at renewal. An owner changes at reorganization. A thermal role changes the day containment is reconfigured. A circuit's feed designation changes when the panel is re-fed. Each of these is genuinely useful information, and each of them belongs in a field of the record, or on a secondary line of the label that can be replaced on its own, rather than inside the value that everything else points at.

This is the same advice RFC 1178 gave about host names in 1990, and it has aged better than most naming guidance because it is not about computers. A name that describes a changeable property is a claim that has to be maintained, and it will be maintained everywhere except the one place somebody is reading during an incident.

Attribute	Why it is tempting	Where it belongs instead
Service or application	The person requesting the label thinks in services	A record attribute, revised without a reprint
Tenant or customer	Makes a colocation floor plan readable at a glance	A record attribute and, if needed, a separate removable marker
Thermal role	Feels permanent while containment is in place	Nowhere on a row identifier; see the aisle and row signage guide
Owner or cost center	Simplifies a billing export	The billing system, joined on the identifier
Hardware model or size	Helps at install time	The asset record, where it is already captured

Write the exclusions into the dictionary with a one-line reason each. An exclusion without a reason gets overturned by the first person with a deadline.

Triage the naming problem before choosing a format#

First establish whether the missing convention concerns the object itself, its location, or the way people refer to it. Ask a technician to point to the item named in a recent work order, then ask the records owner to identify the corresponding record. If they select different objects, start with identity and scope. If they select the same object but use different abbreviations, start with the dictionary and crosswalk. If the record is clear but the label cannot carry the text, retain the meaning while reviewing the physical layout.

Write down the decision that the identifier must support. A rack location helps someone reach a destination. An asset identifier distinguishes a physical item through its history. A connection identifier links a cable to its endpoint relationship. One string may contain several fields, but each field still needs a declared meaning. Do not make a new format absorb every attribute simply because those attributes are available in the inventory export.

If an approved policy already exists, record the specific gap before replacing it. The failure may be an unpublished revision, competing issuers, or a printer template that drops a field. Repairing that gap can preserve useful existing identifiers. If no governing policy can be found, the first deliverable is a draft with an accountable owner and unresolved decisions, not a production label sheet.

Define the dictionary at the level people actually use#

For each object type, specify a complete example, the meaning of each component, and the boundary within which the complete value must be unique. Explain whether identical short rack numbers may occur in different halls. Explain what a work order must include when it leaves the local hall context. Write the difference between an object-type code and a location code even when both happen to contain the same letters.

Define missing information deliberately. A draft record with an unassigned location needs a visible state that cannot be confused with an issued location. Avoid a placeholder that resembles an actual rack or port. Keep uncertainty in a status or exception field when the approved identifier cannot represent it clearly. A technician should not need to know that a particular number secretly means “not allocated.”

Agree on field lengths and permitted characters with the people who maintain the records and print the labels. Test what they actually enter, export, search, and scan. Record where leading zeros matter and whether case differences are meaningful under the local policy. A comparison rule can normalize copies for finding possible matches; it should not silently rewrite the authoritative string. Include the accepted separator and display form so two teams do not invent different renderings of one issued value.

Two halls separated by a wall, each with its own lettered rows on a numbered tile grid and its name painted on the floor, H1 and H2. A cabinet in hall one row A is tinted blue and a cabinet in hall two row A is tinted amber. Both are the fourteenth in their hall and both labels end in R014, so only the hall field tells them apart. — Fictional example; scope DC01. Schematic teaching model: the hall is shortened, and every identifier, row letter and tile number is fictional. Open diagram at full size ↗

State the uniqueness scope in terms a system can enforce#

"Unique" is not a property of an identifier. It is a property of an identifier and a boundary, stated together, and the boundary is the part people leave out.

If rack numbers restart in every hall, then R014 is not an identifier at all: DC01-H1-R014 is, and a work order that leaves the hall without carrying the hall has lost the part that made it unambiguous. If rack numbers are unique across the site, a short form is safe inside the site and still ambiguous in a report that spans sites.

Systems already model this, and their rules are a useful check on a policy written on paper. NetBox, for example, treats a device name as optional, and where a name is set it must be unique within the assigned site unless the device has been assigned to a tenant; placement is carried separately as site, location, rack, rack face and position fields rather than being parsed out of the name. NetBox device model. Whether or not that is the system you run, it is the shape of the question: what is the boundary, what happens at the boundary, and is the placement a field or a substring?

A CMDB answers the same question from the other direction. ServiceNow's identification and reconciliation engine resolves whether an incoming payload describes an existing item or a new one using configured identification rules. If your naming policy and those rules disagree about what makes two records the same thing, the disagreement surfaces as duplicates, and it surfaces long after the labels are printed. Compare them deliberately rather than discovering the difference in an audit; the duplicate identifier guide covers the cleanup when they have already diverged.

Record the scope for each object class as a sentence a person can check: this value is unique among all cabinets in DC01; this value is unique among ports on this panel; this value is unique across the estate and never reused.

Make issuance a controlled handoff#

Describe the route from request to issued identifier. A useful request states the object type, required scope, intended use, and requesting work package. The issuer checks existing allocations, reserves a value, and records who may release it for printing. The label preparer then works from the released entry. The installation reviewer records the physical result against that same entry. These are suggested responsibilities; a small team may combine them if the decisions remain traceable.

Distinguish reserved, issued, installed, corrected, and retired states in terms your site already uses. A reservation prevents competing allocation while a design is being reviewed. An issued identifier has an allocation decision behind it, but issuance alone does not prove installation. A retired identifier remains discoverable in history if old work orders still refer to it. Decide whether reuse is allowed and who can approve it instead of leaving reuse to the next person who notices a gap in a sequence.

Plan corrections as well as successful issuance. If a typo appears only on a printed label, preserve the valid issued value and replace the incorrect rendering through the applicable work process. If the allocated value itself conflicts with policy, obtain the issuer's correction decision and update dependent references. Record which problem occurred. Otherwise the next audit cannot distinguish a printing error from an allocation failure.

Test the policy with awkward but realistic cases#

Build a small review pack that represents the next work package and its likely variations. Include the longest permitted rack address, the first object in a new hall, an equipment move, a replaced panel, and two object types with similar short numbers. Ask the reviewer to decode each example without verbal help. Record the exact ambiguity they encounter rather than a general “looks good.”

Try the complete value in the real record fields and label preview. Confirm that a exported list, printed work order, and field lookup preserve the identifier. If a system has a limit, record that limit and propose a policy-compatible display or data change. Do not approve the policy based on a shortened demonstration that hides the actual constraint.

Finally, give a different person the label example and a small set of competing records. Their task is to select the intended object and explain which fields disambiguate it. This tests whether the scheme communicates its meaning, not whether the designer remembers the answer. Revise the dictionary when the reader reasonably reaches another interpretation, then repeat only the affected examples. Keep the accepted review pack with the policy revision as evidence of the decisions made.

Introduce a convention into an existing facility#

For an existing facility, preserve observed labels and record references before changing them. Create a crosswalk that distinguishes active identifiers, historical aliases, and values whose meaning is unresolved. A legacy format can remain in use during a controlled transition if the approved policy explains how it maps to the current record. The transition should not require every technician to remember an undocumented exception.

Choose a bounded starting area or work package with a named owner. Record which labels, records, drawings, and open work orders are in scope. Close that area with evidence before treating the result as a general rule for the whole facility. When two legacy formats overlap, route the actual collisions through the duplicate-identifier process; a new style guide alone does not establish which physical object owns an old value.

In a new build, test the same boundaries before bulk allocation. Confirm that the naming dictionary used by designers, label preparers, and receiving operations is the same revision. Make the handoff include both the dictionary and the issued register. A neat installation with no allocation history leaves operations unable to extend the scheme confidently.

Scenario: a service name was mistaken for panel identity#

Consider a separate fictional case in DC01 / H1. Panel PNL-G01-301 occupies DC01/H1/R301/U40. An older work package calls it “Storage Panel,” while a later package calls the same panel “Compute Panel.” Neither phrase is an issued physical identity. The operations lead initially asks for two replacement stickers, which would preserve the ambiguity.

The reviewer compares the panel's recorded position, existing identifying evidence, and work-package history. The diagnosis is one physical panel with changing service descriptions. The naming owner decides that PNL-G01-301 is the retained panel identity in this example. The dictionary defines the service description as a separate editable attribute. Both historical phrases become clearly marked aliases in the crosswalk, tied to their respective work packages.

The label preparer produces a proof showing the retained panel ID and approved location information. The records owner updates the active panel entry and records how the old descriptions resolve to it. The reviewer checks that a work order using either historical description finds the intended panel without creating a second active panel record. Closure includes the approved dictionary revision, the alias crosswalk, and evidence that the installed identifier agrees with the record.

If the investigation had found two physical panels, the outcome would be different. Each would require its own allocation decision and separate location evidence. The owner cannot choose the one-panel outcome merely because it makes the register easier to tidy.

Decide who owns unresolved naming questions#

Assign questions to the role capable of deciding them. The allocation owner resolves uniqueness and reuse rules. The location owner resolves hall, row, and rack vocabulary. The asset owner decides which physical identities persist through moves or replacement. The printing owner validates how the approved text fits the chosen layout. The receiving operations team confirms that the result can be interpreted during actual work.

Keep each unresolved question attached to a concrete example and the work it affects. “Choose a separator” is too vague; “the current export splits DC01-H1-R301 into three columns when imported with this setting” gives the owner something reviewable. Record the decision, affected templates, and effective revision together. Where a decision is deferred, state which issuance or printing work remains held.

Review the policy when a real change exposes a gap: a new object class, a new hall, a system migration, or a move pattern the dictionary cannot describe. Record the triggering example and update the affected rules. Rewriting unrelated conventions at every review makes it harder to understand which change solved the problem.

Turn a standards reference into a reviewable local policy#

A reference to TIA-606 is a starting point for the project's requirements discussion, not a complete naming dictionary. The cited public scope overview describes administration through identifiers, records, relationships, and reports. Keep the distinction between that overview, the edition adopted by the project, and the original local examples in this guide.

Create a requirements-to-decision record for the actual work package. For each applicable requirement identified by the authorized project reviewer, record the governing document and edition, the decision it affects, the proposed local treatment, and the evidence the receiving team will inspect. Use the full applicable source when a requirement must be interpreted; do not turn a short publisher summary into a clause-level compliance claim.

Separate three kinds of statements in the naming document. A project requirement states what the adopted documents or owner require. A local policy decision states how the facility chooses to implement a convention within those requirements. A worked example shows a fictional or project-specific instance of that decision. A reader should be able to tell which kind they are reading without relying on the author's memory.

If the project reviewer cannot determine applicability from the available material, record the question and the role responsible for deciding it. Continue developing unaffected examples and field definitions, but keep the disputed rule unapproved. A clear unresolved decision is more useful than describing every local choice as “TIA compliant” without supporting evidence.

Compare location-rich and record-linked identifiers#

A location-rich identifier can help a worker interpret where an object belongs when the field meanings and scope are understood. Its useful property is visible context. Its maintenance question is what happens when that context changes. If a field describes a moveable object's current location, the policy must explain which printed and stored values change during a move and how old references remain interpretable.

A record-linked asset identifier can retain identity while location, owner, service, and other attributes change in the associated record. Its useful property is separation of identity from those attributes. Its practical question is whether the worker can reach and interpret the needed record at the point of work. An identifier that selects a correct record is only part of the task when the worker also needs a readable destination.

Compare the two approaches with the same cases rather than declaring one universally superior. Give reviewers a moved asset, an unchanged rack location, a replaced panel, and a work order used outside the local hall. Ask what the label tells them directly, what they must look up, and which records require change. The answers help the owner choose a pattern suited to that object class.

A combined label may carry a durable ID and a separately identified location line. If the site adopts that arrangement, make the line meanings explicit and assign maintenance for each. Do not concatenate the two into a single unexplained identity merely because the physical label has room for them.

Work through a naming change without creating a second system#

Suppose a separate fictional policy review in DC01 / H1 finds that old panel identifiers contain service-team names. Panel PNL-G01-302 at DC01/H1/R302/U38 has appeared in work orders as “Storage-West-Panel” and “Platform-West-Panel.” The owner proposes a stable panel ID with service and location kept as separate attributes.

Before release, list the references that currently select the panel: the physical marker, panel map, cable endpoint schedules, active work orders, and any print source. For each, record its current value, approved replacement or alias treatment, owner, and completion evidence. This list defines the transition scope. It is not enough to publish the new syntax and assume that every consumer will adopt it.

Prepare the panel label proof and the record crosswalk together. Keep both old descriptions clearly historical or transitional according to the approved policy. Have a reviewer start with an old work-order description and find the intended physical panel, then start with the new ID and find its current location and relationships. Both directions should work within the supported access context.

If a dependent system cannot yet use the new pattern, record its exact limitation and the approved interim mapping. Give that exception an owner and closure condition. Do not let the interim display become another undocumented issuer of physical IDs. When the dependency is corrected, retain the history needed to interpret its old references while making the active value unambiguous.

Define policy maintenance through concrete triggers#

Name the events that should bring the policy back for review. Examples include adding a hall, introducing a new object class, changing an inventory system, discovering a collision, or finding that an issued value cannot fit an approved label. Tie each event to the affected rule and a representative case so the review can stay focused.

Keep a change record describing what changed, why it changed, which example exposed the problem, and which issued or future identifiers are affected. State whether the revision changes new issuance only, requires an active transition, or clarifies existing meaning without changing IDs. Those outcomes require different communication and physical work.

Maintain the dictionary, allocation register, print templates, and lookup instructions as related records with identifiable revisions. A policy update that changes a field's meaning while leaving an old template active can create apparently valid labels under two interpretations. Have the responsible owners record their actual update outcomes.

For a periodic review already required by the site's process, sample cases that exercise the difficult boundaries: reused locations, moved assets, long identifiers, and separate halls with repeated short values. The purpose is to confirm that the current policy still explains actual work. Avoid a ceremonial review that only changes the document date while leaving known exceptions unresolved.

Worked example#

Fictional local policy: the full rack address contains three independently defined fields.

DC01-H1-R014
 |    |   +-- Rack R014 within hall H1
 |    +------ Hall H1 within site DC01
 +----------- Site DC01
Rack location: DC01-H1-R014
Asset identity: AST-008421 (separate field)

This fictional syntax is a local choice, not official TIA syntax. Rack expansion leaves the example asset identity unchanged.

Common mistakes#

Using an unexplained abbreviation that only one team understands.
Encoding a changeable service name into every physical object's identity.
Publishing examples without an owner or issuance rule.

Verification#

Each field has one stated meaning.
Uniqueness scope is explicit.
Expansion examples remain unambiguous.
A second reader decodes the examples correctly.
Policy revision and issuance owner are recorded.

Worksheet: Naming convention worksheet#

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
Object type	Kind of item governed by this rule.	Rack location
Uniqueness scope	Boundary within which the full ID is unique.	All DC01 halls
Pattern	Field order and separators.	SITE-HALL-RACK
Field meanings	Meaning assigned to each component.	Site; hall; rack
Allowed values	Character, case, and padding rules.	Uppercase; rack R001-R999
Example identifier	A complete sample of the pattern.	DC01-H1-R014
Policy revision	Version governing issuance.	NAM-01 rev 2
Owner	Role accountable for the rule.	Infrastructure records lead
Evidence	Record of the review or source decision.	DEMO-NAM-REVIEW-01
Verifier	Person who checked interpretation.	Example reviewer
Verification date	Date the check was performed.	2026-09-12
Status	Review state; examples are not approvals.	Example only

Frequently asked questions#

Must every ID contain its location?#

No. Decide what the identifier represents. A durable asset ID can refer to a record holding its current location.

Should we relabel everything immediately?#

Define the policy first. Use a tracked transition list and the site's change process to resolve old formats in manageable groups.

Who should approve the convention?#

Name a policy owner who can resolve object meaning and allocation scope, then obtain input from the teams that create, print, maintain, and use the records. Approval should identify the revision and the examples reviewed. A meeting agreement without a published dictionary gives later issuers nothing reliable to follow.

Can we keep a useful legacy abbreviation?#

Yes, if its meaning, scope, and relationship to the current identifier are explicit. Check that it does not select multiple active objects in the intended workflow. Retain an ambiguous abbreviation as historical search context rather than presenting it as a complete production identifier.

What belongs in a naming-policy exception?#

Record the affected object class, observed value, conflicting rule, responsible decision owner, temporary handling, and closure condition. An exception should explain how a specific case remains interpretable while it is resolved. It should not become an undocumented alternative convention that another team can copy freely.

Should rack numbers restart in every hall?#

Either answer works, as long as the policy says which and the label carries enough of the identifier to match. If numbers restart per hall, the hall field is part of the identifier and a work order that travels outside the hall has to carry it. If they are unique across the site, a short form is safe inside the site and still ambiguous in any report that spans sites. What does not work is restarting per hall and printing only the short form.

Should we number cabinets sequentially or by floor tile?#

Sequential numbering reads more easily and lets anyone guess the next value. Tile coordinates never renumber, because the coordinate belongs to the floor rather than to the equipment. Choose sequential for a hall that is built out once, and coordinates for a hall you expect to re-lay out. The expensive outcome is choosing sequential and then re-laying out, which leaves R014, R014A and R014B sitting nowhere near each other.

How many digits should a rack number have?#

Set the width from the largest count the field will ever plausibly hold, not the current one, and pad to it. Two digits with no padding breaks the first time something sorts R100 between R1 and R2, which is every plain text sort in the toolchain including a printer merge file. Padding wider than needed wastes label area that the readable part of the identifier needed.

Can the rack identifier also be the server's host name?#

Only if you accept renaming the host every time the machine is re-racked, and finding every place the old name was recorded. The two names answer different questions: one says where to walk, the other selects a machine. Keep them separate and let the record join them.

Which letters should we skip in row identifiers?#

At minimum the ones that are misread on a worn label or in handwriting: I against 1, O against 0, and usually S, Z and Q. Skipping them costs nothing at design time. Record which letters you skipped, in the dictionary, or somebody fills the gaps back in during the next expansion and reintroduces the ambiguity you paid for.

Does upper and lower case matter in an identifier?#

Prefer that it does not. A policy where R014 and r014 are different objects will eventually produce two records for one cabinet, because no reader can resolve that difference on a printed label. Pick one case for issuance, state that comparison ignores case, and make sure the systems that store the value agree.

Where should the numbering start in a row?#

Wherever you like, as long as the policy states the origin and the direction, and the room shows them. An origin that exists only in the policy document is an origin only its author can apply. Signing both ends of the row with the range and the direction is what makes the decision usable by the person standing in the aisle.

Can we put the customer or tenant name in a colocation cabinet identifier?#

It is tempting, because it makes a floor plan readable at a glance, and it breaks at the first renewal or churn. The tenant belongs in a record attribute and, if the floor genuinely needs it visible, on a separate marker that can be replaced without touching the cabinet identifier everything else points at.

More worked label examples

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

GUIDE 01 / EXAMPLE 1

Issue a cabinet ID and a separate location address

A fictional issuance record distinguishes a movable cabinet from its floor location, so each field has one meaning.

SCOPE: DC01 / H1
POLICY: NAM-G01-101 r1; issuer: Infrastructure records

PHYSICAL LABEL FACE          ISSUANCE RECORD
+----------------------+     Type: Cabinet asset
| CAB-G01-101          | --> Identity: CAB-G01-101
| LOC DC01-H1-R101     |     Location: DC01-H1-R101
+----------------------+     State: Issued

DICTIONARY
CAB = cabinet asset; G01 = fictional example namespace
101 = allocated sequence; not a row or rack coordinate
DC01-H1-R101 = site / hall / rack-location address
RESERVED NEXT: CAB-G01-102; location assigned separately

FICTIONAL EXAMPLE / NOT TO SCALE

Replace the example namespace with the object-type codes your allocation owner actually issues. Decide whether the cabinet itself is tracked as an asset before using both fields.
Define uniqueness for the complete ID and location address separately. Test the longest permitted address in the label layout and in the work-order field before approving the pattern.

GUIDE 01 / EXAMPLE 2

Keep a panel identity stable when its service changes

A second naming-policy example keeps the panel ID constant while a changeable service description remains a record field.

SCOPE: DC01 / H1
OBJECT LABEL FACE
+------------------------+
| PANEL PNL-G01-201      |
| DC01-H1-R201 / U40     |
+------------------------+

RECORD FIELD        BEFORE               AFTER
Panel ID            PNL-G01-201          PNL-G01-201
Service description Storage links       Compute links
Location            R201 / U40          R201 / U40
Policy reference    NAM-G01-201 r2       NAM-G01-201 r2

FIELD RULE: service description is not part of panel ID
NEW PANEL: allocate PNL-G01-202; never copy PNL-G01-201