Skip to main content
Jira progress: loading…

META

Metadata Enrichment Engines

1. Identity​

AttributeValue
Type codeMETA
Canonical nameMetadata Enrichment Engines
Parent type—
Type statusreview
Tier scopetier-0, tier-2, tier-3
Invocationchained
Payload effectannotate
Lineage rolestamps-cmi

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

2. Purpose and boundary​

Metadata Enrichment Engines (META) are Micro Engines responsible for attaching semantic, taxonomic, and governance metadata to data signals.

META engines do not compute, transform, or aggregate numeric values.
They enrich signals with meaning and context, enabling:

  • regulatory interpretation,
  • explainability,
  • policy reasoning,
  • federation discovery.

Design rationale​

Separating metadata enrichment into a dedicated engine type ensures:

  • semantic clarity between values and meaning,
  • reusable, composable regulatory mappings,
  • auditable explanation of why a signal is treated a certain way,
  • federation-safe discovery without coupling logic.

Metadata is not decoration — it is machine-readable meaning, and META engines make it explicit.

3. Membership criteria​

3.1 Inclusion tests​

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

META engines attach or derive non-numeric meaning, including:

  • Regulatory tags (e.g. ESRS-E1, ESRS-E5, EU-Taxonomy)
  • Domain and scope annotations (e.g. scope:3, category:travel)
  • Materiality or relevance indicators
  • Jurisdictional or framework context
  • Disclosure readiness or completeness flags

META engines may also:

  • normalize tag vocabularies,
  • map free-form labels to canonical taxonomies,
  • enrich signals for federation discovery.

Tagging engines are a subset of META engines.

3.2 Exclusions​

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

  • ❌ Primary computation (CALC)
  • ❌ Validation or constraint checking (VALI)
  • ❌ Unit or format conversion (TRFM)
  • ❌ Aggregation or roll-ups (AGGR)
  • ❌ Estimation or extrapolation (SEM)
  • ❌ Policy enforcement or routing (ZSSR)

META engines describe signals — they do not decide or compute.

3.3 Boundary cases​

  • META versus RMAP: META attaches taxonomy and context; RMAP maps a signal into a risk framework (category, band, severity). A framework tag is META; a risk band is RMAP.
  • META versus TRFM: metadata that sits beside an unchanged payload is META; a change to the payload itself is TRFM.
  • META versus GEOX: a location-derived attribute resolved from geometry is GEOX; a jurisdiction tag taken from existing metadata is META.

4. Design rules​

RULE-META-001 — Non-Mutating Values

META engines SHALL NOT alter quantitative values.

RULE-META-002 — Semantic First

All enrichment is driven by explicit taxonomies, ontologies, or controlled mappings.

RULE-META-003 — Composable Metadata

Metadata can be layered incrementally without invalidating prior enrichments.

RULE-META-004 — Traceable Enrichment

Every enrichment action leaves a lineage record explaining what was added and why.

5. Contract​

5.1 Inputs​

META engines consume:

  • Validated signals or computation outputs
  • Taxonomy, ontology, or registry references
  • Contextual parameters, such as:
    • jurisdiction
    • reporting framework
    • scope or boundary definitions

Inputs SHALL be semantically valid, but need not be numerically complete.

5.2 Outputs​

META engines produce:

  • The original signal payload (unchanged)
  • Attached metadata annotations
  • Enrichment provenance, including:
    • enrichment rule or mapping reference
    • engine version
    • execution context

META outputs are commonly consumed by:

  • reporting and disclosure pipelines,
  • explainability layers (ZARA),
  • routing and orchestration (ZSSR),
  • federation and partner discovery.

6. Position in the computation chain​

6.1 Placement​

META engines can operate at multiple points in a pipeline:

INPUT
  → VALI
  → CALC
  → TRFM
  → AGGR
  → META
  → Reporting / Disclosure / Assurance

They may also run:

  • immediately after CALC (to tag scope or category),
  • after AGGR (to tag disclosure-level outputs),
  • independently as contextual enrichment.

7. Identity rules for members​

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

  • mice.category SHALL be META.
  • The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of ENRICH, CLASSIFY.
  • The DOMAIN segment SHALL be any registered MEID domain.
  • Typical FUNCTION segments: ENRICHER, CLASSIFIER.
  • 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-2, tier-3; invocation: chained; payload effect: annotate.
  • USO role: attaches semantic context to signals

META identifiers appear in:

  • signal lineage (CMI stamps),
  • registry metadata,
  • explainability surfaces.

10. Members​

Loading micro engines…
  • CALC — Calculation Engines
  • AGGR — Aggregation Engines
  • EXTR — Extraction Engines
  • NORM — Normalization Engines
  • RMAP — Risk Mapping Engines
  • SCEN — Scenario Engines
  • SCORE — Scoring Engines
  • AME — Assurance / Meta engines
  • VALI — Validator Engines
  • TRFM — Transformation Engines
  • ZARA — Explainability & reasoning


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