A detailed, capability-focused walkthrough of how Carbon Upscale runs legacy and verified lanes in one platform: from supplier intake to claim controls, registry issuance, and public checkpoint transparency.
Executive Snapshot
2
Legacy lane + verified dMRV lane running in one platform.
6
From `draft` to `mint_ready` with explicit forward transitions.
5
Claims, checkpoints, verifier context, issuance metadata, and transaction linkage.
4
Founders, investors, suppliers, and operations teams.
Why This Matters
Carbon Upscale now operates as a migration-friendly marketplace with a verified lane for higher-assurance procurement. These pillars summarize the strategic value in operational terms.
Legacy suppliers can keep listing with low friction while verified suppliers move into dMRV controls.
You keep revenue velocity on existing projects while progressively upgrading trust for strategic accounts.
Checkpoint anchoring, methodology linkage, and verifier context build a transparent provenance narrative.
Investors and enterprise buyers can see a credible path from impact data to on-chain retirement outcomes.
Claims, issuances, and mint readiness are controlled by forward-only workflow states and quantity guards.
Governance is operationalized in product logic rather than relying on manual process discipline alone.
Verified-path purchases retain claim references and dMRV flags for reconciliation, payout reporting, and reviews.
Board, finance, and compliance teams can trace execution without rebuilding reporting from scratch.
Architecture
The platform intentionally supports both a legacy lane and a verified lane so Carbon Upscale can balance adoption speed and high-assurance proof requirements.
End-To-End Journey
This timeline mirrors the operational journey from supplier intake to final transaction traceability. Each stage is represented in schema, API logic, and audit controls.
Terminal exits for non-progressing claims: rejected / withdrawn.
Supplier identity is represented as an AIO and tied into dMRV structures.
Projects are mapped to impact modules to create a clear evidence context.
Claims progress through forward-only status gates with submission prerequisites.
Issuance quantity controls and transition RPCs prevent over-allocation and workflow bypass.
Checkpoint packages are anchored and exposed through read-safe public retrieval.
Verified-path transactions preserve claim linkage for finance and reconciliation.
Mint Safety
Verified-path issuance is protected by explicit quantity accounting and state transitions that keep claims, issuance inventory, and mint events aligned.
`dmrv_registry_issuances` tracks `quantity`, `quantity_reserved`, and `quantity_minted` per issuance object.
`reserve_issuance_quantity`, `confirm_issuance_mint`, and rollback functions enforce consistency under load.
Verified-path minting only proceeds when claim status is `mint_ready`, avoiding governance bypass.
`pending -> submitted -> issued` (or `rejected`) is tracked for registry alignment.
Public Transparency
dMRV evidence is made useful when it is both machine-verifiable and understandable to external stakeholders. This is the public retrieval chain used for that goal.
Evidence package is hashed and stored in `checkpoints` with period context and claim linkage.
`get_public_checkpoint_transparency(project_id, limit, offset)` returns proof + context without raw table exposure.
Downstream consumers verify checkpoint hashes, claim status, methodology metadata, and verifier context.
Data Model
The dMRV path works because each operational step has a durable entity model. This map helps founders explain how supplier intake, verification, and transactions connect.
`projects.dmrv_exempt` controls legacy vs verified execution path
Includes dMRV readiness tier and source profile metadata for organization mapping
Bridges supplier identity via `suppliers.organization_id` and legacy supplier mapping fields
Connects methodology context and project-level impact claims
Referenced by `impact_modules.methodology_id` to standardize methodology structure
References `impact_module_id`, optional `verifier_id`, and status transitions through mint readiness
Stores hashes, anchoring status, and transparency output context
Linked through `impact_claims.verifier_id` for VVB accountability
Enforces quantity reservation, mint confirmation, and rollback controls
Retains `dmrv_verified` and `impact_claim_id` for downstream reporting
Captures `event_type`, severity, and endpoint metadata from security logging
Audience Messaging
Legacy supply remains monetizable while verified dMRV creates institutional-grade evidence depth.
Teams can run one repeatable sequence from supplier intake to public transparency delivery.
Suppliers can list now in legacy mode, then graduate to verified mode for stronger provenance narratives.
Source Alignment
Keep these references in sync whenever the dMRV story is updated for board packs, investor materials, or supplier onboarding collateral.
Governance
This section packages the most important controls into board-ready language and a repeatable review checklist for internal alignment.
Hard gates for status progression and verifier requirements that protect claim integrity.
Confirm all dMRV lanes use intended `projects.dmrv_exempt` values per supplier profile.
Confirm each supplier has an up-to-date `suppliers.dmrv_tier` value.
Confirm claim transitions and verification steps are enforced by admin tooling and API guards.
Confirm mint logs always write `transactions.impact_claim_id` and `transactions.dmrv_verified`.
Confirm `DMRV_REQUIRE_VVB_ASSIGNMENT` and `DMRV_RECONCILIATION_THRESHOLD` are intentionally configured per environment.
Confirm public checkpoint responses include registry issuance, methodology, and verifier metadata.
Next Step
Keep language capability-focused and update this route whenever workflow, controls, or schema surfaces change.