Carbon / ESG Tokenization

What you will build.

Reconcile fictional certificate DEMO-CERT-01 against its source registry. A digital token has been burned, but the registry has not confirmed retirement. Test duplicate certificate claims and disputed evidence without claiming that a digital record establishes environmental impact.

Your working record

Create a private worksheet with columns for the source reference, observed state, responsible system, observation time, expected result and unresolved issue. Use the same fictional case throughout the steps; do not paste live personal or financial records into this exercise.

1. 01Anchor the record in its source registry
2. 02Check competing or disputed claims
3. 03Separate token action from retirement
4. 04Prepare a bounded evidence report

Run the example before changing it.

Inspect the baseline record below. Download and read the complete JavaScript file before running it. It uses only Node’s built-in test and assertion modules; there is no package installation, account connection or secret to configure.

{
  "duplicateClaim": false,
  "disputed": false,
  "registryRetired": true
}

Save it as carbon-esg-tokenization.mjs. Open a terminal in that folder and run:

node --version
node --test carbon-esg-tokenization.mjs

Expected result: four passing tests and zero failures. These tests verify the teaching classifier only. They do not verify a production integration, security boundary or financial outcome.

// Hybrid-Chain offline teaching model: carbon-esg-tokenization
// Fictional fields/states; NOT an API client, authorization system or production implementation.
// No network calls, credentials, payments or file writes. Review before running.
// Requires Node.js 22+. Run: node --test carbon-esg-tokenization.mjs
import test from 'node:test';
import assert from 'node:assert/strict';

export function inspect(record) {
  if (record.duplicateClaim) return 'DUPLICATE_REVIEW_REQUIRED';
  if (record.disputed) return 'EVIDENCE_REVIEW_REQUIRED';
  if (!record.registryRetired) return 'REGISTRY_RETIREMENT_UNCONFIRMED';
  return 'REGISTRY_EVIDENCE_REVIEWABLE';
}

const baseline = {
  "duplicateClaim": false,
  "disputed": false,
  "registryRetired": true
};
const cases = [
  {
    "name": "source evidence reviewable",
    "patch": {},
    "expected": "REGISTRY_EVIDENCE_REVIEWABLE"
  },
  {
    "name": "duplicate source claim",
    "patch": {
      "duplicateClaim": true
    },
    "expected": "DUPLICATE_REVIEW_REQUIRED"
  },
  {
    "name": "disputed supporting evidence",
    "patch": {
      "disputed": true
    },
    "expected": "EVIDENCE_REVIEW_REQUIRED"
  },
  {
    "name": "no registry retirement",
    "patch": {
      "registryRetired": false
    },
    "expected": "REGISTRY_RETIREMENT_UNCONFIRMED"
  }
];

for (const example of cases) {
  test(example.name, () => {
    assert.equal(inspect({...baseline, ...example.patch}), example.expected);
  });
}

Know what the tests demonstrate

source evidence reviewable

REGISTRY_EVIDENCE_REVIEWABLE

duplicate source claim

DUPLICATE_REVIEW_REQUIRED

disputed supporting evidence

EVIDENCE_REVIEW_REQUIRED

no registry retirement

REGISTRY_RETIREMENT_UNCONFIRMED

Now change one fixture at a time. If you change a case’s input without changing its expected result, the test should fail. Read the actual-versus-expected difference and use the walkthrough to decide whether your rule or your expectation needs correcting. Keep an unchanged copy for comparison.

Work through the case, step by step.

1. 01

   Anchor the record in its source registry

   Do this

   1. Create DEMO-CERT-01 with the registry identifier, issuer and relevant methodology reference.
   2. Keep the digital asset reference in a separate field.
   3. Record the owner of measurement verification and the owner of registry reconciliation.

   Expected result

   The worksheet distinguishes provenance of a digital record from the substantive validity of the environmental claim.

   If your result is different

   If no authoritative source certificate can be identified, do not treat token issuance as a substitute.

2. 02

   Check competing or disputed claims

   Do this

   1. Run the baseline, then set duplicateClaim=true and expect DUPLICATE_REVIEW_REQUIRED.
   2. Restore the fixture, set disputed=true and expect EVIDENCE_REVIEW_REQUIRED.
   3. Preserve the conflicting references and assign them to the registry/verifier rather than deleting one.

   Expected result

   The design has a clear hold-for-review path when the source evidence cannot support a clean reconciliation.

   If your result is different

   A content hash cannot by itself detect duplicate issuance in a separate registry or validate a measurement.

3. 03

   Separate token action from retirement

   Do this

   1. Set registryRetired=false and expect REGISTRY_RETIREMENT_UNCONFIRMED.
   2. Add a manual tokenBurned=true field to the worksheet and explain why it does not change that outcome.
   3. Identify the specific registry confirmation needed before describing the certificate as retired.

   Expected result

   The retirement claim depends on recognized source evidence, not merely on a digital asset lifecycle event.

   If your result is different

   If the registry integration is unavailable, leave retirement unconfirmed; do not synthesize a confirmation.

4. 04

   Prepare a bounded evidence report

   Do this

   1. Restore the baseline and record REGISTRY_EVIDENCE_REVIEWABLE.
   2. List which integrity checks you performed and which environmental assertions remain with the independent verifier.
   3. Use Data Vault to plan access to protected supporting files while retaining permitted references for review.

   Expected result

   The report communicates what is inspectable without overstating verified impact or external-registry synchronization.

   If your result is different

   Do not convert a successful local classifier result into a public certification badge.

Review what you produced.

Save the worksheet, unmodified test output, one deliberately failing case and the explanation of its fix. A useful result includes an unresolved item with an owner; it is not just a screenshot of four green tests.

Map the model to actual systems.

The issuer, registry, and independent verifier own methodology, certification, issuance rights, reconciliation, and recognized retirement. External registry integration must be separately confirmed.

For each worksheet field, name the owning system, exact current operation, permission and error behavior. Put “not available” next to any missing operation and assign a dependency owner. Do not substitute the teaching classifier for that missing integration.

Open the current API reference and inspect each operation’s request, response, scope and implementation status. Code examples on this page are local models only; they do not call those operations.

Before a real deployment, the responsible organization must obtain appropriate legal, compliance and security review. The tutorial does not determine licensing, eligibility, entitlement enforceability or financial suitability.

Take the next technical step.

Use your worksheet and failing-case notes in the next walkthrough. Keep the same reference trail so you can see which assumptions become actual observations—and which remain dependencies.

Need help with access or an unavailable integration? Contact the team with a redacted error and the guide step. Never send credentials or private records.