Jira progress: loading…

EXTR

Extraction Engines

1. Identity

Attribute	Value
Type code	EXTR
Canonical name	Extraction Engines
Parent type	—
Type status	review
Tier scope	pre-tier, tier-0
Invocation	ingress
Payload effect	derive
Lineage role	stamps-cmi

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

---

2. Purpose and boundary

Extraction Engines (EXTR) are micro-engines responsible for converting unstructured or semi-structured source material into structured, schema-valid data signals suitable for downstream computation.

EXTR engines operate at the ingestion boundary of the ZAYAZ platform.

They do not compute ESG metrics.
They materialize raw signals from documents, files, text, or external feeds.

Design Rationale

By isolating extraction into its own engine type, ZAYAZ ensures:

• ingestion uncertainty is visible and auditable,
• downstream engines operate only on declared structure,
• re-extraction is possible without recomputing metrics,
• assurance systems (AAE) can reason about where data originated.

Extraction is not “data prep” — it is a first-class, governed operation.

---

3. Membership criteria

3.1 Inclusion tests

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

• Optical Character Recognition (OCR)
• Table and layout extraction
• Field extraction from text (NLP-assisted)
• Parsing of invoices, disclosures, and structured files
• Conversion of external feeds into internal signal envelopes

EXTR outputs are the first structured signals in the system.

3.2 Exclusions

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

• ❌ Compute metrics or indicators (CALC)
• ❌ Validate business rules or completeness (VALI)
• ❌ Normalize units or formats (TRFM)
• ❌ Aggregate across entities or time (AGGR)
• ❌ Apply semantic enrichment or classification (META / RMAP)

3.3 Boundary cases

• EXTR versus CONN: a document, scan, text or feed that has no usable structure is EXTR; a structured source reached through an API, database or file format with a schema is CONN.
• EXTR versus SENS: both run before Tier-1. A source that is a document, file, text or external feed is EXTR; a source that is a physical device or telemetry stream is SENS.
• EXTR versus TRFM: producing structure where there was none is EXTR; converting one structured format to another is TRFM.
• EXTR versus VALI: EXTR reports extraction confidence; it does not decide admissibility.

---

4. Design rules

RULE-EXTR-001 — Loss-Aware Extraction

Any uncertainty, ambiguity, or confidence degradation introduced during extraction SHALL be explicitly surfaced.

RULE-EXTR-002 — Source Traceability

Every extracted value retains references to its original source (document, page, cell, paragraph, timestamp).

RULE-EXTR-003 — Non-Interpretive

EXTR engines extract structure — they do not infer meaning, apply policy, or assess correctness.

---

5. Contract

5.1 Inputs

EXTR engines consume:

• Unstructured or semi-structured sources:
  • PDFs, scans, spreadsheets
  • Text documents or disclosures
  • External system feeds or APIs
• Extraction schemas or templates
• Optional confidence thresholds or extraction profiles

5.2 Outputs

EXTR engines produce:

• Structured payloads conforming to declared schemas
• Confidence or certainty scores per extracted field
• Source references (document ID, page, range, position)
• Extraction metadata (engine version, profile, timestamp)

EXTR outputs are typically consumed by:

• VALI (schema and structural validation)
• META (semantic enrichment)
• CALC (once validated)

---

6. Position in the computation chain

6.1 Placement

EXTR engines sit at the very start of the computation pipeline:

Source Material
   → EXTR
      → VALI
         → META
            → CALC / TRFM / AGGR

This ensures:

• clear separation between extraction and computation,
• explicit provenance from raw source to reported metric,
• auditability of ingestion steps.

---

7. Identity rules for members

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

• mice.category SHALL be EXTR.
• The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of INGEST.
• The DOMAIN segment SHALL be any registered MEID domain.
• Typical FUNCTION segments: PARSER, DOCUMENT, VECTORIZER.
• CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE, MODEL.
• Lineage: members append their CMI stamp to the USO lineage tail.
• Tier scope: pre-tier, tier-0; invocation: ingress; payload effect: derive.

---

10. Members

Loading micro engines…

---

11. Related types

• VALI — Validator Engines
• META — Metadata Enrichment Engines
• CALC — Calculation Engines
• TSER — Time-Series Engines
• TRFM — Transformation Engines
• AGGR — Aggregation Engines
• RMAP — Risk Mapping Engines
• CONN — Connector Engines

---