Remove equipment protocol survey — driver list confirmed by v2 team

The OtOpcUa v2 implementation team committed all 8 core drivers from
internal knowledge of the estate, making the formal protocol survey
unnecessary for driver scoping. Removed current-state/equipment-protocol-
survey.md and cleaned up all references across 7 files.

The UNS hierarchy snapshot (per-site equipment-instance walk for site/area/
line/equipment assignments + UUIDs) is now a standalone Year 1 deliverable,
decoupled from protocol discovery. Tracked in status.md and goal-state.md
UNS naming hierarchy section.

Eliminates ~52 TBDs (all placeholder data in the pre-seeded survey rows).

CLAUDE.md

@@ -16,7 +16,6 @@ Plan content lives in markdown files at the repo root to keep it easy to read an
 ### Component detail files
 
 - [`current-state/legacy-integrations.md`](current-state/legacy-integrations.md) — authoritative inventory of **bespoke IT↔OT integrations** that cross ScadaBridge-central outside ScadaBridge. Denominator for pillar 3 retirement.
-- [`current-state/equipment-protocol-survey.md`](current-state/equipment-protocol-survey.md) — authoritative inventory of **native equipment protocols** across the estate. Input to the OtOpcUa core driver library scope decision in Year 1.
 - [`goal-state/digital-twin-management-brief.md`](goal-state/digital-twin-management-brief.md) — meeting-prep artifact for the management conversation that turns "we want digital twins" into a scoped response. Parallel structure to `goal-state.md` → Strategic Considerations → Digital twin.
 
 ### Output generation pipeline

README.md

@@ -39,7 +39,7 @@ The plan also declares a **Unified Namespace (UNS)** composed of OtOpcUa + Redpa
 | File | Purpose |
 |---|---|
 | [`current-state/legacy-integrations.md`](current-state/legacy-integrations.md) | Pillar 3 denominator: 3 legacy IT/OT integrations to retire |
-| [`current-state/equipment-protocol-survey.md`](current-state/equipment-protocol-survey.md) | Year 1 protocol survey template (also produces UNS hierarchy snapshot) |
+| ~~`current-state/equipment-protocol-survey.md`~~ | Removed — protocol survey no longer needed; OtOpcUa v2 team committed driver list directly |
 | [`goal-state/digital-twin-management-brief.md`](goal-state/digital-twin-management-brief.md) | Digital twin management conversation brief (completed) |
 
 ### Output Generation

STATUS.md

@@ -22,7 +22,7 @@ The plan is substantively fleshed out. All three core documents are populated, t
 **Component detail files:**
 
 - [`current-state/legacy-integrations.md`](current-state/legacy-integrations.md) — authoritative inventory for pillar 3 retirement. **Closed as denominator = 3**: LEG-001 Delmia DNC, LEG-002 Camstar MES, LEG-003 custom email notification service. Historian MSSQL reporting surface explicitly carved out as *not* legacy.
-- [`current-state/equipment-protocol-survey.md`](current-state/equipment-protocol-survey.md) — template/schema for the Year 1 protocol survey that drives OtOpcUa core driver library scope. **Dual mandate:** same discovery walk also produces the initial UNS naming hierarchy snapshot (equipment-instance granularity) for the `schemas` repo. Six expected categories pre-seeded as placeholders.
+- ~~`current-state/equipment-protocol-survey.md`~~ — **Removed.** Protocol survey no longer needed; the OtOpcUa v2 implementation team committed the 8-driver core library from internal knowledge. The UNS hierarchy snapshot (equipment-instance walk) is now a standalone Year 1 deliverable tracked separately.
 - [`goal-state/digital-twin-management-brief.md`](goal-state/digital-twin-management-brief.md) — meeting-prep artifact for the (now completed) digital twin management conversation; "Outcome" section at top captures the resolution.
 
 **Input / reference files:**
@@ -65,7 +65,7 @@ All four items from the previous status check have been **advanced to the point
 ### External-dependency items — waiting on real-world action
 
 1. **BOBJ → Power BI coordination with reporting team.** Plan position documented in `goal-state.md` → Strategic Considerations → **Enterprise reporting: BOBJ → Power BI migration (adjacent initiative)** — three consumption paths analyzed, recommended position stated (Path C with Path A as strategic direction), eight questions and a four-bucket decision rubric included. **Action needed:** schedule the coordination conversation with the reporting team; bring back a bucket assignment. Once a bucket is assigned, update `goal-state.md` → Enterprise reporting and, if the outcome is Bucket A or B, update `roadmap.md` → Snowflake dbt Transform Layer to include reporting-shaped views.
-2. **Equipment protocol survey execution (dual mandate: protocol survey + initial UNS hierarchy snapshot).** Template, schema, classification rule, rollup views, and discovery approach documented in [`current-state/equipment-protocol-survey.md`](current-state/equipment-protocol-survey.md). The file is pre-seeded with expected categories (OPC UA-native, Siemens S7, Allen-Bradley EtherNet/IP, Modbus, Fanuc FOCAS, long-tail) as placeholders — these are **not authoritative** until real discovery data replaces them. **Dual mandate:** the same discovery walk also produces the initial **UNS naming hierarchy snapshot** (equipment-instance granularity, with site/area/line assignments and stable UUIDs) that gets committed to the `schemas` repo — see `current-state/equipment-protocol-survey.md` → **Companion deliverable** and `goal-state.md` → **Unified Namespace (UNS) posture → UNS naming hierarchy standard**. Two outputs, one walk. **Action needed:** assign a survey owner; walk System Platform IO config, Ignition OPC UA connections, and ScadaBridge templates (steps 1–3 of the discovery approach) within Q1 of Year 1 — capturing both equipment-class data (for the protocol survey) and equipment-instance data (for the UNS hierarchy) in the same pass; interview-driven gap-filling follows in parallel with core driver build. This is a **Year 1 prerequisite** — the OtOpcUa core driver library cannot be scoped without it, and the canonical model v1 cannot be published without the initial hierarchy snapshot. **Sub-blocker:** the UNS hierarchy's enterprise-level shortname is currently a placeholder (`ent` in goal-state.md); the real shortname needs to be assigned before the initial hierarchy snapshot can be committed to the `schemas` repo. Small decision, blocking the hierarchy materialization.
+2. **UNS hierarchy snapshot walk.** The protocol survey has been **removed** — the OtOpcUa v2 implementation team committed the core driver list (8 drivers) based on internal knowledge, making a formal protocol survey unnecessary for driver scoping. What remains is the **UNS hierarchy snapshot**: a per-site equipment-instance walk capturing site / area / line / equipment assignments and stable UUIDs, which feeds the initial `schemas` repo hierarchy definition and canonical model. See `goal-state.md` → **Unified Namespace (UNS) posture → UNS naming hierarchy standard**. **Action needed:** assign a walk owner; walk System Platform IO config, Ignition OPC UA connections, and ScadaBridge templates across integrated sites within Q1–Q2 of Year 1; capture equipment instances at site/area/line/equipment granularity (not protocol — that's already resolved). The canonical model v1 cannot be published without the initial hierarchy snapshot. **Sub-blocker:** the UNS hierarchy's enterprise-level shortname is currently a placeholder (`ent` in goal-state.md); the real shortname needs to be assigned before the initial hierarchy snapshot can be committed to the `schemas` repo.
 3. **Digital twin use case 2 — funded simulation initiative (exploratory).** The digital twin management conversation is complete; management provided three use cases and the plan absorbs two of them (canonical state vocabulary + canonical model declaration — see closed items). **Use case 2 (Virtual Testing / Simulation)** is served minimally by Redpanda historical replay + OtOpcUa's architectural support for a future `simulated` namespace, but **full commissioning-grade simulation stays out of scope** for this plan. **No action needed** unless and until a funded simulation initiative materializes with a sponsor, scope, and timeline; at that point the meeting-prep brief at [`goal-state/digital-twin-management-brief.md`](goal-state/digital-twin-management-brief.md) can be reused for a use-case-2-specific scoping conversation. Keep on the radar, don't actively work on it.
 
 ### Closed since last status check

current-state.md

@@ -129,7 +129,7 @@ SCADA responsibilities are split across two platforms by purpose:
   - **No single access-control point.** Authorization is enforced by whatever each consumer happens to present to the equipment — no site-level chokepoint exists to inspect, audit, or limit equipment access.
   - **Inconsistent data.** The same tag read by three different consumers can produce three subtly different values (different sampling intervals, different deadbands, different session buffers).
 - _TBD — exact inventory of which equipment is reached by which consumers today; whether any equipment is already fronted by a shared OPC UA aggregator at the site level._
-- **Equipment protocol survey.** The authoritative inventory of **native equipment protocols** across the estate (Modbus, EtherNet/IP, Siemens S7, Fanuc FOCAS, native OPC UA, long-tail) lives in [`current-state/equipment-protocol-survey.md`](current-state/equipment-protocol-survey.md). That file is the Year 1 input to the **OtOpcUa core driver library** scope — see [`goal-state.md`](goal-state.md) → OtOpcUa → Driver strategy and [`roadmap.md`](roadmap.md) → OtOpcUa → Year 1.
+- **Equipment protocols — resolved.** The OtOpcUa v2 implementation design has committed the core driver library based on the team's internal knowledge of the estate: OPC UA Client, Modbus TCP, AB CIP, AB Legacy (PCCC), Siemens S7, Beckhoff TwinCAT (ADS), FANUC FOCAS, plus the Galaxy driver carried forward from LmxOpcUa. See [`goal-state.md`](goal-state.md) → OtOpcUa → Driver strategy for the full list and stability tiers. A formal protocol survey is no longer needed for driver scoping; the **UNS hierarchy snapshot** (equipment-instance-level site/area/line/equipment walk) is still required — see [`goal-state.md`](goal-state.md) → UNS naming hierarchy standard.
 
 ### Camstar MES (sole MES)
 - **Role:** the **only MES** in use across the estate. There are no other MES products at any site — Camstar is the enterprise-wide system.

current-state/equipment-protocol-survey.md

@@ -1,268 +0,0 @@
-# Equipment Protocol Survey
-
-The authoritative inventory of **equipment protocols in use across the estate**. Feeds scope decisions for the **OtOpcUa core driver library** (see [`../goal-state.md`](../goal-state.md) → OtOpcUa → Driver strategy).
-
-> This file is the **input** to the Year 1 OtOpcUa decision: which protocols get a driver built **proactively** (core library) vs. which get built **on-demand** (long-tail) as each site onboards. Without this survey, the core driver library cannot be scoped — the whole Year 1 OtOpcUa workstream sits on top of it. See [`../roadmap.md`](../roadmap.md) → OtOpcUa → Year 1.
-
-## Why this inventory exists (and why it's not the legacy-integrations inventory)
-
-Different question, different denominator:
-
-- [`legacy-integrations.md`](legacy-integrations.md) tracks **bespoke IT↔OT integrations that cross the ScadaBridge-central boundary outside ScadaBridge**. Denominator for pillar 3 retirement.
-- **This file** tracks **equipment protocols on the OT side** — the native protocols that PLCs, controllers, and instruments actually speak on the shopfloor, which OtOpcUa has to translate into OPC UA. Denominator for the OtOpcUa core driver library scope.
-
-They are unrelated lists. Equipment that already speaks OPC UA natively is **in scope for this survey** (because OtOpcUa still needs to connect to it), even though "OPC UA → OtOpcUa" is not a driver build.
-
-## Companion deliverable: initial UNS hierarchy snapshot
-
-**The discovery walk for this survey is the same walk that produces the initial UNS naming-hierarchy snapshot.** See [`../goal-state.md`](../goal-state.md) → **Target IT/OT Integration → Unified Namespace (UNS) posture → UNS naming hierarchy standard**.
-
-The UNS hierarchy (Enterprise → Site → Area → Line → Equipment, with stable equipment UUIDs) and this protocol survey both require someone to walk System Platform IO config, Ignition OPC UA connections, and ScadaBridge templates across the estate. Running those walks once and producing two artifacts is dramatically cheaper than running them twice.
-
-**Different granularity, same source:**
-
-- **This file** captures data at **equipment-class granularity** — "approximately 40 three-axis CNC mills, Vendor X, Modbus TCP, across Warsaw West and Warsaw North" — because the core driver library scope is a per-protocol decision and individual instance detail would be noise at that level.
-- **The UNS hierarchy snapshot** captures data at **equipment-instance granularity** — one entry per physical machine, with site / area / line / equipment-name / stable UUID — because the hierarchy is a per-instance addressing surface.
-
-**Guidance for the walker:** at every step of the Discovery approach below, capture both levels of data in the same pass. Each equipment instance found becomes both (a) an increment to this file's equipment-class count for its protocol, and (b) a row in the initial UNS hierarchy snapshot for the `schemas` repo. Do not split into two discovery efforts.
-
-The initial hierarchy snapshot is not stored in this file (it belongs in the `schemas` repo as part of the UNS canonical definition), but capturing it is a **required output** of the same discovery walk. If the walker produces only protocol-survey data and no hierarchy data, the work has to be redone for the UNS snapshot — unacceptable duplication.
-
-## How to use this file
-
-- **One row per (site, equipment class, protocol) combination.** An equipment class is a grouping of functionally equivalent machines — "3-axis CNC milling machines, Vendor X, 2015–2020 generation" is one class, regardless of how many individual machines fit that description. If the same equipment class appears at multiple sites speaking the same protocol, list all sites in the `Sites` field of a single row. If the same class speaks different protocols at different sites (e.g., older fleet on Modbus, newer fleet on OPC UA), split into separate rows.
-- **Rows are discovery-grade.** Exact model numbers, exact counts, and exact firmware revisions are **not** required. The survey only has to be precise enough to scope driver work — "approximately 40 units across 3 sites, Modbus TCP" is enough; a CMDB dump is not.
-- **Missing values are fine during discovery** — mark them `_TBD_` rather than leaving blank.
-- **Rows are not removed once the driver ships.** A row represents "this protocol exists in the estate," which stays true even after OtOpcUa can speak it. Rows are removed only when the underlying equipment is decommissioned.
-
-## Field schema
-
-| Field | Description |
-|---|---|
-| `ID` | Short stable identifier (e.g., `EQP-001`). Never reused. |
-| `Equipment Class` | Human-readable grouping — machine type + vendor + generation. Precise enough to mean something to a shopfloor engineer, not precise enough to require a part number. |
-| `Vendor(s)` | Equipment manufacturer(s) covered by this class. |
-| `Native Protocol` | The protocol the equipment actually speaks on the wire. One of: `OPC UA`, `Modbus TCP`, `Modbus RTU`, `EtherNet/IP` (CIP), `Siemens S7` (ISO-on-TCP), `Profinet`, `Profibus`, `DeviceNet`, `MTConnect`, `Fanuc FOCAS`, `Heidenhain DNC`, `Siemens SINUMERIK OPC UA`, `ASCII serial`, `proprietary`, other (name it). |
-| `Protocol Variant / Notes` | Sub-variant if relevant (e.g., `Modbus TCP with custom register map`, `EtherNet/IP explicit messaging only`, `S7-300 vs S7-1500`). |
-| `Sites` | Sites where equipment in this class is present. `All integrated sites` is acceptable shorthand. |
-| `Approx. Instance Count` | Rough order-of-magnitude across all listed sites (e.g., `~40`, `~10–20`, `>100`, `unknown`). A magnitude is enough. |
-| `Current Access Path` | How equipment in this class is accessed **today** — direct OPC UA from Aveva System Platform / Ignition / ScadaBridge, via a site-level gateway, via a vendor-specific driver in System Platform, not connected at all, etc. |
-| `OtOpcUa Driver Needed?` | One of: `No — already OPC UA` (OtOpcUa connects as an OPC UA client, no driver build), `Yes — core candidate` (protocol is broad enough to warrant a proactive driver), `Yes — long-tail` (protocol is narrow; driver built on-demand when the first site that needs it onboards), `Unknown` (survey incomplete). |
-| `Driver Complexity (Estimate)` | `Low` / `Medium` / `High` / `Unknown`. Proxy for how much the driver will cost to build and maintain; influences core-vs-long-tail decision. |
-| `Priority Site(s)` | If this driver is on the critical path for onboarding a specific site or cluster, name it. Drives sequencing. |
-| `Notes` | Vendor docs availability, known quirks, existing LMX or ScadaBridge work that could be reused, anything else. |
-
-## Classification: core vs long-tail
-
-A protocol becomes a **core library driver** if it meets **any one** of these criteria:
-
-1. **Breadth** — present at **three or more sites**, regardless of instance count.
-2. **Volume** — present at **any number of sites** with a combined instance count **above ~25** across the estate.
-3. **Blocker** — needed to onboard a site that is on the roadmap for Year 1 or Year 2, regardless of how narrowly the protocol is used elsewhere.
-4. **Strategic vendor** — the protocol belongs to a vendor whose equipment is expected to grow in the estate (e.g., the vendor is winning new purchases), even if today's footprint is small. This is a **judgment call**, not a hard rule — use sparingly.
-
-A protocol is **long-tail** by default if none of the above apply. Long-tail drivers are built **on-demand** when the first site that needs the protocol reaches onboarding.
-
-**Protocols already OPC UA** are **neither core nor long-tail** — OtOpcUa speaks OPC UA natively and the work is a connection configuration, not a driver build.
-
-**Tiebreakers:**
-- When a protocol narrowly misses a threshold, **err toward long-tail.** Core drivers are a commitment to maintain; long-tail drivers are one-off builds. The cost of building a long-tail driver later is bounded; the cost of committing to maintain a core driver forever is not.
-- When a protocol narrowly makes a threshold but is **known to be retiring** from the estate (old generation equipment scheduled for replacement), **err toward long-tail** and make a note about the retirement horizon.
-
-## Current inventory
-
-> **Discovery not started.** Populate as the protocol survey is conducted. The rows below are pre-seeded with **expected categories** based on typical discrete-manufacturing estates — they are **placeholders** to make the shape of the table obvious, not confirmed observations. Remove or merge them as real discovery data arrives. **Nothing in this section is authoritative until it has a non-TBD `Approx. Instance Count` and at least one confirmed `Sites` entry.**
-
-### EQP-001 — OPC UA-native equipment
-
-| Field | Value |
-|---|---|
-| **ID** | EQP-001 |
-| **Equipment Class** | Equipment speaking OPC UA natively (mixed vendors and generations) |
-| **Vendor(s)** | _TBD — almost certainly a mix, name the top 3–5 vendors once known_ |
-| **Native Protocol** | OPC UA |
-| **Protocol Variant / Notes** | _TBD — security modes actually in use (`None` / `Sign` / `SignAndEncrypt`), profiles (`Basic256Sha256`, `Aes256_Sha256_RsaPss`, etc.), auth tokens (anonymous vs UserName vs certificate)_ |
-| **Sites** | _TBD_ |
-| **Approx. Instance Count** | _TBD_ |
-| **Current Access Path** | Mixed — direct OPC UA sessions from Aveva System Platform, Ignition, and/or ScadaBridge depending on the equipment. See [`../current-state.md`](../current-state.md) → Equipment OPC UA. |
-| **OtOpcUa Driver Needed?** | **Uses the `OpcUaClient` gateway driver** from the core library — no new protocol-specific driver project required, but per-equipment configuration (endpoint URL, browse strategy, namespace remapping to UNS, certificate trust, security policy) is still real work. **Onboarding effort per OPC UA-native equipment is ~hours of config, not zero.** |
-| **Driver Complexity (Estimate)** | Low — config work, not protocol work. But non-trivial in aggregate if the OPC UA-native fleet is large. |
-| **Priority Site(s)** | N/A |
-| **Notes** | Will be the **lowest per-unit effort** equipment class to bring onto OtOpcUa — the `OpcUaClient` gateway driver handles them, but each equipment still needs endpoint config, browse strategy, namespace remapping, and certificate trust. Expected to be a meaningful fraction of the estate given the "OPC UA-first" posture of most equipment vendors over the last decade. Survey should **still** capture this category because the count informs (a) how much of the tier-1 ScadaBridge cutover is "configure an existing driver" vs "build a new one" and (b) aggregate config effort. |
-
-### EQP-002 — Siemens PLC family (S7)
-
-| Field | Value |
-|---|---|
-| **ID** | EQP-002 |
-| **Equipment Class** | Siemens S7 PLCs (S7-300 / S7-400 / S7-1200 / S7-1500) |
-| **Vendor(s)** | Siemens |
-| **Native Protocol** | Siemens S7 (ISO-on-TCP); newer S7-1500 also speaks OPC UA natively |
-| **Protocol Variant / Notes** | _TBD — mix of S7 generations determines whether the S7 driver is actually needed or whether OPC UA covers most units_ |
-| **Sites** | _TBD_ |
-| **Approx. Instance Count** | _TBD_ |
-| **Current Access Path** | _TBD — likely a mix of System Platform S7 IO drivers and direct OPC UA on newer units_ |
-| **OtOpcUa Driver Needed?** | **Unknown.** Depends on whether the S7-1500 OPC UA footprint has displaced older S7 generations. If S7-300/400 still dominate → **core candidate**. If fleet is mostly S7-1500 → `No — already OPC UA` for most units, long-tail for the residual older generations. |
-| **Driver Complexity (Estimate)** | Medium — S7 protocol is well-documented; multiple open-source implementations exist; the work is in matching existing System Platform semantics. |
-| **Priority Site(s)** | _TBD_ |
-| **Notes** | Strong core candidate on first-principles grounds — Siemens is a common PLC vendor in discrete manufacturing. Confirm or refute with a specific count during discovery. |
-
-### EQP-003 — Allen-Bradley / Rockwell PLC family (EtherNet/IP)
-
-| Field | Value |
-|---|---|
-| **ID** | EQP-003 |
-| **Equipment Class** | Allen-Bradley / Rockwell ControlLogix, CompactLogix, MicroLogix, SLC families |
-| **Vendor(s)** | Rockwell Automation |
-| **Native Protocol** | EtherNet/IP (CIP) |
-| **Protocol Variant / Notes** | _TBD — implicit vs explicit messaging, tag-based vs legacy data table access_ |
-| **Sites** | _TBD_ |
-| **Approx. Instance Count** | _TBD_ |
-| **Current Access Path** | _TBD — likely System Platform EtherNet/IP IO driver_ |
-| **OtOpcUa Driver Needed?** | **Unknown — likely core candidate.** Rockwell equipment does not generally speak OPC UA natively at the controller level, so if Rockwell has any meaningful footprint in the estate, an EtherNet/IP driver is a core candidate. |
-| **Driver Complexity (Estimate)** | Medium-to-high — CIP is a large protocol family; scope depends on which message classes are actually needed. |
-| **Priority Site(s)** | _TBD_ |
-| **Notes** | Paired with EQP-002 (Siemens) as the two most likely dominant PLC protocol families. Confirm scope during discovery. |
-
-### EQP-003a — Allen-Bradley Legacy (SLC 500 / MicroLogix — PCCC protocol)
-
-| Field | Value |
-|---|---|
-| **ID** | EQP-003a |
-| **Equipment Class** | Allen-Bradley / Rockwell SLC 500, MicroLogix families (legacy — separate from ControlLogix/CompactLogix CIP) |
-| **Vendor(s)** | Rockwell Automation |
-| **Native Protocol** | PCCC (Programmable Controller Communication Commands) — different protocol stack from EtherNet/IP CIP, despite same vendor |
-| **Protocol Variant / Notes** | Data table addressing (integer, float, binary, timer, counter files), not tag-based like CIP. Shared library (libplctag) with EQP-003, but separate driver project due to different protocol semantics. |
-| **Sites** | _TBD_ |
-| **Approx. Instance Count** | _TBD_ |
-| **Current Access Path** | _TBD — likely System Platform PCCC/DH+ IO driver_ |
-| **OtOpcUa Driver Needed?** | **Core candidate (pre-committed in v2 design).** The v2 OtOpcUa design commits AB Legacy as a separate driver from AB CIP. Marginal cost is low (shared libplctag library) but it has its own stability tier (B), test coverage, and Admin UI surface. |
-| **Driver Complexity (Estimate)** | Low-to-Medium — shares libplctag with EQP-003; the added work is the data-table addressing model and validation against legacy hardware. |
-| **Priority Site(s)** | _TBD_ |
-| **Notes** | Split from EQP-003 based on v2 OtOpcUa implementation findings — CIP and PCCC are different enough to warrant separate driver instances. Confirm via survey whether SLC/MicroLogix equipment still exists in meaningful numbers or has been replaced by ControlLogix. |
-
-### EQP-003b — Beckhoff TwinCAT (ADS protocol)
-
-| Field | Value |
-|---|---|
-| **ID** | EQP-003b |
-| **Equipment Class** | Beckhoff TwinCAT PLCs and motion controllers |
-| **Vendor(s)** | Beckhoff Automation |
-| **Native Protocol** | TwinCAT ADS (Automation Device Specification) — proprietary Beckhoff protocol with native subscription support |
-| **Protocol Variant / Notes** | ADS supports native subscriptions (no polling needed), which makes it more efficient than poll-based protocols for high-frequency data. ADS runs over TCP. |
-| **Sites** | _TBD — known Beckhoff installations at specific sites per OtOpcUa team's internal knowledge_ |
-| **Approx. Instance Count** | _TBD_ |
-| **Current Access Path** | _TBD — likely direct ADS or via a Beckhoff OPC UA server_ |
-| **OtOpcUa Driver Needed?** | **Core candidate (pre-committed in v2 design).** Not in the original plan's expected categories — added based on known Beckhoff installations at specific sites, confirmed by the OtOpcUa team ahead of the formal protocol survey. |
-| **Driver Complexity (Estimate)** | Medium — ADS protocol is well-documented by Beckhoff; native subscriptions simplify the subscription model. Tier B stability (wrapped native, mature). |
-| **Priority Site(s)** | _TBD — the sites with known Beckhoff installations should be confirmed during the protocol survey_ |
-| **Notes** | **Pre-survey addition.** This category was not in the original expected list (EQP-001 through EQP-006). Added based on v2 OtOpcUa implementation design findings confirming known Beckhoff installations. The formal protocol survey should validate whether the committed core driver is justified by the install base. |
-
-### EQP-004 — Generic Modbus devices
-
-| Field | Value |
-|---|---|
-| **ID** | EQP-004 |
-| **Equipment Class** | Modbus TCP and Modbus RTU devices across instruments, sensors, power meters, older PLCs, variable-frequency drives |
-| **Vendor(s)** | Mixed — Modbus is multi-vendor |
-| **Native Protocol** | Modbus TCP, Modbus RTU (often bridged to TCP via a gateway) |
-| **Protocol Variant / Notes** | _TBD — per-device register map is the real work, not the protocol itself_ |
-| **Sites** | _TBD_ |
-| **Approx. Instance Count** | _TBD_ |
-| **Current Access Path** | _TBD — likely a mix of System Platform Modbus driver and site-level gateways_ |
-| **OtOpcUa Driver Needed?** | **Likely core candidate.** Modbus is the most common low-cost protocol in the estate on first-principles grounds. The driver itself is simple; the long-tail is **per-device register maps**. |
-| **Driver Complexity (Estimate)** | Low for the protocol; Medium-to-High for the register-map configuration surface (needs to be editable per-device without code changes). |
-| **Priority Site(s)** | _TBD_ |
-| **Notes** | **Register map configuration is the real work.** The core driver should ship a configuration mechanism (UI or templates) for register-map definition so new Modbus devices don't require code changes. Strong candidate for core library. |
-
-### EQP-005 — Fanuc CNC controllers (FOCAS)
-
-| Field | Value |
-|---|---|
-| **ID** | EQP-005 |
-| **Equipment Class** | Fanuc CNC machine controls |
-| **Vendor(s)** | Fanuc |
-| **Native Protocol** | Fanuc FOCAS (proprietary library, not a wire protocol) |
-| **Protocol Variant / Notes** | FOCAS1 / FOCAS2 library versions |
-| **Sites** | _TBD_ |
-| **Approx. Instance Count** | _TBD_ |
-| **Current Access Path** | _TBD — likely direct or via a vendor-specific driver_ |
-| **OtOpcUa Driver Needed?** | **Core candidate if any significant CNC footprint exists.** FOCAS is the de-facto API for Fanuc CNCs and does not come "for free" with OPC UA. |
-| **Driver Complexity (Estimate)** | High — FOCAS is a C library with platform-specific bindings and licensing considerations; wrapping it into a .NET driver carries non-trivial ops/licensing work. |
-| **Priority Site(s)** | _TBD — Warsaw campuses or TMT likely candidates if they have CNC machining centers_ |
-| **Notes** | **Decouple from core library decision until the CNC count is known.** If CNC is a meaningful fraction of the estate, FOCAS is unavoidable. If CNC is a handful of machines, build on-demand as long-tail. A separate alternative — MTConnect — is worth asking about (some modern CNCs expose MTConnect, which is a simpler target). |
-
-### EQP-006 — Other long-tail equipment
-
-| Field | Value |
-|---|---|
-| **ID** | EQP-006 |
-| **Equipment Class** | Everything else — instruments, ovens, vision systems, stand-alone controllers, legacy proprietary devices |
-| **Vendor(s)** | Mixed |
-| **Native Protocol** | Various — ASCII serial, proprietary, vendor-specific |
-| **Protocol Variant / Notes** | _TBD — catalog as encountered_ |
-| **Sites** | _TBD_ |
-| **Approx. Instance Count** | _TBD_ |
-| **Current Access Path** | _TBD — often bespoke per-device integration work in System Platform today_ |
-| **OtOpcUa Driver Needed?** | **Long-tail — build on-demand.** This is the category the "on-demand long-tail" driver strategy exists to serve. |
-| **Driver Complexity (Estimate)** | Low-to-High per device — varies wildly. |
-| **Priority Site(s)** | Wherever the first blocker appears. |
-| **Notes** | Track individual long-tail cases as separate rows (EQP-007, EQP-008, …) as discovery identifies them. The placeholder above exists only to anchor the category. |
-
-### _Further rows TBD — add as discovery progresses_
-
-## Rollup views
-
-These views are **derived** from the row-level data above. Regenerate as rows are updated.
-
-### By protocol — drives core library scope
-
-| Native Protocol | Row IDs | Total Approx. Instances | Sites | Core / Long-tail / Already OPC UA |
-|---|---|---|---|---|
-| OPC UA | EQP-001 | _TBD_ | _TBD_ | Uses `OpcUaClient` gateway driver (core library) — config work per equipment, not protocol work |
-| Siemens S7 | EQP-002 | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) — validate with survey |
-| EtherNet/IP (CIP) | EQP-003 | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) |
-| PCCC (AB Legacy) | EQP-003a | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) — validate SLC/MicroLogix fleet still exists |
-| TwinCAT ADS (Beckhoff) | EQP-003b | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) — based on known installations, validate with survey |
-| Modbus TCP/RTU | EQP-004 | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) |
-| Fanuc FOCAS | EQP-005 | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) — **pilot equipment class for canonical model** |
-| Long-tail mix | EQP-006+ | _TBD_ | _TBD_ | Long-tail — on-demand |
-
-**Decision output of this table:** the **core driver library scope** for Year 1 OtOpcUa. A protocol row tagged `Core` becomes a Year 1 build commitment; `Long-tail` becomes a Year 2+ on-demand build budget; `Already OPC UA` becomes connection configuration work only.
-
-### By site — drives onboarding sequencing
-
-| Site | Row IDs present | Protocols present | Blockers for tier-1 cutover |
-|---|---|---|---|
-| South Bend DC (primary cluster) | _TBD_ | _TBD_ | _TBD_ |
-| Warsaw West | _TBD_ | _TBD_ | _TBD_ |
-| Warsaw North | _TBD_ | _TBD_ | _TBD_ |
-| Shannon | _TBD_ | _TBD_ | _TBD_ |
-| Galway | _TBD_ | _TBD_ | _TBD_ |
-| TMT | _TBD_ | _TBD_ | _TBD_ |
-| Ponce | _TBD_ | _TBD_ | _TBD_ |
-
-**Decision output of this table:** **tier-1 ScadaBridge cutover sequencing.** The roadmap commits tier 1 at large sites first; this view identifies which sites can cut over with which drivers available, so that sequencing is driven by driver availability, not just site size.
-
-## Discovery approach
-
-Recommended path — not prescriptive. **Each step produces both protocol-survey rows (equipment-class granularity) and UNS hierarchy snapshot rows (equipment-instance granularity) in the same pass** — see "Companion deliverable" above.
-
-1. **Walk the Aveva System Platform IO configuration** at the primary cluster and each site cluster. System Platform's IO server layer is the most complete existing inventory of "what protocols are we talking to what equipment with." Every configured IO object is a row candidate — and its parent galaxy / area / cluster assignment maps directly onto UNS Site and Area levels.
-2. **Walk the Ignition OPC UA connections** at the central Ignition footprint in South Bend. These are the equipment Ignition talks to directly today. Every distinct endpoint is a row candidate; Ignition's tag browse tree typically groups endpoints by site and production area, which feeds the UNS hierarchy walk directly.
-3. **Walk ScadaBridge template configuration** for equipment-facing templates. Less complete than System Platform IO, but captures anything already templated on ScadaBridge. Template groupings also surface line-level organization where it exists.
-4. **Walk any existing site asset registers or CMDBs** if present. Lower priority — often stale, rarely matches reality — but may surface equipment not yet integrated with any SCADA layer, and may be the best source for a stable enterprise equipment ID that can seed the UNS UUID.
-5. **Interview site controls/automation engineers** at each large site. They are the ground truth for "what's actually out there" — especially for long-tail equipment that never made it into a central inventory. Interviews are also the best source for **Line-level structure**, which is frequently implicit in operator knowledge and absent from System Platform or Ignition configuration.
-6. **Cross-check against Camstar's equipment master data** (if Camstar tracks equipment at that granularity) as a sanity check against what manufacturing operations believes is on the floor — and as a tiebreak when different configuration sources name the same machine differently.
-
-**Order matters.** Steps 1–3 are cheap and produce most of the signal for both outputs. Steps 4–6 are interview-driven and time-consuming; reserve them for gap-filling after the System Platform / Ignition / ScadaBridge walks are done.
-
-**Dual output at each step:** the walker should carry two notebooks (or two sheets of a spreadsheet) and capture entries in both as they go — one equipment instance observed produces one row in each notebook. Reconciliation between the two outputs happens at the end of the walk, not during it. If reconciliation reveals mismatches (a machine shows up in the protocol survey but not the hierarchy, or vice versa), that's a walker error to chase down, not a data difference to split the difference on.
-
-## Open questions for the survey itself
-
-- **Who owns the survey?** The OtOpcUa workstream lead, a dedicated discovery resource, or a rotating responsibility across site automation engineers? _TBD._
-- **Deadline.** Year 1 OtOpcUa work cannot scope the core driver library without this survey — it's a **Year 1 prerequisite**. Aim to complete at least steps 1–3 (System Platform / Ignition / ScadaBridge walks) within the first quarter of Year 1 so core driver library build can start by quarter 2. Interview-driven gap-filling can extend through the rest of Year 1 in parallel with core driver build.
-- **How often is this file reviewed after Year 1?** Recommended: quarterly during Year 1 (active discovery), annually thereafter (to catch drift from new equipment purchases). Add a row when a new equipment class shows up in the estate; do **not** remove rows when drivers ship.
-- **Relationship to Site Onboarding workstream.** When a smaller site (Berlin, Winterthur, Jacksonville, …) is onboarded in Year 2, its equipment should be added to this file as part of the onboarding checklist — that way the core-vs-long-tail decision is re-evaluated as the estate grows.
-- **MTConnect.** Modern CNCs often expose MTConnect as an alternative to FOCAS. If MTConnect coverage is broad enough, it may replace FOCAS as the CNC driver choice. Worth an explicit "is MTConnect in play here?" question during discovery.

goal-state.md

@@ -209,7 +209,9 @@ The hierarchy will change. Sites get added (smaller sites onboarding in Year 2).
 - **Logical vs physical equipment.** The plan's hierarchy addresses **physical equipment instances**. Logical groupings (e.g., "all CNC mills," "all equipment on the shop floor") are queryable via equipment class + attributes in dbt or via OPC UA browse filters — not via the path hierarchy.
 - **Real-time UNS browsing UI.** If stakeholders want a tree-browse experience against the UNS (an HMI, an engineering tool), that is a consumer surface, not a hierarchy definition. The projection service discussed below is the likely delivery path if this is ever funded.
 
-_TBD — enterprise shortname (currently `ent` placeholder); authoritative initial hierarchy snapshot for the currently-integrated sites (blocked on the per-site area/line/equipment walk that the equipment-protocol survey will partially produce — overlap with `current-state/equipment-protocol-survey.md`); storage format for the hierarchy in the `schemas` repo (YAML vs Protobuf vs both); whether the dbt `dim_equipment` historical-path tracking needs a slowly-changing-dimension type-2 pattern or a simpler current+history list; ownership of hierarchy change PRs (likely a domain SME group, not the ScadaBridge team)._
+**Resolved:** storage format for the hierarchy in the `schemas` repo is **JSON Schema** (see "Where the authoritative hierarchy lives" above).
+
+_TBD — enterprise shortname (currently `ent` placeholder); authoritative initial **UNS hierarchy snapshot** for the currently-integrated sites — requires a per-site area/line/equipment walk to capture equipment instances, their UNS path assignments, and stable UUIDs (the protocol survey has been removed since the OtOpcUa v2 design committed the driver list directly; the hierarchy walk is now a standalone Year 1 deliverable); whether the dbt `dim_equipment` historical-path tracking needs a slowly-changing-dimension type-2 pattern or a simpler current+history list; ownership of hierarchy change PRs (likely a domain SME group, not the ScadaBridge team)._
 
 #### How this differs from a classic MQTT-based UNS
 
@@ -438,10 +440,10 @@ _TBD — service name (working title only); hosting (South Bend, alongside Redpa
 - **Mitigation:** equipment that already speaks native OPC UA does not require a *new protocol-specific driver project* — the `OpcUaClient` gateway driver in the core library handles all of them. However, per-equipment configuration (endpoint URL, browse strategy, namespace remapping to UNS, certificate trust, security policy) is still required. **Onboarding effort per OPC UA-native equipment is ~hours of config, not zero** — the "no driver build" framing from earlier versions of this plan understated the work.
 - **Driver strategy: hybrid — proactive core library plus on-demand long-tail.** A **core driver library** covering the top equipment protocols for the estate is built **proactively** (Year 1 into Year 2), so that most site onboardings can draw from existing drivers rather than blocking on driver work. Protocols beyond the core library — long-tail equipment specific to one site or one equipment class — are built **on-demand** as each site onboards.
   - **Why hybrid:** purely lazy (on-demand only) makes site onboarding unpredictable and bumpy; purely proactive risks building drivers for protocols nobody actually uses. The hybrid matches the reality of a mixed equipment estate over a 3-year horizon.
-  - **Core library scope** is driven by the equipment-protocol inventory, not by guessing — the top protocols are whichever ones are actually most common in the estate once surveyed.
+  - **Core library scope** is confirmed by the v2 implementation team's internal knowledge of the estate. A formal protocol survey is no longer required for driver scoping.
-  - **Committed core driver list (from v2 implementation design, confirmed by team's internal knowledge of the estate ahead of the formal protocol survey):** (1) **OPC UA Client** — gateway driver for OPC UA-native equipment; (2) **Modbus TCP** (also covers DL205 via octal address translation); (3) **AB CIP** (ControlLogix / CompactLogix); (4) **AB Legacy** (SLC 500 / MicroLogix, PCCC — separate driver from CIP due to different protocol stack); (5) **Siemens S7** (S7-300/400/1200/1500); (6) **TwinCAT** (Beckhoff ADS, native subscriptions — known Beckhoff installations at specific sites); (7) **FOCAS** (FANUC CNC). Plus the existing **Galaxy** driver (System Platform namespace, carried forward from LmxOpcUa v1). Total: 8 drivers. The formal protocol survey (`current-state/equipment-protocol-survey.md`) will validate this list and may add or deprioritize entries.
+  - **Committed core driver list (from v2 implementation design):** (1) **OPC UA Client** — gateway driver for OPC UA-native equipment; (2) **Modbus TCP** (also covers DL205 via octal address translation); (3) **AB CIP** (ControlLogix / CompactLogix); (4) **AB Legacy** (SLC 500 / MicroLogix, PCCC — separate driver from CIP due to different protocol stack); (5) **Siemens S7** (S7-300/400/1200/1500); (6) **TwinCAT** (Beckhoff ADS, native subscriptions — known Beckhoff installations at specific sites); (7) **FOCAS** (FANUC CNC). Plus the existing **Galaxy** driver (System Platform namespace, carried forward from LmxOpcUa v1). Total: 8 drivers.
   - **Implementation approach:** embedded open-source protocol stacks (NModbus for Modbus, Sharp7 for Siemens S7, libplctag for Ethernet/IP and AB Legacy) wrapped in OtOpcUa's driver framework. Reduces driver work to "write the OPC UA ↔ protocol adapter" rather than "implement the protocol."
-  - _TBD — formal protocol survey to validate the committed list; how long-tail driver requests are prioritized vs site-onboarding deadlines._
+  - _TBD — how long-tail driver requests (protocols beyond the committed 8) are prioritized vs site-onboarding deadlines._
 - **Driver stability tiers (v2 implementation design decision — process isolation model).** Not all drivers have equal stability profiles. The v2 design introduces a three-tier model that determines whether a driver runs in-process or out-of-process:
   - **Tier A (pure managed .NET):** Modbus TCP, OPC UA Client. Run **in-process** in the OtOpcUa server. Low risk — no native code, no COM interop.
   - **Tier B (wrapped native, mature libraries):** S7, AB CIP, AB Legacy, TwinCAT. Run **in-process** with additional guards — SafeHandle wrappers, memory watchdog, bounded queues. The native libraries are mature and well-tested, so process isolation is not required, but guardrails contain resource leaks.
@@ -562,7 +564,7 @@ The plan already delivers the infrastructure for a cross-system canonical model
 
 This subsection makes that declaration. It is the plan's answer to **Digital Twin Use Cases 1 and 3** (see **Strategic Considerations → Digital twin**) and — independent of digital twin framing — is load-bearing for pillar 2 (analytics/AI enablement) because a canonical model is what makes "not possible before" cross-domain analytics possible at all.
 
-> **Schemas-repo dependency is on the OtOpcUa critical path (B2 from v2 corrections).** The `schemas` repo does not exist yet. Until it does, OtOpcUa equipment configurations are hand-curated per-equipment with no class templates, no auto-generated tag lists, no cross-cluster consistency checks, and no signal-validation contract for Layer 3 state derivation. The plan commits to **schemas-repo creation as a Year 1 deliverable** (its own scope, distinct from the OtOpcUa workstream) with a **pilot equipment class (FANUC CNC)** landed in the repo before Tier 1 cutover begins. The Equipment Protocol Survey output feeds both: (a) OtOpcUa core driver scope, and (b) the initial schemas-repo equipment-class list.
+> **Schemas-repo dependency is on the OtOpcUa critical path (B2 from v2 corrections).** The `schemas` repo does not exist yet. Until it does, OtOpcUa equipment configurations are hand-curated per-equipment with no class templates, no auto-generated tag lists, no cross-cluster consistency checks, and no signal-validation contract for Layer 3 state derivation. The plan commits to **schemas-repo creation as a Year 1 deliverable** (its own scope, distinct from the OtOpcUa workstream) with a **pilot equipment class (FANUC CNC)** landed in the repo before Tier 1 cutover begins. The **UNS hierarchy snapshot** (a per-site equipment-instance walk) feeds the initial schemas-repo equipment-class list and hierarchy definition. Core driver scope is already resolved by the v2 implementation team's committed driver list.
 
 > **Unified Namespace framing:** this canonical model is also the plan's **Unified Namespace** (UNS) — see **Target IT/OT Integration → Unified Namespace (UNS) posture**. The UNS posture is a higher-level framing of the same mechanics described here: this section specifies the canonical model mechanically; the UNS posture explains what stakeholders asking about UNS should understand about how the plan delivers the UNS value proposition without an MQTT/Sparkplug broker.
 

outputs/longform-spec.md

@@ -28,7 +28,6 @@ Chapter 1 — Current State          (source: ../current-state.md)
 Chapter 2 — Goal State             (source: ../goal-state.md)
 Chapter 3 — Roadmap                (source: ../roadmap.md)
 Appendix A — Legacy Integrations Inventory  (source: ../current-state/legacy-integrations.md)
-Appendix B — Equipment Protocol Survey      (source: ../current-state/equipment-protocol-survey.md)
 ```
 
 **Chapter / appendix file-to-source mapping:**
@@ -39,7 +38,6 @@ Appendix B — Equipment Protocol Survey      (source: ../current-state/equipmen
 | Chapter 2 | Goal State | [`../goal-state.md`](../goal-state.md) |
 | Chapter 3 | Roadmap | [`../roadmap.md`](../roadmap.md) |
 | Appendix A | Legacy Integrations Inventory | [`../current-state/legacy-integrations.md`](../current-state/legacy-integrations.md) |
-| Appendix B | Equipment Protocol Survey | [`../current-state/equipment-protocol-survey.md`](../current-state/equipment-protocol-survey.md) |
 
 ## Explicitly excluded
 
@@ -85,7 +83,7 @@ Markdown links between plan files are resolved to section references in the rend
 | `[goal-state.md](goal-state.md)` | "see Chapter 2 — Goal State" |
 | `[roadmap.md](roadmap.md)` | "see Chapter 3 — Roadmap" |
 | `[legacy-integrations.md](current-state/legacy-integrations.md)` | "see Appendix A — Legacy Integrations Inventory" |
-| `[equipment-protocol-survey.md](current-state/equipment-protocol-survey.md)` | "see Appendix B — Equipment Protocol Survey" |
+| `[equipment-protocol-survey.md](current-state/equipment-protocol-survey.md)` | Render as **plain text** — file removed. Log as warning. |
 | Intra-file anchor links like `[X](#section-name)` | Rendered as internal PDF cross-reference to the numbered section (e.g., "see §1.2") |
 | Links to excluded files (e.g., `status.md`, `digital-twin-management-brief.md`) | Rendered as **plain text** — the link target is dropped, the link text stays. Logged as a warning in the run log. |
 | External links (http://, https://) | Rendered as clickable external links, unchanged. |

roadmap.md

@@ -63,7 +63,7 @@ The roadmap is laid out as a 2D grid — **workstreams** (rows) crossed with **y
 
 | Workstream | **Year 1 — Foundation** | **Year 2 — Scale** | **Year 3 — Completion** |
 |---|---|---|---|
-| **OtOpcUa** | **Evolve LmxOpcUa into OtOpcUa** — extend the existing in-house OPC UA server to add (a) a new equipment namespace with single session per equipment via native protocols translated to OPC UA (committed core drivers: OPC UA Client, Modbus TCP, AB CIP, AB Legacy, S7, TwinCAT, FOCAS, plus Galaxy carried forward), and (b) clustering (non-transparent redundancy, 2-node per site) on top of the existing per-node deployment. **Driver stability tiers:** Tier A in-process (Modbus, OPC UA Client), Tier B in-process with guards (S7, AB CIP, AB Legacy, TwinCAT), Tier C out-of-process (Galaxy — bitness constraint, FOCAS — uncatchable AVE). **Protocol survey** across the estate — template in [`current-state/equipment-protocol-survey.md`](current-state/equipment-protocol-survey.md); target steps 1–3 done Q1 to validate committed driver list and feed initial UNS hierarchy snapshot. **Build ACL surface** (per-cluster `EquipmentAcl` table, Admin UI, OPC UA NodeManager enforcement) — required before tier-1 cutover. **Deploy OtOpcUa to every site** as fast as practical. **Begin tier 1 cutover (ScadaBridge)** at large sites. **Prerequisite: certificate-distribution** to consumer trust stores before each cutover. **Aveva System Platform IO pattern validation** — Year 1 or early Year 2 research to confirm Aveva supports upstream OPC UA data sources, well ahead of Year 3 tier 3. _TBD — survey owner; first-cutover site selection; cutover plan owner (OtOpcUa team or integration team); enterprise shortname for UNS hierarchy root._ | **Complete tier 1 (ScadaBridge)** across all sites. **Begin tier 2 (Ignition)** — Ignition consumers redirected from direct-equipment OPC UA to each site's OtOpcUa, collapsing WAN session counts from *N per equipment* to *one per site*. **Build long-tail drivers** on demand as sites require them. Resolve Warsaw per-building multi-cluster consumer-addressing pattern (consumer-side stitching vs site-aggregator OtOpcUa instance). _TBD — per-site tier-2 rollout sequence._ | **Complete tier 2 (Ignition)** across all sites. **Execute tier 3 (Aveva System Platform IO)** with compliance stakeholder validation — the hardest cutover because System Platform IO feeds validated data collection. Reach steady state: every equipment session is held by OtOpcUa, every downstream consumer reads OT data through it. _TBD — per-equipment-class criteria for System Platform IO re-validation._ |
+| **OtOpcUa** | **Evolve LmxOpcUa into OtOpcUa** — extend the existing in-house OPC UA server to add (a) a new equipment namespace with single session per equipment via native protocols translated to OPC UA (committed core drivers: OPC UA Client, Modbus TCP, AB CIP, AB Legacy, S7, TwinCAT, FOCAS, plus Galaxy carried forward), and (b) clustering (non-transparent redundancy, 2-node per site) on top of the existing per-node deployment. **Driver stability tiers:** Tier A in-process (Modbus, OPC UA Client), Tier B in-process with guards (S7, AB CIP, AB Legacy, TwinCAT), Tier C out-of-process (Galaxy — bitness constraint, FOCAS — uncatchable AVE). Core driver list confirmed by v2 implementation team (protocol survey no longer needed for driver scoping). **UNS hierarchy snapshot walk** — per-site equipment-instance discovery (site/area/line/equipment + UUID assignment) to feed the initial schemas-repo hierarchy definition and canonical model; target done Q1–Q2. **Build ACL surface** (per-cluster `EquipmentAcl` table, Admin UI, OPC UA NodeManager enforcement) — required before tier-1 cutover. **Deploy OtOpcUa to every site** as fast as practical. **Begin tier 1 cutover (ScadaBridge)** at large sites. **Prerequisite: certificate-distribution** to consumer trust stores before each cutover. **Aveva System Platform IO pattern validation** — Year 1 or early Year 2 research to confirm Aveva supports upstream OPC UA data sources, well ahead of Year 3 tier 3. _TBD — survey owner; first-cutover site selection; cutover plan owner (OtOpcUa team or integration team); enterprise shortname for UNS hierarchy root._ | **Complete tier 1 (ScadaBridge)** across all sites. **Begin tier 2 (Ignition)** — Ignition consumers redirected from direct-equipment OPC UA to each site's OtOpcUa, collapsing WAN session counts from *N per equipment* to *one per site*. **Build long-tail drivers** on demand as sites require them. Resolve Warsaw per-building multi-cluster consumer-addressing pattern (consumer-side stitching vs site-aggregator OtOpcUa instance). _TBD — per-site tier-2 rollout sequence._ | **Complete tier 2 (Ignition)** across all sites. **Execute tier 3 (Aveva System Platform IO)** with compliance stakeholder validation — the hardest cutover because System Platform IO feeds validated data collection. Reach steady state: every equipment session is held by OtOpcUa, every downstream consumer reads OT data through it. _TBD — per-equipment-class criteria for System Platform IO re-validation._ |
 | **Redpanda EventHub** | Stand up central Redpanda cluster in South Bend (single-cluster HA). Stand up bundled Schema Registry. Wire SASL/OAUTHBEARER to enterprise IdP. Create initial topic set (prefix-based ACLs). Hook up observability minimum signal set. Define the three retention tiers (`operational`/`analytics`/`compliance`). **Stand up the central `schemas` repo** with `buf` CI, CODEOWNERS, and the NuGet publishing pipeline. **Publish the canonical equipment/production/event model v1** — including the canonical machine state vocabulary (`Running / Idle / Faulted / Starved / Blocked` + any agreed additions) as a Protobuf enum, the `equipment.state.transitioned` event schema, and initial equipment-class definitions for pilot equipment. This is the foundation for Digital Twin Use Cases 1 and 3 (see `goal-state.md` → Strategic Considerations → Digital twin) and is load-bearing for pillar 2. **Pilot equipment class for canonical definition: FANUC CNC** (pre-defined FOCAS2 hierarchy already exists in OtOpcUa v2 driver design). Land the FANUC CNC class template in the schemas repo before Tier 1 cutover begins. _TBD — sizing decisions, initial topic list, canonical vocabulary ownership (domain SME group)._ | Expand topic coverage as additional domains onboard. Enforce tiered retention and ACLs at scale. Prove backlog replay after a WAN-outage drill (also exercises the Digital Twin Use Case 2 simulation-lite replay path). Exercise long-outage planning (ScadaBridge queue capacity vs. outage duration). Iterate the canonical model as additional equipment classes and domains onboard. _TBD — concrete drill cadence._ | Steady-state operation. Harden alerting and runbooks against the observed failure modes from Years 1–2. Canonical model is mature and covers every in-scope equipment class; schema changes are routine rather than foundational. |
 | **SnowBridge** | Design and begin custom build in .NET. **Filtered, governed upload to Snowflake is the Year 1 purpose** — the service is the component that decides which topics/tags flow to Snowflake, applies the governed selection model, and writes into Snowflake. Ship an initial version with **one working source adapter** — starting with **Aveva Historian (SQL interface)** because it's central-only, exists today, and lets the workstream progress in parallel with Redpanda rather than waiting on it. First end-to-end **filtered** flow to Snowflake landing tables on a handful of priority tags. Selection model in place even if the operator UI isn't yet (config-driven is acceptable for Year 1). _TBD — team, credential management, datastore for selection state._ | Add the **ScadaBridge/Redpanda source adapter** alongside Historian. Build and ship the operator **web UI + API** on top of the Year 1 selection model, including the blast-radius-based approval workflow, audit trail, RBAC, and exportable state. Onboard priority tags per domain under the UI-driven governance path. _TBD — UI framework._ | All planned source adapters live behind the unified interface. Approval workflow tuned based on Year 2 operational experience. Feature freeze; focus on hardening. |
 | **Snowflake dbt Transform Layer** | Scaffold a dbt project in git, wired to the self-hosted orchestrator (per `goal-state.md`; specific orchestrator chosen outside this plan). Build first **landing → curated** model for priority tags. **Align curated views with the canonical model v1** published in the `schemas` repo — equipment, production, and event entities in the curated layer use the canonical state vocabulary and the same event-type enum values, so downstream consumers (Power BI, ad-hoc analysts, future AI/ML) see the same shape of data Redpanda publishes. This is the dbt-side delivery for Digital Twin Use Cases 1 and 3. Establish `dbt test` discipline from day one — including tests that catch divergence between curated views and the canonical enums. _TBD — project layout (single vs per-domain); reconciliation rule if derived state in curated views disagrees with the layer-3 derivation (should not happen, but the rule needs to exist)._ | Build curated layers for all in-scope domains. **Ship a canonical-state-based OEE model** as a strong candidate for the pillar-2 "not possible before" use case — accurate cross-equipment, cross-site OEE computed once in dbt from the canonical state stream, rather than re-derived in every reporting surface. Source-freshness SLAs tied to the **≤15-minute analytics** budget. Begin development of the first **"not possible before" AI/analytics use case** (pillar 2). | The "not possible before" use case is **in production**, consuming the curated layer, meeting its own SLO. Pillar 2 check passes. |