Jira progress: loading…

ZSSR

ZAYAZ Smart System Router

1. Purpose

The ZAYAZ Smart System Router (ZSSR) is the intelligent orchestration engine of the ZAYAZ platform.

It determines — in a deterministic, auditable, and trust-aware manner — where each signal instance should be routed next.

ZSSR transforms ZAYAZ from a static pipeline architecture into a:

self-orchestrating, trust-aware, audit-linked signal execution network

2. Conceptual Model

                 ┌────────────────────────────────────┐
                 │       ZSSR Router                  │
                 ├────────────────────────────────────┤
                 │ Input: routing context             │         
                 │   - uso_id                         │
                 │   - signal_id                      │
                 │   - csi                            │
                 │   - origin_chain_codes             │
                 │   - trustgate_event_id             │
                 │   - trust_score                    │
                 │   - execution_audit_event_id       │
                 │   - eco_context                    │
                 │   - framework_context              │
                 │   - routing_hint (optional, prior) │
                 ├────────────────────────────────────┤
                 │ Decision Engine                    │
                 │   - RuleSets (by CSI)              │
                 │   - Trust modifiers                │
                 │   - Policy filters                 │
                 ├────────────────────────────────────┤
                 │ Output: routing event              │
                 │   - next_zar_code.                 │
                 │   - operation_type.                │
                 │   - confidence.                    │
                 │   - routing_rule_id                │
                 │   - proposed_by_cmi.               │
                 │   - trustgate_event_id             │
                 │   - execution_audit_event_id       │
                 │   - audit_hash_context             │
                 │   - routing_decision_id            │
                 └────────────────────────────────────┘

ZSSR acts as the semantic router between:

Producers (e.g. MICE.InvoiceEmissions.Engine),
Validators (e.g. DAVE.TrustGate.Engine.Core),
Governance interfaces (FOGE.FFG), and
Assurance or finance systems.

3. Architectural Position

4. Core Principle & Objectives

ZSSR does not move data — it decides where data should go.

Execution is performed by:

DaVE Dispatcher
downstream engines

ZSSR produces:

routing decisions
routing hints
audit-linked metadata

Objectives

Objective	Description
Semantic Routing	Route signals based on CSI, USO Type, CMI, and regulatory context.
Trust-Aware Routing	Use TrustGate telemetry, not only raw trust scores, to decide next steps.
Audit-Linked Decisions	Every routing decision must reference the TrustGate event and/or execution audit event that informed it.
Dynamic Adaptation	Route low-confidence or policy-sensitive signals to review, enrichment, or assurance workflows.
Deterministic Replay	Ensure routing decisions can be replayed from the same input context and ruleset version.
Compliance Automation	Route signals only through engines and workflows permitted by applicable ESRS, ISO, CPI, or internal policy rules.
External Verifiability	Allow high-value routing decisions to be cryptographically sealed and optionally anchored through Hyperledger Fabric.

5. Input Model (Routing Context)

ZSSR consumes a fully traceable routing context, derived from:

USO instance
TrustGate telemetry
execution audit layer

Routing Context Schema

routing-context-schema.jsonGitHub ↗
{
  "uso_id": "0196F...",
  "signal_id": "sssr:compute_method_registry.created_at",
  "csi": "COMP.AIIL_CON.SIGNAL.CREATED_AT.V1",
  "origin_chain_codes": ["MIE12", "TG3K7"],
  "trustgate_event_id": "tg_evt_...",
  "trust_score": 0.98,
  "execution_audit_event_id": "exec_evt_...",
  "eco_context": ["ECO-123456"],
  "framework_context": ["ESRS", "CSRD"],
  "routing_hint": null
}

6. Decision Engine

ZSSR evaluates routing decisions using:

Inputs

CSI (Signal Type)
CMI / origin_chain_codes
TrustGate results
Execution audit metadata
ECO / regulatory context
RuleSets (ZAR-registered)

7. RuleSet Architecture

ZSSR RuleSets are governed artifacts stored in ZAR (KIND=RULESET).

Structure

RuleSet Architecture Structure

Field	Type	Description
ruleset_id	text	Stable identifier for the routing ruleset.
ruleset_cmi	text	CMI of the ruleset artifact registered in ZAR.
version	text	Ruleset version or date tag.
applies_to	text[]	CSI, USO Type, module, or framework patterns the ruleset applies to.
conditions	jsonb	Conditional routing rules.
outputs	jsonb	Candidate destinations, usually ZAR codes or CMIs.
confidence_formula	text	Formula used to calculate route confidence.
required_context	jsonb	Required input fields such as trust score, USO Type, ECO context, or framework context.
fallback_route	jsonb	Safe fallback destination when no condition matches.
policy_constraints	jsonb	Regulatory, jurisdictional, or framework constraints.
owner_team	text	Responsible owner.
status	text	draft, active, deprecated, or archived.

Example RuleSet

example-ruleset.jsonGitHub ↗
{
  "ruleset_id": "ZSSR.Router.RuleSet.InvoiceLines.2026_01_01",
  "applies_to": ["MICE.InvoiceEmissions.OUTPUT.*"],
  "conditions": [
    {
      "if": "trust_score < 0.8",
      "then": {
        "next_zar_code": "FFG99",
        "operation_type": "MANUAL_REVIEW"
      }
    },
    {
      "if": "framework_context includes 'ESRS' && trust_score >= 0.8",
      "then": {
        "next_zar_code": "TG3K7",
        "operation_type": "VALIDATE"
      }
    }
  ],
  "confidence_formula": "min(1.0, trust_score + completeness_factor * 0.1)"
}

When multiple candidates exist, the downstream orchestration service (DaVE Dispatcher) chooses the route with the highest validated confidence, or fans out in async mode if needed.

8. Routing Flow

9. Routing Output (Decision Event)

ZSSR produces a routing decision event, which is:

auditable
hashable
optionally anchorable

Decision Fields

Field	Type	Description
routing_decision_id	text	Unique decision event identifier.
uso_id	text	USO instance being routed.
signal_id	text	Canonical signal identifier.
next_zar_code	text	Compact alias for the next artifact or workflow.
next_cmi	text	Optional full CMI for the next artifact.
operation_type	text	VALIDATE, ENRICH, MANUAL_REVIEW, ARCHIVE, DISCLOSE, etc.
confidence	numeric	Routing confidence from 0–1.
routing_rule_id	text	Rule that generated the decision.
proposed_by_cmi	text	CMI of the ZSSR engine or RuleSet.
trustgate_event_id	text	TrustGate event used in the routing decision.
execution_audit_event_id	text / bigint	Execution audit event linked to the decision.
reason	text	Human-readable explanation.
audit_input_hash	text	Hash of the routing input context.
audit_decision_hash	text	Hash of the produced decision.
ttl_ms	integer	Time-to-live for routing hint validity.
status	text	proposed, executed, expired, superseded, or failed.

Routing Decision Schema

routing-decision-schema.jsonGitHub ↗
{
  "routing_decision_id": "zssr_evt_0196F...",
  "uso_id": "0196F...",
  "signal_id": "sssr:compute_method_registry.created_at",
  "next_zar_code": "TG3K7",
  "operation_type": "VALIDATE",
  "confidence": 0.97,
  "routing_rule_id": "ZSSR.Router.RuleSet.InvoiceLines.2026_01_01",
  "proposed_by_cmi": "ZSSR.Router.Engine.1_0_0",
  "trustgate_event_id": "tg_evt_...",
  "execution_audit_event_id": "exec_evt_...",
  "reason": "High trust + ESRS context",
  "audit": {
    "input_hash": "sha256:...",
    "decision_hash": "sha256:...",
    "generated_at": "2026-05-05T12:00:00Z"
  }
}

10. Routing Hint (Lineage Attachment)

ZSSR appends routing hints to the signal lineage.

routing-hint.jsonGitHub ↗
{
  "routing_hint": {
    "version": "1.1",
    "proposed_by_cmi": "ZSSR.Router.Engine.1_0_0",
    "ttl_ms": 60000,
    "candidates": [
      {
        "next_zar_code": "TG3K7",
        "confidence": 0.9,
        "operation_type": "VALIDATE"
      },
      {
        "next_zar_code": "FFG99",
        "confidence": 0.6,
        "operation_type": "MANUAL_REVIEW"
      }
    ],
    "audit": {
      "decision_hash": "sha256:...",
      "input_hash": "sha256:..."
    }
  }
}

11. Routing Intelligence Sources

ZSSR combines multiple metadata dimensions to make routing decisions:

Source	Example	Function
CSI	COMP.AIIL_CON.SIGNAL.CREATED_AT.V1	Identifies the canonical signal type.
USO Type	uso_type:emissions.calc_engine.estimate.spend_based.scope3.category1@v1	Provides semantic classification and ESG context.
USO Instance	uso_id = 0196F...	Identifies the specific runtime signal instance.
CMI / ZAR Code	CMID-ZYZ-000001 / TG3K7	Identifies producing or processing artifacts.
Origin Chain	["MIE12", "TG3K7"]	Shows prior transformations and validations.
TrustGate Telemetry	trustgate_event_id, trust_score, validator_id	Supplies validation context and trust outcome.
Execution Audit	execution_audit_event_id, hashes, replay context	Provides reproducibility and audit context.
ECO Context	ECO-123456, country, NACE	Applies entity, sector, or jurisdiction-specific routing rules.
Framework Context	ESRS, CSRD, ISO 14001, PEF	Applies framework-specific routing constraints.
RuleSet CMI	ZSSR.Router.RuleSet.InvoiceLines.2026_01_01	Provides versioned routing logic.

12. Database Schema (Routing Events)

routing-events-schema.sqlGitHub ↗
CREATE TABLE zar.zssr_routing_event (
  zssr_routing_event_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  uso_id text,
  signal_id text,
  trustgate_telemetry_id bigint,
  trustgate_event_id text,
  execution_audit_event_id bigint,
  routing_rule_id text NOT NULL,
  proposed_by_cmi text NOT NULL,
  next_zar_code text NOT NULL,
  operation_type text NOT NULL,
  confidence numeric(5,4),
  reason text,
  audit_input_hash text,
  audit_decision_hash text,
  ttl_ms integer,
  executed_by_cmi text,
  executed_at timestamptz,
  status text DEFAULT 'proposed',
  created_at timestamptz DEFAULT now(),
  updated_by text
);

Example SQL Query — Trace Routing Path

trace-routing-path.sqlGitHub ↗
SELECT
  uso.uso_id,
  uso.signal_id,
  uso.origin_chain_codes,
  route.zssr_routing_event_id,
  route.next_zar_code,
  route.operation_type,
  route.confidence,
  route.reason,
  route.routing_rule_id,
  route.trustgate_event_id,
  route.execution_audit_event_id,
  route.executed_by_cmi,
  route.executed_at,
  route.status,
  route.created_at
FROM zar.uso_instance uso
JOIN zar.zssr_routing_event route
  ON route.uso_id = uso.uso_id
WHERE uso.uso_id = '0196F...'
ORDER BY route.created_at ASC;

Optional stronger version with TrustGate:

trace-routing-path-trustgate.sqlGitHub ↗
SELECT
  uso.uso_id,
  uso.signal_id,
  route.next_zar_code,
  route.operation_type,
  route.confidence,
  route.reason,
  route.routing_rule_id,
  tg.trustgate_decision,
  tg.trust_score,
  tg.validator_id,
  route.status,
  route.created_at
FROM zar.uso_instance uso
JOIN zar.zssr_routing_event route
  ON route.uso_id = uso.uso_id
LEFT JOIN zar.trustgate_telemetry_event tg
  ON tg.trustgate_event_id = route.trustgate_event_id
WHERE uso.uso_id = '0196F...'
ORDER BY route.created_at ASC;

13. Integration with TrustGate

ZSSR consumes TrustGate telemetry events, not just trust scores.

Required fields

trustgate_event_id
trust_score
policy_id
validator_id

Principle

Routing decisions must always reference the TrustGate event — never just the score.

14. Integration with Execution Audit Layer

ZSSR operates on top of execution_audit_event.

ensures replayability
guarantees deterministic routing
supports forensic reconstruction

15. Cryptographic Sealing

ZSSR decisions are cryptographically sealable.

Each decision:

generates a hash
can be stored in execution audit
can be anchored externally

Purpose

tamper-proof routing history
regulator-grade audit trails
deterministic replay

16. Hyperledger Fabric Anchoring

ZSSR decisions may be anchored via:

decision_hash
execution_audit_event_id
trustgate_event_id

Anchoring enables:

external verification
multi-party trust
audit independence

17. Responsibilities Separation

Layer	Responsibility
ZARATHUSTRA	defines semantic rules
SSSR	defines signal structure
USO	tracks runtime instances
TrustGate	evaluates trust
Execution Audit	records system truth
ZSSR	decides routing
DaVE Dispatcher	executes routing

18. Design Principles

Metadata-driven — no hardcoded pipelines
Deterministic — same input → same routing
Audit-linked — every decision traceable
Trust-aware — routing depends on validation context
Sealable — decisions can be cryptographically proven
Composable — integrates across all ZAYAZ modules

19. Example End-to-End Flow

20. Governance & Assurance

Control	Purpose
RuleSet Versioning	Every routing decision must reference the exact ruleset CMI/version used.
RuleSet Signing	Active routing rulesets should be signed or hash-verified before use.
TrustGate Linkage	Routing decisions must reference TrustGate telemetry when trust context influenced the route.
Execution Audit Linkage	Route decisions should be reproducible through execution audit context.
Immutable Decision Logs	Routing decisions are append-only and retained for replay/audit.
Fallback Safety	If no route is found, ZSSR routes to a safe review workflow, usually FOGE/FFG.
Cryptographic Sealing	High-value decisions may be included in a hash chain and seal.
Fabric Anchoring	Externally relevant decisions may be anchored through Hyperledger Fabric.
Human Review	Low-confidence, policy-sensitive, or conflicted routing decisions require review.
Compliance Traceability	Routing paths should support ESRS, ISO, CPI, and internal governance evidence.

21. Compliance Alignment and Future Extensions

Area	Objective
Assurance Readiness	Routing events are linked to TrustGate telemetry, execution audit events, and replayable lineage.
ESRS / ISO Traceability	Routing paths can demonstrate how material signals moved through validation, enrichment, review, and disclosure workflows.
AI-Assisted RuleSets	Future ZARA/DSAIL modules may propose routing rule improvements based on historical routing outcomes.
Self-Healing Networks	Engine capability registries may allow ZSSR to rebuild routing options when services fail or are deprecated.
Cross-Domain Routing	Signals may be routed from TrustGate into FOGE, financial impact engines, CPI workflows, or disclosure modules.
External Verification	High-value routing decisions may be cryptographically sealed and anchored through Hyperledger Fabric.

22. Summary

The ZAYAZ Smart System Router (ZSSR) transforms the platform into a self-orchestrating ESG intelligence fabric:

Every signal knows its type (CSI), origin (CMI), and trustworthiness (TrustGate). ZSSR uses these to decide, document, and execute routing — transparently, verifiably, and adaptively.

Together with USO, SSSR, and ZAR, it closes the loop from:

data creation → validation → assurance → disclosure

ZSSR is the decision intelligence layer of ZAYAZ.

It ensures that:

every signal is routed correctly
every decision is explainable
every action is auditable
every pathway is reproducible

ZSSR decides. ZAYAZ executes. Auditors verify.

GitHub Repo Request for Change (RFC)

1. Purpose​

2. Conceptual Model​

3. Architectural Position​

4. Core Principle & Objectives​

5. Input Model (Routing Context)​

6. Decision Engine​

7. RuleSet Architecture​

8. Routing Flow​

9. Routing Output (Decision Event)​

10. Routing Hint (Lineage Attachment)​

11. Routing Intelligence Sources​

12. Database Schema (Routing Events)​

13. Integration with TrustGate​

14. Integration with Execution Audit Layer​

15. Cryptographic Sealing​

16. Hyperledger Fabric Anchoring​

17. Responsibilities Separation​

18. Design Principles​

19. Example End-to-End Flow​

20. Governance & Assurance​

21. Compliance Alignment and Future Extensions​

22. Summary​