RULES
Rule-Sets, Signal Governance & Enforcement Logic in ZAYAZ
Design principle: Precision before automation. Rule-sets in ZAYAZ exist to protect compliance meaning, data trust, and auditability — not to micromanage every field.
1. Purpose of Rule-Sets in ZAYAZ
Rule-sets in ZAYAZ are governance instruments, not UI constraints.
They exist to ensure that when a signal:
- affects compliance obligations,
- participates in computation or inference,
- or introduces trust or assurance risk,
…the platform can enforce correctness, explainability, and traceability in a deterministic way.
ZAYAZ intentionally treats every column in every table as a signal within the Smart Searchable Signal Registry (SSSR). However, not every signal requires a rule-set.
This chapter defines:
- when a signal requires rule governance,
- how governance levels are applied,
- and how signals are automatically classified at scale.
2. Core Design Decision: “Everything is a Signal”
In ZAYAZ, every column is registered in SSSR as a signal — including:
- identifiers,
- system metadata,
- descriptions,
- operational fields,
- and compliance-critical metrics.
This design enables:
- uniform AI interpretation (ZARA / ZAAM),
- cross-table reasoning,
- future-proof extensibility.
However:
Rule-sets are applied selectively — not universally.
The system must therefore distinguish between:
- governed signals (compliance-relevant), and
- non-governed signals (metadata / operational).
3. When Does a Signal Require a Rule-Set?
ZAYAZ uses three binary tests. A signal requires a rule-set if any one of them evaluates to true.
Rule-Set Requirement Decision
rule_required = Disclosure_Relevance
OR Computation_Relevance
OR Trust_Risk
3.1. Test A — Disclosure Relevance (Framework-Linked)
A signal is governed if it is referenced by any disclosure framework, including but not limited to:
- CSRD / ESRS
- EU Taxonomy
- GRI
- XBRL / iXBRL mappings
- National or sector frameworks
Examples
- Total energy consumption (kWh)
- Scope 1 emissions
- Workforce headcount
Implementation
- Determined via
framework_signal_map - No hard-coding inside rules
3.2. Test B — Computation Relevance (Engine-Linked)
A signal is governed if it is:
- an input to a Micro Engine (MICE), or
- an output of a Micro Engine, or
- part of derived or aggregated metrics.
This includes engines in categories such as:
- CALC (calculation)
- VALI (validation)
- NORM (normalization)
- AGGR (aggregation)
- SEM (estimation / extrapolation)
Rationale If a signal participates in computation, its correctness and provenance must be enforced.
3.3. Test C — Trust Risk (Human or External Origin)
A signal is governed if it is:
- entered manually by a human,
- imported from external systems (ERP, API, OCR),
- or used as evidence, policy, or assertion requiring assurance.
Rationale Any signal that can introduce error, bias, or misrepresentation must be rule-controlled.
4. Signal Kind Classification (signal_kind)
To prevent rule inflation, every signal is classified by signal kind.
This is orthogonal to governance level and enables cheap, deterministic filtering.
Signal Kind Enum (Minimal Canonical Set)
| signal_kind | Description | Default Rule Requirement |
|---|---|---|
| identifier | IDs, keys, ECO numbers, UUIDs | 🔴 No |
| system_meta | created_at, row_version, source_system | 🔴 No |
| descriptive_meta | names, descriptions, notes | 🔴 No |
| control_meta | workflow state, status flags | 🔴 No |
| measure | quantitative values with units | ⚠️ Evaluate A/B/C |
| attribute | categorical facts (country, NACE) | ⚠️ Evaluate A/B/C |
| document_evidence | files, URLs, certificates | ✅ Yes |
| computed | derived outputs | ✅ Yes |
Important: identifier, system_meta, and descriptive_meta signals are still signals — they simply do not require rule-sets beyond schema constraints.
5. Governance Level Model (Compact & Deterministic)
Instead of one-off rule logic, ZAYAZ applies governance levels.
Each governed signal is assigned exactly one level.
Governance Levels
| Level | Name | Purpose |
|---|---|---|
| 0 | none | No rule-set; schema only |
| 1 | basic | Format, unit, range checks |
| 2 | compliance | Completeness, applicability, framework logic |
| 3 | assurance | Evidence, provenance, verifier readiness |
5.1. Governance Level Semantics
Level 0 — none
- Identifiers
- System metadata
- Descriptive text
Controls
- Datatype
- Length
- FK / uniqueness
Level 1 — basic Used for operational but non-reportable signals.
Controls
- Datatype & unit enforcement
- Range checks
- Enum constraints
Level 2 — compliance Used for framework-relevant signals.
Controls
- Applicability rules (NACE, size, geography)
- Completeness rules
- Cross-signal consistency
- Framework mapping validation
Level 3 — assurance Used for signals that may be audited or verified.
Controls
- Evidence requirements
- Source provenance
- Trust scoring (DaVE / VTE)
- Verifier workflow integration
- Audit logging (ALTD)
6. Auto-Classifier Specification (SSSR at Scale)
To avoid manual tagging, ZAYAZ includes an auto-classification mechanism implemented as a TAGG micro-engine.
6.1. Heuristic Classification Rules
Identifier Detection
- Column name ends with _id, _uuid, _key, _ref
- Datatype: UUID, PK, FK
→ signal_kind = identifier
System Metadata Detection
- Names like created_at, updated_at, ingested_at
- Source tracking fields
→ signal_kind = system_meta
Descriptive Metadata Detection
- Names containing description, comment, note, label
→ signal_kind = descriptive_meta
Measure Detection
- Numeric datatype
- Unit defined or expected
- Time granularity present
→ signal_kind = measure
Evidence Detection
- Names containing file, url, certificate, attachment
- Datatype: file reference, blob, URL
→ signal_kind = document_evidence
6.2. Governance Level Assignment Logic
if signal_kind in [identifier, system_meta, descriptive_meta]:
governance_level = 0
else if Disclosure_Relevance OR Computation_Relevance:
governance_level = 2
else if Trust_Risk:
governance_level = 1
if document_evidence OR verifier_required:
governance_level = 3
This logic is:
- deterministic,
- explainable,
- auditable,
- overrideable by Super Admins.
7. Relationship to Rule Primitives (Forward Reference)
This chapter defines when rule-sets apply and at what level.
The Rule Primitive Taxonomy (defined in the next chapter) defines:
- how rules are composed,
- what rule primitives exist (applicability, validation, computation),
- where rules are executed (engines, not forms).
Key separation: Governance Level decides if rules apply. Rule Primitives decide how they apply.
8. Architectural Guarantees
This model guarantees that ZAYAZ:
- avoids rule explosion,
- scales across frameworks,
- preserves AI interpretability,
- remains audit-ready,
- and survives regulatory change.
ZAYAZ governs reality — not checklists. Frameworks are mappings. Signals are truth. Rules protect meaning.