USO
Universal Signal Ontology (USO) - Semantic Framework
Purpose:
The Universal Signal Ontology (USO) in ZAYAZ consists of two layers:
-
USO Type (Semantic Layer)
Defines the semantic origin and classification of a signal (e.g., emissions.invoicecrawler.estimated@v1). -
USO Instance (Runtime Layer)
A unique lineage identity created at signal execution (“signal birth”), representing a specific occurrence of a signal.
Each USO Instance links:
- a producing artifact (CMI),
- a canonical signal type (CSI),
- and a semantic classification (USO Type),
forming the first node in the signal’s lineage chain and enabling full traceability through TrustGate telemetry.
Signal execution:
CMI ──produces──▶ CSI
│
▼
USO Instance
│
▼
TrustGate / Telemetry
1. At signal birth:**
- The system creates a new USO ID (unique lineage identity).
- It attaches existing metadata:
- primary_origin_cmi = the producing artifact’s CMI (from ZAR registry)
- csi = the canonical signal type (from SSSR registry)
No new CMI or CSI is created at runtime — they’re predefined in registries. Only the USO instance is minted dynamically.
1.1. Visual Breakdown
+-------------------------------------------------------------+
| Signal Instance (USO Record) |
| uso_id: 01JBF0W8S9Q0R1S2T3U4V5W6X |
| born_at: 2025-10-25T14:21Z |
| primary_origin_cmi: comp.TAC.Engine.1_1_0 |
| csi: comp.TAC.OUTPUT.CO2E.1_0 |
| origin_chain: [comp.TAC.Engine.1_1_0] |
| origin_chain_codes: [MIE12] |
| context: { eco_numbers: [“ECO-196-123-456-789“] } |
+-------------------------------------------------------------+
1.2. Registries that existed before birth
| Registry | Contains | Example Entry | Purpose |
|---|---|---|---|
| ZAR | CMIs (artifacts) | comp.TAC.Engine.1_1_0 | Declares what engines exist |
| SSSR | CSIs (signal types) | comp.TAC.OUTPUT.CO2E.1_0 | Declares what signals exist |
| USO (runtime) | USO IDs | 01JBF0W8S9Q0R1S2T3U4V5W6X | Declares that this signal instance exists now |
1.3. Correct cause–effect relationships
| Relationship | Direction | Example |
|---|---|---|
| CMI → CSI | Artifact produces a signal of type | comp.TAC.Engine.1_1_0 → comp.TAC.OUTPUT.CO2E.1_0 |
| CSI → SSSR field(s) | Signal type maps to table/column(s) | CO2E.1_0 → sssr:op_activity_facts.value@OAF-0074 |
| USO → CMI + CSI | Instance references its type & origin | uso_id=01JBF... → (CMI, CSI) |
1.4. Common misunderstanding (flipped roles)
| Misconception | Correction |
|---|---|
| “The CMI is created for this new signal.” | ❌ The CMI already existed — it’s the code artifact (engine) that produced the signal. |
| “The CSI tells where the signal came from.” | ❌ The CSI tells what kind of signal it is, not where it came from. |
| “The USO code tells what type it is.” | ❌ The USO tells which instance it is (like a unique serial number). |
In one sentence When a signal is born:
- ZAYAZ mints a new USO ID for that specific data instance, and attaches two existing references — a CMI (who produced it) and a CSI (what type it is).
1.5. Analogy for memory
| Analogy | Real-life equivalent |
|---|---|
| USO ID | A person’s birth certificate number |
| CSI | The species (“Homo sapiens”, “signal type = CO₂e”) |
| CMI | The hospital or machine that delivered the baby |
| ZAR Code | The hospital code used for routing / traceability |
1.6. Example end-to-end
| Layer | Identifier | Example | Notes |
|---|---|---|---|
| Artifact (who) | CMI | comp.TAC.Engine.1_1_0 | Declared in ZAR |
| Signal Type (what) | CSI | comp.TAC.OUTPUT.CO2E.1_0 | Declared in SSSR |
| Signal Instance (which) | USO ID | 01JBF0W8S9Q0R1S2T3U4V5W6X | Created at runtime |
| Short Code (how we track) | ZAR Code | MIE12 | Derived from CMI |
| Chain (how it moved) | origin_chain | [MIE12, TG3K7] | Appended as it moves |
1.7. USO Type ↔ USO Instance relationship
USO Type (semantic class)
↓
referenced by
↓
USO Instance (runtime lineage record)
2. Conceptual Role in the ZAR Framework
| Role | Description |
|---|---|
| Semantic Origin Identifier | Every signal instance receives a USO Instance at birth, which uniquely references a USO Type, which defines its semantic class (e.g., emission estimate, financial transaction, or audit outcome). |
| Interpretive Context Provider | USO Type provides semantic classification used by interpretation layers (e.g., CSI, policy engines, AI models). |
| Cross-Domain Consistency Anchor | It allows ZSSR and the AI Intelligence Layer to understand equivalent concepts across systems — ensuring that “CO₂e Emission Estimate” or “Supplier Verification Signal” mean the same thing regardless of their source table or MICE module. |
| Auditable Origin Token | Each USO code persists across every transformation and can be referenced in the TrustGate telemetry to reconstruct a full data lineage for audit purposes (ESRS 1 § 81(c); ISO 14064-1 § 7.3). |
3. Structure of a USO Type (Semantic Classification)
Each USO Type is composed of three structural parts, designed for both human readability and machine traceability:
| Field | Description | Example |
|---|---|---|
| Domain | The semantic layer or category (e.g. emissions, finance, governance, social, risk) | emissions |
| Origin | The micro-engine, data stream, or ingestion point where the signal was first instantiated | invoicecrawler, sensorhub, inputgateway |
| Signal Class | The conceptual signal type — describing the nature of the data produced | estimated, validated, assured, derived |
The canonical naming format for USO Type structure is:
uso_type:<domain>.<origin>.<signal_class>@<version>
Example: uso_type: emissions.invoicecrawler.estimated@v1 describes a signal generated by the Invoice Crawler that estimates GHG emissions from invoices.
USO in the Signal Lineage Chain
| Stage | Identifier | Purpose |
|---|---|---|
| USO | uso_type: emissions.invoicecrawler.estimated@v1 | Defines what this signal represents semantically. |
| CSI | trustgate.decision.output.co2e_factor.v1_0_0 | Defines where it is stored or processed (component, kind, name). |
| CMI | MICE.AAE.Validator.Proof.1_0_0 | Defines which micro-engine or computation module processed it. |
Together, these three identifiers make each signal semantically complete — traceable by origin, type, and computational lineage.
USO Assignment Rules
| Step | Trigger | Action |
|---|---|---|
| 1. Signal Birth | A new data record or metric enters the system via ingestion, user input, or external API. | ZAYAZ mints a new uso_id for the signal instance and attaches the predefined uso_type classification. |
| 2. Context Propagation | The signal passes through one or more MICE engines. | The USO is copied forward unchanged; new CMI references are appended to the lineage tail. |
| 3. Output or Decision Stage | TrustGate, AAE, or the AI Intelligence Layer publishes a result. | The USO remains intact as part of the published metadata, enabling reverse lineage and causal inference. |
Example: Emission Estimate Lifecycle
| Phase | Example Signal | USO | CSI | CMI |
|---|---|---|---|---|
| Invoice read | Raw invoice data | uso:emissions.invoicecrawler.raw@v1 | trustgate.emissions.estimated.invoice.v1 | MICE.Parser.Invoice.1_0_0 |
| Emission factor match | Matched EF | uso:emissions.ef.lookup@v1 | trustgate.emissions.estimated.emission_factor.v1 | MICE.Mapper.Climatiq.1_0_0 |
| CO₂e computation | Derived estimate | uso:emissions.estimate.derived@v1 | trustgate.emissions.estimated.co2e.v1 | MICE.Calculator.CO2e.1_0_0 |
| Decision & assurance | TrustGate decision signal | uso:trust.decision.assurance@v1 | trustgate.decision.decision.v1 | MICE.AAE.Validator.Proof.1_0_0 |
USO and Smart Searchable Signal Registry (SSSR) Integration
Every SSSR signal is linked to a USO Type, defining its semantic class. At runtime, each produced signal instance is assigned a USO Instance ID, which references that USO Type.
This provides semantic unification across all stored data tables, regardless of physical schema.
| SSSR Field | Example |
|---|---|
| sssr_id | sssr:tg_emissions_estimated_co2e.value@COE-0013 |
| uso_name | uso_type: emissions.invoicecrawler.estimated@v1 |
| domain | trustgate.emissions.estimated |
| csi | trustgate.emissions.estimated.co2e.v1_0_0 |
Through this link, the system can automatically: Discover all signals of a certain semantic class (uso:emissions.*) Trace their processing lineage across MICE engines (the “tail”) Generate assurance evidence through AAE or the AI Intelligence Layer using semantic-level reasoning.
Role in Governance and Audit The USO serves as a semantic fingerprint for compliance traceability: Enables auditors to verify semantic consistency across disclosures and data sources. Provides input for the AI Intelligence Layer’s causal reasoning models, identifying how upstream data types influence ESG outcomes. Supports EAA/GSL governance layers by ensuring each approval corresponds to a defined semantic signal class.
Summary
[Raw Invoice Data]
↓ (USO: emissions.invoicecrawler.raw@v1)
[Invoice Crawler → EF Match → CO₂e Calculation]
↓ (USO propagated)
[TrustGate Decision + AAE Assurance]
↓
[ETN Disclosure]
↓
[Auditor Verification]
(Lineage: USO + CSI + CMI chain = full semantic + computational trace)
What Data Does the USO Contain?
The USO is a stable identifier for the instance lineage record, with its “tail” stored separately as metadata (origin_chain / origin_chain_codes).
Each signal instance gets a USO ID (ULID/UUIDv7 style).
- The “tail” (movement through the system) is tracked in:
- origin_chain (full CMI path)
- origin_chain_codes (short ZAR codes, compact)
- The uso_id itself never changes — it stays constant from birth to end-of-life.
| Concept | Mutable? | Example | Notes |
|---|---|---|---|
| uso_id | ❌ No | 01JBF0W8S9Q0R1S2T3U4V5W6X | The lineage identity of this signal instance. |
| origin_chain | ✅ Yes (grows) | [DSAIL.OCR.Engine.1_2_0, MICE.InvoiceEmissions.Engine.1_1_0, DAVE.TrustGate.Engine.1_0_0] | The audit trail. |
| origin_chain_codes | ✅ Yes (grows, short form) | [DSA9Q, MIE12, TG3K7] | Compact ZAR code tail for routing. |
Think of it as: USO ID = the “passport number” Origin chain = the stamps inside the passport