08b - GREMI at maturity, the complete shape

Status. Draft v0.1 · First draft: 17-03-2026 · This doc is the destination picture. Pair-doc to 08 - GREMI, phased, which describes how we get there from today. If you want to understand what is being built, read this first. If you want to understand current state and trajectory, read 08 first.

Why this matters. Doc 08 talks about phases, releases, “the three loops”, “five apps”, “twelve personas”. Without the destination picture, those terms are unsupported jargon. This doc paints the picture. When all phases land - perhaps in two to four years, depending on regulatory cadence and commercial adoption - the platform is five inter-connected applications serving five distinct actors, with work flowing across them in three end-to-end loops. Eleven architectural principles hold across all of it. This is the shape we are building toward; doc 08 is the order we build it in.

---

1. The five actors

The platform exists to make industrial carbon claims trustworthy enough that buyers, verifiers, and regulators act on them. That purpose implies a set of actors. Five of them.

Tenant - the industrial operator producing the carbon claim. A steel mill, cement plant, aluminium smelter, chemical works, pharmaceutical facility. Topworth Steel is the first Tenant. Tenant work spans twelve persona roles across two classes: operational personas (plant manager, unit operations manager, utilities engineer, materials coordinator, lab/QC manager, shift coordinator, IT integrator) who are field-bound and mobile-first by default; and analytical-and-governance personas (executive sponsor, sustainability lead, sustainability analyst, finance reviewer, customer engagement lead) who are detail-bound and desktop-first by default. The Tenant is who the platform’s purpose serves - without a Tenant producing a claim, nothing else matters.

Verifier - the independent third party attesting to the Tenant’s claim. Accredited under ISO 14065 by a national accreditation body. The Verifier reads the Tenant’s data within an agreed engagement scope, walks the audit chain, files findings, and issues a signed VerificationStatement. Verifier firms operate cross-Tenant; a single firm serves many Tenants across many industries. Verifier work is performed by four persona classes - Engagement Manager, Auditor, Reviewer, and Firm Lead (who holds statement-signing authority). The Verifier is the amplifier of trust: a claim from the Tenant alone is a self-attestation; a claim attested by an accredited Verifier has external standing.

Buyer / Regulator - the consumer of the verified claim. A procurement officer at a downstream manufacturer asking whether a shipment of low-carbon steel actually is what it claims to be. A customs officer checking a CBAM declaration. An academic researcher. A competitor verifying a public claim. A regulator auditing compliance. Treated as a single actor because their needs overlap (verify a passport, trust a claim, walk the lineage to its origin) even where their contexts differ. Anonymous; mobile-first; trust-first; no login. The buyer scans a QR code or visits a URL and everything they need to trust the claim must be on the page they land on.

Product Owner (Grevoro) - the product company that builds and operates GREMI. Maintains GREMI’s roadmap, runs the commercial relationship with Tenants, and provides Engineers who provision and configure each Tenant’s instance. Grevoro’s work is performed by four persona classes - Onboarding Engineer (gets new Tenants live), Data Engineer (operates connectors and mappings for live Tenants), Support Engineer (handles tickets), Grevoro Admin (coordinates assignments and firm-internal governance). The architecture supports multiple Product Owners over time; Grevoro is the first.

Platform (Sphuran) - the research company that builds and operates SIDK, the vertical-agnostic kernel underneath GREMI. Owns the cross-product infrastructure: the verifier registry, the accreditation chain governance, the DID infrastructure for Tenants, the response-signing keys. Two persona classes - Sphuran Operations Staff (routine governance) and Sphuran Security Lead (security-critical infrastructure: signing-key governance, snapshot key management, incident response). The structural separation between Sphuran and Grevoro is what makes the trust chain externally credible; see 04a.

2. The five apps

Each actor has a primary application. Five of them, one per actor.

GREMI - the Tenant-operational application. Polished, Grevoro-branded. The heaviest application in the platform by surface count, persona count, and feature scope. Where Tenants do their daily work: operate the plant, refine calculations, lock periods, issue passports, respond to verifier findings, govern the long-term carbon program. Houses the Quantification Loop in full, the Tenant-side of the Trust Loop, and the Stewardship Loop in full. Accommodates twelve Tenant personas, with mobile-first surfaces for operational personas and desktop-first surfaces for analytical ones.

Grevoro Console - the Product-Owner-operational application. Tool-shaped in tone. Where Grevoro runs its product. Houses the Tenant pipeline (commercial dashboard across stages), engineer assignments, the vertical-pack registry, the Onboarding Engineer’s cross-Tenant fleet view, the mapping workspace canvas, the sensor and connector pipelines, the program-health learning surfaces. Authenticated against a Grevoro-internal identity provider; four persona classes; cross-Tenant scope through EngineerAssignment records. The application that makes Grevoro’s onboarding work efficient and repeatable; the prerequisite for commercial scale beyond a handful of plants.

Verifier Workspace - the Verifier-operational application. Tool-shaped, professional. Co-branded by default - Sphuran’s brand carries the underlying trust infrastructure; the verifier firm’s identity is surfaced in its own workspace. Where verifiers do their work: engagement management (which Tenants the firm is engaged with, on what scope, for what period), audit chain navigation (walking the hash-anchored evidence trail), methodology review, finding authoring (questions and challenges filed against the Tenant), sampling and test-of-detail tracking, statement authoring (drafting and signing the VerificationStatement). Authenticated against a Verifier-org identity provider; access to a specific Tenant’s data is additionally gated by an active engagement record.

Public Verifier - the Buyer/Regulator-consumption application. Minimal, civic-infrastructure-feeling, Sphuran-branded. Where the trust chain meets the rest of the world. Houses the passport-rendering surface (a buyer scans a QR and lands here), 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.

Sphuran Console - the Platform-operational application. Tool-shaped, internal in tone. Sphuran-branded. Where Sphuran runs the platform. Houses platform health monitoring (the kernel itself, infrastructure observability, cross-product service-level indicators), identity governance (Organisation and Product registration), the verifier registry (accreditation registration, suspension, termination), the vertical-pack registry (versioning, publishing, deprecation across all Product Owners using a pack), cross-org submissions (signing key rotation, verifier engagement governance), audit and elevations. Authenticated against a Sphuran-internal identity provider with strict elevation controls - hardware-2FA, IP-allowlisting, short sessions, purpose-code-required audit. Critical actions require two-person approval with Maker and Checker as distinct identities.

Why five apps, not one or many

A single combined application fails on four grounds: identity realms cannot be combined (each authentication context has a fundamentally different threat model); tone cannot be combined (a polished Tenant-branded surface and a Sphuran-neutral verifier surface cannot coexist in one shell without compromising one or both); attack surface cannot 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 cannot be combined (a single user typically belongs to exactly one actor type). Fragmenting further also fails - each additional app adds collaboration overhead, brand dilution, and integration cost. Five is the minimum partition that respects the actor model.

3. The three loops

Apps are where work happens. Loops are what work happens. Specifying only apps produces gaps where work spans apps - work that has a starting point in one app, a middle in another, and an end in a third. Loops are the connective-tissue layer that prevents these gaps. Three loops, differing in cadence and in which apps they span.

Quantification Loop - daily to weekly to monthly. Produces the canonical numbers - the carbon inventory itself. The arc: sensor reading → variable aggregation → quality check → reconciliation → calculation → period running estimate → period lock → canonical number. Operational personas drive the data-capture end (shift coordinator, unit operations manager, utilities engineer, materials coordinator, lab/QC manager). Analytical personas drive the compute-and-lock end (sustainability analyst, sustainability lead). Onboarding Engineers (Grevoro side) maintain the sensor and connector pipelines that feed the loop. Primary app: GREMI. Touches Grevoro Console for sensor lifecycle and connector and template management. Without the Quantification Loop running well, every other loop has nothing to work with.

Trust Loop - monthly to annual. Takes the canonical numbers produced by the Quantification Loop and converts them into externally-trustworthy claims. The arc: calculation → passport draft → passport issuance → verifier engagement → finding ↔ response → VerificationStatement → public verification. On the Tenant side: sustainability lead governs the engagement, sustainability analyst responds to findings, customer engagement lead links passports to buyers. On the verifier side: the four verifier personas (engagement, audit, finding, statement). On the consumption side: buyer/regulator (anonymous). Spans all four customer-facing apps - GREMI for Tenant-side authoring and finding-response, Verifier Workspace for the verifier-side work, Public Verifier for consumption, Sphuran Console for verifier-registry governance. The loop most exposed to outside scrutiny; every architectural principle in the platform is in some sense protecting this loop.

Stewardship Loop - annual to multi-year. Governs the long-term carbon program. Sets targets (a fifty-percent reduction by 2030, a science-based target validated under SBTi). Tracks reduction projects (waste heat recovery, fuel switching, electrification, supplier engagement) and attributes realised reductions to them. Decides methodology (which GWP set, which boundary, which Scope 2 method, which allocation rule). Engages suppliers (chasing primary data, monitoring PCF coverage). Produces disclosures (CDP, CSRD, TCFD, internal annual reports). Governance personas dominate: executive sponsor, sustainability lead, finance reviewer. Primary app: GREMI. Touches Grevoro Console for cross-Tenant pattern learning. The loop that turns a carbon-accounting tool into a carbon-management platform.

Loop × app matrix

Loop	GREMI	Grevoro Console	Verifier Workspace	Public Verifier	Sphuran Console
Quantification	Primary	Touches (sensor lifecycle)	-	-	-
Trust	Primary (Tenant side)	-	Primary (verifier side)	Primary (consumption)	Touches (verifier registry)
Stewardship	Primary	Touches (cross-Tenant patterns)	-	-	-

“Primary” means the loop’s main work happens in that app. “Touches” means supporting work. GREMI is touched by all three loops, which is why it is the heaviest application. Grevoro Console supports two loops in supporting roles. Verifier Workspace and Public Verifier exist almost entirely to serve the Trust Loop. Sphuran Console supports the Trust Loop at the registry-governance level.

4. How the trust chain composes for a buyer scanning a QR

A worked example of the mature picture, end to end, from the perspective of the only actor who is anonymous:

A buyer scans a QR code on a packaging of a coil they have just received. The QR encodes a Public Verifier URL - https://verify.[platform]/p/{passportId}. The buyer’s browser opens the page. The page is largely static. The browser fetches the passport JSON from the platform; the response is signed with SIDK’s response-signing key, verifiable against the JWKS published at a well-known URL. The passport contains the Tenant’s signature, verifiable against the Tenant’s DID document. If the passport references a VerificationStatement, the browser fetches it, fetches the Verifier’s public key from Sphuran’s registry, and verifies the Verifier’s signature. The browser also checks the Verifier’s accreditation status - ACTIVE, SUSPENDED, or TERMINATED - and surfaces it.

The page renders. The buyer sees the headline carbon number with its boundary statement, a status badge (ISSUED, SUPERSEDED, REVOKED), a verifier summary (name, accreditation, outcome) if attested, a lineage navigator showing the passport’s ancestry, and - collapsible - a cryptographic detail block showing all three signatures verified, all three public keys located, all three trust anchors confirmed.

The entire verification is client-side. SIDK is not in the trust path at verification time - it is in the trust path at issuance time (running the registries and DID infrastructure) and at delivery time (signing the response). A determined buyer could run the same verification offline using the credential JSON, the DID document, and a local JSON-LD library. The trust chain is fully decentralisable at the consumption end.

This worked example only becomes possible after Phase 4 (Public Verifier) lands. Today, the substrate is wired for it; the user-facing surface is not. See 08 - GREMI, phased.

5. The eleven architectural principles, in shorthand

Cross-cutting rules. They apply to every app, every loop, every surface, every entity. Any specification downstream that violates these principles is the specification that is wrong.

How trust is built - six principles that compose the trust substrate:

1. Cryptographic anchoring. Every claim, attestation, and delivery is cryptographically signed by three distinct keys held by three distinct entities. Anyone can verify all three signatures independently, client-side, offline.
2. Structural neutrality. Sphuran is structurally separate from any Product Owner. The trust surfaces (Verifier Workspace, Public Verifier, the verifier registry) are operated by an entity with no commercial stake in any specific product’s claims. See 04a.
3. Independence of attestation. Every state change runs through a Submission with a Maker and a Checker who must be different actors. No exceptions for urgency or seniority.
4. Determinism in canonical computation. Values produced by the kernel are formula-driven, rule-based, and reproducible. Realised by the Carbon Engine; see 06.
5. Auditability by hash chain. Every state-changing operation is recorded in an append-only, hash-anchored audit chain. Tamper-evident; queryable; walkable backward from any claim to its inputs.
6. Provenance of evidence. Every canonical value carries its evidence - the tier of measurement, the source system, the uncertainty, the quality flags. Confidence is rendered, not hidden. Five-tier evidence model: continuous → periodic → declared → default → substituted.

How the products are designed - five principles that govern surface behaviour:

7. Canonical vs derived presentation. Apps present canonical values produced by the kernel and also produce derived outputs (dashboards, summaries, alerts). Derived outputs are visually marked and structurally bounded; they cannot be cited as evidence; they cannot mutate canonical state.
8. Non-canonical inference cannot mutate canonical state. Any AI, ML, or other inference output reads canonical data and produces derived outputs. Where it proposes an action, the action routes through a Submission with human Maker and Checker. The inference layer is an assistant; the Submission is the authoritative path. See 05 §8 for what this enables.
9. Provisioning vs operating. The Product Owner provisions (configures sensors, connectors, templates, mappings). The Tenant operates (reads sensors, raises tickets, approves Submissions, locks periods). Crossing this seam corrupts the trust model.
10. Realm isolation. Each app authenticates against a distinct identity realm. Cross-app collaboration happens via Submissions and shared kernel entities, never via shared UI sessions. Five realms - Tenant, Grevoro, Verifier, Sphuran, Public.
11. Mobile vs desktop by persona class. Operational personas are field-bound, mobile-first. Analytical personas are detail-bound, desktop-first. Per-surface policy, not per-app - a single app may have mobile-first and desktop-first surfaces in the same shell.

6. How the mature picture differs from today

Today (May 2026): GREMI is in PoC integration at one factory; the platform is wired for all of the above; release cadence begins this month with sequential delivery of user-facing capability. See 08 - GREMI, phased for the trajectory.

Differences worth flagging between this destination doc and today’s reality:

• The five apps are not all live. GREMI’s first phase is the only user-facing surface beginning to ship; Grevoro Console comes in Phase 2; Verifier Workspace in Phase 3; Public Verifier in Phase 4; Sphuran Console is internal-use from early on.
• The three loops are not all operational. Quantification Loop’s data path is functional at the substrate level; Trust Loop requires the Verifier Workspace and an accredited verifier (Phase 3); Stewardship Loop requires significant new entities and surfaces (Phase 5).
• The twelve Tenant personas, four Verifier persona classes, four Grevoro persona classes, two Sphuran persona classes are the destination cast. Today, only a small subset of these have functional surfaces tailored to them.
• The AI overlay is being introduced in stages across the phases, with the deepest integrations (the AI Twin’s scenario engine, Q&A overlay, what-if analysis) deferred to Phase 5+. The substrate property that makes AI trustworthy on SIDK (05 §8) is true from day one; the user-facing AI surfaces ship progressively.

The mature picture in this doc is the destination. The trajectory in doc 08 is how we get there. Both are honest - the destination is genuinely ambitious; the trajectory is paced to what can be built and validated in sequence; the substrate underneath is wired for the whole thing.

7. Why the architecture has this shape

A reader might wonder: why is the architecture this elaborate? Why five apps and not one? Why three loops and not just “the carbon-accounting workflow”? Why structural separation between Sphuran and Grevoro? Why deterministic substrate with AI on the boundary rather than AI throughout?

The honest answer is that every one of these is the right shape for the trust problem the platform exists to solve. The seven properties in 04 - stated boundary, traceable to source data, reproducible under pinned versions, uncertainty and evidence quality, governance by approvals, multi-regime rendering, independent attestation - are not satisfiable by simpler architectures. Each architectural choice in this doc lands as a direct response to one or more of those properties:

• Five apps with realm isolation enable Property 7 (independent attestation) without compromising the security or scoping models that protect Properties 1–5.
• Three loops with explicit cross-app coordination enable Property 6 (multi-regime rendering) because the same canonical data flows through different presentation paths for different audiences.
• Structural neutrality between Sphuran and Grevoro enables Property 7 to have an unusually clean structural foundation.
• The deterministic substrate with non-canonical inference on the boundary enables Property 3 (reproducibility under pinned versions) to hold even as the AI capability scales arbitrarily on top.

Read backward, the platform is large and the architecture has many moving parts. Read forward through the seven properties and this doc’s destination picture, every part is doing recognisable work.

---

References & further reading

Source documents (canonical)

This doc is a paraphrase of the canonical Foundation document, compressed for the knowledge-base audience. Where this doc and Foundation diverge, Foundation is right.

• Docs/GREMI-App-Ecosystem/foundation-v1.4.md - the architectural root. §1 (the five actors), §2 (the five apps), §3 (the three loops), §4 (the eleven architectural principles), §5 (the trust chain), §6 (the doc family). This doc paraphrases all of these in compressed form.
• Docs/GREMI-App-Ecosystem/gremi-app-spec-v1.0.md - GREMI’s full surface inventory.
• Docs/GREMI-App-Ecosystem/grevoro-console-app-spec-v1.0.md - Grevoro Console’s full surface inventory.
• Docs/GREMI-App-Ecosystem/verifier-workspace-app-spec-v1.0.md - Verifier Workspace’s full surface inventory.
• Docs/GREMI-App-Ecosystem/public-verifier-app-spec-v1.0.md - Public Verifier’s full surface inventory.
• Docs/GREMI-App-Ecosystem/sphuran-console-app-spec-v1.0.md - Sphuran Console’s full surface inventory.
• Docs/GREMI-App-Ecosystem/quantification-loop-v1.2.md - Quantification Loop, end-to-end specification.
• Docs/GREMI-App-Ecosystem/trust-loop-v1.2.md - Trust Loop, end-to-end specification.
• Docs/GREMI-App-Ecosystem/stewardship-loop-v1.0.md - Stewardship Loop, end-to-end specification.

Cross-references within the knowledge base

• 04 - Carbon as trust infrastructure - the seven properties this destination architecture operationalises.
• 04a - Sphuran, Grevoro, and what their separation means - Principle 2 (structural neutrality) in detail.
• 05 - SIDK, and what it is NOT - the substrate underneath all five apps; especially §8 (AI as substrate consequence).
• 06 - The Carbon Engine - Principles 4, 5, and 6 in their realisation layer.
• 07 - Inputs and sensors - how the Quantification Loop’s data-capture arc actually flows.
• 08 - GREMI, phased - the trajectory from today to the destination described here.

External authoritative sources

• W3C Verifiable Credentials Data Model 2.0. The cryptographic standard underpinning the three-signature trust chain. https://www.w3.org/TR/vc-data-model-2.0/
• W3C Decentralized Identifiers (DIDs) v1.0. The identifier framework for Tenant signing keys. https://www.w3.org/TR/did-core/
• ISO 14065:2020 - General principles and requirements for bodies validating and verifying environmental information. The accreditation standard for the verifier population the Verifier Workspace serves. https://www.iso.org/standard/74257.html
• ISO 14064-3:2019 - Specification with guidance for the verification and validation of greenhouse gas statements. The procedural standard the Trust Loop’s verifier-side work operates under. https://www.iso.org/standard/66455.html