# Module 3: Building Your SSOT

# Module 3: Building Your SSOT

<div class="callout callout-info" id="bkmrk-module-overview%3A-the">**Module Overview:** The SSOT is the infrastructure that makes SUI verification possible. This module guides you through assessing your current data architecture, designing a minimum viable SSOT, and planning the path to audit-readiness. Allow 2–3 hours.

</div>## Learning Objectives

By the end of this module, you will have:

1. Assessed your current SSOT maturity (Level 0–3)
2. Mapped all data sources relevant to your SUI
3. Designed a minimum viable SSOT architecture for your company
4. Written your data governance policy (who can write, read, export)
5. Identified the tools and resources needed to reach SSOT Level 2

## 3.1 The SSOT Maturity Self-Assessment

Answer these questions honestly. The goal is to find your current state — not to impress anyone.

### Level 0 Indicators (Fragmented)

- \[ \] Impact data lives in multiple spreadsheets maintained by different team members
- \[ \] There is no single place where someone new to the team could find all the data behind your impact claims
- \[ \] Different presentations use different numbers for the same metric
- \[ \] You could not produce a complete history of your impact events from the last 12 months in one hour

### Level 1 Indicators (Consolidated)

- \[ \] All impact data is in one central place (even a single well-maintained spreadsheet)
- \[ \] The data is dated — you know when each entry was added
- \[ \] Access is controlled — not everyone can edit the master file
- \[ \] A new team member could find and understand the data without a guided tour

### Level 2 Indicators (Automated)

- \[ \] Data flows automatically from source systems (ERP, IoT, CRM) to the central repository
- \[ \] Manual data entry is minimised or eliminated
- \[ \] Changes are logged with timestamps and the identity of who made them
- \[ \] Errors create a correction record, not an overwrite of the original

### Level 3 Indicators (Audit-Ready)

- \[ \] Records are cryptographically immutable once verified
- \[ \] Role-based access control with access logging in place
- \[ \] Verifiers can access underlying data directly without company staff assistance
- \[ \] Structured export in verifier-specified format is automated
- \[ \] SOC 2 or equivalent security certification in progress

## 3.2 Data Source Mapping

For every data element in your SUI calculation, identify:

<table id="bkmrk-data-elementcurrent-"><thead><tr><th>Data Element</th><th>Current Location</th><th>Update Frequency</th><th>Owner</th><th>Gap to SSOT</th></tr></thead><tbody><tr><td>Application event record (count)</td><td>\[e.g., Sales ERP, manual CSV\]</td><td>\[daily/monthly\]</td><td>\[Sales team\]</td><td>\[needs automated export\]</td></tr><tr><td>Outcome measurement (observed value)</td><td>\[e.g., Lab report PDFs in Dropbox\]</td><td>\[per batch\]</td><td>\[R&amp;D team\]</td><td>\[needs ingestion system\]</td></tr><tr><td>Baseline value</td><td>\[e.g., Static value in spreadsheet\]</td><td>\[annual\]</td><td>\[Impact lead\]</td><td>\[needs version control\]</td></tr><tr><td>Conversion factors (emission factors)</td><td>\[e.g., Hardcoded in Excel model\]</td><td>\[annual IPCC update\]</td><td>\[Impact lead\]</td><td>\[needs versioning and update trigger\]</td></tr></tbody></table>

Complete this table for every data element. Gaps represent your SSOT development roadmap.

## 3.3 Minimum Viable SSOT Design

For most CTH portfolio startups at seed or Series A stage, the minimum viable SSOT has four components:

### Component 1: The Central Repository

Choose one of the following, based on your technical capacity:

<table id="bkmrk-optiontechnical-leve"><thead><tr><th>Option</th><th>Technical Level</th><th>SSOT Level Achievable</th><th>Annual Cost</th></tr></thead><tbody><tr><td>Google Sheets (structured, access-controlled)</td><td>Low</td><td>Level 1</td><td>$0 (Workspace included)</td></tr><tr><td>Airtable or Notion database</td><td>Low-Medium</td><td>Level 1–2</td><td>$10–$50/month</td></tr><tr><td>PostgreSQL (self-hosted or Supabase)</td><td>Medium</td><td>Level 2–3</td><td>$25–$100/month</td></tr><tr><td>Dedicated impact data platform (Proof of Impact, Persefoni, Greenly)</td><td>Low (managed)</td><td>Level 2–3</td><td>$500–$5,000/month</td></tr></tbody></table>

**CTH recommendation:** Start with Airtable or a structured Google Sheet at Level 1. Build the data governance discipline before investing in technology. Most startups over-invest in tooling before establishing the human processes that make any tool work. Plan the path to PostgreSQL or equivalent at Series A.

### Component 2: The Ingest Protocol

Define how data gets from each source system into the central repository:

- For each source system, specify: who extracts the data, in what format, at what frequency, and how they upload it to the central repository
- For automated sources (IoT, API): define the integration (webhook, API pull, ETL pipeline)
- Include a validation step: what checks run when data is ingested to catch errors before they enter the record

### Component 3: The Change Log

The most important single addition to any existing data system. Implement a simple rule: **no record is ever overwritten**. Corrections are new records with a reference to the original. Every change carries a timestamp and the identifier of who made it. This can be implemented in Google Sheets with a formula-protected "corrections" tab — no engineering required.

### Component 4: The Access Control Matrix

Document who has what access to the SSOT:

<table id="bkmrk-roleaccess-typewhat-"><thead><tr><th>Role</th><th>Access Type</th><th>What They Can See/Do</th></tr></thead><tbody><tr><td>Impact Lead</td><td>Write</td><td>Add new records, update baseline values (with change log entry)</td></tr><tr><td>CEO / CFO</td><td>Read</td><td>All aggregated data; no write access to underlying records</td></tr><tr><td>Board / Investors</td><td>Read (aggregated)</td><td>Impact dashboard; not raw records</td></tr><tr><td>Third-party Verifier</td><td>Read (full, time-limited)</td><td>All records including raw data, during audit window only</td></tr><tr><td>External (public)</td><td>None</td><td>No access to SSOT</td></tr></tbody></table>

## 3.4 The Digital Twin: Your Minimum Viable Version

Your Digital Twin does not need to be sophisticated at this stage. A minimum viable Digital Twin is a version-controlled calculation model with documented inputs. Here is a 5-step protocol:

1. **Create a dedicated calculation file** (Excel or Python notebook) that contains only your SUI calculation — not mixed with financial models or operational data
2. **Document every input cell** with a comment or adjacent cell containing: value source, source URL, year, geographic scope
3. **Version control it:** Save as "SUI\_Model\_v1.0\_\[date\].xlsx" each time you make a material change. Store all versions (never delete old versions)
4. **Lock the formula cells:** Only the input cells should be editable; calculation cells are password-protected
5. **Run a sensitivity analysis:** Identify which inputs have the largest impact on the SUI magnitude; document which ones you monitor most closely

## 3.5 Module 3 Deliverable

Produce a 2-page SSOT Architecture Document containing:

- Current maturity level (with evidence for each indicator checked)
- Data source map (completed table from section 3.2)
- Central repository choice and rationale
- Ingest protocol (one paragraph per data source)
- Access control matrix
- Target maturity level and timeline (with resource requirements)

Submit to CTH with your SUI Specification Document for joint review.

---

*Next: [Module 4: Connecting Impact to Finance](#bkmrk-next%3A-module-4%3A-conn) — translating your verified SUI into investor conversations.*