Knowledge base · 08-gremi-phased

08 - GREMI, phased

Status. Draft v0.1 · First draft: 17-03-2026 · Co-authored from a structured discussion with the team. This doc describes the actual phasing of GREMI’s product capability - what is real, what is releasable, and in what order. The destination picture - what GREMI looks like when all phases land, with the five apps, three loops, and twelve Tenant personas in full - is in the pair-doc 08b - GREMI at maturity. Read either doc first. Read 08b first if you want to understand what is being built before reading how we get there; read this doc first if you want to start from current state and trajectory. Terms used here - “three loops”, “five apps”, “twelve personas”, “the Quantification / Trust / Stewardship Loop” - are defined in 08b.

Why this matters. GREMI’s canonical app spec describes a polished, multi-loop, multi-persona platform - Quantification Loop, Trust Loop, Stewardship Loop, twelve personas, every surface specified to fine detail. Read uncritically, the spec implies that all of this is product reality today. It is not, and saying so honestly is more important than a confident marketing posture. The product is in PoC integration at one factory. The platform underneath is built to support the full picture. The phasing question is therefore not “can the platform support this?” - it is “in what order do user-facing capabilities go live, and on what cadence?” This doc states that order, names the current state honestly, and connects each phase to the substrate properties that make it deliverable.

1. Where GREMI actually is today

The product is in PoC at one factory. Topworth Steel, part of the Amalgam Group. The access path is mission-aligned: Amalgam Group’s management is an investor in Grevoro, and the investment relationship is what unlocks the operational access to a real working steel plant. The PoC is the first concrete instance of GREMI being applied to a real industrial site.

Integration is being wired; no real production carbon numbers are flowing yet. Sensor wiring, SAP connectors, mapping the plant’s topology onto SIDK’s entity model, scoping the calculation boundaries, configuring the steel pack’s NodeClasses against the actual Topworth plant - this work is happening now. The carbon engine is functional, the substrate is ready, but the PoC has not yet reached the state where it is producing real measured carbon numbers from real Topworth sensor and SAP data. That state is a near-term milestone, not a present achievement.

The honest read is: platform-first, plant-second. The platform has been built to support the full vision; the first plant is being onboarded now to validate the integration end-to-end. This is the right way around. Most failed industrial-software efforts start the other way - build narrowly for one customer, then try to generalise - and discover too late that the foundation is wrong.

A second consequence of this state worth flagging: GREMI’s release cadence is not gated on Topworth reaching production. The Grevoro Console, the Verifier Workspace integration, and several other phase capabilities can be released independently of Topworth’s progress. Topworth is the proof-of-concept for the end-to-end Tenant deployment workflow, not for the platform’s existence. We expect the first user-facing capability releases - including some of the Console functionality - to begin within the next month, possibly before Topworth is fully commissioned.

2. The six phases - what they are, why this order

The phasing is a release schedule, not an engineering trajectory. SIDK is already wired to support all six phases. App specs, tech-stack decisions, and plans for GREMI have been made with the full picture in mind. The sequence below is the order in which user-facing capabilities are released - driven by commercial logic, dependency between capabilities, and the natural way Tenants and verifiers will encounter the product.

Phase 1 - Per-plant carbon accounting, internal use

What ships. The core capability set Topworth was built for and that every subsequent Tenant will start with. Sensor integration via the edge agent; SAP and ERP connectors for activity data and lot lineage; the Carbon Engine running per-lot and per-period calculations; report and declaration drafting in the formats relevant to the Tenant’s regimes (CBAM Communication, CSRD-compatible inventories, EN 15804 EPDs, India CCTS submissions, internal monthly closes). Confidence and uncertainty bands surfaced in the UI. Method drill-down and data-gap visibility. A live view of the few sensors currently connected - modest in scope today, scaling as more sensors come online. Concrete splits by boundary, scope, source, and evidence tier.

Why this comes first. A Tenant’s daily reality is: capture data, run numbers, draft reports. Without these working end-to-end, nothing else matters. Phase 1 is the value-creating core; everything else either makes Phase 1 sustainable to deploy widely (Phase 2), externally trustworthy (Phases 3 and 4), or strategically meaningful (Phase 5). It is also the right phase to validate the substrate’s claim - if Phase 1 works for Topworth, the architectural bets in SIDK and the Carbon Engine are operationally vindicated.

What this depends on. SIDK’s Live Data Layer, Canonical Fact Layer, and Governance Layer (all ready). The Carbon Engine itself (ready). The steel pack (ready, encoding all the principal BF-BOF, EAF, DRI route variants). See 05 - SIDK and 06 - The Carbon Engine.

Phase 2 - Grevoro Console

What ships. The Product Owner-side application that industrialises Tenant onboarding and operational maintenance. Tenant pipeline (commercial dashboard across stages). Engineer assignments (which Grevoro Engineer is responsible for which Tenant). The mapping workspace canvas where an Engineer scopes a plant and binds it to SIDK. Sensor lifecycle management (PLANNED → CONFIRMED → INSTALLED → COMMISSIONING → LIVE). The connector pipeline. The template library for ERP and lab uploads. The ticket queue for tickets raised by assigned Tenants. The cross-Tenant fleet view for Onboarding Engineers and Data Engineers.

Why this comes second. The hardest task in deploying GREMI is not running the calculations - that is the substrate’s job and it works. The hardest task is scoping a new factory: walking the plant, mapping out what they do, identifying every emission source, every sensor needed, every connector that needs to be built, every template that needs to be authored. Doing this from scratch every time, with bespoke setup per plant, makes GREMI unsustainable past the first three or four Tenants. The Grevoro Console exists to make this work efficient and repeatable for the Engineering teams who do it for a living. Scale matters; without the Console, GREMI cannot grow past pilot scale.

Why this comes before the trust-chain phases. A trust chain is only valuable if there are claims to trust. A claim is only commercially valuable if it comes from a Tenant with a real production deployment. The Console is what makes “first Tenant” plural - going from one to ten to fifty plants is a Console-enabled motion, not a heroic-engineering motion. Without ten or more live Tenants, the trust-chain phases are infrastructure waiting for a counter-party.

What this depends on. Phase 1’s stability. SIDK’s Identity & Isolation Layer (multi-realm authentication, EngineerAssignment records, cross-Tenant scope through the Grevoro realm) and Governance Layer (Submissions for engineer assignments, mapping revisions, sensor lifecycle transitions). See Principle 9 in 08b §5 on the provisioning/operating seam.

Phase 3 - Verifier engagement (Verifier Workspace)

What ships. The Verifier-side application. Engagement management (which Tenants the verifier firm is engaged with, on what scope, for what period). Audit chain navigation (walking the hash-anchored evidence trail). Methodology review (boundary, GWP version, allocation method, factor sources). Finding authoring (questions and challenges filed against the Tenant). Sampling and test-of-detail tracking. Statement authoring (drafting and signing the VerificationStatement). Co-branded with Sphuran’s brand carrying the underlying trust infrastructure.

Why this comes next. A claim signed only by the Tenant is a self-attestation. A claim signed by both the Tenant and an accredited third-party Verifier has external standing - usable for CBAM, CSRD, EPD, CCTS, and SBTi-aligned reporting. Phase 3 is when GREMI’s claims become externally trustworthy. Triple signatures (Tenant signs the claim; Verifier signs the attestation; the platform signs the delivery) become the canonical artefact a buyer or regulator interacts with. See 04 - Carbon as trust infrastructure §7 for the requirement; 08b §4 for the trust-chain mechanics worked end-to-end.

What this depends on. SIDK’s Verifier Authorization Layer (engagements, accreditation binding, engagement scopes, access windows, VerificationStatements). The verifier registry (operated by Sphuran). The Trust Layer’s passport stack. All ready in the substrate. The phase-3 product work is the user-facing surface that exposes these primitives to verifier-firm users.

The verifier counter-party question. The Trust Loop architecturally requires a verifier on the other side. The roadmap for engaging an accredited verifier firm - onboarding the firm to Verifier Workspace, scoping the first engagement, running through the first VerificationStatement - is in active scoping in parallel with Phase 2 work. We expect verifier engagement to be the first phase that requires a named external commercial partner outside Grevoro and Sphuran.

Phase 4 - Public Verifier

What ships. The Buyer/Regulator-consumption application. Minimal, civic-infrastructure-feeling, Sphuran-branded. Per-batch passport rendering - a buyer scans a QR code on a shipment, lands on a passport page. Lineage navigation (walking the chain of passports back to raw inputs at a depth the privacy disclosure matrix allows). Signature verification (client-side, using Web Crypto API, fully offline-capable). Accreditation check (verifying the verifier’s accreditation is currently valid). Anonymous; no authentication; no cookies beyond the security minimum; no analytics scripts. The page is trustworthy in part because no one is watching the visitor.

Why this comes next. Phase 3 makes claims externally trustworthy to verifiers. Phase 4 makes them externally trustworthy to anyone with a browser. A buyer making a procurement decision, a regulator running spot-checks, a competitor verifying a public claim, an academic researcher building a study - all use the same surface, and none of them needs a login. This is where the trust chain composes for the world.

What this depends on. SIDK’s Trust Layer (passport stack, response signing, JWKS publishing). DID infrastructure for Tenants. Verifier registry for accreditation checks. All operated by Sphuran. The phase-4 product work is the public-facing rendering surface; the cryptographic infrastructure is already there.

Phase 5 - Stewardship Loop

What ships. The carbon-management layer on top of the carbon-accounting layer. Target setting (a fifty-percent reduction by 2030, an SBTi-validated science-based target). Reduction projects (waste heat recovery, fuel switching, electrification, supplier engagement) and the attribution of realised reductions to them. Methodology decisions (which GWP set, which boundary, which Scope 2 method, which allocation rule) tracked as Submissions with rationale. Supplier engagement workflows (chasing primary data, monitoring PCF coverage). Disclosure authoring (CDP, CSRD, TCFD, internal annual reports).

Why this comes next. Once accounting works (Phase 1), onboarding scales (Phase 2), and claims become externally trustworthy (Phases 3 and 4), the natural next question is: now what? A platform that does excellent inventory and attestation but does not help the Tenant actually reduce emissions is a carbon-accounting tool, not a carbon-management platform. Phase 5 is what turns the latter into the former. It is also the phase where the relationship with the Tenant’s leadership (executive sponsor, sustainability lead, finance reviewer) deepens - daily operations was the operational personas; reduction strategy is the governance personas.

What this depends on. Phase 1’s data infrastructure (which targets are computed against). Phase 3’s verifier capability (which validates target progress). Significant new entity types - Target, ReductionProject, MethodologyDecision, Supplier, Disclosure - that live in Docs/GREMI-App-Ecosystem/entity-additions-v1.1.md. The substrate supports it; the product work is substantial.

Phase 6 - AI, overlaid across all phases

What ships. Not a single surface. A capability that overlays Phases 1 through 5 progressively, with specific user-facing manifestations at each phase:

In Phase 1: AI-assisted data-quality triage (which substituted readings are most worth investigating; which lab-result anomalies are most likely errors). AI-drafted natural-language summaries of period closes for sustainability leads.
In Phase 2: AI-assisted mapping suggestions for new plants (given Plant X looks structurally similar to Plant Y in the existing portfolio, here are the suggested NodeClass bindings). AI-driven gap-analysis on incoming Tenant data.
In Phase 3: AI-assisted finding authoring for verifiers (here are the evidence items most worth challenging based on substitution patterns and uncertainty bands).
In Phase 4: AI-driven natural-language explanation of passport contents to buyers (“here is what this passport says, in plain English, with the parts you might want to scrutinise”).
In Phase 5: The AI Twin - scenario engine, Q&A overlay, what-if analysis for reduction projects. The deepest AI integration, deferred to the phase where the underlying data is rich enough for it to be useful.

Why this matters more than a feature claim. SIDK is purely deterministic. AI sits on the SIDK boundary, never inside the canonical state. This is a load-bearing architectural commitment (Foundation §4.8). The consequence is that AI built on SIDK reads canonical, traceable, evidence-tiered, boundary-explicit, version-pinned, verifier-walked data. Every recommendation, every summary, every suggestion is grounded in data with full audit lineage. The user can ask “show me the data this is based on” and get a defensible answer. This is qualitatively different from generic AI tools that pattern-match against spreadsheets, ERP exports, or operational historians - those tools read inputs of unknown provenance and produce outputs of unverifiable quality. Doc 05 §8 covers the substrate property in depth; this phase is when it becomes user-visible.

What this depends on. The Projection Boundary Layer (the same contracts the product backend uses). Submissions for any AI-proposed state change. Foundation §4.8’s non-canonical-inference principle is enforced architecturally; the AI integration cannot violate it. The phase-6 work is the AI-surface engineering and the model integration; the substrate’s discipline is already in place.

3. What is explicitly NOT in any current phase

The app spec describes capabilities that this doc does not list as Phase 1–6 work. The honest framing is that they are part of the long-term vision but not part of the committed phased trajectory today. They include, illustratively:

White-label deployments of the Public Verifier surface for enterprise customers.
Multi-Product-Owner expansion (a second Product Owner building a non-carbon product on SIDK).
Marketplace primitives for cross-Tenant discovery or benchmarking.
The full Stewardship Loop’s supplier-engagement workflows at the level of detail the app spec describes.

These are deliberate scope decisions. The platform’s architecture contemplates each of them; none is on the near-term roadmap. As the product matures and customer demand makes specific capabilities pressing, they may move from “long-term vision” to “next phase” - at which point they appear in a future revision of this doc, not in marketing material.

4. The release-cadence story, in one paragraph

Topworth Steel is in PoC integration. The Grevoro Console, Verifier Workspace integration points, and several other phase capabilities are scoped and partially built. The platform underneath them is wired for all of it. We expect releases to begin in rapid cadence over the next month - including some Console capability before Topworth is fully commissioned. The order in §2 is the release order, not the engineering effort order. A Tenant onboarding in (say) Q3 2026 will see a fundamentally different product surface than one onboarding in Q2 2027, even though the substrate is the same throughout. The substrate’s stability is what allows the product to evolve fast without breaking earlier Tenants.

5. How to talk about GREMI today

A few patterns:

Works: “GREMI is in PoC integration at one steel plant - Topworth Steel, accessed through Amalgam Group’s investment in Grevoro. The platform underneath has been six years in development and is wired to support a multi-phase release trajectory. The first user-facing release cycle begins this month.”

Works: “GREMI’s near-term product release cadence is fast because the platform’s architectural work has been done upfront. Releases are sequencing user-facing capability - Tenant accounting, then Grevoro Console for scalable onboarding, then verifier engagement, then public verification, then stewardship - not building each phase from scratch.”

Works: “We are deliberately platform-first, plant-second. Topworth is the first concrete deployment; the platform is built to support many. This is the right way around for a regulated-data product where the substrate’s integrity is what makes the product worth using.”

Overclaims: “GREMI is in production at Topworth Steel.” - Untrue today; integration is being wired, no production output yet.

Overclaims: “The three loops are operational.” - They are vision. The phasing is sequenced delivery of user-facing capability; the three loops are how the canonical foundation organises what work happens, not what is shipped.

Underclaims: “We have a partner that is helping us build a carbon platform.” - Hides the load-bearing fact. The platform is six years of substrate work; the first product is being deployed at a real industrial site; the architecture supports a sequence of releases over the coming months.

6. The shape of the next twelve months

Without committing to specific dates, the next twelve months are shaped by three concrete things:

Topworth Steel reaches integration completion and begins producing real carbon numbers. The first end-to-end Tenant deployment becomes a working reference.
Grevoro Console releases progressively, making the next several Tenant onboardings materially less expensive than Topworth was. Scale becomes possible.
Verifier engagement is scoped and the first accredited firm is brought into Verifier Workspace. The trust chain begins composing externally for the first time.

Public Verifier, Stewardship Loop, and AI surfaces are scoped in parallel; their release timing depends on the pace of the above three and the order in which Tenant or regulatory pressure makes them most urgent. The phasing is not a Gantt chart; it is a logical order with cadence driven by commercial and operational reality.

7. The picture in one sentence

GREMI is the first product built on SIDK; it is currently in PoC integration at one steel plant; its phased trajectory is a release-cadence sequence enabled by a six-year-old substrate that has already been architected for the full picture; the AI capability that overlays all phases is not a feature claim but a structural property of building on a deterministic, auditable substrate.

That sentence is what the rest of the doc unpacks.

References & further reading

Source documents (canonical)

Docs/GREMI-App-Ecosystem/foundation-v1.4.md - the architectural foundation, including the three loops (§3), the eleven architectural principles (§4), and the trust chain (§5). The destination architecture this doc’s phasing leads toward.
Docs/GREMI-App-Ecosystem/gremi-app-spec-v1.0.md - GREMI’s surface inventory, navigation, persona scope, surface-level behaviour. The long-term vision against which this doc’s “what’s not yet in phase” §3 reads.
Docs/GREMI-App-Ecosystem/grevoro-console-app-spec-v1.0.md - Grevoro Console’s surface inventory; the Phase 2 product spec.
Docs/GREMI-App-Ecosystem/verifier-workspace-app-spec-v1.0.md - Verifier Workspace’s surface inventory; the Phase 3 product spec.
Docs/GREMI-App-Ecosystem/public-verifier-app-spec-v1.0.md - Public Verifier’s surface inventory; the Phase 4 product spec.
Docs/GREMI-App-Ecosystem/quantification-loop-v1.2.md, trust-loop-v1.2.md, stewardship-loop-v1.0.md - the three loop specs that describe what work happens across surfaces. Vision documents; the phasing in §2 of this doc is how that vision is rolled out.
Docs/GREMI-App-Ecosystem/entity-additions-v1.1.md - entities specific to GREMI beyond SIDK’s kernel entities (Target, ReductionProject, MethodologyDecision, Supplier, Disclosure, Findings). Especially relevant for Phase 5.

Cross-references within the knowledge base

04 - Carbon as trust infrastructure - the seven-property requirements list this phasing operationalises.
04a - Sphuran, Grevoro, and what their separation means - the corporate context for GREMI as a product company on SIDK.
05 - SIDK - the substrate underneath GREMI; especially §5 (pack-as-data), §6 (six years of refinement), §8 (SIDK as substrate for trustworthy AI).
06 - The Carbon Engine - the deterministic calculation subsystem GREMI consumes in Phase 1 onwards.
07 - Inputs and sensors - how Topworth’s sensor wiring and SAP integration actually flows into the kernel.

External authoritative sources

Amalgam Group corporate information. Topworth Steel is part of the Amalgam Group; Amalgam Group’s management is an investor in Grevoro and the relationship is the access path to Topworth as PoC. https://www.amalgamgroup.com/
CBAM definitive period - first compliance deadlines. The 30 September 2027 deadline for the first annual CBAM declaration is the external date most relevant to GREMI’s Phase 3 trajectory. See 03a - CBAM, in depth.
CSRD Wave 1 reporting. Wave 1 EU companies report FY 2026 data in 2027 - also relevant to the Phase 3 timeline for Tenants who supply Wave 1 companies. See 03 §2.3.