# What is a Single Source of Truth (SSOT)?

# What is a Single Source of Truth (SSOT)?

<div class="callout callout-info" id="bkmrk-definition%3A-a-single">**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.

</div>## 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:

1. **Input records:** Evidence of each product application event (batch production records, delivery confirmations, IoT sensor readings, GPS coordinates of deployment)
2. **Baseline data:** The counterfactual reference data, with source documentation and version history
3. **Calculation engine outputs:** The intermediate steps in converting input records to SUI magnitudes (the Digital Twin layer)
4. **Outcome data:** Third-party measurement results (lab analyses, satellite observations, auditor field reports)
5. **Aggregated SUI ledger:** A time-series of verified SUI events, each linked back to its source input record and outcome measurement
6. **Version history:** All changes to the above, with timestamps and the identity of who made each change

## SSOT vs. Data Warehouse vs. ERP

<table id="bkmrk-system-typepurposeau"><thead><tr><th>System Type</th><th>Purpose</th><th>Audit-Ready?</th><th>Role in SUI Pipeline</th></tr></thead><tbody><tr><td>ERP (SAP, Odoo, QuickBooks)</td><td>Business operations records</td><td>Partially</td><td>Source of input data (production, sales)</td></tr><tr><td>Data Warehouse (Snowflake, BigQuery)</td><td>Analytics and reporting</td><td>No (mutable)</td><td>Intermediate processing layer</td></tr><tr><td>BI Tool (Tableau, Metabase)</td><td>Visualisation</td><td>No</td><td>Output layer for stakeholder dashboards</td></tr><tr><td>**SSOT (SUI Architecture)**</td><td>**Impact claim verification**</td><td>**Yes (immutable audit trail)**</td><td>**Canonical record of all SUI events**</td></tr></tbody></table>

## 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:

<table id="bkmrk-levelnamedescription"><thead><tr><th>Level</th><th>Name</th><th>Description</th><th>Typical Stage</th></tr></thead><tbody><tr><td>0</td><td>Fragmented</td><td>Data in multiple disconnected tools; no single version of truth</td><td>Pre-seed, &lt; 12 months</td></tr><tr><td>1</td><td>Consolidated</td><td>Data centralised in one tool (even a well-structured spreadsheet); no automation</td><td>Seed, pilot phase</td></tr><tr><td>2</td><td>Automated</td><td>Data flows automatically from source systems to a central repository; version control in place</td><td>Series A, growth phase</td></tr><tr><td>3</td><td>Audit-Ready</td><td>Full immutability, access control, traceability, and structured export; third-party verified</td><td>Series B+, pre-MDB engagement</td></tr></tbody></table>

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](#bkmrk-next%3A-the-three-tier) — how data flows from raw inputs to verified SUI events.*