# Overview

The `schemas` repo is the org's single source of truth for OT equipment definitions. Three things live here:

1. **UNS hierarchy** — per-site declarations of which Areas and Lines exist (`uns/`).
2. **Equipment-class templates** — per-class declarations of which raw signals each equipment type exposes (`classes/`).
3. **Format definitions** — JSON Schemas defining what UNS and class files must look like (`format/`).

## Why a central repo

Three OT/IT systems consume the same canonical model:

- **OtOpcUa** equipment namespace — exposes raw signals over OPC UA
- **Redpanda + Protobuf** event topics — canonical event shape on the wire
- **dbt curated layer in Snowflake** — analytics model

Without a central source, they would drift. With one repo, every consumer pulls a versioned snapshot and validates against it. Drift becomes a CI failure, not a production incident.

## Lifecycle

```
[author edits JSON in this repo]
          │
          ▼
[CI validates against format/*.schema.json]
          │
          ▼
[PR review by maintainer + consumer reps]
          │
          ▼
[merge to main → tag a semver release]
          │
          ▼
[each consumer pulls the tag and integrates per docs/consumer-integration.md]
```

## What's NOT in this repo

- **Per-equipment configuration** — which specific CNC at Warsaw West runs which program. That's per-instance config in OtOpcUa's central config DB (`lmxopcua/docs/v2/config-db-schema.md` Equipment table), not template-level material.
- **State derivation rules** — how raw signals derive into `Running` / `Idle` / `Faulted` / `Starved` / `Blocked`. That's Layer 3 logic in Aveva System Platform / Ignition. Equipment-class templates can declare which states the class supports (`stateModel.states`) but not the derivation itself.
- **Wire-format Protobuf schemas** — those are code-generated from this repo into a separate output artifact for Redpanda. The authoring source is here; the binary wire format is derived.
- **Authoritative LDAP groups, ACL grants, OPC UA security policies** — those live in the consuming systems (OtOpcUa central config DB, identity provider).