Jira progress: loading…

VALI

Validator Engines

1. Identity

Attribute	Value
Type code	VALI
Canonical name	Validator Engines
Parent type	—
Type status	review
Tier scope	tier-0, tier-1, tier-2, tier-3
Invocation	chained
Payload effect	none
Lineage role	emits-meta-signal

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

---

2. Purpose and boundary

Validator Engines (VALI) are Micro Engines responsible for verifying correctness, completeness, and admissibility of payloads and computed outputs in the ZAYAZ computation chain.

VALI engines enforce contracts (schemas + constraints) and emit deterministic validation results and violation objects.
They are explicitly non-mutating: they do not “fix” values — they only accept, reject, warn, or flag.

---

3. Membership criteria

3.1 Inclusion tests

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

• JSON Schema validation (required/optional fields, types, enums, formats)
• Range / bounds checks (min/max, non-negative, unit admissibility)
• Cross-field consistency rules (e.g., totals vs components)
• Temporal shape validation (e.g., time-series ordering, missing timestamps)
• Referential validation (dataset refs exist; IDs resolve; schema IDs valid)
• Output “violation objects” suitable for routing / governance gating

3.2 Exclusions

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

• ❌ Compute new metric values (CALC)
• ❌ Transform or normalize units/formats (TRFM)
• ❌ Estimate / impute missing values (SEM)
• ❌ Aggregate / roll-up across entities (AGGR)
• ❌ Issue assurance proof statements (AME / Tier-0)

Important: VALI is not the same as AAE.
VALI validates contracts. AAE issues assurance meta-signals and policy-grade proof statements.

3.3 Boundary cases

• VALI versus AME: VALI checks a payload against a contract (schema, bounds, cross-field rules) and answers PASS/WARN/FAIL; AME evaluates trust and admissibility from lineage and evidence metadata and emits assurance meta-signals.
• VALI versus SENS: a plausibility rule bound to a specific device type is SENS; a contract rule independent of the acquisition device is VALI.
• VALI versus TSER: ordering and continuity checks on a time series that also condition the series are TSER; a check that only reports violations is VALI.

---

4. Design rules

RULE-VALI-001 — Non-Mutating

• VALI engines SHALL NOT alter the input payload.
• They MAY output a separate structured validation report (violations, severity, pointers).

RULE-VALI-002 — Contract-First

• Validation is driven by explicit JSON Schema contracts and domain constraints.
• Any rule change is versioned and traceable (ZAR + lineage stamps).

RULE-VALI-003 — Fail-Fast (Configurable)

• By default, detect invalid data as early as possible.
• Support both strict mode (fail) and permissive mode (warn), depending on policy.

RULE-VALI-004 — Deterministic

• Same input + same validator version + same options ⇒ same results.

---

5. Contract

5.1 Inputs

VALI engines typically receive:

• A payload (raw input OR computed output)
• A contract reference (schema ZAR address or MEID-linked contract)
• Optional validation options (strictness, tolerance, jurisdiction, sector)

5.2 Outputs

VALI engines emit:

• status: PASS | WARN | FAIL
• violations: list of structured issues (code, severity, pointer/path, message, hint)
• coverage: what was checked, what was skipped, why
• runtime metadata: timestamps, lineage stamps, schema IDs, versions

VALI results are consumed by:

• ZSSR gates (route to manual review / recompute / reject)
• CALC engines (as prerequisites)
• Reporting workflows (completeness and admissibility checks)
• AAE (as evidence inputs into assurance scoring)

---

6. Position in the computation chain

6.1 Placement

Typical placement patterns:

• Pre-compute gate: validate raw payloads before CALC
• Post-compute gate: validate computed outputs before AGGR/reporting
• Ingress acceptance: validate external uploads and API payloads
• Federation import: validate partner-provided signals / registry bundles

Example (conceptual):

INPUT → VALI(schema + constraints)
     → CALC(compute)
     → VALI(output contract)
     → AGGR(roll-up)
     → AAE(assurance meta-signals, optional policy gate)

---

7. Identity rules for members

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

• mice.category SHALL be VALI.
• The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of VALIDATE.
• The DOMAIN segment SHALL be any registered MEID domain.
• Typical FUNCTION segments: VALIDATOR, EVALUATOR.
• CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE, RULESET.
• Lineage: members emit a new meta-signal USO and do not stamp the evaluated signal.
• Tier scope: tier-0, tier-1, tier-2, tier-3; invocation: chained; payload effect: none.
• USO role: emits validation meta-signals about a payload (does not compute the payload)

---

10. Members

Loading micro engines…

---

11. Related types

• EXTR — Extraction Engines
• SENS — Sensor Logic Units
• TSER — Time-Series Engines
• TRFM — Transformation Engines
• CALC — Calculation Engines
• AGGR — Aggregation Engines
• AME — Assurance / Meta engines

Other related documents

• AAE — Assurance engine (policy-grade proof meta-signals; not a VALI subtype)

---