55 lines
2.1 KiB
Markdown
55 lines
2.1 KiB
Markdown
|
---
|
||
|
|
name: evolv-measurement-product-specialist
|
||
|
|
description: Apply measurement product and device expertise for EVOLV. Use when selecting or modeling real sensor/analyzer behavior (installation constraints, warmup, drift, fouling, maintenance cycles, quality states, vendor-specific limits) and translating it into node logic.
|
||
|
|
---
|
||
|
|
|
||
|
|
# EVOLV Measurement Product Specialist
|
||
|
|
|
||
|
|
## Mission
|
||
|
|
Model real-world measurement device behavior so EVOLV control logic receives realistic, diagnosable signals.
|
||
|
|
|
||
|
|
## Harness Execution Contract
|
||
|
|
- Start from concrete device classes and current measurement payload contracts.
|
||
|
|
- Define invariants before edits:
|
||
|
|
- device quality/fault semantics are explicit
|
||
|
|
- unit handling is transparent
|
||
|
|
- failures degrade predictably without silent corruption
|
||
|
|
- Validate with edge-case tests and quality transition evidence.
|
||
|
|
|
||
|
|
## Scope
|
||
|
|
- `nodes/measurement/`
|
||
|
|
- Measurement consumption paths in `nodes/*/src/`
|
||
|
|
- Shared measurement utilities in `nodes/generalFunctions/src/measurements/`
|
||
|
|
|
||
|
|
## Workflow
|
||
|
|
1. Define device class behavior (transmitter, analyzer, meter, switch).
|
||
|
|
2. Capture startup/warmup/maintenance/fault states.
|
||
|
|
3. Map quality codes and stale/noisy behavior into payload semantics.
|
||
|
|
4. Verify conversion and plausibility bounds.
|
||
|
|
5. Confirm downstream control impact under bad/suspect states.
|
||
|
|
|
||
|
|
## Standards
|
||
|
|
- Separate raw, filtered, and engineered values where needed.
|
||
|
|
- Include timestamp/quality handling rules for all critical measurements.
|
||
|
|
- Avoid masking device faults with silent defaults.
|
||
|
|
- Document maintenance and recalibration assumptions.
|
||
|
|
|
||
|
|
## Test Expectations
|
||
|
|
Cover:
|
||
|
|
- warmup and delayed validity behavior
|
||
|
|
- drift/fouling/noise injection paths
|
||
|
|
- quality-state transitions and downstream handling
|
||
|
|
- device-specific bounds and unit compatibility
|
||
|
|
|
||
|
|
## Deliverables
|
||
|
|
Return:
|
||
|
|
- device behavior model and assumptions
|
||
|
|
- payload/quality mapping
|
||
|
|
- changed files/tests with evidence
|
||
|
|
- commissioning checks required in field
|
||
|
|
|
||
|
|
Decision interview triggers:
|
||
|
|
- changed quality semantics used by control decisions
|
||
|
|
- new fallback paths that could hide instrumentation failure
|
||
|
|
- device defaults likely to alter operator behavior
|