Skip to main content
Jira progress: loading…

SSSR-ENHM

Smart Searchable Signal Registry (SSSR)

(Enhanced for Canonical Signal Identifiers and Schema Linkage)

1. Purpose​

The Smart Searchable Signal Registry (SSSR) is the canonical signal definition layer of the ZAYAZ platform.

It defines what a signal is, independently of:

  • where it is stored
  • how it is produced
  • how it is validated

SSSR enables:

  • semantic consistency across all modules
  • traceability from schema → runtime → validation
  • machine-discoverable ESG data architecture
  • regulator-grade explainability

2. Architectural Position​

SSSR is not a single table — it is a composed registry layer.

ZARATHUSTRA (Semantic Definition)
        ↓
SSSR (Signal Definition Layer)
        ↓
USO (Runtime Lineage)
        ↓
TrustGate (Validation & Trust)
        ↓
Execution Audit (Optional Replay Layer)

3. Core Components of SSSR​

3.1. zar.signal_registry (Core Definition)​

Defines the canonical signal:

  • signal_id → global identity (e.g. sssr:compute_method_registry.created_at)
  • signal_name
  • signal_domain
  • signal_role
  • unit_of_measure
  • cmid (canonical producing artifact reference)

This is the semantic anchor

3.2. zar.signal_binding_registry (Physical Binding)​

Maps signals to physical storage:

  • table
  • column
  • schema
  • storage format

3.3. zar.signal_csi_binding (Conceptual Identity)​

Stores Canonical Signal Identifier:

<MODULE>.<COMPONENT>.<KIND>.<NAME>.<VERSION>

Example:

COMP.AIIL_CON.SIGNAL.CREATED_AT.V1

Separates:

  • meaning (CSI)
  • from structure (signal_registry)

3.4. zar.signal_uso_type_binding (Definition-time Ontology)​

Defines:

What type of real-world signal this represents

Example:

governance.audit_workflow.assurance.direct_measurement.total.total

4. Runtime Layer (USO Integration)​

SSSR connects directly to runtime via:

zar.uso_instance

Each signal instance gets:

  • uso_id (ULID)
  • signal_id
  • csi
  • cmi
  • origin_chain
  • input_hash, output_hash
  • execution_context

This creates:

One signal definition → many runtime instances

5. Validation Layer (TrustGate Integration)​

zar.trustgate_telemetry_event

Stores:

  • validation decisions
  • trust scores
  • policy execution
  • validator results

Example:

validation-layer.jsonGitHub ↗
{
  "trustgate_decision": "pass",
  "trust_score": 0.98,
  "validator_id": "trustgate.signal.required_fields.v1"
}

This turns SSSR into:

Not just a schema layer — but a validated schema layer

6. Conceptual Model​

Signal Definition Layer (SSSR)

   signal_registry
        │
        ├── signal_binding_registry   (physical)
        ├── signal_csi_binding        (conceptual identity)
        └── signal_uso_type_binding   (ontology)

Runtime Layer

   uso_instance
        │
        └── trustgate_telemetry_event

Optional Audit Layer

   execution_audit_event

7. Relationships​

RegistryRole
SSSRdefines meaning
ZAR (CMI)defines producer
USOtracks runtime lineage
TrustGatevalidates correctness
Auditproves reproducibility

8. Example Query​

example-query.sqlGitHub ↗
SELECT
  sr.signal_id,
  sr.signal_name,
  csi.csi,
  uso.uso_id,
  tg.trust_score
FROM zar.signal_registry sr
LEFT JOIN zar.signal_csi_binding csi
  ON csi.signal_id = sr.signal_id
LEFT JOIN zar.uso_instance uso
  ON uso.signal_id = sr.signal_id
LEFT JOIN zar.trustgate_telemetry_event tg
  ON tg.uso_instance_id = uso.uso_instance_id
WHERE sr.signal_id = 'sssr:compute_method_registry.created_at';

9. Key Design Principles​

  1. Separation of Concerns
    • Structure ≠ Meaning ≠ Runtime ≠ Validation
  2. Signal-Centric Architecture
    • Everything revolves around signal_id
  3. Immutable Runtime
    • USO instances are append-only
  4. Validation as First-Class Citizen
    • TrustGate is not optional
  5. Composable Registries
    • No monolithic schema


GitHub RepoRequest for Change (RFC)