What is a Single Source of Truth (SSOT)?
What is a Single Source of Truth (SSOT)?
Definition: A Single Source of Truth (SSOT) is a system of record in which every piece of data relevant to an enterprise's impact claims exists in exactly one canonical location — structured, timestamped, access-controlled, and audit-ready — such that any authorised party can independently verify the enterprise's SUI claims without relying on summaries prepared by the enterprise itself.
Why "Single Source"?
Most early-stage companies manage their data across a fragmented set of tools: spreadsheets emailed between team members, production records in an ERP system, customer data in a CRM, lab results in PDFs stored in Dropbox, and impact metrics calculated in a separate Excel model. Each of these is a source of data — but none is authoritative. When an investor asks "show me how you calculated 102.4 kg CO₂e per hectare," the answer cannot be found in any single place.
An SSOT eliminates this fragmentation. It does not necessarily mean one database — it means one canonical layer through which all relevant data flows, where every claim is traceable to its source, and where the chain of custody is documented.
What the SSOT Must Contain
For SUI verification purposes, the SSOT must hold:
- Input records: Evidence of each product application event (batch production records, delivery confirmations, IoT sensor readings, GPS coordinates of deployment)
- Baseline data: The counterfactual reference data, with source documentation and version history
- Calculation engine outputs: The intermediate steps in converting input records to SUI magnitudes (the Digital Twin layer)
- Outcome data: Third-party measurement results (lab analyses, satellite observations, auditor field reports)
- Aggregated SUI ledger: A time-series of verified SUI events, each linked back to its source input record and outcome measurement
- Version history: All changes to the above, with timestamps and the identity of who made each change
SSOT vs. Data Warehouse vs. ERP
| System Type | Purpose | Audit-Ready? | Role in SUI Pipeline |
|---|---|---|---|
| ERP (SAP, Odoo, QuickBooks) | Business operations records | Partially | Source of input data (production, sales) |
| Data Warehouse (Snowflake, BigQuery) | Analytics and reporting | No (mutable) | Intermediate processing layer |
| BI Tool (Tableau, Metabase) | Visualisation | No | Output layer for stakeholder dashboards |
| SSOT (SUI Architecture) | Impact claim verification | Yes (immutable audit trail) | Canonical record of all SUI events |
The Four Properties of a SUI-Grade SSOT
Property 1: Immutability
Once a SUI event is recorded and verified, it cannot be modified without creating a new, linked record that documents the correction. This is achieved through append-only data structures, cryptographic hashing of records, or blockchain anchoring (for the highest assurance levels). The principle: you can correct errors, but the original record and the correction are both permanently visible.
Property 2: Traceability
Every SUI magnitude in the impact ledger must be traceable back to its source input records. A verifier must be able to ask: "Show me the raw data behind SUI event #4,721" and receive a complete chain: batch record → production quantity → application event → calculation log → outcome measurement → verified SUI value.
Property 3: Access Control with Audit Logging
The SSOT must implement role-based access control: company staff can write new records; investors can read aggregated data; independent verifiers can access underlying records during audit windows. Every access event is logged — who accessed what, when, and what they downloaded.
Property 4: Structured for External Consumption
The SSOT must be able to produce a standardised data export in a format specified by the relevant verification standard (e.g., ISAE 3000, ISO 14064-3, or the auditor's own format). This is not a spreadsheet dump — it is a structured, machine-readable dataset that maps to the SUI parameter specification.
SSOT Maturity Levels
Not every startup needs a full enterprise SSOT from day one. CTH recognises four maturity levels:
| Level | Name | Description | Typical Stage |
|---|---|---|---|
| 0 | Fragmented | Data in multiple disconnected tools; no single version of truth | Pre-seed, < 12 months |
| 1 | Consolidated | Data centralised in one tool (even a well-structured spreadsheet); no automation | Seed, pilot phase |
| 2 | Automated | Data flows automatically from source systems to a central repository; version control in place | Series A, growth phase |
| 3 | Audit-Ready | Full immutability, access control, traceability, and structured export; third-party verified | Series B+, pre-MDB engagement |
A startup at SSOT Level 1 can still define and communicate a SUI — the specification document is the foundation. Verification becomes possible at Level 2 and full financial instrument eligibility at Level 3.
Next: The Three-Tier Validation Pipeline — how data flows from raw inputs to verified SUI events.
No hay comentarios para mostrar
No hay comentarios para mostrar