Knowledge base · 04-carbon-as-trust-infrastructure

04 - Carbon as trust infrastructure

Status. Draft v0.1 · First draft: 17-03-2026 · Pre-discussion.

Why this matters. Up to this point, the knowledge base has covered what carbon accounting is (docs 01–02) and what regulations exist around it (03, 03a). This is enough to understand the world the platform operates in, but not enough to understand why a platform exists at all. Many people, reading docs 01–03, ask a reasonable question: “Couldn’t a spreadsheet, an ERP module, or a careful consultant produce these numbers?” The answer is no, and this doc is the explanation of why not. A carbon number is not a number. It is a trust claim - and a trust claim requires seven specific properties before it can carry weight outside the organisation that made it. Spreadsheets, ERP modules, and consultants cannot deliver all seven simultaneously. A platform like SIDK can. This doc names those seven properties and treats them as the load-bearing requirements list every subsequent architecture choice answers to.

If you read only one section in the knowledge base after the carbon-and-regulations background, read this one.

1. The framing

A carbon number written on a piece of paper, in isolation, is not useful. To be useful - to be cited, surrendered, sold against, or relied on by a third party - it must carry seven properties. Drop any one of them and the number degrades from evidence to assertion. Drop two and it becomes marketing.

The seven properties are not a wish-list. Each one is the answer to a specific kind of question a careful reader (buyer, regulator, verifier, competitor) will ask of the claim. Each one has a failure mode that materialises when it is absent. And each one is hard to deliver alone - which is why the platform has the shape it has.

The properties fall into three groups by function:

Prerequisites - what the number must be computed against. Without these, the number is unanchored. (Properties 1, 2.)
Engineering discipline - how the number must be produced. Without these, the number is irreproducible. (Properties 3, 4, 5.)
Output-side trust - what the number must be capable of, once produced. Without these, the number cannot leave the organisation. (Properties 6, 7.)

The properties are largely orthogonal. A claim can fail any one of them while passing the other six, and a careful reader will catch that single failure.

2. The prerequisites

Property 1 - Computed under a stated boundary

What it means. Every carbon number is the answer to a specific question - for this subject, under this boundary, including these emission sources, with this Scope 2 method, in this geography, valid as of this date. The boundary descriptor is part of the number; without it, the number is meaningless. “2,005 kg CO₂ per tonne of slab” is incomplete; “2,005 kg CO₂ per tonne of slab, gate-to-gate at BF-1+BOF-1, Scope 1 only, India geography, 2026 reporting period” is a claim.

Why it’s required. Different regimes ask for different boundaries from the same physical reality. CBAM wants the CBAM production process boundary, with its own precursor rules. EN 15804 EPDs want A1–A3. CSRD wants Scope 1+2+3 at the corporate level. Indian CCTS wants intensity per unit product at the installation level. The same Lot under different boundaries gives different - and all defensible - numbers.

Where it’s realised in the platform. The Carbon Engine treats boundary as a first-class input. Every CalculationResult carries its full boundary descriptor: kind, scope2Method, scope3Inclusion, geography, reportingDate. Two calculations of the same subject under different boundaries are two distinct CalculationResults, both retained, both queryable. The boundary vocabulary itself (cradle-to-gate, cradle-to-grave, cradle-to-cradle, EN 15804 modules, CBAM production process) is covered in 02a - Boundaries; how the engine implements it is in 06 §5.

Failure mode prevented. Without an explicit boundary, two carbon claims that disagree by a factor of three can both be correct - they’re answering different questions. A buyer comparing them concludes one of them is dishonest. A verifier rejects the claim that doesn’t state its boundary. A regulator throws out the filing.

Property 2 - Traceable to source data

What it means. Every number in the carbon claim must be walkable backward - through the calculations that produced it, through the inputs that fed those calculations, through the sensor readings, lab results, ERP transactions, and supplier declarations that originated those inputs, to the physical reality at the leaves of the chain. Every link in the chain is independently verifiable.

Why it’s required. A verifier’s job under ISO 14064-3 is to test the assertion against the underlying evidence. A regulator’s audit is the same test conducted later. A buyer asking “where does this number come from?” is asking the same question informally. Without traceability, the verifier has nothing to test, the regulator has nothing to audit, and the buyer has nothing to trust.

Where it’s realised in the platform. The Carbon Engine’s lot-lineage walk traverses the PRODUCED_BY and CONSUMED_BY edges of the lot-lineage DAG, attaching every emission to the specific TransformationEvent, the specific input Lots, and the specific Variable readings that produced it. The append-only audit chain (one of SIDK’s seven primitives) hash-anchors every state-changing operation, so any modification to history invalidates the chain. The edge agent assigns deterministic IDs to every captured point so the journey from sensor to claim is reconstructable end-to-end. See 06 §7 and 07 §2.

Failure mode prevented. A claim with no traceable lineage is a self-attestation. The producer is asking the reader to take its word for it. This is exactly the trust gap that turns “carbon number” into “marketing claim” in the popular imagination - and it is the gap binding regulations like CBAM exist to close. A platform without per-Lot lineage cannot serve CBAM, cannot serve a CSRD-compliant Scope 3, and cannot serve a sophisticated buyer.

3. The engineering discipline

Property 3 - Reproducible under pinned methods and factors

What it means. A verifier or regulator, given the same inputs the producer had, must be able to independently re-run the calculation and reach the same number. Not “approximately the same”; not “the same up to rounding”; the same. This requires that the engine itself be deterministic, and that every input that affected the number - the engine binary version, the per-method rule version, the factor values in force at calculation time - be pinned to the result.

Why it’s required. Reproducibility is what makes a calculation an experiment rather than an opinion. An opinion is the producer’s view of the world; an experiment is a procedure the producer claims will yield the same answer when anyone runs it. Regulators do not accept opinions. Verifiers do not attest to opinions. The audit standard for greenhouse gas claims (ISO 14064-3) builds re-performance into its required verification procedures.

Where it’s realised in the platform. Every CalculationResult carries a calculationVersionId (which engine binary ran it) and methodVersionIds[] (the rule version of each method actually used). When a ReportingPeriod is LOCKED, the LockedSnapshot pins both, plus all factorIdsUsed with their effective versions at lock time. The engine is replay-ready: given a LockedSnapshot ID and the original engine + method versions, it reconstructs the calculation and the result should match the snapshot byte-for-byte. Mismatches are alerts, not silent corrections. See 06 §11.

Failure mode prevented. A claim that the verifier cannot reproduce is a claim the verifier cannot attest to. If the engine produced different numbers on Tuesday than on Wednesday for the same inputs, the entire audit chain falls apart. Worse, an undetectable lack of reproducibility - caused by silent factor updates, undeclared engine changes, or hidden state - corrupts historical claims without anyone knowing. Pinning is the discipline that makes the corruption impossible.

Property 4 - Accompanied by uncertainty and evidence quality

What it means. The number is not enough; the number plus how confident we are in it is what counts. A 2,000 kgCO₂/t coil computed from a continuously-measured CEMS with calibrated coverage is qualitatively different evidence from the same number computed from a default emission factor applied to an ERP-derived fuel quantity. Both are valid; they sit at different tiers of measurement confidence. The claim must surface this difference explicitly - both as a numeric uncertainty band (±7.2% standard, k=1) and as a structured evidence breakdown (30% Tier 4 continuous, 32% Tier 3 periodic, 20% Tier 2 declared, 8% Tier 1 default, 10% substituted).

Why it’s required. Without uncertainty, a number is presented as if it were exact, which it isn’t. Without evidence quality, two numbers that look identical can have wildly different underlying rigour. The most sophisticated current buyers and verifiers - and CBAM’s verification expectations, and ISO 14064-3 - assume both will be present. A platform that hides them produces claims that look comparable when they aren’t, and look certain when they shouldn’t.

Where it’s realised in the platform. The Carbon Engine propagates uncertainty through every calculation - analytically via GUM first-order for multiplicative chains, via Monte Carlo Latin Hypercube Sampling for mass balance (where subtraction of close magnitudes breaks the analytical assumption). For Methods 1 and 2, Monte Carlo also runs as parallel validation on every locked-period calculation; divergence raises a finding. The five-tier evidence model (Tier 4 continuous through Substituted) is aggregated per CalculationResult and exposed in the result’s evidenceBreakdown. Coverage factor is explicit (k=1 / k=2 / k=3) so output labels are never ambiguous. See 06 §8, §10.

Failure mode prevented. A claim with no uncertainty band is over-asserted. A buyer making a procurement decision on “1,800 vs 2,000 kgCO₂/t” between two suppliers, where both numbers have a ±15% band that fully overlaps, is making a non-decision dressed up as a decision. A regulator auditing a “1,500 kgCO₂/t” claim where 90% of the evidence is Tier 1 default cannot distinguish a well-measured low-carbon producer from a heavily-defaulted producer. Hiding uncertainty and evidence quality is the platform analogue of false precision; surfacing them is the discipline that lets sophisticated buyers and regulators act intelligently.

Property 5 - Governed by approvals and restatements

What it means. No carbon number is final the moment it is computed. Inputs are corrected. Late lab results arrive. Factor versions are superseded. Methodology evolves. A serious carbon system has to accommodate this without losing the audit trail. Every state-changing operation - a factor override, a period restatement, a manual data entry - must be a deliberate, dual-actor-approved, recorded action. Maker proposes; Checker independently approves; both identities are in the audit chain; the change is visible to any later verifier.

Why it’s required. Two reasons. First, change is inevitable - refusing to allow restatement means the system locks itself into early errors, which is worse than admitting they happened. Second, unilateral change is corruption - letting any one actor silently modify a locked carbon number is the trust hole every accreditation framework is designed to close. The discipline of dual-actor approval with audited restatement is what separates an accounting system from an editable database. CBAM, EU ETS, ISO 14064-3 and SOX all require it.

Where it’s realised in the platform. Every state change in SIDK runs through a Submission with a Maker and a Checker who must be different actors. The Submission catalogue covers every state-changing operation: factor overrides, period restatements, monthly closes, passport issuances, passport revocations, mapping revisions, engineer assignments, signing key rotations, verifier engagements. Restatement creates a new LockedSnapshot with parentSnapshotId pointing to the original; both remain queryable forever; the diff endpoint shows what changed. The append-only audit chain hash-anchors every event. See 06 §11–12 and 08b §5 (Principle 3).

Failure mode prevented. A platform without dual-actor enforcement is a platform whose state can be unilaterally manipulated - by a malicious actor, by a well-intentioned one in a hurry, by a script with too much scope. A platform without audited restatement is one whose history is editable, which is the same thing as one with no history. Both failure modes turn the entire audit chain into theatre. The discipline is unglamorous and load-bearing.

4. Output-side trust

Property 6 - Renderable into different regimes

What it means. A single underlying inventory must be projectable into multiple regime-specific views - a CBAM Communication, a CSRD ESRS E1 disclosure, an EN 15804 EPD, a CDP questionnaire, an Indian CCTS submission, an ISSB IFRS S2 statement - from the same underlying data, without recomputation. The producer maintains one canonical truth; the platform produces many regime projections.

Why it’s required. Regimes proliferate. A global steel producer in 2026 faces five to seven simultaneously. Maintaining a separate carbon inventory per regime is a recipe for inconsistency: the producer’s CBAM number does not match its CSRD number, the verifier cannot reconcile them, the buyer notices, and the regulator opens a file. The producer needs to be able to point at one underlying calculation and say “and here is how it renders under each regime.”

Where it’s realised in the platform. The Carbon Engine treats boundary, indicator, and reporting-period as orthogonal inputs to the same calculation. The same underlying CalculationResults serve a CBAM_PRODUCTION_PROCESS boundary and a CRADLE_TO_GATE_LOCATION boundary; the engine always computes both location-based and market-based Scope 2 so neither needs recomputation; the indicator dimension (v1: GHG_GWP; future: water, biodiversity, land use) is schema-ready. Per-regime allocation defaults (GHG Product Standard vs CBAM vs EN 15804) are respected automatically based on the boundary kind. See 06 §5–6.

Failure mode prevented. A producer with a different carbon answer in every disclosure is a producer the market does not trust. Inconsistency across regimes is one of the easier red flags for a sceptical buyer or auditor; it is also one of the easier ways for a regulator to assert under-declaration. A platform that cannot render one canonical inventory into many regime views forces its users into exactly this trap.

Property 7 - Attestable by an independent verifier

What it means. A producer’s claim, however carefully made, is a self-attestation. It acquires external standing only when an independent accredited verifier - accredited by a recognised national body under ISO 14065 - has reviewed the evidence chain, raised challenges, and issued a signed VerificationStatement attesting to one of a small set of outcomes (UNQUALIFIED, QUALIFIED, ADVERSE, DISCLAIMED). The verifier’s accreditation is publicly checkable. The verifier’s signature is cryptographic and independently verifiable. The verifier’s independence from the producer is structural, not contractual.

Why it’s required. Every binding regime in the world today (CBAM, EU ETS, CSRD, SB 253, ISSB-adopting jurisdictions, India CCTS, EPD systems under EN 15804) requires independent third-party verification or assurance. The reason is the trust gap from Property 2: the producer’s word, however honest, has no standing across organisational boundaries. The verifier closes the gap.

Where it’s realised in the platform. SIDK runs the verifier registry, the accreditation chain governance, and the cryptographic anchoring (the DID infrastructure for Tenants, the JWK Set for Verifiers, the JWKS for platform delivery signatures). The Verifier Workspace application - see 08b §2 - gives the verifier the audit chain to walk, the finding queue to file challenges, and the statement-authoring surface to issue the VerificationStatement. The three-signature trust chain - Tenant signs claim, Verifier signs attestation, platform signs delivery - composes the result client-side, offline, on a buyer’s phone, with no party able to compromise the chain alone. The structural separation between the platform’s operator and any product owner is what makes the verifier registry credibly neutral, which is what makes the attestation credible. See 08b §4 for the full worked example of the trust chain composing for a buyer.

Failure mode prevented. Without independent attestation, the producer is asking the world to trust them. This works in low-stakes settings (a sustainability report nobody reads) and fails in high-stakes ones (a CBAM declaration with real money on the line; a buyer paying a green-steel premium and needing to defend the spend; a regulator opening an audit). The verifier is the institution that turns a producer’s claim into a claim with external weight, and the platform’s role is to give the verifier a defensible, walkable evidence chain rather than a spreadsheet to argue with.

5. The interactions between the properties

The seven properties are largely orthogonal - each addresses a distinct failure mode - but they are not independent. Some properties enable others; some require others as prerequisites:

Properties 1 and 2 enable Property 3. Reproducibility (3) is meaningless without a stated boundary (1) and traceable inputs (2). You can only reproduce a calculation if you know what it was computed against.
Properties 3, 4, and 5 enable Property 7. A verifier (7) cannot attest to a calculation they cannot reproduce (3), cannot interpret the confidence of (4), or that lacks a tamper-evident audit chain (5). Verifier scrutiny is what forces the engineering discipline; the platform’s job is to make the discipline cheap enough that producers actually adopt it.
Properties 1, 2, 3, and 5 enable Property 6. Multi-regime rendering (6) only works if the underlying calculation is properly bounded, traceable, reproducible, and governed. Otherwise the “render” is just a re-statement that diverges silently.
Property 7 is the load-bearing output-side trust. Properties 1–6 produce evidence; Property 7 turns evidence into a signed third-party attestation that buyers and regulators can act on.

A platform that delivers properties 1, 2, 3, 4, 5, and 6 but not 7 has produced a meticulously-engineered self-attestation. Useful internally; commercially significant; insufficient externally. A platform that delivers 7 alone - verification on top of an unbounded, untraceable, irreproducible spreadsheet - is the dominant pre-platform world, and it scales badly because the verifier’s time is the bottleneck.

The seven together are the platform claim. Each one is hard to deliver in isolation. Delivering all seven simultaneously, at scale, across multiple regimes, repeatedly month after month, is what justifies a platform over a series of spreadsheets, ERPs, and consultancies.

6. Why this argument is the bridge to the architecture

Up to this point the knowledge base has been world-shaped: what carbon is, what regulations exist, what the practical challenges look like. From this doc onward, the knowledge base becomes platform-shaped: how SIDK is structured, how the Carbon Engine works, how inputs flow, how the trust chain composes. The bridge between the two is exactly this: the seven properties are the requirements list every architectural choice answers to.

When 05 - SIDK explains the seven primitives, each primitive lands as a specific commitment against one or more of the seven properties. When 06 - The Carbon Engine explains the four-method dispatch, the mass-balance treatment, the dual Scope 2, the shadow-calc, the locked-snapshot discipline - every choice is in service of Properties 1, 3, 4, 5, or 6. When the trust-chain section explains why the platform has three signatures rather than one, that’s Property 7’s mechanism.

Read backward, the platform is large and the architecture has many moving parts. Read forward through the seven properties, every part is doing recognisable work.

That is the whole point of stating them as a set.

7. A consequence worth naming explicitly - these are also the requirements for trustworthy AI on industrial data

The seven properties were derived from what a carbon claim needs to be defensible. They turn out to describe, almost without modification, what AI outputs on industrial data need to be defensible. Both are derived assertions about physical reality that someone other than the producer needs to act on; both require the same substrate properties to be auditable; both fail catastrophically when even one property is missing.

This is not a coincidence and not a stretch. AI built on top of a substrate that satisfies the seven properties reads canonical, traceable, evidence-tiered, boundary-explicit, version-pinned, governance-bound, verifier-walkable data. Every output the AI generates can be drilled into back to a specific sensor reading, a specific lab result, a specific Maker-Checker approval. The AI’s recommendation remains non-canonical (it does not mutate the substrate’s state - that is enforced architecturally; see Foundation §4.8), but the evidence the recommendation reads from is canonical. The user can ask “show me the data this is based on” and get a verifiable, auditable answer.

This is qualitatively different from generic AI tools that pattern-match against spreadsheets, ERP exports, or operational historians - tools that read inputs of unknown provenance and produce outputs of unverifiable quality. The same prompt against bad inputs produces vivid, confidently-wrong output. The same prompt against substrate-anchored inputs produces output that can be interrogated and defended. For industrial users in regulated or competitive contexts, only the second category of AI is usable.

The argument is treated at length in 05 - SIDK §8. It is named here because the seven properties are where the case actually starts: they are the requirements list, and AI usability is one of the consequences that falls out when the requirements are met properly. Anyone arguing for why the substrate matters - to investors, partners, or technical audiences - has the seven properties as the foundation and the AI-substrate consequence as one of the strongest downstream payoffs.

References & further reading

Source spec (canonical)

Docs/GREMI-App-Ecosystem/foundation-v1.4.md - Foundation document, especially §4 (Architectural principles) and §5 (Trust chain). The seven properties in this doc are a re-shaped reading of Foundation’s principles, organised around the function each property serves rather than around the architectural mechanism that delivers it.
Docs/05-carbon-engine.md - Carbon Engine Spec. The realisation layer for Properties 1, 3, 4, 5, and the boundary mechanics of 6.
Docs/SIDK Handoff Docs/architecture.md - the seven primitives that compose SIDK’s architecture; each primitive maps to one or more of the seven properties in this doc.

External authoritative sources

ISO 14064-3:2019 - Greenhouse gases - Part 3: Specification with guidance for the verification and validation of greenhouse gas statements. The procedural standard that defines what a verifier is testing for. The requirements in 14064-3 effectively enumerate properties 2, 3, 4, and 5 as the things a verifier expects to find. https://www.iso.org/standard/66455.html
ISO 14065:2020 - General principles and requirements for bodies validating and verifying environmental information. The accreditation standard for verifier bodies - the upstream of Property 7. https://www.iso.org/standard/74257.html
GHG Protocol - Corporate Accounting and Reporting Standard (revised 2004). The framework that established the Scope 1/2/3 partition that Property 1 (stated boundary) is the operationalisation of. https://ghgprotocol.org/corporate-standard
JCGM 100:2008 - Evaluation of measurement data - Guide to the expression of uncertainty in measurement (GUM). The international framework for combining measurement uncertainties - the rigorous backbone of Property 4. https://www.bipm.org/en/committees/jc/jcgm/publications
NIST Special Publication 800-92 - Guide to Computer Security Log Management. Out-of-domain but conceptually identical: the security-engineering literature on tamper-evident audit logs is the same discipline as Property 5. Useful when explaining “why is the audit chain hash-anchored” to engineering-shaped stakeholders. https://csrc.nist.gov/pubs/sp/800/92/final
W3C Verifiable Credentials Data Model. The cryptographic standard underneath Property 7’s “three-signature, independently-verifiable” chain. https://www.w3.org/TR/vc-data-model-2.0/
European Accreditation - The EU CBAM and the role of accreditation. The clearest explainer of how accreditation, attestation, and the verifier-registry interact in a real regulatory regime - Property 7 made concrete. https://european-accreditation.org/the-eu-cbam-and-the-role-of-accreditation/