The same filler, three names

A bottling plant runs three lines. Each was commissioned in a different year by a different integrator. On line 1 the good-bottle count from the filler is called Filler_Cnt. On line 2 it is FIL2_COUNT_GOOD. On line 3 someone typed L3 Filler Good Bottles, with spaces. All three mean exactly the same thing.

Now the plant manager asks for one screen showing good bottles per hour on every line. Someone must find the three names, learn what each one means, check whether each counts the same way, and write three queries. When line 4 arrives, the work is repeated. When an AI agent is asked "how many good bottles did we make yesterday?", it has to guess that these three names are the same measure, and it may guess wrong.

A naming standard fixes this at the source. It is a short document, owned by the people who run the plant, that says how every machine, line, measure and tag is named. It costs nothing but an afternoon to write, and it is the part of a data platform that domain experts, not IT, are best placed to own.

The names your plant already has

No plant starts from nothing. Each piece of equipment already carries several names, each made for a different job and a different team. A standard does not throw them away; it picks one as the name the platform uses and records the others against it.

What each name tells you

An ISA-5.1 tag tells an instrument technician what an instrument measures and does: in FIC-101, F is flow, I is indicating, C is controlling, and 101 is the loop number ^[1]. An ISO/IEC 81346 code tells an electrician what function a part serves, which product it is and where it is ^[2]. A device address tells the controller where a value sits in memory. None of these tells a dashboard which site, area and line a value comes from. That is what the platform's name must do.

The backbone: the ISA-95 hierarchy

The platform's name needs an order that every plant already understands. ISA-95 (IEC 62264) provides it: enterprise, site, area, then the work centre (a line, a process cell or a storage zone) and the equipment inside it ^[4]. It is the same hierarchy Session 3's schema used for its tables. Written as a path, each level becomes one segment, joined by slashes, which is exactly how MQTT topics are built ^[5].

This order is what makes a Unified Namespace work: a consumer can ask for acme/cle/bottling/+/filler/good_count and receive the good count from every filler in the bottling area, without knowing how many lines there are. The + is MQTT's single-level wildcard; # matches everything below a level ^[5]. Neither works if the levels are in a different order on each line.

Six rules on one page

A standard that people can remember beats a complete one that nobody reads. The six rules below cover almost every name a small or mid-size plant needs. Each exists because breaking it has caused a real problem.

The vocabulary: measures your intent needs

Start from the intent statement you wrote in Session 2. It names the decision and the data the decision needs. Each piece of data becomes a measure, and each measure gets one word. For a supervisor deciding which line gets the next technician, from downtime by reason and open work orders, the list starts small:

Counts and states carry no unit suffix because they have no physical unit. A state should use a fixed list of values, written in the standard. PackML's machine states are a published model to borrow from if your equipment supports it ^[3].

Time, and where it lives

A measure's name never contains a time or a date. Each value carries its own timestamp, stored in UTC and written in ISO 8601 form (for example 2026-10-04T13:05:00Z) ^[4]. Shift and day boundaries are computed from the timestamp and the plant's time zone, never baked into a name such as count_shift_b.

Writing it down

The standard is a file in the platform's repository, so it is versioned, reviewed and visible to every person and agent who works on the platform. A short Markdown file is enough. Here is a complete one for the bottling plant:

# Naming standard (version 1)
Owner: operations engineering. Changes by pull request, reviewed by the area owner.

## Path
enterprise/site/area/line/equipment/measure   (all six, in this order)
Example: acme/cle/bottling/line-2/filler/good_count

## Characters
Lower case a-z and digits 0-9 only.
Levels: words joined by hyphens (press-shop, line-2).
Measures: words joined by underscores (good_count).
Never: spaces, dots, + # or a leading $.

## Units
Physical measures end with the unit: temp_c, pressure_bar, flow_l_min, speed_bpm.
Counts and states have no unit.

## Vocabulary (add a word only by review)
state, down_reason, good_count, reject_count, speed_bpm, temp_c, pressure_bar

## Codes
Sites: cle = Cleveland. Areas: bottling, packaging, utilities.
Lines: line-1 ... line-9. Equipment: filler, capper, labeller, pasteuriser, palletiser.

## Aliases
Every legacy tag is recorded in the alias table with its standard name.

Renaming the legacy tags

With the standard written, each existing tag gets its standard name. Nothing in the control system is renamed: the PLC keeps its addresses and the SCADA keeps its tags. The connector, or the template in your SCADA, maps each old name onto the new one, and the alias table records the pair ^[5].

1. Export the tag list from the SCADA or historian as a spreadsheet (name, description, unit, address).
2. Add a column for the standard name. Fill it level by level: site, area, line, equipment, then the measure from the vocabulary.
3. Where no vocabulary word fits, write the proposed word in a separate column. These go to review, not straight into the standard.
4. Where two tags turn out to be the same measure, keep one and mark the other as a duplicate.
5. Save the finished list as the alias table: legacy name, standard name, unit, source system.

Make the right name the easy name

People do not break naming standards on purpose. They break them at 2 a.m. during a changeover, when typing a new tag by hand is faster than looking up the rule. The answer is to make sure nobody types names by hand. In a SCADA such as Ignition, a user-defined type (UDT) is a template: define a Filler once with its members (state, good count, reject count, speed), and every filler you create from it has exactly those members with exactly those names ^[1]. A parameter maps each instance onto its controller's addresses, which is aliasing done by the template.

The same idea works without a SCADA. CESMII's Smart Manufacturing Profiles and the OPC UA information models are published, reusable definitions of a type of equipment and its attributes, so different vendors' machines can present the same structure ^{[2] [3]}. Whatever tool you use, the pattern is the same: one type, many instances, names generated from the type.

Make the database refuse a bad name

The platform's database is the last line of defence. Session 3's schema has a table for the measures the platform knows about. A CHECK constraint on that table makes PostgreSQL refuse any row whose path breaks the standard, whoever or whatever tries to insert it ^[4]. A constraint cannot be forgotten, and an AI agent that writes a bad name gets an error instead of silently creating an island.

-- Every measure path must follow the naming standard (docs/naming-standard.md).
alter table measures
  add constraint measures_path_follows_standard check (
    path ~ '^[a-z0-9]+(-[a-z0-9]+)*(/[a-z0-9]+(-[a-z0-9]+)*){4}/[a-z][a-z0-9]*(_[a-z0-9]+)*$'
  );

Read the pattern left to right: one level of lower-case words joined by hyphens, then exactly four more such levels after a slash, then a slash and a measure of lower-case words joined by underscores. It is exactly rules 1, 2, 3 and 6 of the standard. Rule 4 (vocabulary) is checked against the list in the next step, and rule 5 (units) by the vocabulary itself, because every word in the list already carries its unit.

Check every change in CI

The database catches names at the moment they are written. CI catches them earlier, in the pull request, before anything reaches the live platform. A short test reads the vocabulary from the standard, then checks every name in the seed data, the synthetic data generator from Session 4 and any configuration file. Branch protection (Session 1) means a failing check blocks the merge ^[5].

// test/names.test.mjs — every name in the seed data follows the standard.
import { readFileSync } from "node:fs";
import assert from "node:assert/strict";

const standard = readFileSync("docs/naming-standard.md", "utf8");
const vocabulary = standard.split("## Vocabulary")[1].split("\n")[1].split(",").map((w) => w.trim());
const PATH = /^[a-z0-9]+(-[a-z0-9]+)*(\/[a-z0-9]+(-[a-z0-9]+)*){4}\/[a-z][a-z0-9]*(_[a-z0-9]+)*$/;

const seed = JSON.parse(readFileSync("db/seed/measures.json", "utf8"));
for (const { path } of seed) {
  assert.match(path, PATH, `${path}: breaks the naming standard`);
  const measure = path.split("/").pop();
  assert.ok(vocabulary.includes(measure), `${path}: "${measure}" is not in the vocabulary`);
}
console.log(`${seed.length} names follow the standard`);

The file names above (db/seed/measures.json) are examples: your agent will use the paths in your own repository. What matters is that the test reads the standard itself, so the document and the check can never disagree.

An owner for every branch

A standard also needs people. Give each area of the tree an owner: the person who decides what a new measure in bottling is called, or whether packaging gets a new line code. Changes follow one loop, through a pull request, so every decision has a reviewer and a date.

Renames never break anything

Sooner or later a name will be wrong: a line is renumbered, an area is split. Never rename in place. Add the new name, record the old one as an alias, move consumers across, and only then retire the old name. Consumers keep working throughout, and the history is never orphaned.