shopdb-flask/docs/adr/ADR-005-equipment-vs-measuringtools.md

<!-- docmeta
purpose: explanation
audience: developer
status: historical
summary: The 2026 split of machinery from metrology tools into two plugins. Superseded by ADR-018.
loadwith: none
-->

# ADR-005: Equipment plugin scope vs measuringtools plugin

- **Status:** SUPERSEDED by [ADR-018](ADR-018-metrology-instruments-are-machines.md)
- **Date:** 2026-05-08
- **Deciders:** ShopDB maintainers
- **Supersedes:** none

> **Do not build against this.** ADR-018 (2026-09-04) retired the
> `measuringtools` plugin and made metrology instruments machines. The split
> below was sound for the population it described, and that population never
> arrived: the plugin held zero rows. Kept as the record of why the split was
> made and why it was undone.

## Context

ADR-001 narrowed the migration to physical manufacturing equipment with a `machinenumber`. In practice, the legacy `category='Equipment'` rows contain two distinct asset classes:

1. **Manufacturing machinery** (5-axis mills, lathes, broachers, heat treatment ovens). These produce parts.
2. **Metrology and inspection instruments** (CMMs, Keyence vision systems, wax-and-trace surface profilometers, GenSpec instruments). These measure parts.

Both share `Asset` properties (vendor, model, location, controller). They differ in domain fields (axes vs measurement accuracy, cycle time vs calibration interval, controller protocol vs measurement software).

Mixing them under one plugin pollutes the schema and confuses cross-plugin queries ("show me all measuring tools" requires an enumeration of measuring-instrument equipmenttype values, which scales badly).

## Decision

Two plugins, separate concerns, shared platform contract.

### `equipment` plugin

Tracks manufacturing machinery. Bundled, in-tree.

Schema (per ADR-001 contract):

```
equipment
- assetid                FK to assets, PK
- equipmenttypeid        FK to equipmenttypes (5-axis mill, lathe, broacher, heat treat, ...)
- vendorid               FK to vendors (platform)
- modelid                FK to models (platform)
- controllertypeid       FK to controllertypes (equipment plugin)
- controllerosid         FK to controlleros (equipment plugin)
- (other shared fields: spindle count, axes, max workpiece size, ...)

equipmenttypes (lookup, equipment plugin)
- equipmenttypeid, name (5-axis mill, lathe, broacher, heat treat, ...)

controllertypes (lookup, equipment plugin)
- controllertypeid, name (Fanuc 31i, Siemens 840D, Mitsubishi M70, Heidenhain TNC640, ...)
- vendorid (FK to vendors)

controlleros (lookup, equipment plugin - separate from PC OS)
- controllerosid, name (FAPT, VxWorks, embedded Windows, Linux RT, ...)

equipmentfocas (subtype, optional, present only when FOCAS-equipped)
- assetid                PK, FK to equipment
- focasipaddress         text
- focasport              integer
- focasversion           text
- focasmachinenumber     text

equipmentclm (subtype, optional, present only when CLM-equipped)
- assetid                PK, FK to equipment
- (CLM-specific: address, port, station ID - finalize when plugin is built)

equipmentmtconnect (subtype, optional, present only when MTConnect-equipped)
- assetid                PK, FK to equipment
- mtconnectagenturl      text
- mtconnectdevicename    text
```

The `equipment.protocol` enum field is deliberately **not** included. Presence or absence of a subtype row indicates which protocol applies. Avoids a denormalized field that can drift out of sync.

### `measuringtools` plugin

Tracks metrology and inspection instruments. Bundled, in-tree (built in Phase 3-4 of the refactor as the first new plugin built using the framework scaffold).

Schema (initial draft, refined when plugin is built):

```
measuringtools
- assetid                FK to assets, PK
- measuringtooltypeid    FK to measuringtooltypes (CMM, vision system, profilometer, surface tester, ...)
- vendorid               FK to vendors (platform)
- modelid                FK to models (platform)
- measurementaxes        integer (e.g., 3 for a 3-axis CMM)
- accuracyspec           text (e.g., "+/-0.5um")
- calibrationintervaldays  integer
- lastcalibrationdate    date
- nextcalibrationdate    date (computed)
- (other domain fields as needed)

measuringtooltypes (lookup, measuringtools plugin)
- measuringtooltypeid, name (CMM, vision system, surface profilometer, gage block, ...)
```

Future extension: subtype tables for measurement-software integrations (PC-DMIS, Keyence, GenSpec). Same pattern as equipment subtype tables.

### Subtype-table pattern (general)

Both plugins use the same pattern for protocol- or software-specific fields:

- Core plugin table carries shared, common fields
- Optional subtype tables (one per protocol or software) hold extension fields
- Each subtype table is keyed by `assetid` (PK), one-to-one with the parent
- Subtype row exists if and only if the asset uses that protocol or software
- Sister sites add new subtype tables for their own integrations without touching core

## Reclassification of legacy data

ADR-001's migration moves all legacy `category='Equipment' AND machinenumber IS NOT NULL` rows to `assets` with `assettype='Equipment'` and into the equipment plugin's `equipment` table. This includes both manufacturing machinery and measuring tools.

After the equipment migration, when the measuringtools plugin is built:

1. Build a mapping table: legacy `machinetypeid` values that are measuring tools (CMM type, Keyence type, etc.)
2. Run a reclassification script:
   - For each `assets` row where the original `machinetypeid` is in the measuring-tool mapping
   - Change `assets.assettype` to `'MeasuringTool'`
   - Move the row from `equipment` to `measuringtools`
   - Map domain fields where they differ (e.g., legacy `axes` field maps to `measurementaxes`)
3. Verify counts pre- and post-reclassification
4. Audit log entry per reclassified row

Reclassification is one-shot, run once, archived. Like the original migration script.

## Consequences

### Positive

- Manufacturing machinery and measuring tools are first-class plugins, each with appropriate domain fields
- Sister sites can install one or both depending on what they track
- Subtype-table pattern is the canonical example for protocol-specific data and extends naturally to other plugins
- Building `measuringtools` mid-refactor validates the plugin scaffold tooling against a real new plugin

### Negative

- Reclassification is a second migration step. Lower risk than the initial migration because it is data-only (no schema change beyond moving rows between two tables that share the same `assetid` link).
- Sites that adopt the framework before `measuringtools` ships need to either keep measuring tools in `equipment` (workable but suboptimal) or wait for the plugin

### Neutral

- Legacy `machinetypeid` is preserved on the equipment row during migration to enable reclassification

## Alternatives considered

1. **Single equipment plugin with sub-typed assets.** Use `equipment.equipmenttypeid` to discriminate manufacturing vs metrology. Rejected: domain fields differ enough that a single table is wide and full of NULLs.
2. **Migrate split (build mapping before initial migration).** Cleaner end state but requires the `measuringtools` plugin to exist before the migration runs, which delays Phase 5. Rejected.
3. **JSON blob for protocol data instead of subtype tables.** Considered for both plugins. Rejected: weak typing, awkward queries, no schema validation.

## References

- ADR-001 (Asset is platform contract)
- ADR-002 (versioning of the surface)
- `plugins/machines/` (equipment plugin, renamed per ADR-011)
- `plugins/computers/` (existing example of plugin pattern)