3yearplan/schemas/uns/QUESTIONS.md

UNS Hierarchy — Follow-up Questions

Purpose: open questions that need answers before the per-site UNS subtree files in this directory can be finalized. Capturing them up front so the hierarchy walk doesn't have to be redone if a convention changes mid-walk. Once a question is answered, fold the answer into the relevant subtree file (and into goal-state.md → UNS naming hierarchy standard if the answer changes a global convention).

Owner

The schemas-repo owner team (TBD per ../README.md open questions). Until ownership is named, these questions sit with the 3-year-plan author.

Status legend

• OPEN — needs an answer before the walk produces stable output.
• OPEN — informational — answer would help but the walk can proceed without it; resolve later.
• DEFERRED — answered "later" by the goal-state spec; included here so the walk team doesn't reopen it.

---

Site-level questions

Q1 — Warsaw North building set (OPEN — blocks warsaw-north.json)

Warsaw North is a campus running per-building clusters (per current-state.md → Largest Sites). What is the authoritative list of production-building numbers at Warsaw North? (Warsaw West is confirmed as buildings 5 and 19.) Building numbers are needed before warsaw-north.json can be authored — using _default would be structurally wrong for a multi-cluster campus.

Sub-question: are non-production buildings on the Warsaw campuses (offices, warehouses, labs, utilities) ever expected to host equipment that lands in the UNS? If yes, the area set widens beyond production buildings. If no (likely), the rule is "Areas at Warsaw campuses = production buildings only" and we capture that explicitly.

Q2 — Site shortname conventions (OPEN — informational, blocks tmt.json confidence)

The current draft uses warsaw-west, warsaw-north, shannon, galway, tmt, ponce as site segments. Are these the canonical shortnames? Specifically:

• TMT — is this an acronym, and if so should the UNS segment be the acronym (tmt) or an expanded form? Site-name uniqueness across the org is the only hard constraint; readability is secondary.
• Does the org have an established site-code system (e.g., 3-letter site codes used by IT/HR/finance) that the UNS should align with rather than invent its own naming? If yes, switching now is cheap; switching later is not.
• Capitalization in displayName — is "TMT" the right display form, or does it expand to a longer name in stakeholder-facing artifacts?

Q3 — Multi-floor / multi-tenant production buildings (OPEN — informational)

Are any production buildings (Warsaw or otherwise) split across multiple floors with distinct production processes per floor? If yes, does floor become an Area-equivalent (i.e., bldg-5-floor-2) or a Line-level distinction? Recommendation: keep Area at the building level and let Line names carry floor distinctions when needed (line-2-mezzanine) — but worth confirming before the walk.

Q4 — Sites not yet integrated (DEFERRED)

Berlin, Winterthur, Jacksonville, and other unintegrated smaller sites are deliberately not seeded. The walk does not cover them. The site-list volatility note in current-state.md applies — wait until each site has firm onboarding scope before authoring its subtree.

---

Line-level questions

Q5 — Line naming convention (OPEN — must be settled before walk produces line names)

Two reasonable patterns appear in the current goal-state.md examples:

• Numeric — line-1, line-2, ... — site-stable, terse, but loses semantic info.
• Process-named — assembly-a, packout-1, injection-2 — readable, but requires a controlled vocabulary so two sites don't end up with assembly-a meaning different things in different contexts.

Recommended convention to ratify: allow either form, but prefer numeric-with-displayName-carrying-process (name: "line-2", displayName: "Line 2 — Machining"). Numeric for the path (machine-stable, site-locally-unique); process info in the displayName (operator-readable). The walk should default to numeric line-N and capture the process description in displayName.

Sub-question: when a site's existing line numbering (per System Platform / Ignition) is non-contiguous or uses internal codes (e.g., MX-204), do we (a) preserve the existing identifier verbatim as the line name (after kebab-casing) or (b) renumber to sequential line-N and stash the legacy identifier in displayName? Recommendation: (a) preserve — renaming creates lineage churn and breaks operator mental model. Confirm before the walk.

Q6 — Line vs. cell vs. work center (OPEN — must be settled before walk)

The goal-state defines a Line as "a production line or work cell within an area." That blurs two concepts:

• A line typically means a full sequence of stations producing a product end-to-end.
• A work cell is often a smaller grouping (one to a few machines) operating semi-autonomously.

Question: is the UNS Line level (a) always the full-line concept (cells live below it, possibly as part of equipment naming), (b) always the smallest-named-grouping (so a four-cell line shows up as four UNS lines), or (c) whichever the site's own taxonomy uses (which makes the level non-uniform across sites)? Recommendation: (a) full-line for uniformity, with cells encoded in equipment names (cell-3-cnc-mill-05) — but confirm. Sub-line groupings can also be supported by an optional 4.5-level convention if it ever proves necessary, but we should not introduce that without a real driver.

Q7 — Multi-product lines and changeovers (OPEN — informational)

When a single physical production line runs different products on different shifts or after changeover, does that line stay one UNS Line (recommended — physical reality drives the path) or split into one Line per product (not recommended — would shift paths on every changeover)? Recommendation: one UNS Line per physical line, with product association captured at the canonical event level (the running work-order / product-id is in the message, not the topic / path). Confirm.

Q8 — Lines that span buildings (OPEN — informational)

If a production flow physically crosses building boundaries on a Warsaw campus (e.g., front-end machining in bldg-5, finishing in bldg-19, joined by manual transport), is that one logical line spanning two areas (which the 5-level hierarchy can't directly express — each line lives under exactly one area) or two coupled lines, one per area? Recommendation: two lines, coupled by canonical workorder events — keep the hierarchy strict and let the event stream carry cross-building flow. Confirm.

---

Equipment-level questions (level 5)

These don't block the walk's higher-level output but should be settled before equipment names are committed, since the walk also captures equipment instances.

Q9 — Equipment leaf naming convention (OPEN — must be settled before walk commits equipment names)

The goal-state example uses cnc-mill-05. Pattern appears to be {class-shortname}-{counter}. Questions:

1. Counter scope — is 05 unique within the line, the site, or the enterprise? Recommendation: unique within the (site, area, line) triple — the path itself disambiguates across sites. Enterprise-wide uniqueness is provided by the UUID, not the leaf name; trying to make leaf names enterprise-unique fights with operator readability.
2. Class-shortname source — does it come from the equipment-class file's classId (e.g., fanuc-cnc → fanuc-cnc-05) or a class-defined display shortname (cnc-mill-05)? Recommendation: a separate pathShortname field on the equipment-class definition, distinct from classId. Add this to the equipment-class schema once confirmed.
3. Asset-tag-based naming — some sites have existing physical asset tags on equipment (e.g., WW-CNC-204). Should the UNS leaf name preserve that tag (after kebab-casing) or use the class-counter pattern with the asset tag captured as another equipment identifier alongside UUID? Recommendation: class-counter pattern in the path; asset tag stored as an equipment-level identifier alongside UUID and EquipmentId. The path is for navigation, the identifiers are for lineage / cross-system joins.

Q10 — Mobile or portable equipment (OPEN — informational)

Some equipment is portable and moves between lines (e.g., a calibration rig, a mobile inspection station). Does it:

• (a) Get a stable home line and stay on that path even when physically elsewhere?
• (b) Get re-pathed each time it moves (UUID stays stable, path changes — supported by the Area-promotion governance pattern in goal-state.md)?
• (c) Live at _default line as "site-level shared equipment"?

Recommendation: (a) with a "shared" home line per site (_default line if no better fit) — minimizes path churn. Confirm.

Q11 — Non-production equipment (utilities, monitoring, support) (OPEN — informational)

Compressed-air compressors, chillers, building-monitoring sensors, lab equipment — does this surface in the UNS?

• (a) Yes, with a support or utilities line per area: zb.warsaw-west.bldg-5.utilities.compressor-01.
• (b) Yes, on _default line: zb.warsaw-west.bldg-5._default.compressor-01.
• (c) No — out of UNS scope; surfaced through a separate channel.

Recommendation: (a) with a reserved line name (utilities, support, lab, etc. — short list to be ratified). Out-of-scope is wrong because these do feed analytics (energy, OEE-adjacent metrics). _default is wrong because that placeholder is reserved for "level not applicable." Confirm and add the reserved line names to the global rules.

---

Cross-level questions

Q12 — Lines / equipment shared across sites (OPEN — informational, low-frequency)

Are there any equipment items that are physically singular but logically shared across multiple sites (e.g., a corporate lab in South Bend whose results feed multiple sites)? If yes, where does it sit in a per-site hierarchy? Recommendation: path under its physical site; logical sharing handled at the canonical-event consumer level, not in the path. Confirm if any such cases exist.

Q13 — Hierarchy change governance (OPEN — informational, will be settled when ownership is named)

goal-state.md already commits to: Area-placeholder → named-area promotion via PR; UUID stable across path changes; dim_equipment in Snowflake retains historical paths. Open: who reviews and approves a hierarchy change PR? A site's own SMEs only? A central data-governance group? The schemas-repo owner team alone? Will resolve when the schemas-repo owner team is named.

Q14 — Synthetic / aggregate equipment nodes (OPEN — informational)

Will the UNS ever need to expose synthetic equipment — e.g., a virtual "line-level OEE node" that publishes computed metrics derived from the underlying equipment? If yes, does it follow the same path/UUID rules as physical equipment, or sit in a different namespace? Recommendation: same rules, with equipment-class metadata flagging it as synthetic; physical vs synthetic is a property of the class, not a hierarchy distinction. Defer the decision until a real synthetic-equipment use case appears (likely with the canonical state vocabulary's OEE work in Year 1–2).

---

How to use this list during the walk

1. Before starting per-site walks, get answers to Q1, Q2, Q5, Q6, Q9 — these shape the walk's output schema.
2. Q3, Q7, Q8, Q10, Q11 can be resolved by the walk team applying the recommended defaults; raise back to this list only if a site's reality contradicts the default.
3. Q12, Q13, Q14 do not block the walk. Resolve later.
4. As each question is closed, move it to a Resolved section at the bottom (with the resolution and the file(s) updated) so the audit trail is preserved.

---

Resolved

(empty — populate as questions are closed)