Skip to main content
Jira progress: loading…

META

Metadata Enrichment Engines

1. Overview

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.

META is an engine type in the MICE taxonomy.
Concrete enrichers are implemented as MEID-registered micro engines.


2. Design Principles

  1. Non-Mutating Values
    META engines never alter quantitative values.

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

  3. Composable Metadata
    Metadata can be layered incrementally without invalidating prior enrichments.

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


3. Scope of Responsibility

3.1 What META engines do

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.


4. What META engines do not do

META engines explicitly do not perform:

  • ❌ 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.


5. 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 must be semantically valid, but need not be numerically complete.


6. 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.

7. Position in the computation chain

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.

8. Canonical identification

  • Engine Type: META
  • USO role: attaches semantic context to signals
  • Category: Micro Engine (MICE)

META identifiers appear in:

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

9. Registry view

All engines tagged as meta:

Loading micro engines…

10. 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.


  • CALC — Calculation Engines
  • VALI — Validator Engines
  • TRFM — Transformation Engines
  • AGGR — Aggregation Engines
  • SCEN — Scenario Engines
  • ZARA — Explainability & reasoning

Stable

GitHub RepoRequest for Change (RFC)