Skip to main content

MOD-DEF

The ZAYAZ Modules

Formal Module Definition Schema (ZAYAZ Canonical)​

Purpose​

This section formalizes the term “Module” within the ZAYAZ platform to eliminate ambiguity between modules, engines, and micro-engines.

This distinction is architecturally mandatory for:

  • scalability
  • auditability
  • AI governance (EU AI Act)
  • white-label licensing
  • verifier assurance
  • future federation (EGFS / FAGF)

1. Canonical Definitions​

1.1 Micro-Engine (MICE)​

Definition
A Micro-Engine is the smallest executable computation unit in ZAYAZ.

Characteristics

  • Atomic, single-purpose logic
  • Deterministic or narrowly probabilistic
  • Versioned via MEID
  • Replaceable without domain impact
  • No governance authority

Examples

  • Flight emissions calculator
  • Scope 3 category validator
  • Risk tagger
  • Monte Carlo sampler
  • Unit conversion transformer

Micro-engines compute. They do not decide.

1.2 Engine​

Definition
An Engine is a reusable computation or intelligence service that may orchestrate multiple micro-engines and apply structured logic.

Characteristics

  • May aggregate multiple MICE
  • May use AI / probabilistic logic
  • Reusable across multiple modules
  • No domain ownership
  • No regulatory meaning on its own

Examples

  • DICE (Data Integrity & Completeness Engine)
  • DaVE (Data Validation Engine)
  • SEM (Statistical Extrapolation Model)
  • AISIM (AI Synthesis & Insight Module)
  • NETZERO Core Compute Engine

Engines compute and reason, but do not own ESG intent.

1.3 Module (Canonical Definition)​

Definition
A Module is a domain-bounded, governed capability unit that orchestrates engines, signals, workflows, trust logic, and outputs to fulfill a specific ESG purpose.

A Module is NOT an engine.
It is a decision-grade orchestration boundary.

2. Mandatory Properties of a Module​

A component MUST satisfy all of the following to be classified as a Module:

PropertyRequired
Domain ScopeClearly bounded ESG capability
Engine OrchestrationUses ≥1 engines
Signal OwnershipDefined SSSR signal scope
Governance LogicTrust thresholds, escalation rules
AuditabilityALTD + replay support
Workflow InterfacesZADIF / Verifier / Calendar / HubSpot
Output AuthorityProduces decision-grade outputs
Licensing BoundaryCan be licensed / white-labeled

If any of these are missing → it is not a module.

3. Canonical Official Module Registry (OMR) JSON Schema (v1)​

3.1. Purpose and Role of the OMR​

The Official Module Registry (OMR) defines and governs all canonical Modules, Engines, and Micro-Engines in the ZAYAZ platform.

The OMR serves as:

  • the machine-readable backbone for architecture governance,
  • the authoritative classification mechanism for platform components,
  • the source for documentation tagging, tables, and references,
  • the enforcement layer for module lifecycle and AI governance rules.

All platform intelligence, documentation, and tooling MUST align with the OMR.

3.2. Canonical Status​

The OMR JSON schema is the primary and canonical definition of:

  • what exists in the platform,
  • how it is classified,
  • what governance rules apply.

Conceptual definitions and prose descriptions are normative references only. They do not override or supersede the OMR.

3.3. Canonical OMR JSON Schema (v1)​

The following JSON schema defines the required structure for all OMR entries.

The schema is versioned and governed under the Change Management & Compatibility Framework (CMCB).

module-registry-excerpt.jsonGitHub ↗
{
  "id": "rif",
  "code": "RIF",
  "name": "Risk Intelligence Framework",
  "classification": "module",
  "domain": "governance-risk",
  "category": "risk-intelligence",

  "description": "Decision-grade ESG risk identification, quantification, scenario analysis, and escalation.",

  "lifecycle": {
    "status": "active",
    "semver": "1.0.0",
    "introduced_in": "v0.3",
    "deprecated_in": null
  },

  "governance": {
    "ai_risk_level": "high",
    "human_review_required": true,
    "trust_threshold": 0.9,
    "verifier_involved": true
  },

  "dependencies": {
    "engines": [
      "RMAP",
      "MonteCarloEngine",
      "BayesianScenarioEngine",
      "AISIM",
      "DICE",
      "DaVE"
    ],
    "micro_engines": [
      "MEID_RMAP01",
      "MEID_CFIL01",
      "MEID_MC02"
    ],
    "modules": []
  },

  "signals": {
    "uso": ["ESRS_E", "ESRS_S", "ESRS_G", "FIN_RISK"],
    "sssr_tags": ["risk", "materiality", "governance"],
    "csi": ["CSI_RISK_INTELLIGENCE"]
  },

  "outputs": [
    "RiskScore",
    "ScenarioRange",
    "BoardNarrative"
  ],

  "audit": {
    "ledger": "ALTD",
    "replay_supported": true
  },

  "tags": ["core-module", "decision-grade", "csrd", "esrs"]
}

See Appendix B for more information about OMR as the Single Source of Truth (SSoT).

3.4. OMR Entry Structure and Semantics​

Each OMR entry represents exactly one of the following classifications:

  • module
  • engine
  • micro-engine

Mandatory Fields

All entries MUST define:

  • id
  • code
  • name
  • classification
  • domain
  • category
  • lifecycle
  • entrypoints
  • dependencies
  • signals

Missing mandatory fields constitute a registry violation.

3.5. Classification Rules (Normative)​

Modules

An entry MAY be classified as module only if it:

  • orchestrates one or more engines,
  • owns a bounded ESG or governance domain,
  • defines decision-grade outputs,
  • carries governance and AI risk metadata,
  • participates in audit and replay logic.

Engines

An entry classified as engine:

  • provides reusable computation or intelligence,
  • may be used by multiple modules,
  • does not own governance authority.

Micro-Engines

An entry classified as micro-engine:

  • performs atomic, single-purpose logic,
  • is identified via MEID,
  • has no independent governance meaning.

Misclassification is treated as an architectural defect.

3.6. Lifecycle Semantics​

Each entry MUST define a lifecycle object with:

  • status
  • semver
  • introduction and deprecation markers where applicable

Lifecycle status controls:

  • visibility in documentation,
  • eligibility for use in production,
  • white-label exposure,
  • audit and replay obligations.

3.7. Dependency Semantics​

Dependencies MUST be explicitly declared and are restricted as follows:

  • Modules MAY depend on:
    • Engines
    • Micro-Engines
    • Other Modules (explicitly declared)
  • Engines MAY depend on:
    • Micro-Engines only
    • Micro-Engines MUST NOT depend on Modules

Circular dependencies are prohibited.

3.8. Signal Ownership and Tagging​

Each entry MUST declare:

  • USO signal domains it consumes or produces
  • SSSR tags for search, routing, and documentation
  • CSI identifiers where applicable

Signal ownership defines:

  • routing authority,
  • audit scope,
  • cross-module interoperability.

3.9. Governance and AI Risk Metadata​

Entries classified as module MUST declare:

  • AI risk level (Low / Medium / High)
  • human review requirements
  • trust thresholds
  • verifier involvement flags

These fields are directly mapped to:

  • the AI Risk Register
  • verifier workflows
  • EU AI Act compliance logic

3.10. Enforcement Rule (Normative)​

All MDX documentation, diagrams, APIs, and partner materials MUST reference Modules, Engines, and Micro-Engines exclusively via the OMR.

Hardcoded names, ad hoc classifications, or undocumented components are prohibited.

3.11. Relationship to Other Governance Artifacts​

The OMR is tightly coupled with:

  • Module Governance & Registration Process
  • AI Risk Register
  • Change Management & Compatibility Framework (CMCB)
  • ZAR, SSSR, and USO registries

Together, these form the governance spine of ZAYAZ.

3.12. Strategic Outcome​

By elevating the OMR to canonical status, ZAYAZ ensures:

  • deterministic architecture
  • enforceable governance
  • audit-ready intelligence
  • scalable documentation and tooling

The platform evolves intentionally, not accidentally.

Precision before automation. Integrity above velocity.

3.13. Module Qualification Rules​

This section defines the normative qualification rules that determine whether a component is eligible to be registered as a Module in the Official Module Registry (OMR).

See Appendix C for more information on Module Qualification Rules.

4. Canonical ZAYAZ Module Map​

4.1 Core Platform Modules​

ModuleDomainDescription
Input HubData AcquisitionStructured ESG input, onboarding, system capability mapping
Computation HubAnalyticsCross-domain computation & modeling
Reports & Insights HubDisclosureReport generation, visualization, stakeholder outputs
SISServicesShared Governance Services
ZARAGovernance AIPrompt-driven ESG orchestration
ZAAMAI AssistanceRole-aware agent system
RIFRiskESG risk intelligence & escalation
NETZEROClimateDecarbonization modeling & pathways
Verification & AssuranceTrustVerifier workflows & assurance logic
SEELMaterialityStakeholder engagement & materiality
EcoWorld AcademyEducationCapacity building & ESG fluency

See Appendix A for information on Module Governance.

5. Engine → Micro-Engine Mapping (Excerpt)​

RIF – Risk Intelligence Framework (Module)

Engines

  • Risk Mapping Engine (RMAP)
  • Scenario Simulation Engine
  • AI Risk Interpretation Engine
  • DICE / DaVE

Micro-Engines

  • MEID_RMAP01 – ESRS risk classifier
  • MEID_CFIL01 – Confidence filter
  • MEID_MC01 – Monte Carlo sampler
  • MEID_BAY01 – Bayesian inference engine

NETZERO (Module)

Engines

  • Emissions Aggregation Engine
  • Pathway Simulation Engine
  • Cost Impact Engine

Micro-Engines

  • MEID_CALC_GHG01 – Scope 1–3 calc
  • MEID_TSYN01 – Time-series aligner
  • MEID_MC_NET01 – Net-zero simulation

ZARA (Module)

Engines

  • Intent Parser Engine
  • Signal Resolver Engine
  • Narrative Synthesis Engine

Micro-Engines

  • MEID_NLP_INTENT01
  • MEID_TAGG_ESRS01
  • MEID_AISIM_SUM01

6. Anti-Patterns (Explicitly Disallowed)​

The following are NOT modules:

  • ❌ Single engines (e.g. DICE alone)
  • ❌ Micro-engine collections without governance
  • ❌ UI features without orchestration authority
  • ❌ AI models without audit & trust logic

If it does not own a decision boundary, it is not a module.

7. Architectural Rule (Non-Negotiable)​

Modules decide. Engines compute. Micro-engines execute.

This rule is enforced across:

  • architecture diagrams
  • registries
  • API contracts
  • AI governance
  • partner documentation

8. Strategic Outcome​

This schema enables:

  • clean white-label licensing
  • verifier-safe audit scopes
  • EU AI Act alignment
  • future federation of ESG intelligence
  • zero ambiguity across teams

Precision before automation.

APPENDIX A - Module Governance & Registration Process (ZAYAZ Canonical)​

Purpose of the formal governance process​

This section defines the formal governance process for introducing, modifying, or deprecating Modules within the ZAYAZ platform.

Its purpose is to:

  • preserve architectural integrity
  • prevent module sprawl
  • protect audit and AI-governance boundaries
  • ensure long-term scalability and white-label stability

This process is mandatory for all platform evolution.

A.1. Scope & Authority​

A.1.1. Scope​

This process applies to:

  • all new Modules
  • any material change to an existing Module
  • any proposal to elevate an Engine or subsystem to Module status
  • any deprecation or merger of Modules

It does not apply to:

  • Engines
  • Micro-Engines (MICE)
  • UI features
  • internal refactors with no governance impact

A.1.2. Governing Authority​

Module governance is owned by:

  • ZAYAZ Architecture & Governance Board (AGB)
    (CTO / Lead Architect / AI Governance Lead / Platform Ops)

Final approval authority rests with the AGB.

A.2. Module Lifecycle States​

Every Module MUST exist in exactly one lifecycle state:

StateMeaning
ProposedUnder formal review, not deployable
Approved (Active)Canonical module, listed in registry
RestrictedActive but limited (pilot, regulated, or high-risk)
DeprecatedScheduled for retirement
ArchivedNo longer active, retained for audit replay

No module may skip states.

A.3. Registration Criteria (Hard Gate)​

A proposal MAY ONLY be considered if all criteria are met.

A.3.1. Structural Criteria​

A proposed Module MUST:

  • satisfy the Module Definition Schema
  • orchestrate one or more engines
  • own a bounded ESG domain
  • have clear signal scope (SSSR)
  • define decision-grade outputs
  • require governance logic

Failure on any item → automatic rejection.

A.3.2. Governance Criteria​

The proposal MUST define:

  • AI risk classification (Low / Medium / High)
  • human-in-the-loop requirements
  • trust thresholds
  • audit & replay obligations
  • verifier interaction (if applicable)

If AI risk is High, AI Governance approval is mandatory.

A.3.3. Non-Duplication Rule​

A new Module MUST NOT:

  • duplicate the domain of an existing Module
  • overlap without explicit parent–child delineation
  • fragment an existing Module without deprecation logic

“Convenience” is not a valid justification.

A.4. Module Proposal Package (Required)​

All proposals MUST submit a Module Proposal Package (MPP) containing:

A.4.1. Required Artifacts​

  1. Module Definition Schema (JSON)
  2. Domain Boundary Statement
  3. Engine & Micro-Engine Map
  4. Signal Ownership Map (SSSR)
  5. Governance & AI Risk Assessment
  6. Audit & Replay Impact Statement
  7. White-Label / Licensing Impact
  8. Backward Compatibility Analysis

Incomplete packages are not reviewed.

A.5. Review & Approval Process​

Step 1 — Intake & Validation​

  • Architecture team validates completeness
  • Schema compliance checked
  • Anti-pattern screening applied

Outcome: Accept for review / Reject

Step 2 — Governance Review​

  • AI Governance Lead reviews risk & trust logic
  • Audit & verifier implications assessed
  • Escalation paths validated

Outcome: Pass / Conditional Pass / Reject

Step 3 — Architectural Review​

  • Domain boundaries stress-tested
  • Engine vs Module classification confirmed
  • Long-term roadmap alignment checked

Outcome: Recommend / Recommend with Conditions / Reject

Step 4 — AGB Decision​

  • Formal vote or sign-off
  • Conditions recorded (if any)

Outcome: Approved → Registry Entry
Rejected → Closed with rationale

A.6. Official Module Registry (OMR)​

A.6.1. Registry Rules​

All approved Modules MUST be registered in the Official Module Registry (OMR).

Each entry includes:

  • module_id (immutable)
  • version
  • lifecycle state
  • domain
  • AI risk level
  • governance flags
  • effective date

Unregistered modules are non-canonical and unsupported.

A.6.2. Versioning Rules​

  • MAJOR: domain scope change (rare, breaking)
  • MINOR: capability expansion (non-breaking)
  • PATCH: governance or metadata updates

Versioning follows the CMCB framework.

A.7. Modification & Deprecation​

A.7.1. Modifying an Existing Module​

Changes that require re-registration:

  • domain expansion
  • new decision authority
  • AI risk level increase
  • new verifier or regulatory role

Minor internal changes do not.

A.7.2. Deprecation​

Deprecation requires:

  • formal notice period
  • migration path
  • audit replay guarantee
  • registry status update

No module may be removed without archival.

A.8. Explicit Anti-Patterns (Disallowed)​

The following are explicitly forbidden:

  • promoting an Engine to Module “for clarity”
  • creating Modules for UI convenience
  • partner-specific Modules without governance
  • duplicating Modules under new names
  • bypassing the registry

Violations are treated as architecture defects.

A.9. Enforcement Rule (Normative)​

If it is not registered, it is not a Module.
If it is not governed, it is not allowed.

This rule applies to:

  • internal development
  • documentation
  • partner integrations
  • white-label deployments

A.10. Strategic Outcome​

This process ensures that:

  • ZAYAZ remains coherent at scale
  • governance keeps pace with intelligence
  • audits remain defensible
  • evolution is intentional, not accidental

Precision before automation.
Governance before growth.

APPENDIX B - OMR as the Single Source of Truth (SSoT)​

Normative Statement​

The Official Module Registry (OMR) is the single, authoritative source of truth for all Modules, Engines, and Micro-Engines within the ZAYAZ platform.

Any component that is not registered in the OMR:

  • is not considered canonical,
  • must not be referenced as a Module, Engine, or Micro-Engine,
  • must not be exposed in documentation, APIs, white-label deployments, or governance workflows.

If it is not registered in OMR, it does not exist operationally.

Scope of Authority​

The OMR governs and defines:

  • architectural classification (module, engine, micro-engine)
  • lifecycle state (draft, active, restricted, deprecated, archived)
  • governance and AI risk metadata
  • signal ownership and tagging
  • dependency relationships
  • white-label and licensing eligibility

All other representations (MDX documentation, diagrams, tables, APIs, dashboards) must derive their definitions from the OMR, either directly or via generated views.

Conflict Resolution Rule​

In the event of any discrepancy between:

  • prose documentation,
  • diagrams,
  • code comments,
  • partner materials,
  • or internal references,

the OMR entry SHALL prevail.

Documentation or systems found to diverge from the OMR are considered non-compliant and must be corrected.

Governance Implication​

The OMR is governed under the Module Governance & Registration Process. Changes to the OMR are subject to:

  • architectural review,
  • AI governance validation,
  • lifecycle and compatibility rules (CMCB),
  • audit and replay guarantees.

Direct modification outside the approved governance process is prohibited.

Strategic Rationale​

Establishing the OMR as the Single Source of Truth ensures:

  • zero ambiguity between Modules, Engines, and Micro-Engines
  • deterministic documentation and tagging
  • enforceable AI risk boundaries
  • stable white-label contracts
  • long-term architectural coherence

Precision before automation.
Governance before growth.

APPENDIX C - Module Qualification Rules (Normative)​

Appendix C – Module Qualification Rules (Normative)

C.1 Purpose and Authority​

This appendix defines the normative qualification rules that determine whether a component is eligible to be classified as a module and registered as such in the Official Module Registry (OMR).

These rules:

  • do not define what exists in the platform,
  • do not override the OMR,
  • do not introduce alternative schemas.

Instead, they define what is allowed to exist as a Module.

The OMR is the Single Source of Truth.
These rules are the gatekeeper for OMR eligibility.

C.2 Normative Status​

This appendix is normative and binding for:

  • platform architecture decisions,
  • module registration and review,
  • AI governance classification,
  • white-label and partner integrations,
  • audit and verifier scope definition.

Any deviation from these rules constitutes an architectural governance violation.

C.3 Canonical Definitions (Recap)​

For the avoidance of doubt:

  • Module
    A governed, domain-bounded orchestration unit with decision authority.

  • Engine
    A reusable computation or intelligence service without domain ownership.

  • Micro-Engine (MICE)
    An atomic execution unit performing single-purpose logic.

Only components that satisfy the criteria in this appendix MAY be classified as module.

C.4 Mandatory Qualification Criteria for Modules​

A component MUST satisfy all criteria below to be eligible for classification as a Module.

Failure on any single criterion results in automatic disqualification.

C.4.1 Domain Ownership​

The component MUST:

  • own a clearly bounded ESG, governance, or intelligence domain,
  • have an explicit problem statement that is not a subset of another module,
  • avoid ambiguous or overlapping domain claims.

Examples of valid domains:

  • Risk Intelligence
  • Net-Zero Transition Modeling
  • Verification & Assurance
  • Materiality & Stakeholder Engagement

Examples of invalid domains:

  • “Calculations”
  • “AI Processing”
  • “Forms”
  • “Dashboards”

C.4.2 Engine Orchestration​

The component MUST:

  • orchestrate one or more Engines, and
  • coordinate their execution toward a domain-level outcome.

A component that only:

  • performs computation,
  • applies a model,
  • executes a single algorithm,

does not qualify as a Module.

C.4.3 Decision-Grade Outputs​

The component MUST produce outputs that:

  • influence compliance, governance, or strategic decisions,
  • may require human review or escalation,
  • have audit or verifier relevance.

Purely intermediate or technical outputs are insufficient.

C.4.4 Governance Authority​

The component MUST define and enforce:

  • governance rules,
  • trust thresholds,
  • escalation logic,
  • human-in-the-loop requirements (where applicable).

A component without governance authority cannot be a Module.

C.4.5 Auditability and Replay​

The component MUST:

  • participate in audit logging (ALTD or equivalent),
  • support deterministic or explainable replay,
  • preserve historical decision context.

If a component’s outputs cannot be audited or replayed, it is ineligible for Module classification.

C.4.6 Signal Ownership​

The component MUST:

  • declare ownership or stewardship over specific signal domains (USO / SSSR),
  • define how signals are interpreted, aggregated, or escalated,
  • avoid acting purely as a passive signal consumer.

Signal routing authority is a core attribute of a Module.

C.4.7 Governance and AI Risk Declaration​

If the component uses AI or probabilistic logic, it MUST:

  • declare an AI risk level (Low / Medium / High),
  • specify human review requirements,
  • define trust thresholds,
  • align with the AI Risk Register.

Undeclared AI risk automatically disqualifies Module status.

C.5 Explicit Disqualification Rules​

The following MUST NOT be classified as Modules:

  • Engines (even if complex or AI-based)
  • Micro-Engines (MICE)
  • UI layers or feature bundles
  • Data pipelines or ETL processes
  • Reporting templates
  • Partner-specific customizations
  • Rebranded or duplicated existing modules

Complexity alone does not justify Module status.

C.6 Non-Duplication and Containment Rule​

A proposed Module MUST NOT:

  • duplicate the scope of an existing Module,
  • fragment an existing Module without formal deprecation,
  • introduce parallel governance boundaries.

If new functionality fits entirely within an existing Module’s domain, it MUST be implemented as:

  • an Engine, or
  • an internal extension of that Module.

C.7 Elevation Prohibition Rule​

An Engine or subsystem MUST NOT be “promoted” to a Module solely to:

  • improve naming clarity,
  • simplify documentation,
  • satisfy partner preferences,
  • create artificial product boundaries.

Elevation to Module status requires full re-qualification under this appendix and formal OMR registration.

C.8 Relationship to the Official Module Registry (OMR)​

These rules are enforced exclusively through the OMR.

A component may only be classified as module if:

  • it satisfies all qualification rules in this appendix, and
  • it is registered and approved in the OMR under the Module Governance process.

OMR registration is necessary but not sufficient.
Qualification under this appendix is mandatory.

C.9 Enforcement and Remediation​

Violations of these rules result in one or more of the following:

  • reclassification (module → engine),
  • removal from documentation,
  • revocation of white-label exposure,
  • governance review and remediation.

Repeated or willful violations are treated as systemic architecture defects.

C.10 Strategic Intent​

These rules exist to ensure that:

  • Modules remain rare, meaningful, and governed,
  • the platform scales without conceptual drift,
  • audits remain defensible,
  • AI intelligence remains accountable,
  • ZAYAZ evolves intentionally.

Modules are constitutional boundaries, not convenience labels.

Precision before automation.
Integrity above velocity.

{
  "module_id": "RIF",
  "module_name": "Risk Intelligence Framework",
  "domain": "Risk & Governance",
  "description": "Decision-grade ESG risk identification, quantification, and escalation",
  "owned_signal_domains": ["ESRS_E", "ESRS_S", "ESRS_G", "FIN_RISK"],
  "engines_used": [
    "RMAP",
    "MonteCarloEngine",
    "BayesianScenarioEngine",
    "AISIM",
    "DICE",
    "DaVE"
  ],
  "micro_engines_used": ["MEID_RMAP01", "MEID_CFIL01", "MEID_MC02"],
  "governance": {
    "human_review_required": true,
    "trust_threshold": 0.9,
    "ai_risk_level": "High"
  },
  "workflows": ["ZADIF", "VerifierRouting", "BoardEscalation"],
  "outputs": ["RiskScore", "ScenarioRange", "BoardNarrative"],
  "audit": {
    "ledger": "ALTD",
    "replay_supported": true
  }
}


GitHub RepoRequest for Change (RFC)