RPT
Rule Primitive Taxonomy
Design principle: Rules must be composable, reusable, auditable, and decoupled from frameworks.
This chapter defines the Rule Primitive Taxonomy (RPT) used across the ZAYAZ platform.
Rule primitives are the atomic building blocks from which all rule-sets are composed.
They are intentionally:
- small,
- framework-agnostic,
- deterministic,
- and engine-executable.
1. What Is a Rule Primitive?
A rule primitive is a minimal, self-contained unit of governance logic that:
- applies to one or more signals,
- performs exactly one logical function,
- produces a deterministic outcome,
- is independently auditable,
- and can be reused across frameworks, disclosures, and engines.
Rule primitives are not ESRS rules. ESRS, CSRD, GRI, etc. reference primitives — they do not define them.
2. What Rule Primitives Are Not
To avoid architectural drift, rule primitives must not:
- contain UI logic,
- hard-code framework identifiers (e.g. “E1-6”),
- mix multiple responsibilities,
- perform orchestration,
- embed narrative or explanation logic.
Those responsibilities belong to:
- FOGE (forms),
- ZARA / ZAAM (reasoning & explanation),
- ZADIF (dispatch),
- Disclosure mappings (presentation layer).
3. The Six Canonical Rule Primitive Categories
All rule primitives in ZAYAZ fall into exactly one of the following categories.
This constraint is intentional.
3.1. Applicability Primitives (APL)
Purpose: Determine whether a signal or rule-set applies in a given context.
Typical conditions
- Company size
- Legal form
- Listing status
- Geography
- NACE / sector
- Value-chain position
- Reporting year
Examples
APL_COMPANY_SIZE>= LARGEAPL_NACE_IN[C24, C25]APL_COUNTRY_IN_EU= true
Properties
- Boolean output
- No data mutation
- No computation
- Evaluated early in rule chains
Used by
- Governance Level ≥ 2 (compliance, assurance)
3.2. Materiality Primitives (MAT)
Purpose: Determine whether a topic or signal is required based on materiality logic.
Typical conditions
- IRO score thresholds
- Stakeholder relevance
- Financial vs impact materiality
- Sectoral overrides
Examples
MAT_IMPACT_SCORE> thresholdMAT_TOPIC_FLAG= trueMAT_STAKEHOLDER_GROUP_INCLUDED
Properties
- Boolean or categorical output
- May depend on SEEL outputs
- Must be explainable
Used by
- CSRD / ESRS conditional disclosures
- Dynamic form generation
- ZARA gap analysis
3.3. Completeness Primitives (CMP)
Purpose: Ensure required data is present at the correct scope and granularity.
Typical checks
- Signal exists
- Period coverage complete
- Entity / site coverage complete
- Required combinations present
Examples
CMP_SIGNAL_PRESENTCMP_PERIOD_COVERAGE= FULLCMP_SITE_COUNT_MATCHES
Properties
- Deterministic
- No value judgment
- No range or correctness checks
Used by
- Governance Level ≥ 2
- Readiness dashboards
- “Missing data” workflows
3.4. Validation Primitives (VAL)
Purpose: Ensure data correctness at the signal level.
Typical checks
- Datatype
- Unit
- Allowed range
- Enum validity
- Cross-signal consistency
Examples
VAL_UNIT = kWhVAL_RANGE 0 ≤ x ≤ 10^9VAL_SCOPE1 + SCOPE2 + SCOPE3 = TOTAL
Properties
- Deterministic
- No estimation
- No correction (only flagging)
Used by
- Governance Level ≥ 1
- DICE / DaVE
- Pre-assurance checks
3.5. Computation Primitives (CAL)
Purpose: Derive new signals from existing ones.
Typical functions
- Aggregation
- Conversion
- Intensity calculation
- Normalization
- Allocation
Examples
CAL_SUM(site_energy → total_energy)CAL_KG_TO_TONNESCAL_INTENSITY= emissions / revenue
Properties
- Pure functions
- Versioned
- Executed exclusively by MICE engines
- Always auditable
Used by
- Derived metrics
- Reporting outputs
- Analytics and benchmarking
3.6. Assurance & Provenance Primitives (ASS)
Purpose: Ensure audit and verification readiness.
Typical checks
- Evidence attached
- Source type declared
- Confidence threshold met
- Verifier sign-off present
Examples
ASS_EVIDENCE_REQUIREDASS_SOURCE_TYPE!=SELF_DECLAREDASS_VERIFIER_APPROVED
Properties
- Governance Level 3 only
- Integrated with ALTD
- Triggers verifier workflows
Used by
- External assurance
- Regulator-facing reports
- Public trust layers (E-C-O™)
4. Rule Primitive Composition Model
Rule primitives are never executed alone. They are composed into rule chains.
Rule Chain Example (Conceptual)
APL → MAT → CMP → VAL → CAL → ASS
Important constraints:
- Applicability and materiality always run first.
- Computation never runs if validation fails.
- Assurance primitives never mutate data.
- Chains are declarative, not imperative.
5. Mapping Rule Primitives to Governance Levels
| Governance Level | Active Primitive Categories |
|---|---|
| 0 — none | (none) |
| 1 — basic | VAL |
| 2 — compliance | APL, MAT, CMP, VAL |
| 3 — assurance | APL, MAT, CMP, VAL, CAL, ASS |
This ensures:
- no over-governance,
- predictable behavior,
- consistent audit semantics.
6. Rule Primitive Identity & Versioning
Each primitive has a canonical identifier.
Example ID Format
RPT_<CATEGORY>_<NAME>_v<MAJOR.MINOR>
Examples
RPT_VAL_RANGE_NON_NEGATIVE_v1.0RPT_APL_NACE_MATCH_v2.1RPT_CAL_SUM_AGGREGATION_v1.3
Rules are:
- immutable once published,
- versioned on logic change,
- referenced — never duplicated.
7. Where Rule Primitives Execute
Rule primitives do not execute in forms.
They are executed by:
- MICE engines (CAL, VAL, CMP),
- SSSR runtime evaluators (APL, MAT),
- Assurance engines (ASS).
This ensures:
- separation of concerns,
- scalable execution,
- replayable audit trails.
8. Relationship to Frameworks (Critical Clarification)
Frameworks (ESRS, CSRD, GRI):
- do not define rules
- do not own logic
- do not execute primitives
They only:
- reference signals,
- reference required primitive chains,
- define presentation and disclosure structure.
This is what makes ZAYAZ future-proof.
9. Design Guarantees
By enforcing this taxonomy, ZAYAZ guarantees:
- no rule explosion,
- consistent behavior across frameworks,
- deterministic AI reasoning,
- regulator-grade auditability,
- and safe extensibility.
Rule primitives protect meaning. Frameworks describe obligations. ZAYAZ connects the two — without coupling them.
Agreed — a worked ESRS example as an appendix is exactly the right move, and you’re also right not to interfere with the existing rule-set registry. The appendix should demonstrate usage, not redefine infrastructure.
Below is a Docusaurus-ready Appendix chapter that:
- Shows the full chain Signal → Governance → Rule Primitives → Engines → ESRS disclosure
- Uses existing concepts only (SSSR, governance levels, primitives, MICE)
- Avoids inventing registry schemas
- Is readable by engineers, auditors, and product stakeholders
You can place this under e.g.:
/docs/appendices/appendix-esrs-worked-example.md
Appendix — Worked ESRS Example (End-to-End)
Purpose of this appendix This appendix illustrates, step by step, how ZAYAZ operationalizes an ESRS disclosure using:
- canonical signals,
- governance levels,
- rule primitives,
- and micro-engines,
without embedding ESRS-specific logic into rules or engines.
This is a reference example, not a normative specification.
A.1 Example Chosen
Framework: ESRS Standard: ESRS E1 — Climate Change Disclosure: E1-6 — Gross Scopes 1, 2 and 3 GHG emissions
This disclosure is selected because it:
- spans multiple scopes,
- involves computation,
- is conditionally required,
- and is commonly assured.
A.2 Step 1 — Canonical Signals (SSSR)
ZAYAZ does not treat “E1-6” as a signal. Instead, it identifies the underlying canonical signals required.
Relevant Signals (Illustrative Subset)
| signal_id | signal_kind | description |
|---|---|---|
| ghg_scope1_tco2e | measure | Scope 1 emissions |
| ghg_scope2_location_tco2e | measure | Scope 2 (location-based) |
| ghg_scope2_market_tco2e | measure | Scope 2 (market-based) |
| ghg_scope3_total_tco2e | measure | Scope 3 total |
| reporting_year | control_meta | Reporting period |
| org_boundary_definition | descriptive_meta | Boundary description |
| ghg_methodology_document | document_evidence | Calculation methodology |
All of the above exist independently of ESRS.
A.3 Step 2 — Governance Classification
Each signal is evaluated using the rule-set requirement tests.
Governance Outcome
| signal_id | rule_required | governance_level |
|---|---|---|
ghg_scope1_tco2e | true | 3 — assurance |
ghg_scope2_location_tco2e | true | 3 — assurance |
ghg_scope3_total_tco2e | true | 3 — assurance |
reporting_year | false | 0 — none |
org_boundary_definition | false | 0 — none |
ghg_methodology_document | true | 3 — assurance |
Why level 3?
- Disclosure-relevant
- Computation-linked
- Typically subject to external assurance
A.4 Step 3 — Applicability & Materiality Resolution
Before any computation or validation, ZAYAZ evaluates whether E1-6 applies.
Applicability Primitives (APL)
- Company size ≥ threshold
- Entity in CSRD scope
- Reporting year ≥ CSRD start year
Materiality Primitives (MAT)
- Climate change topic marked material via SEEL
- OR sectoral override applies
If either applicability or materiality fails: → E1-6 is not required → No further rule chains execute
A.5 Step 4 — Rule Primitive Chains (Conceptual)
For each governed signal, ZAYAZ resolves a rule chain based on governance level.
Example Rule Chain (Scope 1 Emissions)
APL → MAT → CMP → VAL → CAL → ASS
Applied Primitive Categories
- APL: Company in scope
- MAT: Climate material
- CMP: Scope 1 value present for reporting year
- VAL: Non-negative, unit = tCO₂e
- CAL: Aggregation from sites (if applicable)
- ASS: Evidence & provenance checks
Each primitive is resolved from the existing rule-set registry by reference.
A.6 Step 5 — Micro-Engine Execution (MICE)
All computation and validation is delegated to micro-engines.
Example Engines Involved
| Engine Category | Purpose |
|---|---|
MEID_VALI_GHG_RANGE | Validate emission ranges |
MEID_CALC_SITE_TO_ENTITY | Aggregate site emissions |
MEID_NORM_UNIT_STANDARD | Unit normalization |
MEID_ASS_EVIDENCE_CHECK | Evidence verification |
Important:
- Engines do not “know” about ESRS
- Engines operate on signal metadata and rule instructions only
A.7 Step 6 — Completeness & Gap Detection
ZAYAZ evaluates disclosure readiness:
- Are all required signals present?
- Are all scopes covered?
- Is Scope 3 required but missing?
If gaps exist:
- ZARA flags missing elements
- Tasks are dispatched via RBAC / HubSpot
- Optional SEM extrapolation may be suggested (flagged as AI-derived)
A.8 Step 7 — Assurance Readiness
For governance level 3 signals:
- Evidence documents must be attached
- Source type must be declared
- Trust score must exceed threshold
- Verifier workflow may be triggered
All actions are logged in ALTD and linked to:
- signal_id
- rule primitive IDs
- engine IDs
- timestamps
A.9 Step 8 — ESRS Disclosure Assembly
Only after all checks pass does ZAYAZ assemble the ESRS disclosure.
Key Principle
ESRS E1-6 is a view, not a computation.
The disclosure:
- pulls validated signal values,
- applies ESRS-specific presentation structure,
- maps values to XBRL tags,
- and includes narrative generated by ZARA (where applicable).
No ESRS logic exists in:
- rule primitives,
- engines,
- or signal definitions.
A.10 What This Example Demonstrates
This worked example shows that:
- ESRS disclosures are resolved, not hard-coded
- Rules remain reusable across frameworks
- Signals remain framework-agnostic
- Assurance is built-in, not bolted on
- AI operates on governed truth, not guesses
ZAYAZ does not implement ESRS. ZAYAZ implements reality — and lets ESRS describe it.
A.11 Reuse Across Frameworks
The same signals and rule primitives shown here can simultaneously support:
- EU Taxonomy climate KPIs
- GRI 305
- Internal net-zero dashboards
- Public E-C-O™ transparency views
Only the mapping layer changes.
Appendix Addition 1 — ESRS Resolution Flow (Visual Sequence Diagram)
Purpose To visually demonstrate how ZAYAZ resolves an ESRS disclosure without embedding ESRS logic into rules or engines.
This diagram complements Appendix A (Worked ESRS Example).
AA1.1 High-Level Sequence (Conceptual)
AA1.2 Key Observations (Important for Reviewers)
- **ESRS is not queried until the final step
- Rule primitives never reference ESRS IDs
- Engines never know why they are executed
- Auditability is end-to-end (signal → rule → engine → disclosure)
This diagram is intentionally framework-agnostic.
AA1.3 Failure Path (Missing Data Example)
No recomputation. No rule mutation. No ESRS logic leakage.
Appendix Addition 2 — Worked ESRS Example (Scope 3–Heavy)
Purpose To demonstrate ZAYAZ handling the most complex ESG case: Scope 3 emissions with partial data, estimation, and assurance constraints.
AA2.1 Example Chosen
- Framework: ESRS
- Standard: ESRS E1
- Disclosure: E1-6 (focus on Scope 3 Categories)
Scope 3 Categories in Focus
- Category 1 — Purchased Goods & Services
- Category 4 — Upstream Transportation
- Category 6 — Business Travel
AA2.2 Canonical Signals (Illustrative)
| signal_id | category | signal_kind | governance_level |
|---|---|---|---|
| scope3_cat1_tco2e | Purchased Goods | measure | 3 |
| scope3_cat4_tco2e | Transport | measure | 3 |
| scope3_cat6_tco2e | Business Travel | measure | 3 |
| supplier_spend_by_category | Input | measure | 2 |
| travel_distance_km | Input | measure | 2 |
| emission_factor_reference | Methodology | document_evidence | 3 |
AA2.3 Rule Primitive Chains (Category 1 Example)
APL_COMPANY_IN_SCOPE
→ MAT_SCOPE3_MATERIAL
→ CMP_SCOPE3_CAT1_PRESENT
→ VAL_NON_NEGATIVE
→ CAL_SPEND_BASED_ESTIMATION (optional)
→ ASS_EVIDENCE_OR_METHOD_DECLARED
Important Detail
CAL_SPEND_BASED_ESTIMATIONonly runs if:- primary data missing
- estimation allowed
- estimation is flagged as such
No silent estimation is ever allowed.
AA2.4 Estimation Is Explicit (Not Hidden)
When estimation is used:
- Signal is tagged:
data_origin = estimated - Methodology document becomes mandatory
- Confidence score is reduced
- Assurance level is constrained
This directly affects:
- trust scoring
- verifier workflow
- public E-C-O™ visibility
AA2.5 Mixed Data Maturity (Realistic Case)
| Category | Data Status | Outcome |
|---|---|---|
| Cat 1 | Estimated | Allowed, flagged |
| Cat 4 | Missing | Gap raised |
| Cat 6 | Primary | Fully compliant |
ZAYAZ:
- does not block the entire disclosure
- does not fabricate totals
- does not hide uncertainty
AA2.6 Disclosure Assembly (Scope 3)
The ESRS output includes:
- category-by-category values
- clear methodology notes
- confidence indicators
- explicit gaps (where applicable)
This is regulator-safe behavior.
Appendix Addition 3 — Why This Architecture Survives ESRS Updates
Audience: Board members, regulators, auditors, partners, procurement leaders (Non-technical but accountability-focused)
AA3.1 The Core Problem with ESG Software
Most ESG systems fail because they:
- hard-code disclosure requirements,
- bake ESRS structure into logic,
- duplicate rules per framework,
- and require rewrites when standards change.
This creates:
- high regulatory risk,
- slow response to updates,
- and unverifiable logic paths.
AA3.2 What ZAYAZ Does Differently
- Signals Represent Reality — Not Regulations
Energy, emissions, workforce, suppliers exist before ESRS and after ESRS.
ZAYAZ models those facts, not the reporting template.
- Rules Are Framework-Agnostic
Rule primitives:
- validate values,
- check completeness,
- assess applicability,
- enforce assurance.
They do not reference:
- ESRS paragraph numbers
- disclosure IDs
- regulator wording
- Frameworks Are Mappings, Not Logic
When ESRS changes:
- mappings are updated
- signals stay the same
- rules stay the same
- engines stay the same
This is a configuration update, not a system rewrite.
- Assurance & Audit Trails Are Preserved
Historical reports remain:
- replayable
- explainable
- traceable
Even if:
- ESRS definitions evolve
- thresholds change
- categories are added
AA3.3 What Happens When ESRS Updates?
| Change Type | ZAYAZ Impact |
|---|---|
| New disclosure | Add mapping |
| Disclosure removed | Mapping retired |
| Calculation guidance updated | Engine version bump |
| Scope clarified | Applicability rule updated |
| Terminology change | No system impact |
No cascade failures. No re-validation of old data unless required.
AA3.4 Strategic Result
ZAYAZ is not “ESRS-compliant software”. ZAYAZ is a sustainability intelligence system that ESRS can safely sit on top of.
This is why:
- auditors trust it,
- regulators can inspect it,
- enterprises can scale on it,
- and Viroway can future-proof it.