Questions stakeholders ask, with grounded answers.
Curated from the full knowledge base. Every answer links to the source doc for the deeper version.
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 that are consumed rather than operated, embodied carbon is the whole story.
Why is steel a particularly hard case?
Three reasons. (1) 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; one chimney measurement is not enough. (2) Routes give a tenfold spread for the same spec sheet - BF-BOF ~2.0–2.3 tCO₂e/t, scrap-EAF ~0.3, H₂-DRI on clean grid approaching zero. (3) For EAF and DRI, the grid factor for purchased electricity swings the answer by an order of magnitude.
What's the difference between Scope 1, 2, and 3?
Scope 1 is direct emissions from sources the company owns or controls. Scope 2 is emissions from purchased energy. Scope 3 is everything else in the value chain - 15 categories spanning upstream (purchased goods, capital goods, transport, etc.) and downstream (use of sold products, end-of-life, investments). Scope 1 is dominant for integrated BF-BOF steel; Scope 2 dominates for scrap-EAF; Scope 3 is the largest and hardest-to-measure for most manufacturers.
Why does the dual Scope 2 (location vs market) matter so much?
For an electrified mill, the answer to "how much CO₂ is in this tonne of steel" depends almost entirely on which kWh-emissions factor applies. Location-based uses the average grid intensity for the region. Market-based uses the producer's contractual instruments (PPAs, RECs). 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.
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. Scope is the categorisation of each emission by who controls the source. A single emission has one scope but can appear inside many boundaries. Both must be stated for a carbon number to be meaningful.
How can the same physical steel produce different carbon numbers under different boundaries?
Because the boundaries answer different questions. One tonne of HRC can be 80 kgCO₂e/t (gate-to-gate, rolling step only) or 2,250 (cradle-to-grave) or 1,650 (cradle-to-cradle with Module D recycling credit) - every number correct under its own boundary. Without normalising boundaries, cross-supplier comparisons are invalid.
CBAM specifically
Does CBAM require a carbon declaration per shipment?
No. The CBAM declaration is annual, not per-shipment. One authorised 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. First definitive-period declaration: 30 September 2027 for 2026 imports.
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). Mill X's 2026 reporting-period specific embedded emissions is applied to every tonne of that mill's relevant production sent to the EU during that period. Not heat-number-specific. The "CBAM Communication" is the per-installation-per-period data unit that flows in supply chains.
So why bother with lot-level carbon data?
Because the market 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 and a per-lot PCF has compliance value AND commercial differentiation. The platform's lot-lineage and passport machinery exists for exactly this.
What happens if we use default values instead of actuals?
Defaults are permitted where actual verified data is unavailable but carry a progressive mark-up: 10% in 2026, 20% in 2027, 30% from 2028 (steel, aluminium, cement). From 2027 onwards an exporter with verified actuals materially undercuts a competitor on defaults.
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 is practical for thousands of small sources. Mass balance is the only correct method for integrated metallurgical sites. Default factors are the floor. The engine selects per emission source, with audited fallback.
What's "shadow calculation" and why does it matter?
For sources where two independent methods can both compute emissions (e.g. CEMS and mass balance on a blast-furnace top-gas stack), the engine runs both in parallel during every locked-period calculation. CEMS is authoritative; mass balance is shadow. The engine compares them; persistent divergence (3+ periods) blocks the period lock without explicit override. The engine never silently switches methods - silent downgrade is more dangerous than a blocked lock.
What does "locked period" mean and why can't I just update last month's numbers?
When a period is LOCKED, the engine writes an immutable LockedSnapshot with all CalculationResults, evidence packages, factor versions, and a content hash. Late-arriving data is not silently incorporated. If material, a restatement Submission is filed; on dual-actor approval, the engine writes a new LockedSnapshot pointing at the original. Both remain queryable; the diff endpoint shows exactly what changed. This is the audit discipline that makes the output evidence rather than assertion.
Inputs and sensors
How does sensor data physically reach the kernel?
Via an on-site Rust edge agent supporting OPC-UA, MQTT, and Modbus TCP. The agent buffers durably (RocksDB, 90-day replay window), assigns deterministic IDs for idempotent retries, and uploads to SIDK's ingestion API. Sites can be offline for up to 90 days without data loss.
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. The Tenant operates with the topology that exists and raises a ticket if something is wrong; the Engineer changes what exists.
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: "must this resolve and verify later under signed regulatory scrutiny?" - yes → SIDK, no → GREMI's backend. Most of GREMI's code is by definition product-side (UI, workflows, notifications), not SIDK-side.
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 emerged from how the two companies arose, not from a corporate-structure decision. The trust-architecture consequence - that the entity running SIDK's signing keys has no commercial stake in GREMI's outcomes - is real, verifiable, and unusually clean.
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; 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.
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) live in the pack as data, not code. Adding a cement pack involves deep research on cement production, structured into the pack format. GREMI itself can build versions for other verticals on the same substrate. The pack-as-data architecture is the load-bearing design choice that makes this possible without engineering risk.
AI on SIDK
How is AI different on SIDK versus a generic platform?
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 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 platform shape
What does GREMI look like when all phases land?
Five inter-connected applications serving five actors, with work flowing across them in three end-to-end loops. GREMI for Tenants. Grevoro Console for Grevoro's engineers. Verifier Workspace for accredited verifiers. Public Verifier for anonymous buyers. Sphuran Console for platform governance. Three loops cut across: Quantification (daily-to-monthly), Trust (monthly-to-annual), Stewardship (annual-to-multi-year). Eleven architectural principles hold across all of it.
Why five apps and not one?
Identity realms can't be combined; tone can't be combined; attack surface can't be combined; 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.
Have a question not here? It probably belongs in this FAQ. Add it to the team's working channel - the FAQ is living and grows as questions come up more than once.