Private briefing
Knowledge base · 99-faq

99 - Frequently asked questions

Status. Living. v0.1 · First draft: 17-03-2026 · Seeded from the full set of KB docs.

Quick navigation

About carbon, basics

What is “embodied carbon”?

The cumulative greenhouse-gas footprint of a product up to a defined boundary - for industrial inputs like steel, every emission from raw material extraction through manufacturing. Contrasts with operational carbon, the emissions a product generates while it is being used. For materials like steel that are consumed rather than operated, embodied carbon is the whole story. See 01 - Embodied carbon.

Why is steel a particularly hard case?

Three reasons: (a) the carbon is in the recipe - coal is both fuel and chemical reductant in a blast furnace, so the carbon ends up split across off-gas, slag, steel, dust, and fugitive paths; you can’t just measure one chimney. (b) The same finished product can come from BF-BOF (~2 tCO₂e/t), scrap-EAF (~0.3–0.7), or H₂-DRI (approaching zero) - a ten-fold spread in carbon for the same spec sheet. (c) For EAF and DRI routes, the grid factor for purchased electricity swings the answer by more than an order of magnitude. See 01 §2.

What’s the difference between CO₂ and CO₂-equivalent?

CO₂-equivalent (CO₂e) converts every greenhouse gas to a single comparable basis by multiplying each gas’s mass by its Global Warming Potential (GWP) factor. Methane has a GWP-100 of 27.0 (biogenic) or 29.8 (fossil); nitrous oxide 273; some industrial gases run into the thousands. The version of the GWP set (AR4, AR5, AR6) is part of the answer - values differ by 10–20% between versions. See 01 §4.

What does “verified” actually mean?

A claim is verified when an accredited third-party verifier - a firm accredited under ISO 14065 by a national accreditation body - has reviewed the data, walked the audit chain, raised challenges, and issued a signed VerificationStatement. The verifier is independent of the producer; the verifier’s accreditation is independent of the platform; both are publicly checkable. A self-attested claim has no external standing under any binding regime. See 01 §5.

Why does the dual Scope 2 (location vs market) thing matter so much?

For a modern EAF mill the answer to “how much CO₂ is in this tonne of steel?” depends almost entirely on which kWh-emissions factor you apply. The location-based answer uses the average grid intensity for the region; the market-based answer uses whatever contract the mill signed (PPA, REC). The two can differ by more than an order of magnitude for the same physical kWh. The GHG Protocol’s 2015 Scope 2 Guidance requires both to be reported. The proposed 2027 revision will tighten market-based to require hourly matching. See 02 §3.

About boundaries

What’s a “boundary” and why is it separate from scope?

Boundary is the question the calculation is answering - gate-to-gate, cradle-to-gate, cradle-to-grave, EN 15804 A1-A3, CBAM production process, and so on. Scope (1, 2, 3) is the categorisation of each emission inside that boundary by who controls the source. A single emission has one scope but can appear inside many boundaries. The two are orthogonal; both must be stated for any carbon number to be meaningful. See 02a - Boundaries.

What’s the difference between cradle-to-gate, cradle-to-grave, and cradle-to-cradle?

Cradle-to-gate covers raw material extraction through the producing factory’s gate - the default for industrial product carbon footprints. Cradle-to-grave covers the full life cycle: production, transport, installation, use, end-of-life. Cradle-to-cradle is cradle-to-grave plus avoided-emission credits from recycling at end-of-life. The numerical spread between them for the same physical product can be 2-3×. See 02a §1.

What are the EN 15804 modules A1-A5, B, C, D?

The modular life-cycle structure used in construction-product EPDs. A1-A3 is the product stage (cradle-to-gate equivalent). A4-A5 is construction (transport to site, installation). B1-B7 is the use stage. C1-C4 is end-of-life. Module D is reported separately and covers avoided-emission credits from reuse/recycling beyond the system boundary - never folded into the cradle-to-grave total. Required reading for anyone parsing steel EPDs. See 02a §2.

How can the same physical steel produce different carbon numbers under different boundaries?

Because the boundaries answer different questions. A worked example in 02a §4 shows the same tonne of HRC at 80 kgCO₂e/t (gate-to-gate) to 2,250 (cradle-to-grave) to 1,650 (cradle-to-cradle with Module D credit) - a 28× range, every number correct under its own boundary. Without normalising to a common boundary, cross-supplier comparisons are invalid.

Is CBAM’s boundary the same as cradle-to-gate?

No - close, but not the same. CBAM defines its own “production process” boundary per aggregated goods category, with specific rules for direct emissions, indirect (electricity) emissions, and precursor handling. The Carbon Engine’s CBAM_PRODUCTION_PROCESS boundary kind is not interchangeable with CRADLE_TO_GATE_LOCATION. See 02a §3 and 03a.

What’s the first thing I should ask of any published carbon number?

Which row of the boundary table in 02a §6 is it? If the boundary is not stated, the number is not a claim; it’s a marketing artefact. Push back.

About regulations

Which regulations actually apply to us?

Depends on: where the Tenant operates, where they sell, where they raise capital, and whether their buyers face downstream disclosure requirements. For a steel producer exporting to the EU, the binding regimes today are CBAM (importer-side), India CCTS (if Indian), and (if their EU customer is CSRD-bound) effective pressure for verified Scope 1+2 + PCF. See 03 - Regulations landscape.

What’s CSRD, and is Scope 3 mandatory under it?

The EU’s Corporate Sustainability Reporting Directive, requiring annual sustainability statements per the ESRS standards. ESRS E1 covers climate. Scope 3 is mandatory where material. Post-Omnibus I (December 2025), Wave 1 reports on FY 2026 in 2027; Wave 2 delayed to 2028; thresholds raised to >1,000 employees and >€450M turnover. See 03 §2.3.

What’s ISSB IFRS S2, and does it apply outside the EU?

The International Sustainability Standards Board’s climate-disclosure standard. As of January 2026, 21+ jurisdictions have adopted it on a mandatory or voluntary basis - including Hong Kong, Pakistan, Chile, Qatar, Mexico, with firm timelines in Australia, Singapore, Japan, Malaysia, Brazil, and others. It is the convergence layer the world is gravitating toward. See 03 §2.4.

What about California - SB 253 and SB 261?

California’s two climate disclosure laws, applying to companies doing business in California above turnover thresholds, regardless of headquarters. SB 253 (>$1B revenue) requires Scope 1+2 reporting from 2026 (first deadline 10 August 2026, FY 2025 data) and Scope 3 from 2027. SB 261 (>$500M, biennial climate-related-financial-risk disclosures) is currently paused by a Ninth Circuit injunction. SB 253 is unaffected. See 03 §2.5.

What does India’s CCTS do?

The Indian Carbon Credit Trading Scheme. Nine sectors notified for gradual inclusion - aluminium, chlor-alkali, cement, fertilisers, iron & steel, pulp & paper, petrochemicals, petroleum refining, textiles. Intensity-based targets (tCO₂e per unit of product). First seven sectors operating under binding obligations for FY 2026 and FY 2027 with FY 2024 as baseline; first CCC trading expected mid-2026. See 03 §2.7.

What’s the relationship between SBTi and these binding regimes?

SBTi is voluntary corporate target-setting, but most Tenants engage with it because their investors and customers expect it. SBTi-validated targets require a credible inventory baseline and credible reduction projects - both of which are first-class concepts in the Stewardship Loop (08b §3). See 03 §3.1.

About CBAM specifically

Does CBAM require a carbon declaration per shipment?

No. The CBAM declaration is annual, not per-shipment. One authorised CBAM declarant files one declaration per calendar year covering all CBAM-covered goods imported the prior year. The deadline (post-Omnibus) is 30 September of the following year. The first definitive-period declaration is due 30 September 2027, covering 2026 imports. Each customs declaration must reference the authorised CBAM declarant via EORI, but the carbon data does not travel per shipment. See 03a §3.1.

Does the carbon number need to match the exact lot of goods imported?

No. Embedded emissions are calculated at the installation level over the installation’s reporting period (default: calendar year) and divided by total production output. Mill X’s 2026 reporting-period specific embedded emissions (SEE) is applied to every tonne of that mill’s relevant production sent to the EU during that period. Not heat-number-specific; not melt-batch-specific. This is set in Annex IV of Regulation 2023/956 and elaborated in Implementing Regulation (EU) 2025/2547. See 03a §3.2.

So why bother with lot-level carbon data?

Because the market increasingly wants more than CBAM requires. EU buyers exposed to the proposed 2028 downstream-extension are pushing for per-lot Product Carbon Footprints with strong provenance. A producer who can supply both an installation-period SEE (for CBAM) and a per-lot PCF (for the buyer’s commercial preference) has both compliance and differentiation. The platform’s lot-lineage and passport machinery exists for exactly this - produce per-lot PCFs and roll them up into installation-period SEE without recomputation. See 03a §3.2 and 06 §7.

When does CBAM actually cost money?

The first certificate purchases are in 2027. The first mandatory surrender (and the first real penalty exposure) is 30 September 2027 for 2026 imports. 2026 itself is a preparation year - get authorised, gather supplier data, engage a verifier. See 03a §2.

Who can verify CBAM data?

A verifier accredited under EN ISO/IEC 14065, in accordance with Regulation (EC) 765/2008, with the CBAM-specific overlay set in Delegated Regulation (EU) 2025/2551. EU national accreditation bodies issue the accreditations; existing EU ETS (IR 2018/2067) verifiers are not automatically accredited for CBAM - they can extend, but the operational mechanics are still being implemented in 2026. Verifiers cannot register in the CBAM Registry before 1 September 2026, which creates a real H1-2027 capacity bottleneck. See 03a §6.

What happens if we use default values instead of actuals?

Defaults are permitted where actual verified data is unavailable, but they carry a progressive mark-up: 10% in 2026, 20% in 2027, 30% from 2028 (for steel, aluminium, cement). Fertilisers receive a flat 1%. The country-specific defaults are set in Implementing Regulation (EU) 2025/2621 and are computed as the average emission intensity of the ten highest-emitting exporting countries - a worst-in-class benchmark. From 2027 onwards, an exporter who supplies verified actuals materially undercuts a competitor on defaults. See 03a §5.

What’s the de minimis threshold?

50 tonnes net mass per importer per calendar year, cumulative across CBAM-covered goods. Hydrogen and electricity are excluded - always in scope regardless of volume. A declarant who crosses the threshold mid-year becomes liable for all imports since 1 January of that year - no grace period. Artificial splitting to stay under 50 t triggers an aggravated penalty of EUR 300–500/tCO₂e (vs the standard EUR 100). See 03a §7.

How does CBAM relate to a domestic carbon price like India’s CCTS?

CBAM’s Article 9 (as amended) permits deduction of verifiable carbon prices effectively paid in the country of origin. An Indian mill paying CCTS prices can in principle deduct them against CBAM surrender. The methodology for “effective price” is open - Commission guidance is expected. See 03a §8.

About the Carbon Engine

Why four methods, not one?

Because carbon emissions can be measured or computed several different ways, with different accuracy and applicability trade-offs. Direct measurement (CEMS) is most accurate but covers only what you instrument. Fuel-combustion calculation is everyday-practical for thousands of small sources. Mass balance is the only correct method for integrated metallurgical sites where carbon flows through multiple streams. Default factors are the floor, used where higher tiers are infeasible. The engine selects per emission source, with audited fallback. See 06 §2-3.

Why does the engine treat boundary as a “first-class input”?

Because the same Lot has different carbon numbers under different boundaries - gate-to-gate is one number, cradle-to-gate location-based is another, CBAM production process is another, EPD A1-A3 is another. None of these are “the” answer; they answer different questions. The engine produces all of them from the same underlying CalculationResults by varying the boundary descriptor, without recomputation. This is what lets a single Tenant inventory serve CBAM, CSRD, EN 15804, and CCTS at once. See 06 §5.

Why does the engine always compute both location-based and market-based Scope 2?

Because the choice between them can be regime-driven and changes over time. Computing both costs a few extra factor lookups during a calculation. Re-running an entire mill’s locked period because a downstream regime now wants the other variant would be far more expensive. Small cost now, big saving later. See 06 §5 and 02 §3.

What is Monte Carlo “validation”, as distinct from Monte Carlo “method”?

For Method 3 (mass balance), Monte Carlo Latin Hypercube Sampling is the primary uncertainty method - the analytical GUM formula gives an inflated, pessimistic uncertainty band on the subtraction-of-close-magnitudes structure of mass balance. For Methods 1 and 2, the primary method is analytical (GUM first-order); MC runs in addition, as a parallel validation. The MC median is compared to the analytical value; deltas beyond threshold raise findings. The primary value remains canonical; MC lives in uncertaintyValidation on the same CalculationResult. See 06 §8.

What’s the “shadow calculation”?

Beyond MC-as-check on uncertainty, the engine runs two independent methods on the same source in parallel - typically Method 1 (CEMS) and Method 3 (mass balance) on a blast-furnace top-gas stack. The CEMS number is authoritative; the mass-balance is shadow. The engine computes the delta, compares to combined uncertainty, and emits a finding. Persistent divergence (3+ periods) blocks the period lock without explicit override. The engine does not auto-switch to the shadow method - silent downgrade is more dangerous than a blocked lock. See 06 §9.

What does “locked period” mean and why can’t I just update last month’s numbers?

When a ReportingPeriod is LOCKED, the engine writes a LockedSnapshot with all CalculationResults, evidence packages, factor versions, and a content hash. The snapshot is immutable. Late-arriving data is not silently incorporated. If it is material, a restatement Submission is filed; on dual-actor approval, the engine writes a new LockedSnapshot pointing to the original via parentSnapshotId. Both snapshots remain queryable; the diff endpoint shows exactly what changed. This is the audit discipline that makes the output evidence rather than assertion. See 06 §11.

What’s the “Readiness Check”?

A pre-lock pre-flight that surfaces problems before the period is locked: overdue calibrations, missing lab results, unreconciled mass balances, persistent shadow-calc divergence. Three severity levels - INFO (proceed), WARNING (proceed with warning recorded), CRITICAL (block until resolved or override-submission-approved). Overrides are visible to verifiers; nothing is hidden. See 06 §12.

About inputs and sensors

How does sensor data physically reach the kernel?

Via an on-site Rust edge agent that supports OPC-UA, MQTT, and Modbus TCP, buffers durably to RocksDB (90-day replay window), and uploads to SIDK’s ingestion API. The agent assigns each captured point a deterministic ID so retries after network glitches are idempotent. Quality flags travel per-point. See 07 §2.

What if the site loses internet for two weeks?

The edge agent keeps capturing and accumulating points in its local durable buffer. When connectivity returns, it uploads everything. The v1 guarantee is up to 90 days offline without data loss. See 07 §2.

Who configures and maintains the sensors?

Grevoro’s Onboarding Engineers, not the Tenant. This is the provisioning/operating seam: a Tenant operating its own sensor configuration would compromise the calibration discipline that makes the data audit-grade; a Tenant raises a ticket when something is wrong, and an Engineer changes the topology. The Tenant operates with what exists; the Engineer changes what exists. See 07 §10.

What does it mean for a sensor to be “LIVE”?

The Variable has completed the lifecycle PLANNED → CONFIRMED → INSTALLED → COMMISSIONING → LIVE. Only LIVE Variables contribute to calculations. Commissioning-state data is captured and stored but not consumed by calculations - it is the state where calibration is verified and ranges are sanity-checked. See 07 §4.

What happens when a sensor flags BAD or goes missing?

The engine applies a tiered substitution hierarchy inspired by EPA Part 75 - linear interpolation for short gaps, percentile-based substitutes for medium gaps, conservative worst-case for long gaps. The chosen substitution tier is recorded per period on the CalculationResult. If the substituted fraction exceeds 10%, Readiness Check WARNING; above 25%, CRITICAL - the period cannot be locked without an explicit override. See 07 §8.

What are the five evidence tiers, and why do they matter?

Tier 4 (continuous direct measurement, e.g., CEMS), Tier 3 (periodic measurement, e.g., scheduled lab assays), Tier 2 (supplier-declared with documentation), Tier 1 (industry/IPCC default), and Substituted. Every component of a CalculationResult carries its tier; the result’s evidenceBreakdown aggregates them. A sophisticated buyer or regulator can distinguish a well-measured claim from a heavily-defaulted one. Without this distinction, every claim looks the same. See 06 §10 and 07 §5-6.

What does the engine do with supplier-provided Product Carbon Footprints?

It resolves Scope 3 inputs through a five-tier order: PO-specific supplier PCF → aggregate supplier PCF → tenant-private corrected default → platform-shared default → IPCC/industry default. The resolution tier is recorded on every component so a verifier can see how primary the data was. Over time, the intent is that suppliers on the platform issue cryptographically signed PCFs that travel with shipments, letting a buyer’s Scope 3 inherit the supplier’s Scope 1+2 with full lineage. See 07 §7.

About SIDK, GREMI, Sphuran, and Grevoro

Is SIDK Gremi’s backend?

No. SIDK is a vertical-agnostic industrial data kernel; GREMI is a product built on top of SIDK with its own product backend. The boundary test for what belongs in SIDK versus in a product backend is the “must this resolve and verify later under signed regulatory scrutiny?” question. If yes → SIDK. If no → GREMI’s backend. Most of GREMI’s code is by definition product-side (UI, workflows, customer notifications), not SIDK-side. See 05 - SIDK, especially §2 (what SIDK is NOT) and §4 (the boundary test).

Why are Sphuran and Grevoro separate companies?

Because they are separate - separate legal entities, separate cap tables, separate investors, no overlap in leadership. Operationally independent, mission-aligned around sustainable manufacturing. The structural separation was not designed as a moat; it emerged from how the two companies arose (Sphuran does research; Grevoro builds products; their missions aligned). The trust-architecture consequence - that the entity running SIDK’s signing keys and verifier registry has no commercial stake in GREMI’s customer outcomes - is real, verifiable, and unusually clean compared to the typical “neutral platform vs product company” arrangement. See 04a - Sphuran, Grevoro, and what their separation means.

What does GREMI actually do, day to day?

Today, GREMI is in PoC integration at Topworth Steel (part of the Amalgam Group; Amalgam Group’s investment in Grevoro is the access path). Integration is being wired; no real production carbon numbers are flowing yet. The platform underneath is built to support a six-phase release trajectory: per-plant accounting → Grevoro Console for scalable onboarding → Verifier Workspace → Public Verifier → Stewardship Loop → AI overlay across all of the above. Release cadence begins this month, including capability releases before Topworth is fully commissioned. See 08 - GREMI, phased for the trajectory and 08b - GREMI at maturity for the destination picture.

Why does this platform exist at all? Couldn’t a Tenant just hire a consultant for a CBAM declaration?

A one-off CBAM declaration is a project; a trustworthy, continuously-produced, verifier-walkable inventory across CBAM + CSRD + EN 15804 + CCTS + buyer-driven PCF requests, kept current month over month with monthly closes, restatement audit chains, per-Lot lineage, and AI-overlaid analytics, is not. The economics of trust at this volume favour a platform built on a deterministic, audit-grade substrate. The seven properties in 04 - Carbon as trust infrastructure are why a platform is the right shape; 05 - SIDK §6 is what makes this particular platform credible (six years of substrate work, internally validated across multiple research domains, with research-grade engine on top).

Who actually signs the claims?

Three signatures, three independent identities, three independent verification paths: the Tenant signs the claim with its DID-registered key; the Verifier signs the attestation with its registry-published key; SIDK (operated by Sphuran) signs the delivery with the platform’s response-signing keys. Any party - a buyer with a phone, a regulator with a script - can verify all three signatures independently, client-side, offline. The structural separation between Sphuran and Grevoro is what makes the third signature meaningful: the entity holding the platform’s signing keys has no commercial stake in the specific claim’s outcome. See 04a §6 and 05 §3.

How is AI different on SIDK versus a generic platform?

The seven properties in doc 04 turn out to be the requirements list for trustworthy AI on industrial data, not just for verifiable carbon claims. AI on SIDK reads canonical, traceable, evidence-tiered, boundary-explicit, version-pinned, verifier-walked data - every output can be drilled back to specific sensor readings, lab results, and Maker-Checker approvals. AI on spreadsheets or ERP exports reads inputs of unknown provenance and produces outputs of unverifiable quality. SIDK itself is purely deterministic; AI sits on the boundary and can never mutate canonical state. The full argument is in 05 - SIDK §8, with the positioning consequence in 04 §7.

Has SIDK been used for anything other than carbon?

Yes. Inside Sphuran, SIDK has been used for years to trace how a product’s properties are affected by processes, machine parameters, and environmental conditions in its production chain; to anchor insights for medical equipment; to run operational control loops in test conditions. Carbon, via GREMI, is the first product taken to market on SIDK, but inside Sphuran the kernel has been a generalised tool earning its design through multi-domain use. The “industry-neutral” claim is not a design goal - it is an internally demonstrated property. See 05 - SIDK §1 and §6.

Can the platform expand to other industries - cement, aluminium, pharma?

Yes, by authoring a new pack. The kernel stays stable; the vertical’s specifics (NodeClasses, expected variables, preferred methods, factor library, allocation rules, regime mappings) live in the pack as data, not code. Adding a cement pack involves deep research on cement production, structured into the pack format the kernel reads. GREMI itself can build versions for other verticals on the same substrate. Likewise, a different Product Owner could build a non-carbon product on the same substrate. The pack-as-data architecture is the load-bearing design choice that makes this possible without engineering risk. See 05 - SIDK §5.

About the platform’s shape at maturity

What does GREMI look like when all phases land?

Five inter-connected applications, serving five distinct actors, with work flowing across them in three end-to-end loops. GREMI for Tenants (twelve personas in two classes). Grevoro Console for Grevoro’s own engineers (four persona classes). Verifier Workspace for accredited verifiers (four persona classes). Public Verifier for anonymous buyers and regulators. Sphuran Console for platform governance (two persona classes). Three loops cross-cut the apps: Quantification (daily-to-monthly, produces canonical numbers), Trust (monthly-to-annual, converts numbers into verified claims), Stewardship (annual-to-multi-year, governs the long-term carbon program). Eleven architectural principles hold across all of it. Full picture in 08b - GREMI at maturity. Trajectory from today in 08 - GREMI, phased.

Why five apps and not one?

Identity realms can’t be combined (each authentication context has a fundamentally different threat model); tone can’t be combined (a polished Tenant-branded surface and a Sphuran-neutral verifier surface can’t coexist without compromising one or both); attack surface can’t be combined (the public buyer surface is anonymous and adversarial, the Tenant surface is authenticated and trusted, mixing them is a security mistake); and audience scoping can’t be combined (a single user typically belongs to exactly one actor type). Five is the minimum partition that respects the actor model. See 08b §2.

What’s the difference between the three loops and the six phases?

The three loops are a cross-cutting structural description of what work happens on the platform when it’s mature - they describe end-to-end arcs that span apps (a Trust Loop instance starts in GREMI, passes through Verifier Workspace, ends in Public Verifier). The six phases are a temporal description of how user-facing capability gets released over time. They are orthogonal: each phase delivers user-facing pieces of one or more loops. Phase 1 (per-plant accounting) delivers most of the Quantification Loop; Phase 3 (Verifier engagement) delivers the verifier side of the Trust Loop; Phase 5 (Stewardship) delivers the Stewardship Loop. See 08b for the loops, 08 for the phases.

Who actually uses each of the five apps?

GREMI: Tenant operators and analysts. Grevoro Console: Grevoro’s own onboarding/data/support engineers. Verifier Workspace: accredited verifier firms. Public Verifier: anonymous buyers and regulators (no login). Sphuran Console: Sphuran’s own platform-governance staff. The architecture deliberately keeps each app focused on one actor’s needs; cross-app collaboration happens via shared kernel entities (e.g., a Submission filed in GREMI surfaces in Verifier Workspace) rather than via shared UI sessions. See 08b §2.

What are the eleven architectural principles?

Six describe how trust is built into the platform (cryptographic anchoring, structural neutrality, independence of attestation, determinism in canonical computation, auditability by hash chain, provenance of evidence). Five describe how the products are designed (canonical vs derived presentation, non-canonical inference can’t mutate canonical state, provisioning vs operating, realm isolation, mobile vs desktop by persona class). Together they apply to every app, every loop, every surface, every entity. Summarised in 08b §5.

I have a question that isn’t here

Add it to the queue in the team’s working channel. The FAQ is a living doc - questions that come up more than once get folded in.

← Previous
08b-gremi-at-maturity