Tagging basics — what a tag is made of
A tag is the name an element answers to for the rest of its life. It appears on drawings, in schedules, in the handover data the facilities team inherits, and in the clash report someone opens two years from now. This guide explains what goes into one and why, then how STING builds them.
Why "AHU-1" is not enough
Most projects start by numbering equipment in the order it was drawn: AHU-1, AHU-2, AHU-3. This survives until the second building arrives, or a second floor gets its own air handling unit, and suddenly there are two things called AHU-2 in the same information model.
The deeper problem is that a bare number carries no meaning. Given "AHU-2" alone you cannot tell which discipline owns it, which building or floor it serves, or what system it belongs to. Every one of those questions then has to be answered by opening the model — which is exactly the manual lookup that coordinated information is supposed to eliminate.
A structured tag answers all of them in the name itself.
The eight parts
STING assembles tags from eight parts joined by hyphens, in a fixed order:
| Part | Answers | Examples |
|---|---|---|
| DISC | Which discipline owns it | M, E, P, A, S, FP, LV, G |
| LOC | Which building or site area | BLD1, BLD2, EXT |
| ZONE | Which zone within that | Z01, Z02 |
| LVL | Which level | L01, L02 |
| SYS | Which system | HVAC, DCW, DHW, SAN, LV |
| FUNC | What it does in that system | SUP, HTG, DCW, SAN, PWR |
| PROD | What kind of thing it is | AHU, LUM, DB, DR, COL |
| SEQ | Which one of those | 0001, 0042 |
Put together, a supply air handling unit on level 2 of building 1 reads:
M-BLD1-Z01-L02-HVAC-SUP-AHU-0003
You can read that without opening anything. Mechanical, building 1, zone 1, level 2, HVAC system, supply function, air handling unit, the third one. That legibility is the whole point.
Where each part comes from
Almost none of this is typed by hand — that is what makes it viable at scale.
DISC and PROD come from what the element already is. A lighting fixture is electrical and gets LUM; a duct is mechanical and gets DU; a structural column gets COL. STING keeps a lookup from Revit category to discipline and product code, and refines it using the family name — so a mechanical equipment family named as a chiller does not get labelled as an air handling unit just because both live in the same category.
SYS and FUNC come from the element's system where one exists. A pipe assigned to a domestic cold water system gets DCW, and its function follows from the system. Where no system is assigned, STING falls back to a sensible default for the category — which is one reason unassigned MEP elements are worth fixing before a big tagging run.
LVL comes from the element's level. LOC and ZONE are inferred from the room the element sits in, matched against name patterns — a room named "Block A" resolves to BLD1, something in "car park" or "landscape" resolves to EXT. These patterns are yours to adjust; the defaults are a starting point, not a standard.
How numbering works, and why it surprises people
SEQ is the only part that is genuinely arbitrary, and it is the part that causes the most confusion.
STING does not keep one running counter for the whole project. It keeps a separate counter for each combination of discipline, system and level. So the first supply-air unit on level 1 and the first on level 2 are both numbered 0001 — they are distinguished by the L01 and L02 parts, not by the number.
This is deliberate. Per-level numbering means adding a floor does not renumber the floors below it, and each level's schedule reads from 1 rather than starting at 47. If you would rather include zone or location in the counter, that is configurable.
Collisions
When STING is about to write a tag that already exists, it has three ways to behave, and you choose:
- Auto-increment — take the next free number. The default, and usually what you want.
- Skip — leave anything already tagged completely alone. Right when you are adding to a model whose existing tags are correct and issued.
- Overwrite — replace existing tags with newly generated ones. Right when you have inherited an inconsistent model and want to re-tag from scratch.
Overwrite is the one to be careful with. If tags have already gone out on a drawing, overwriting them breaks the link between the issued document and the model.
How STING approaches it
Tagging lives on the TAGGING tab of the main panel. The buttons are grouped by what they do, and the order below is the order you would normally use them.
Audit before you write
Pre-Audit is a complete dry run that changes nothing. It reports what would be tagged, what would be skipped, which collisions would occur and how they would resolve, which elements are missing information, and a breakdown by discipline. It asks whether you want to audit the Active View or the Entire Project.
On a model you did not build, run this first. It is the cheapest way to discover that half the pipework has no system assigned, before rather than after you have written several thousand tags.
Then tag
- Auto Tag — tags what is in the current view, filtered to the disciplines that view is actually about.
- Batch Tag — tags the whole project. It sorts elements by level, then discipline, then category first, so that numbering runs in a sensible contiguous order instead of scattering.
- Tag New — only what has appeared since the last run. This is the one to use on a live model.
- Tag+Combine — tags and assembles the combined text in a single pass.
- Re-Tag, Copy Tags, Swap Tags, Fix Dupes — repair operations for inherited models.
Both tagging commands skip elements you do not own in a shared model, and skip demolished elements, so running them on a workshared project will not fight your colleagues.
Then tidy
▶ SMART ORGANISE deals with the separate problem of tags that exist but sit badly — overlapping, covering geometry, or trailing leaders across a drawing. Quick is a fast pass, Deep works harder, and Anneal keeps rearranging until it settles on the least-crowded result it can find. ↻ Undo reverses a run.
Use Quick during the working day and save Deep or Anneal for just before an issue — they are slower by design.
FLS, but FLS is not in the built-in list of codes the strict validator accepts. If you tag fire alarm devices and see validation complaints, add FLS to the accepted discipline codes in your project settings — the tags themselves are fine.
A sensible first run
- Pre-Audit on the active view. Read it properly.
- Fix what it flags — usually unassigned systems and missing levels.
- Auto Tag on one view, with collisions set to skip.
- Check a handful of resulting tags read the way you expect.
- Only then Batch Tag the project.
Tagging a whole model is easy to do and tedious to undo. The audit step costs a minute and routinely saves an afternoon.
Next: Drawing production covers how those tagged elements end up on properly formatted, consistently numbered sheets.