TSER
Time-Series Engines
1. Overview
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?”
TSER is a type, not an identity.
Concrete engines are identified by MEID, versioned via ZAR, and leave CMI lineage stamps at runtime.
2. Position in the MICE Model
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.
Typical placement
| Dimension | Value |
|---|---|
| Capability type | TSER |
| Common tiers | Tier-1, Tier-2 |
| Typical classification | Contract-Engine |
| Versioning | ZAR (CMI-level) |
| Lineage impact | Appends TSER CMI stamp to USO |
3. Design Principles
-
Temporal Integrity
Time ordering, continuity, and boundaries are always explicit and preserved. -
Deterministic Behavior
Given the same inputs and rules, outputs must be reproducible. -
Explicit Rules
All filtering, alignment, and interpolation rules are declared and versioned. -
Non-Inferential
TSER engines do not guess or statistically infer missing values. -
Auditability
Every temporal decision is traceable to rules, parameters, and engine version.
4. Scope of Responsibility
TSER engines cover two tightly related responsibilities:
4.1 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.
Typical examples:
- validating hourly meter data,
- detecting missing reporting periods,
- smoothing spikes using explicit filters.
4.2 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.
Typical examples:
- aligning facility-level series before aggregation,
- synchronizing sensors with different sampling rates,
- preparing time-series for AGGR or NORM engines.
5. What Time-Series Engines Do Not Do
TSER engines are intentionally narrow.
They do not:
- ❌ 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. Example Time-Series Engines
11. 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.
Stable