Skip to main content
Jira progress: loading…

TSER

Time-Series Engines

1. Identity​

AttributeValue
Type codeTSER
Canonical nameTime-Series Engines
Parent type—
Type statusreview
Tier scopetier-1, tier-2
Invocationchained
Payload effecttransform
Lineage rolestamps-cmi

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

2. Purpose and boundary​

Time-Series Engines (TSER) are a capability class of Micro Engines (MICE) responsible for conditioning, validating, and synchronizing temporal sequences of data.

TSER engines ensure that time-dependent signals are:

  • temporally consistent,
  • explicitly aligned,
  • and safe for downstream computation, aggregation, and reporting.

TSER engines answer: “Is this time-series usable and aligned?”

Capability, not identity​

A Time-Series Engine:

  • does not define which engine runs (MEID does),
  • does not define version or deployment (ZAR does),
  • does define what kind of temporal operation is applied.

Multiple MEIDs may implement TSER capabilities for:

  • different data sources,
  • different temporal resolutions,
  • different assurance or reporting contexts.

Summary​

Time-Series Engines:

  • ensure temporal correctness and alignment,
  • make downstream computation safe and explainable,
  • separate conditioning from estimation by design,
  • provide audit-grade temporal provenance.

They are the temporal backbone of the ZAYAZ computation model.

3. Membership criteria​

3.1 Inclusion tests​

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

TSER engines cover two tightly related responsibilities:

Time-Series Conditioning (formerly TSER)​

Conditioning ensures that individual time-series are internally valid.

What TSER conditioning does:

  • validate temporal ordering and continuity,
  • detect gaps, overlaps, or invalid timestamps,
  • filter noise or spikes using deterministic rules,
  • flag anomalies or integrity violations.

Examples

  • validating hourly meter data,
  • detecting missing reporting periods,
  • smoothing spikes using explicit filters.

Time-Series Synchronization (formerly TSYN)​

Synchronization ensures that multiple time-series can be safely combined.

What TSER synchronization does:

  • align series to a common temporal grid,
  • resample between frequencies (e.g. hourly → monthly),
  • deterministically interpolate missing points (e.g. carry-forward, linear),
  • harmonize fiscal vs calendar periods.

Examples

  • aligning facility-level series before aggregation,
  • synchronizing sensors with different sampling rates,
  • preparing time-series for AGGR or NORM engines.

3.2 Exclusions​

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

  • ❌ compute ESG metrics (CALC)
  • ❌ aggregate across entities or hierarchies (AGGR)
  • ❌ estimate missing data probabilistically (SEM)
  • ❌ infer trends, scenarios, or forecasts (SCEN)
  • ❌ apply policy, governance, or routing logic (ZSSR / assurance)

TSER engines prepare time —
they do not interpret it.

3.3 Boundary cases​

  • TSER versus SENS: SENS rules are bound to a device type and its calibration; TSER rules are source-agnostic and operate on any series.
  • TSER versus AGGR: resampling one series between frequencies is TSER; combining several series or entities is AGGR.
  • TSER versus VALI: TSER may interpolate or filter under declared rules; a check that only reports temporal violations is VALI.

4. Design rules​

RULE-TSER-001 — Temporal Integrity

Time ordering, continuity, and boundaries are always explicit and preserved.

RULE-TSER-002 — Deterministic Behavior

Given the same inputs and rules, outputs SHALL be reproducible.

RULE-TSER-003 — Explicit Rules

All filtering, alignment, and interpolation rules are declared and versioned.

RULE-TSER-004 — Non-Inferential

TSER engines SHALL NOT guess or statistically infer missing values.

RULE-TSER-005 — Auditability

Every temporal decision is traceable to rules, parameters, and engine version.

5. Contract​

5.1 Inputs​

Typical TSER inputs include:

  • one or more time-series datasets,
  • declared temporal resolution and coverage,
  • explicit conditioning or synchronization rules,
  • alignment targets (calendar, fiscal, reporting periods).

Inputs may originate from:

  • EXTR (extracted measurements),
  • SENS or raw telemetry,
  • CALC or AGGR outputs requiring temporal alignment.

5.2 Outputs​

TSER engines emit:

  • conditioned and/or synchronized time-series payloads,
  • anomaly or integrity flags,
  • interpolation and alignment metadata,
  • provenance references to source series and rules.

Outputs are commonly consumed by:

  • CALC engines (time-aware computation),
  • AGGR engines (temporal roll-ups),
  • NORM engines (intensity normalization),
  • reporting and disclosure pipelines.

6. Position in the computation chain​

6.1 Interaction with SEM​

TSER and SEM are explicitly complementary:

  • TSER: deterministic conditioning and alignment
  • SEM: probabilistic estimation and gap filling

A typical safe ordering is:

Raw → TSER → (optional SEM) → CALC / AGGR

This separation ensures:

  • explainability,
  • auditability,
  • and clear responsibility boundaries.

6.2 Interaction with ZSSR​

ZSSR does not route to “TSER” generically.

Instead, it:

  • selects specific MEIDs implementing conditioning or synchronization logic,
  • binds them to approved temporal rules,
  • enforces sequencing relative to CALC, AGGR, or SEM.

Tags such as tser or timeseries may be used as:

  • pre-filters or
  • fallback selectors

…but explicit routing rules always take precedence.

7. Identity rules for members​

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

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

10. Members​

Loading micro engines…
  • EXTR — Extraction Engines
  • SENS — Sensor Logic Units
  • CALC — Calculation Engines
  • AGGR — Aggregation Engines
  • NORM — Normalization Engines
  • SCEN — Scenario Engines


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