Skip to main content
Jira progress: loading…

SENS

Sensor Logic Units

1. Identity​

AttributeValue
Type codeSENS
Canonical nameSensor Logic Units
Parent type—
Type statusreview
Tier scopepre-tier
Invocationingress
Payload effecttransform
Lineage rolestamps-cmi

SENS is a category boundary, not an identity. Members are identified by MEID, versioned through ZAR as CMIs, and carry mice.category: SENS. The type itself has no MEID, no CMI and no runtime presence.

2. Purpose and boundary​

Sensor Logic Units (SENS) are a capability class of Micro Engines (MICE) responsible for device-aware conditioning and plausibility control of sensor/IoT data streams.

SENS engines:

  • apply sensor-specific constraints (calibration, saturation, expected operating envelope),
  • produce conditioned measurements plus quality metadata,
  • act as the trust boundary between physical acquisition and downstream pipelines.

Capability, not identity​

A Sensor Logic Unit:

  • does not define which engine runs (MEID does),
  • does not define version/deployment (ZAR does),
  • does define what kind of responsibility the engine carries (device-bound plausibility + conditioning).

Multiple MEIDs may implement SENS capabilities across:

  • energy meters (electricity, fuels),
  • water meters and discharge monitors,
  • environmental sensors (air quality, temp, humidity),
  • industrial telemetry.

Summary​

Sensor Logic Units:

  • make physical acquisition trust explicit and auditable,
  • protect downstream computation from unreliable device behavior,
  • remain deterministic and replayable by design,
  • support federation by exporting portable conditioning provenance.

They are the device-bound trust gate of the Computation Hub.

3. Membership criteria​

3.1 Inclusion tests​

A micro engine is a member of SENS when its specification satisfies the following:

  • Validate sensor-originated payload structure at the device layer (minimal checks)
  • Apply device-specific plausibility rules:
    • min/max bounds
    • rate-of-change limits
    • “stuck sensor” detection
    • calibration expiry handling
    • saturation / clipping detection
  • Condition raw sensor noise (basic device-level smoothing/cleanup when explicitly defined)
  • Annotate signals with:
    • quality flags
    • confidence scores (rule-derived, not ML-inferred)
    • device health indicators

Typical sources:

  • smart meters
  • BMS / SCADA feeds
  • industrial IoT devices
  • environmental monitoring systems
  • telemetry from operational equipment

3.2 Exclusions​

A micro engine is not a member of SENS when any of the following is its responsibility; each belongs to the type named:

  • ❌ compute ESG metrics (CALC)
  • ❌ aggregate across entities or time windows (AGGR)
  • ❌ perform source-agnostic time-series conditioning (TSER)
  • ❌ synchronize multiple series to a common grid (TSER)
  • ❌ estimate missing values probabilistically (SEM)
  • ❌ apply governance/routing decisions (ZSSR / assurance)

3.3 Boundary cases​

  • SENS versus TSER: a rule that needs the sensor model, calibration state or operating envelope is SENS; a rule that applies to any time series is TSER.
  • SENS versus EXTR: a physical device or telemetry stream is SENS; a document, file or external feed is EXTR.
  • SENS versus VALI: device plausibility (stuck sensor, saturation, drift) is SENS; data-contract conformance is VALI.

4. Design rules​

RULE-SENS-001 — Device awareness

SENS engines are explicitly aware of sensor type, measurement method, calibration state, and acquisition context.

RULE-SENS-002 — Physical plausibility

Readings are evaluated against physical and operational constraints (ranges, rate-of-change, saturation, impossible states).

RULE-SENS-003 — Deterministic conditioning

Conditioning rules SHALL be deterministic and auditable (no probabilistic estimation).

RULE-SENS-004 — Separation of concerns

SENS is device-bound; generic time-series processing belongs in TSER/TSYN; inference/gap filling belongs in SEM.

5. Contract​

5.1 Inputs​

Typical inputs include:

  • raw sensor measurements or streams
  • device metadata:
    • sensor_type / model
    • calibration coefficients + last calibration timestamp
    • expected operating ranges
    • unit and resolution
  • acquisition context:
    • sampling interval expectations
    • site/asset binding
    • known downtime windows

5.2 Outputs​

SENS engines emit:

  • conditioned measurement payload (values preserved unless explicit clipping/cleaning rule applies)
  • quality metadata, e.g.:
    • quality.status (ok|warning|invalid)
    • quality.flags (saturation|drift|gap|stuck|out_of_range)
    • quality.confidence (0–1, rule-derived)
  • provenance links:
    • source device ID
    • applied rule profile reference
    • execution metadata for lineage

Outputs are commonly consumed by:

  • TSER (generic time-series cleaning, anomaly detection)
  • VALI (schema + domain constraints at the data-contract level)
  • TRFM (unit normalization where required)
  • CALC (domain computations once conditioned)

6. Position in the computation chain​

6.1 Interaction with ZSSR​

ZSSR does not route to “SENS” directly unless explicitly designed to.

Preferred routing is:

  • rule-based selection of a specific MEID for a known device type, or
  • tag-based fallback selection (e.g. sens + energy + meter), if no explicit mapping exists.

Tags are selectors and hints, not identity.
Explicit rules still take precedence over tag-driven discovery.

7. Identity rules for members​

Members are micro engines (CMPS-001 mice: block) whose identity satisfies all of the following:

  • mice.category SHALL be SENS.
  • The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of VALIDATE, TRANS, DETECT.
  • The DOMAIN segment SHALL be any registered MEID domain.
  • Typical FUNCTION segments: VALIDATOR, DETECTOR.
  • CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE, RULESET.
  • Lineage: members append their CMI stamp to the USO lineage tail.
  • Tier scope: pre-tier; invocation: ingress; payload effect: transform.

9. Governance and audit​

9.1 Audit & Provenance​

Every SENS execution records:

  • device identifiers + calibration context
  • applied plausibility ruleset ID/version
  • anomalies/flags and their trigger conditions
  • execution timestamp and engine version (CMI/ZAR)

This enables:

  • forensic traceability (“why was this reading excluded/flagged?”)
  • reproducible conditioning under audit
  • partner/verifier portability when shipped with registry proofs

10. Members​

Loading micro engines…
  • TSER — Time-Series Engines
  • VALI — Validator Engines
  • TRFM — Transformation Engines
  • CALC — Calculation Engines
  • AGGR — Aggregation Engines


GitHub RepoRequest for Change (RFC)
Last updated on by ZAYAZ