Private briefing
GREMI
Stakeholder briefing · v1.0 · 17 March 2026

Industrial carbon, made measurable and trustworthy across organisational boundaries.

A briefing on SIDK - a vertical-agnostic industrial data kernel built by Sphuran over six years - and on GREMI, the carbon-platform product Grevoro is building on top of it.

Scroll to begin
I. The problem

The world has decided that industrial carbon must be counted, attested, and trusted across organisational boundaries.

Embodied carbon in steel, cement, aluminium, and chemicals is now a customs gate, a board-disclosure obligation, a supply-chain price signal. The voluntary era ended quietly between 2023 and 2026.

Making a tonne of steel emits roughly 2.18 tCO₂-equivalent on the industry average, with a tenfold spread across production routes - BF-BOF integrated mills run around 2.0–2.3, scrap-EAF as low as 0.3, hydrogen-DRI on clean electricity approaching zero. The carbon answer is a property of how the steel was made, not of what it is. The technical difficulty of measuring it honestly is what makes industrial carbon accounting a platform problem rather than a spreadsheet problem.

The regulatory shoe has dropped. The EU's Carbon Border Adjustment Mechanism entered its definitive period on 1 January 2026; the first annual declaration is due 30 September 2027, with verifier-attested embedded emissions, certificate purchases, and surrender obligations behind it. The EU's Corporate Sustainability Reporting Directive requires Scope 1, 2, and 3 disclosure with limited assurance, beginning to bite this reporting cycle. The ISSB IFRS S2 standard is now mandatory in 21+ jurisdictions including Hong Kong, Chile, Mexico, and Pakistan. California's SB 253 demands Scope 1+2 by August 2026 and Scope 3 from 2027. India's CCTS covers iron & steel as one of nine notified sectors, with first carbon-credit trading expected mid-2026.

Each regime asks for slightly different cuts of the same physical reality. Each requires verifier-attested data. Each is a recurring obligation, not a one-off project. A producer facing them simultaneously cannot run them as parallel consultancies; they need one canonical inventory, defensibly produced, that projects into many regime-specific views without recomputation.

→ Embodied carbon, from first principles → Scope 1, 2, 3 → Boundaries → Regulations landscape → CBAM in depth
II. What a serious claim has to be

A carbon number is not a number. It is a trust claim - and a trust claim has seven properties.

Drop any one and the claim degrades from evidence to assertion. Drop two and it is marketing. These seven are the requirements list every architectural choice downstream answers to.

1 Prerequisite

Computed under a stated boundary

The same Lot under different boundaries - gate-to-gate, cradle-to-gate, CBAM production process, EN 15804 A1–A3 - gives different and all-defensible numbers. Without a stated boundary, a number is not a claim; it is an artefact.

2 Prerequisite

Traceable to source data

Every number must walk back through calculations to inputs, to sensor readings, lab results, ERP transactions, supplier declarations. Untraceable claims are self-attestations; verifiers reject them.

3 Engineering discipline

Reproducible under pinned methods and factors

A verifier with the same inputs and version pins reaches the same number. Engine binary, method version, and every factor used are pinned to every result. Without this, restatement loses meaning.

4 Engineering discipline

Uncertainty and evidence quality, rendered

Numbers carry their ±band (k=1/k=2) and their evidence tier - continuous measurement, periodic, supplier-declared, default, substituted. Without this, every number looks the same.

5 Engineering discipline

Governed by approvals and restatements

Every state change runs through a Submission with a Maker and a different Checker. Restatement creates a new locked snapshot pointing at the original. Nothing is silently rewritten.

6 Output-side trust

Renderable into different regimes

One canonical inventory, many regime projections - CBAM Communication, CSRD ESRS E1, EN 15804 EPD, Indian CCTS submission - without recomputation. The producer maintains one truth; the platform produces many views.

7 Output-side trust

Attestable by an independent verifier

A signed VerificationStatement from a verifier accredited under ISO 14065 by a national accreditation body. The cryptographic chain is independently verifiable client-side, offline, on a buyer’s phone.

A second application, flagged now

These seven properties have a second application worth naming up-front, because we return to it in Section VII. The same seven properties describe what trustworthy AI on industrial data needs - the parallel is not coincidence. Both verified carbon claims and AI outputs are derived assertions about physical reality. Both require the same substrate properties to be defensible. The platform delivers both.

→ The seven properties, in full
III. The substrate

SIDK is a six-year-old data-anchoring kernel that happens to be the right substrate for the carbon moment.

It was not built for carbon. It was built to anchor data against physical reality - asset topologies, lot lineages, transformation events - and to make any downstream claim resting on that data verifiable. Carbon is the first application taken to market.

Sphuran is a multi-domain research organisation: advanced materials, machine topologies, hybrid processes, computational design, computation and electronics, energy and transport, community technology, systems integration. SIDK began as a research tool for anchoring product-property data through processes, machines, and environmental parameters in real production chains - and has been used internally across several Sphuran research domains, including medical-equipment insights and operational control loops, for years.

The architecture is industry-neutral by construction. Vertical content - what a blast furnace is, what an EAF route emits, which factor library applies to cement clinker - lives as data in a pack, never as code. Adding a cement pack, an aluminium pack, a pharma pack, a food-processing pack is a research-and-author-the-pack task. The kernel stays stable; no risk to existing customers when new verticals land.

This is the technical heart of the moat. The substrate predates CBAM, predates ISSB, predates the current regulatory wave. It was built with the rigour of a research organisation that builds its tools to last. The carbon engine on top is recent - but it inherits its methodology from research-validation discipline that predates anyone on the team's involvement in carbon.

Seven primitives

Identity & Isolation · Live Data · Canonical Fact · Governance · Trust · Verifier Authorization · Projection Boundary

Boundary test

Must a signed, verified, or externally-relied-upon artefact resolve and verify this later? Yes → SIDK. No → product backend.

Deterministic by design

Same inputs and version pins → identical output, every time. Replayable by any verifier. Nothing silently mutates.

→ SIDK and what it is NOT → Sphuran & Grevoro separation
IV. The carbon engine

Four methods, audited fallback, boundary as a first-class input, parallel validation on every locked calculation.

The engine is where the platform's claim 'we produce trustworthy carbon numbers' stops being marketing and becomes engineering. It is the thing a verifier audits.

Four methods, in tiered preference
  1. M1Direct measurement - CEMS integrating concentration × flow over time.
  2. M2Fuel-combustion calculation - AD × NCV × EF × OF for metered combustion sources.
  3. M3Mass balance - carbon-in minus carbon-out, for integrated metallurgical sites where the textbook equation is wrong.
  4. M4Default factor - AD × default EF, used where higher tiers are infeasible.
What makes it trustworthy
  • Audited fallback. Every method change is recorded with the reason. No silent substitution.
  • Boundary as a first-class input. One subject under many boundaries yields many distinct, queryable results - all retained.
  • Dual Scope 2 always computed. Location-based and market-based, both stored. No regime requires recomputation.
  • Uncertainty propagated explicitly. GUM analytical chain for multiplicative methods; Monte Carlo LHS for mass balance, where subtraction-of-close-magnitudes breaks the analytical assumption.
  • Monte Carlo as parallel validation on every locked-period calculation. Divergence above threshold is a finding, not a silent overwrite.
  • Replayable. Engine version, method versions, and factor versions are pinned to every result. A verifier with the same inputs reaches the same number, byte for byte.
→ The Carbon Engine, plain-language → Inputs and sensors
V. The trust chain

Three signatures, three independent identities, three independent verification paths.

A buyer scans a QR. The browser verifies the platform signature, the Tenant signature, and the Verifier signature - client-side, offline, in milliseconds. No party can compromise the chain alone.

Signature 1

Tenant signs the claim

The operator who produced the carbon number signs the passport with a DID-registered key. Attests: we produced this, we stand behind these numbers.

Signature 2

Verifier signs the attestation

An accredited third-party verifier signs the VerificationStatement with a registry-published key. Attests: we, independent and accredited, reviewed this and reached this conclusion.

Signature 3

SIDK signs the delivery

The platform signs response bytes with a well-known JWKS key. Attests: the bytes you just received are the bytes our infrastructure served, untampered in transit.

SIDK is in the trust path at issuance time (running the registries and DID infrastructure) and at delivery time (signing the response). It is not in the trust path at verification time. A determined buyer can run the entire three-signature verification offline using the credential JSON, the DID document, and a standard JSON-LD library. The trust chain is fully decentralisable at the consumption end.

→ The trust chain composed end-to-end
VI. Sphuran & Grevoro

Two structurally independent companies. The cleanest answer to the structural-conflict-of-interest question we have seen in the space.

The third signature in the trust chain matters only if the entity holding the keys has no commercial stake in the product whose claims are being verified. Sphuran and Grevoro are configured for this property to hold and stay held.

What is true today
  • · Separate legal entities
  • · Separate cap tables
  • · Separate investors
  • · No overlap in leadership
  • · Operationally independent - separate hiring, separate decision-making
  • · Mission-aligned around sustainable manufacturing
  • · Sphuran does not sell SIDK; the partnership is mission-based, not transactional
What this means structurally

The standard pattern in “neutral platform vs product company” arrangements weakens under scrutiny - shared founders, shared lead investors, subsidiary relationships, operational entanglement. Sphuran-Grevoro has none of these patterns. The two companies are linked only by mission alignment and a working relationship.

The trust-architecture consequence: the entity running the verifier registry, the response-signing keys, and the DID infrastructure has no commercial stake in any specific carbon claim's outcome. The structural separation arose from how the two companies came to exist - not from a corporate-structure decision made to optimise for verifier neutrality. That is a stronger argument than the designed-moat framing, not a weaker one.

→ Sphuran, Grevoro, and what their separation means → About both companies
VII. AI on SIDK · the second payoff

The seven properties from Section II also describe what trustworthy AI on industrial data needs.

We flagged this connection earlier and now return to it. The parallel is not coincidence. Both verified carbon claims and AI outputs are derived assertions about physical reality - and they have the same defensibility requirements. Most industrial AI tools today fail multiple of these properties. AI built on a substrate that satisfies all seven by construction is qualitatively different.

Recall the seven, now in the AI register

Each property has a concrete failure mode for AI on industrial data when it is absent:

  • 1Stated boundary - without it, the AI does not know what question it is answering.
  • 2Traceable to source data - without it, outputs cannot be drilled back to evidence.
  • 3Reproducible - without it, the same input produces different outputs on different days.
  • 4Uncertainty and evidence quality - without it, confident-sounding answers hide their actual confidence.
  • 5Governed by approvals - without it, inferences could silently rewrite canonical history.
  • 6Multi-regime rendering - without it, the AI's view is locked to one frame.
  • 7Independently attestable - without it, the AI is an internal tool, not an externally defensible artefact.
AI on spreadsheets / ERP / SCADA

Pattern-matches against artefacts of unknown provenance. No idea where the numbers came from, what units, what boundaries, whether any human ever vetted them. Outputs can be vivid and confidently wrong; the wrongness is undetectable without going back to original sources - which is exactly the work the AI was supposed to obviate.

AI on SIDK

Reads canonical, traceable, evidence-tiered, boundary-explicit, version-pinned, verifier-walked data. Every recommendation drills back to specific sensor readings, lab results, and Maker-Checker approvals. The AI's recommendation is non-canonical and cannot mutate state (enforced architecturally). The evidence the recommendation reads is canonical. Defensible. Auditable.

SIDK itself is purely deterministic. AI sits on the boundary and never inside. The canonical record is protected by the same Maker-Checker discipline that protects every other state change. AI capability can scale arbitrarily on top of the substrate without compromising the trust chain underneath. This is the load-bearing architectural commitment that makes AI on SIDK defensible to a verifier, a regulator, or a buyer.

→ SIDK as substrate for trustworthy AI
VIII. GREMI at maturity

When all phases land, the platform is five apps serving five actors, with work flowing across them in three loops.

This is the destination picture - the shape GREMI takes when the trajectory in the next section completes. Eleven architectural principles hold across all of it. Read this section if you want to understand what is being built; read the next if you want to understand how we get there from today.

The five apps

One application per actor. Identity realms cannot be combined; tone cannot be combined; attack surfaces cannot be combined; audience scoping cannot be combined. Five is the minimum partition that respects the actor model.

Tenant

GREMI

The Tenant-operational application. The heaviest application in the platform. Twelve personas in two classes - operational (mobile-first, plant-floor) and analytical (desktop-first, governance). Houses the Quantification Loop in full, the Tenant side of the Trust Loop, and the Stewardship Loop in full.

Product Owner

Grevoro Console

Where Grevoro runs its product. Tenant pipeline, engineer assignments, the mapping workspace canvas, sensor and connector and template pipelines, cross-Tenant fleet view, program-health surfaces. Four persona classes; cross-Tenant scope through Engineer assignments.

Verifier

Verifier Workspace

Where accredited verifier firms work. Engagement management, audit chain navigation, methodology review, finding authoring, sampling, statement signing. Co-branded with the platform. Four persona classes; access to any Tenant gated by an active engagement record.

Buyer / Regulator

Public Verifier

Anonymous, no login, no cookies beyond the security minimum. A buyer scans a QR; the passport renders; three signatures verify client-side, offline, in milliseconds. Trustworthy in part because no-one is watching the visitor.

Platform

Sphuran Console

Platform governance. Verifier registry, accreditation chain, vertical-pack registry, cross-org Submissions, audit and elevations. Strict elevation controls: hardware-2FA, IP allowlisting, two-person approval for critical actions.

The three loops

Apps are where work happens. Loops are what work happens. The loops differ in cadence, primary personas, and which apps they span. Together they cover the full arc from sensor reading to publicly-verifiable claim to long-term reduction program.

Daily to monthly

Quantification Loop

Produces the canonical carbon numbers. Sensor reading → variable aggregation → quality check → calculation → period running estimate → period lock. Without this running well, every other loop has nothing to work with.

Monthly to annual

Trust Loop

Converts canonical numbers into externally trustworthy claims. Passport draft → issuance → verifier engagement → finding ↔ response → VerificationStatement → public verification. Spans all four customer-facing apps; the loop most exposed to outside scrutiny.

Annual to multi-year

Stewardship Loop

Governs the long-term carbon program. Targets, reduction projects with attribution, methodology decisions, supplier engagement, disclosure authoring (CDP, CSRD, TCFD, internal reporting). Turns the platform from carbon-accounting tool into carbon-management platform.

Eleven architectural principles, in shorthand

How trust is built (6)
  • Cryptographic anchoring - three signatures by three independent entities, all independently verifiable.
  • Structural neutrality - the platform's operator is structurally separate from any product owner.
  • Independence of attestation - every state change runs through Maker / Checker, who must be different actors.
  • Determinism in canonical computation - same inputs and version pins give the same number every time.
  • Auditability by hash chain - append-only, tamper-evident, walkable backward from any claim.
  • Provenance of evidence - every value carries its tier, source, uncertainty, quality flags.
How the products are designed (5)
  • Canonical vs derived presentation - derived outputs are marked and structurally bounded; only kernel values are citable.
  • Non-canonical inference cannot mutate canonical state - AI assists, Submissions authorise.
  • Provisioning vs operating - Product Owner provisions, Tenant operates; the seam is enforced.
  • Realm isolation - five realms (Tenant, Grevoro, Verifier, Sphuran, Public), collaboration only via shared kernel entities.
  • Mobile vs desktop by persona class - operational personas mobile-first, analytical personas desktop-first, per-surface policy.

The trust chain - three signatures composing on a buyer's phone - is one of the most consequential properties this destination architecture produces. The structural separation between Sphuran and Grevoro is what makes the third signature meaningful. The substrate that all five apps ride on is SIDK, and the discipline of running AI on it without compromising canonical state is covered earlier.

→ GREMI at maturity, in full
IX. GREMI today

Platform-first, plant-second. PoC underway. Six-phase release trajectory scoped in parallel.

GREMI is in PoC integration at Topworth Steel - part of the Amalgam Group, whose investment in Grevoro is the access path. Integration is being wired; production carbon numbers are a near-term milestone. The platform underneath is wired for the full picture in the previous section.

I In integration · Topworth Steel

Per-plant carbon accounting

Sensors, SAP, the Carbon Engine running per-lot and per-period calculations, draft reports in regime formats. The value-creating core.

II Scoped · early releases imminent

Grevoro Console

The Product Owner-side application that industrialises Tenant onboarding - mapping, sensor lifecycle, connectors, templates. The prerequisite for scale past pilot.

III Scoped

Verifier Workspace

Accredited verifiers walk the audit chain, file findings, and sign VerificationStatements. Claims become externally trustworthy. Triple signatures become the canonical artefact.

IV Scoped

Public Verifier

Per-batch shareable passports. A buyer scans a QR; signatures verify client-side, offline, on a phone. The trust chain composes for the world.

V Scoped

Stewardship Loop

Targets, reduction projects, methodology decisions, supplier engagement, disclosures. Carbon accounting becomes carbon management.

VI Progressive · substrate is ready

AI overlay, across all phases

AI surfaces appear progressively across the prior phases. Always on the boundary, never inside the canonical state. Reads SIDK-grounded data; outputs you can drill back to.

Each phase is a release-cadence decision, not an engineering trajectory. SIDK is already wired to support all six. App specs and tech-stack decisions for GREMI were made with the full picture in mind. The first user-facing releases - including parts of the Grevoro Console - are expected within the coming weeks, possibly before Topworth is fully commissioned.

→ GREMI, phased (the trajectory) → GREMI at maturity (the destination)
X. What to do next

Pick your reading path.

Full knowledge base

Read the canonical docs

All 14 docs - embodied carbon, scopes, boundaries, regulations, the seven properties, SIDK, the Carbon Engine, inputs, separation, GREMI phasing, GREMI at maturity, FAQ.
Quick answers

Browse the FAQ

Stakeholder-curated questions and answers, by topic. Carbon basics, boundaries, CBAM, the engine, inputs, the platform shape, AI on SIDK.
The companies

About Sphuran & Grevoro

Who builds what, who funds what, and what the structural separation between them is for.