# Decision: Canonical Unit Anchoring and Curve Unit Normalization in RotatingMachine - Date: 2026-02-24 - Scope: `nodes/rotatingMachine/*`, `nodes/generalFunctions/src/measurements/MeasurementContainer.js`, `nodes/generalFunctions/src/configs/rotatingMachine.json` ## Context RotatingMachine previously relied on node-local defaults for measurement storage units, with implicit assumptions that loaded machine curves used the same units as runtime configuration. This made unit drift likely when model curves, simulated inputs, and runtime settings differed. Owner decision direction: - use a single unit anchor strategy - treat node/UI units as ingress/egress only - add explicit curve unit metadata - reject or flag blank/invalid measurement units ## Decision 1. Extend `MeasurementContainer` with optional canonical-anchor mode: - per-type canonical unit mapping - strict unit validation and required-unit policy - compatibility checks by measure family - requested-unit conversion at flattened output stage 2. Apply canonical policy in `rotatingMachine` runtime: - internal storage and calculations anchored to SI-like canonical units (`Pa`, `m3/s`, `W`, `K`) - egress payloads converted back to configured output units - ingress `simulateMeasurement` path requires explicit valid units 3. Add explicit curve unit metadata (`asset.curveUnits`) and normalize loaded curves into canonical units before predictor initialization. ## Consequences - Unit handling is centralized and deterministic for RotatingMachine. - Curve/model-unit mismatch risk is reduced by explicit metadata plus normalization. - Existing output topic/field names remain stable; values are emitted in configured output units while internals stay canonical. - This establishes a migration template for remaining EVOLV nodes. ## Rollback Notes - Revert `MeasurementContainer` canonical/validation extensions. - Revert RotatingMachine unit-policy and curve-normalization wiring. - Remove `asset.curveUnits` schema entry and restore previous node-local default-unit behavior.