VALI
Validator Engines
1. Overview
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.
VALI is an engine type in the MICE taxonomy. Concrete validators are implemented as MEID-registered micro engines.
2. Design Principles
-
Non-Mutating
- VALI engines never alter the input payload.
- They may output a separate structured validation report (violations, severity, pointers).
-
Contract-First
- Validation is driven by explicit JSON Schema contracts and domain constraints.
- Any rule change is versioned and traceable (ZAR + lineage stamps).
-
Fail-Fast (Configurable)
- By default, detect invalid data as early as possible.
- Support both strict mode (fail) and permissive mode (warn), depending on policy.
-
Deterministic
- Same input + same validator version + same options ⇒ same results.
3. Scope of Responsibility
3.1 What VALI engines do
- 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 What VALI engines do not do
- ❌ Compute new metric values (CALC)
- ❌ Transform or normalize units/formats (TRANS)
- ❌ Estimate / impute missing values (SEM)
- ❌ Aggregate / roll-up across entities (AGGR)
- ❌ Issue assurance proof statements (AAE / Tier-0)
Important: VALI is not the same as AAE.
VALI validates contracts. AAE issues assurance meta-signals and policy-grade proof statements.
4. Where VALI sits in execution chains
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)
5. 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)
6. 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)
7. Canonical Identification
- Engine Type: VALI
- USO role: emits validation meta-signals about a payload (does not compute the payload)
- Category: Micro Engine (MICE)
8. Registry view
All engines tagged as vali:
9. Related engine types
- CALC — Calculation Engines (produce metric values)
- TRANS — Transformation Engines (normalize/convert/classify; mutates outputs, not inputs)
- AGGR — Aggregation Engines (roll-ups across entities)
- AAE (Tier-0) — Assurance engine (policy-grade proof meta-signals; not a VALI subtype)
Stable