Jira progress: loading…

TRFM

Transformation Engines

1. Identity

Attribute	Value
Type code	TRFM
Canonical name	Transformation Engines
Parent type	—
Type status	review
Tier scope	tier-0, tier-1, tier-2
Invocation	chained
Payload effect	transform
Lineage role	stamps-cmi

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

---

2. Purpose and boundary

Transformation Engines (TRFM) are Micro Engines responsible for converting payloads between units, formats, and structural representations while preserving the semantic meaning of the signal.

TRFM engines are the “interoperability layer” of the computation chain: they normalize heterogeneous inputs into stable contracts and prepare outputs for aggregation, reporting, and federation exchange.

---

3. Membership criteria

3.1 Inclusion tests

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

• Unit conversion

  • e.g. kg → t, kWh → MWh, L → m³
  • SHALL preserve magnitude and declared unit metadata.

• Format conversion

  • e.g. XML → JSON, CSV rows → JSON array, XLSX cell range → JSON payload.

• Structural reshaping

  • Rename/re-key fields, unwrap/wrap nested structures, normalize time-series arrays.

• Normalization

  • Harmonize naming conventions, canonicalize enums, enforce standard timestamp formats.

• Classification / mapping (transform subtype)

  • e.g. EWC code → hazardous/non-hazardous label
  • Treatment codes → standardized treatment categories
  • These are transforms, but often tracked as classify/treatment operation tags.

3.2 Exclusions

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

• ❌ Compute new business metrics (CALC)
• ❌ Decide admissibility (VALI) — TRFM may prepare data, but validation is separate
• ❌ Aggregate across entities (AGGR)
• ❌ Estimate missing values (SEM)

Important: TRFM is allowed to change the payload representation.
VALI is not.

3.3 Boundary cases

• TRFM versus NORM: TRFM changes representation (unit, format, shape) and the quantity stays the same; NORM changes scale against a declared base and produces a different quantity.
• TRFM versus META: a classification that replaces or re-keys payload content is TRFM; a classification attached as metadata next to an unchanged payload is META.
• TRFM versus VALI: TRFM may change the payload; VALI never does.

---

4. Design rules

RULE-TRFM-001 — Semantic Preservation

• Transformations MAY change representation (shape, units, encoding), but SHALL NOT change what the signal means.

RULE-TRFM-002 — Traceability

• Every transformation SHALL be traceable via contracts (schemas), options, and lineage stamps.
• “What changed, why, and by which engine version” SHALL be reconstructable.

RULE-TRFM-003 — Deterministic

• Same input + same transformer version + same options ⇒ same output.

RULE-TRFM-004 — Reversible Where Possible

• Some transforms are reversible (e.g., unit conversion).
• When not reversible (e.g., classification), the engine SHALL emit explicit mapping evidence.

---

5. Contract

5.1 Inputs

TRFM engines typically receive:

• A validated payload (raw input or computed output)
• Transformation intent/options (target unit, target schema, mapping profile)
• Registry references for mapping tables and schemas (ZAR addresses)

5.2 Outputs

TRFM engines emit:

• Transformed payload (canonical or target representation)
• Transformation metadata (what mapping was applied)
• Evidence hooks (mapping table refs, conversion factors, schema IDs)
• Runtime provenance (lineage stamps, engine version)

TRFM outputs commonly feed:

• CALC (normalized inputs)
• AGGR (canonicalized measures)
• Reporting pipelines (display-ready normalized payloads)
• Federation exchange packs (portable normalized representations)

---

6. Position in the computation chain

6.1 Placement

Common placement patterns:

• Before CALC: normalize heterogeneous input formats into canonical calculation contracts
• After CALC: convert units/shape for reporting or aggregation layers
• Federation boundary: map partner formats into ZAYAZ canonical signals/contracts

Example (conceptual):

INPUT → VALI(input contract)
     → TRFM(normalize units/shape)
     → CALC(compute)
     → TRFM(output shaping / unit harmonization)
     → VALI(output contract)
     → AGGR(roll-up)

---

7. Identity rules for members

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

• mice.category SHALL be TRFM.
• The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of TRANS, CLASSIFY, NORMALIZE.
• The DOMAIN segment SHALL be any registered MEID domain.
• Typical FUNCTION segments: TRANSFORMER, UNIT, NORMALIZER, CLASSIFIER, HAZARD, TREATMENT.
• 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-0, tier-1, tier-2; invocation: chained; payload effect: transform.
• USO role: emits transformed representations of a signal while preserving semantics

---

10. Members

Loading micro engines…

---

11. Related types

• VALI — Validator Engines
• EXTR — Extraction Engines
• SENS — Sensor Logic Units
• CALC — Calculation Engines
• AGGR — Aggregation Engines
• NORM — Normalization Engines

Other related documents

• SEM — Stochastic Extrapolation Module (gap estimation)

---