📦 Contents

Chapter 8: Conformance, Certification and the Future of DAC Data Standards

The previous seven chapters described what a WIA-conformant direct air capture system records, how it exposes those records, which operational and MRV events it emits and how it connects to storage sites, grids, registries and enterprise systems. This last chapter asks a different question: how does an implementation show that it does all this, and how can someone who does not trust the vendor check that claim?

The standard answers with a small set of conformance tools that are the same in every PHASE document: three conformance tiers, a signed manifest, a profile manifest that lists requirement by requirement what is and is not supported, and an evidence package built around test vectors and a software bill of materials (SBOM). These tools are copied almost word for word across the six specification files as Annexes E to I. This chapter cites them once, explains what each one proves and what it does not, and shows where the shipped tooling stops and implementers must fill the gap.

One distinction runs through the whole chapter. Conformance to a data standard is a statement about software and records: the system produces well-formed, traceable, signed data. It is not a statement that a given facility removed a given number of tonnes. That second claim belongs to the MRV process and the registry (Chapter 6). A well-built conformance programme keeps the two apart, and a well-built product never lets a conformance badge stand in for a verification statement.

8.1 The Three Conformance Tiers

PHASE-1-DATA-FORMAT §3 and the README define three tiers. The table is short, and each row answers three questions: who makes the claim, what evidence stands behind it, and how often that evidence is renewed.

The tiers are not a strict ladder of quality. Verified adds an independent human judgement once a year. Anchored adds continuity and machine-checkable provenance but, as written, does not require an auditor. A registry that needs both independence and freshness should ask for Verified and Anchored evidence rather than assume that the "higher-sounding" tier includes the other. This book recommends that product pages state the tier together with the date of the most recent evidence, for example "Anchored, evidence package of 2026-07-01", so that a reader can see at a glance whether the claim is current.

8.1.1 Declaring the tier

Implementations declare their tier in the OpenAPI document through the vendor extension x-wia-conformance-tier. OpenAPI 3.1 allows x- extensions on the info object, which is the natural place for a claim about the whole API. The discovery document at /.well-known/wia/direct-air-capture (Chapter 4) should repeat the same value and point to the manifest, so that a client can find the evidence from the tier without searching.

openapi: 3.1.0
info:
  title: Example DAC Operations API
  version: 1.4.2
  x-wia-conformance-tier: Anchored
  x-wia-standard: direct-air-capture
  x-wia-manifest: https://dac.example.com/.well-known/wia/manifest.dsse.json
servers:
  - url: https://dac.example.com/api/v1

The x-wia-standard and x-wia-manifest keys in the excerpt are this book's suggestion; the specification defines only x-wia-conformance-tier. The value should be one of the three tier names spelled exactly as in the specification. A client should treat any other value, or a missing value, as "no claim".

8.1.2 Keeping a tier honest

A tier is a claim about a specific version of a specific build. Two practical rules follow, both recommendations of this book rather than text of the standard:

• A tier lapses with its evidence. If the quarterly Anchored recheck is missed, or the annual Verified audit expires, the declared tier should fall back to Surface until new evidence is published. Leaving the old tier in the OpenAPI document is the most common way a conformance claim becomes misleading.
• A tier does not travel between versions. An audit of build 1.4.2 says nothing about build 1.5.0. The implementation changelog mapping described in Annex H (each supported PHASE version mapped to a build or container digest) is the tool that lets an auditor check which builds a claim covers.

Several annexes (for example Annex E in each PHASE file) refer readers to a "conformance tier in Annex A". No Annex A exists in the shipped specification. The tier definitions live in PHASE-1-DATA-FORMAT §3 and are mirrored in PHASE-2-API-INTERFACE and the README; cite those.

8.2 The Signed Manifest and the Profile Manifest

Two JSON documents carry the conformance claim. The manifest says which implementation, which build and which version of the standard. The profile manifest says, requirement by requirement, what that build supports. The specification allows both to be one document or two; it requires only that both be signed with the same key.

8.2.1 Manifest fields

PHASE-1-DATA-FORMAT §2 lists the contents: standardSlug, version, an implementation block, a profile, per-requirement support status and a Sigstore DSSE signature. The CLI's manifest-template command (§8.4) prints a skeleton that covers only part of this list.

Two details matter in practice. First, the manifest's version is the version of the standard, while implementation.build identifies the product. Mixing them up (writing the product version into version) is an easy mistake, and it makes the manifest claim conformance to a standard version that does not exist. Second, the template's issuedAt is a hard-coded date. Replace it with the actual signing time in UTC. As Chapter 4 noted, it is a property of the manifest and has nothing to do with the timestamps of capture or storage records.

8.2.2 Requirement IDs and the profile manifest

Annex I defines three statuses. A requirement is supported, partial (with a reason) or excluded (with a justification). The purpose is stated plainly: to let deployments of different scope "advertise the subset of normative requirements they satisfy without misrepresenting partial conformance as full conformance".

The specification does not publish a list of requirement IDs. For the operational protocols it does not need to: Chapter 5 showed that each step already has an identifier such as DAC-CAPTURE-REG-001 or DAC-MRV-001. For the data and API layers this book suggests the pattern DAC-<PHASE>-<AREA>-<NNN>, for example DAC-DATA-FAC-001 for the facility schema. Until the working group publishes an official list, state in the manifest which ID scheme you use, so that an auditor can map your IDs to the text.

The CLI's profiles command lists four named deployment shapes: single-tenant (one runtime per organisation), multi-tenant (shared runtime with header-based isolation), federated (a peer-to-peer mesh of runtimes) and air-gapped (batch evidence packages, no live connectivity). For DAC the air-gapped profile is not exotic. Plant control networks are often separated from the internet, and a site may export signed daily bundles rather than expose a live API. Profile names carry a major version, as in Annex I's example WIA-P1-DATA-FORMAT-Edge-only/2, which means version 2 of that named profile, not the second deployment.

The following example combines a manifest and profile manifest for a fictional MRV platform. All names, digests and URLs are illustrative.

{
  "documentId": "wia-direct-air-capture-0007",
  "standardSlug": "direct-air-capture",
  "version": "1.0.0",
  "implementation": {
    "name": "Example MRV Platform",
    "build": "sha256:4f1c...e09a",
    "sbom": "https://mrv.example.com/evidence/1.4.2/sbom.cdx.json"
  },
  "profile": { "named": "air-gapped", "version": 1 },
  "requirementIdScheme": "book-recommended DAC-PHASE-AREA-NNN",
  "requirements": [
    { "id": "DAC-DATA-FAC-001", "status": "supported" },
    { "id": "DAC-DATA-CAP-001", "status": "supported" },
    { "id": "DAC-DATA-CRD-001", "status": "partial",
      "reason": "blockchain block accepted but not populated" },
    { "id": "DAC-API-WS-001",  "status": "excluded",
      "justification": "air-gapped profile: no live WebSocket feed; daily signed bundles instead" },
    { "id": "DAC-MRV-001",     "status": "supported" }
  ],
  "issuedAt": "2026-07-01T09:30:00Z"
}

Note how the excluded entry is phrased. It does not say "not implemented"; it explains why the requirement does not apply to this deployment shape. That is the difference between an honest partial claim and a gap. An auditor reads partial and excluded lines first, because they show where the implementation's own judgement is involved.

Federated deployments add one more document: an aggregated manifest that states the union and the intersection of member profiles (Annex I). For a network of DAC sites reporting into one MRV platform, the intersection is the useful number. It tells a registry which requirements hold for every site, and therefore which claims it can make about the network as a whole.

8.2.3 Signing and anchoring

The standard uses Sigstore for signatures. The manifest bytes are wrapped in a DSSE (Dead Simple Signing Envelope) structure, which holds a payloadType, the base64-encoded payload and one or more signatures, and the signing event is recorded in the Rekor transparency log. The log entry lets anyone confirm that the signature existed at a given time and was not silently replaced. The discovery document is signed with the same key (DATA-FORMAT §4), which ties the live API endpoint to the evidence.

{
  "payloadType": "application/vnd.wia.manifest+json",
  "payload": "eyJkb2N1bWVudElkIjoid2lhLWRpcmVjdC1haXItY2FwdHVyZS0wMDA3Ii...",
  "signatures": [
    { "keyid": "mrv-signing-2026", "sig": "MEUCIQ..." }
  ]
}

The payloadType value above is illustrative; the specification does not fix one. With the Sigstore cosign tool, a typical flow signs the manifest file, stores the resulting bundle (signature, certificate and log inclusion proof) next to it, and lets consumers verify with the bundle and the expected signer identity. Exact flags change between cosign releases, so pin the tool version in CI and record it in the evidence package.

Two operational rules follow from the annexes. Updates are issued as new manifests, and the previous one is kept with a supersede marker. Signing keys are rotated according to the deployment policy, and old public keys stay in a published key history, so that an auditor can verify a manifest from three years ago offline. For DAC this is not a formality: a carbon removal credit may be examined years after issuance, and the evidence that the MRV software was conformant at the time must still verify then.

8.2.4 What a signature does not prove

A valid signature proves who issued the manifest and that it has not been altered. It does not prove that the statements in it are true, that the SBOM is complete, or that the facility captured what its records say. Those questions are answered by the test-vector matrix (for software behaviour), by the audit (for the Verified tier) and by the MRV verification report (for tonnes).

8.3 The Evidence Package

Annex G describes the compliance package as a tarball with four artefacts: the SBOM (CycloneDX 1.5 or SPDX 2.3), the OpenAPI document, the test-vector matrix and the signed manifest. It is the unit an Anchored implementation publishes and a Verified auditor reviews.

A layout that keeps these artefacts predictable might look like this (this book's suggestion):

evidence-1.4.2.tar.gz
|-- manifest.json
|-- manifest.dsse.json          (DSSE envelope + Rekor bundle)
|-- profile-manifest.json       (if kept separate)
|-- sbom.cdx.json
|-- openapi.yaml
|-- test-matrix.json
|-- changelog-mapping.json
`-- README.txt                  (tool versions, how to re-verify)

8.3.1 Test vectors: one positive, one negative, per requirement

Annex G asks that "every normative requirement ... has at least one positive vector and one negative vector" under tests/phase-vectors/, and that conforming implementations run all vectors in CI. That directory is referenced but not shipped, so today every implementer has to write its own vectors. The records of Chapters 2 and 3 suggest many useful pairs. Some of them follow directly from JSON Schema; others need the consistency checks that the schema cannot express.

A matrix entry should record the requirement, the vector files, the result for each direction and, if anything was skipped, the reason. For example:

{
  "build": "sha256:4f1c...e09a",
  "standardVersion": "1.0.0",
  "generatedAt": "2026-07-01T08:55:12Z",
  "results": [
    { "requirement": "DAC-DATA-CRD-002",
      "positive": { "vector": "crd-002-pos.json", "result": "pass" },
      "negative": { "vector": "crd-002-neg.json", "result": "pass" } },
    { "requirement": "DAC-API-WS-001",
      "positive": { "result": "skipped", "justification": "excluded by air-gapped profile" },
      "negative": { "result": "skipped", "justification": "excluded by air-gapped profile" } }
  ]
}

Here "pass" for a negative vector means that the implementation correctly rejected the bad input. Writing the convention into the matrix itself helps readers who are new to the format.

8.3.2 Skipped means failed

Annex G states that vendors must report negative results with the same fidelity as positive ones, and that "a test that is skipped without recorded justification is treated by auditors as a failure". The rule closes a familiar loophole: a suite that quietly skips the awkward tests can report 100 % pass. The justification must refer to something the auditor can check, typically an excluded line in the profile manifest. A skip that cites no profile exclusion is a failure.

8.3.3 Quarterly recheck and drift

Implementations re-publish the evidence package every quarter even when their own source has not changed (Annex G). The reason is environmental drift: a compiler, a dependency or an operating-system image changes under the build. For DAC MRV software, a silently updated date library or number-formatting library can change record timestamps or rounding, which in turn changes tonnage totals. A quarterly rebuild and full vector run is a cheap way to catch this before a verifier does. The SBOM diff between two quarterly packages is often the fastest way to explain a new failure.

The cross-vendor crosswalk that Annex G mentions is not published with this standard today; treat it as planned work.

8.4 Hands-on with the CLI

The standard ships one tool, cli/direct-air-capture.sh (version 1.0.0), a Bash script with four commands. It is a useful starting point and a clear illustration of how much work remains between a template and a conformance programme.

$ ./direct-air-capture.sh manifest-template > manifest.json
$ ./direct-air-capture.sh validate manifest.json
OK: manifest.json declares standardSlug=direct-air-capture
$ echo '{"standardSlug":"WIA-ENE-050"}' > wrong.json
$ ./direct-air-capture.sh validate wrong.json
standardSlug mismatch: got 'WIA-ENE-050', expected 'direct-air-capture'

The second run shows a useful property: the tool rejects the spec-body identifier WIA-ENE-050 in the slug field, which enforces the naming rule of Chapter 1. But a manifest with an empty implementation, a missing requirement list or a product version in version still prints "OK". The Python fallback path also builds its command by inserting the file name into the Python source, so a file name containing a quote will break it. Call the tool only with trusted paths, or quote the path in your own wrapper.

Three references in the repository point to things that are not shipped: the conformance vectors in tests/phase-vectors/, the TypeScript SDK in api/typescript/ (the README's @wia/direct-air-capture example is therefore illustrative) and machine-readable schema files. The schemas exist only as JSON inside PHASE-2-DATA, so the first step of any real tool is to extract them into files and version them.

8.4.1 Extending validate with JSON Schema

The simplest improvement is to validate the manifest against a JSON Schema 2020-12 document. The specification does not publish one, so the following schema is this book's proposal. It encodes the rules of Table 8-2 and Annex I.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/schemas/wia-dac-manifest.json",
  "type": "object",
  "required": ["standardSlug", "version", "implementation", "profile", "requirements", "issuedAt"],
  "properties": {
    "standardSlug": { "const": "direct-air-capture" },
    "version": { "type": "string",
      "pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(-[0-9A-Za-z.-]+)?$" },
    "implementation": {
      "type": "object",
      "required": ["name", "build", "sbom"],
      "properties": {
        "name":  { "type": "string", "minLength": 1, "not": { "const": "REPLACE_ME" } },
        "build": { "type": "string", "minLength": 7 },
        "sbom":  { "type": "string", "format": "uri" }
      }
    },
    "profile": {
      "type": "object",
      "required": ["named", "version"],
      "properties": {
        "named": { "enum": ["single-tenant", "multi-tenant", "federated", "air-gapped"] },
        "version": { "type": "integer", "minimum": 1 }
      }
    },
    "requirements": {
      "type": "array", "minItems": 1,
      "items": {
        "type": "object",
        "required": ["id", "status"],
        "properties": {
          "id": { "type": "string" },
          "status": { "enum": ["supported", "partial", "excluded"] }
        },
        "allOf": [
          { "if": { "properties": { "status": { "const": "partial" } } },
            "then": { "required": ["reason"] } },
          { "if": { "properties": { "status": { "const": "excluded" } } },
            "then": { "required": ["justification"] } }
        ]
      }
    },
    "issuedAt": { "type": "string", "format": "date-time" }
  }
}

A short Node.js script runs this schema with Ajv, which supports draft 2020-12 through its ajv/dist/2020 entry point. The ajv-formats package adds the uri and date-time checks.

// validate-manifest.mjs  (illustrative)
import Ajv2020 from "ajv/dist/2020.js";
import addFormats from "ajv-formats";
import { readFileSync } from "node:fs";

const schema = JSON.parse(readFileSync("wia-dac-manifest.schema.json", "utf8"));
const doc = JSON.parse(readFileSync(process.argv[2], "utf8"));

const ajv = new Ajv2020({ allErrors: true, strict: true });
addFormats(ajv);
const validate = ajv.compile(schema);

if (!validate(doc)) {
  for (const e of validate.errors) console.error(`${e.instancePath || "/"} ${e.message}`);
  process.exit(1);
}
if (doc.issuedAt === "2026-04-26T00:00:00Z") {
  console.error("issuedAt still holds the template placeholder");
  process.exit(1);
}
console.log("manifest OK");

The same pattern extends to the data records themselves: extract the facility, capture, sorbent, storage, verification and credit schemas from PHASE-2-DATA, add the consistency checks from Chapters 2 and 3 as separate functions, and have each positive and negative vector call the same entry point. A thin Bash wrapper can keep the original CLI interface, run the old slug check first and then the schema check, so that existing scripts keep working.

8.5 Facility Certification and Software Certification

FOUNDATION §8.2 separates two kinds of certification. They look similar on paper but answer different questions and involve different bodies.

Neither track certifies tonnes. A certified facility can still have a quarter in which its verified amount is lower than its recorded capture, and an Anchored MRV platform does not improve records from a poorly metered site.

8.5.1 Who certifies

The standard cites ISO/IEC 17065:2012, which sets requirements for bodies that certify products, processes and services. In practice this means that a Verified audit should come from a body whose own procedures meet ISO/IEC 17065, ideally with accreditation from a national accreditation body, and not from a consultancy that also built the implementation. Annex E notes that seven years of evidence retention is "sufficient to satisfy ISO/IEC 17065:2012 audit expectations in most jurisdictions". This is the working group's assessment, not a requirement of ISO/IEC 17065 itself; regulators or registries may demand longer retention, and the deployment policy must then extend it. For DAC it is sensible to align software evidence retention with the record retention of Chapter 2 (seven years raw, thirty years aggregated, verification records permanent), because an auditor looking at an old credit will need both.

Verification of the tonnes themselves follows the registry's methodology and is carried out by verifiers the registry accepts. Chapter 6 covered that process. The conformance evidence from this chapter makes the verifier's work easier but does not replace it.

8.5.2 Disputes and appeals

FOUNDATION §8.3 routes disputes by type: technical disputes to the Technical Committee, certification disputes to independent arbitration, data disputes to third-party verification, with an appeal process "clearly defined". The specification does not yet define that process. Implementers can prepare for it in one concrete way: keep every artefact that a dispute would need already signed and dated. A data dispute about a storage event, for example, is resolved from the custody-transfer meter reading, the storage event record, the verification report and the manifest of the software that processed them. If all four exist, are signed and are anchored, the dispute becomes a question of reading evidence rather than reconstructing it.

8.6 Versioning and Governance

The standard follows Semantic Versioning 2.0.0 throughout. A major version marks a backwards-incompatible change to a normative requirement; a minor version adds requirements without breaking existing implementations; a patch is editorial only (Annex H). PHASE-2-DATA §10 applies the same rules to schemas and adds a field-level marker, "deprecated": true. Errata are issued as patch releases, tracked in a public errata register and signed by the working group chair.

Governance is described twice. FOUNDATION §8.1 gives an annual review cycle and an amendment process of RFC, community review, vote and update, run by the WIA-ENE-050 Working Group. PHASE-1-DATA-FORMAT §8 says the WIA Standards working group reviews open issues at the start of every minor release cycle, tracked as GitHub issues with the direct-air-capture label, and publishes a decision log with the release notes. The two are compatible if the annual review is read as the minimum cadence, and the per-release review as the routine one.

8.6.1 Inconsistencies to reconcile

Several rules in the specification conflict with one another. They are listed here so that implementers can make a deliberate choice rather than inherit an accidental one.

None of these conflicts can be settled by an implementer. The right action is to open an issue with the direct-air-capture label, cite the conflicting sections and, meanwhile, adopt the most conservative reading. For deprecation windows, "most conservative" means the longest window, because a DAC credit may be verified or retired long after its underlying records were created, and those records must still validate.

8.6.2 Why long windows matter in carbon removal

In carbon removal a record may be read decades after it was written, for example during post-injection storage monitoring or when a buyer re-examines a retired credit. Schema changes therefore need a migration path for historical records. Two practices help: every record carries the schema version it was written against, so a validator can pick the right schema; and migrations add derived fields instead of rewriting signed originals, because rewriting a signed record breaks its evidence chain.

8.7 The Future of DAC Data Standards

FOUNDATION §9 lists a fifth phase, Ecosystem, after the four PHASE documents: public dashboards, carbon market integration, a research data platform and policy integration. The shipped specification does not yet contain Phase 5 text. The following sections describe the questions such work will have to answer. They are kept qualitative on purpose; this book makes no forecasts about market size or deployment.

8.7.1 From dashboards to comparable public data

Chapter 7 described open-data aggregation and a tiered access model. A public dashboard is only as meaningful as the comparability of what it aggregates. Before any dashboard is built, Phase 5 will need agreed definitions for the published quantities (gross capture, stored amount, verified net removal), for the reporting period and for the treatment of uncertainty. Without them, two facilities reporting the same "tonnes" could mean different things. The conformance tools of this chapter are the natural way to label a data source's quality: a dashboard can show, next to each facility, the conformance tier and date of the software that produced its data.

8.7.2 Durability-tiered claims

The standard already records storage method and a permanence class as enumerations (Chapters 1 and 3). The direction of travel in carbon removal is to make durability explicit in the claim itself, so that a tonne stored in a geological formation and a tonne stored in a product are not sold as interchangeable. For a data standard this means that the permanence class should travel with the credit through every system, including retirement, and that registries and buyers can filter on it. The current classification of utilisation pathways is questionable in places, as Chapter 5 noted. Future versions will need to base any durability class on evidence that a verifier can check, rather than on labels.

8.7.3 Interoperable registries and corresponding adjustments

The credit schema lists Puro.earth, Verra, Gold Standard, ACR and "Other" as registries. Today each registry has its own identifiers and data model. Two developments raise the stakes for interoperability. The first is the risk of the same tonne appearing in more than one registry, which the evidence chain of Chapter 3 is designed to expose. The second is international transfer under Article 6 of the Paris Agreement, where a "corresponding adjustment" to the host country's national accounting is required for certain uses of a credit. A data standard can support both by carrying stable, globally unique identifiers for the storage event and the credit, and by recording the authorisation and adjustment status of each transfer as explicit fields rather than free text.

8.7.4 Data needs of electrochemical DAC

The facility schema includes electrochemical-dac, but the operational and sorbent records were clearly designed around thermal swing processes: regeneration temperature, heat input, sorbent loading and degradation per cycle. Electrochemical processes are driven by voltage rather than heat. A data model that serves them well will likely need fields for electrical energy per cycle, the conditions of the cell (voltage, current, and the charge passed per unit of CO2), and the ageing of electrodes, membranes or other active materials instead of sorbent loading. Because electricity is the main input, time-resolved emission factors of the electricity used become even more central to net removal than they already are (Chapter 7, §7.3). None of this requires a new architecture. The extension mechanisms and profile manifests of this chapter let a vendor add such fields today, declare them as extensions and later propose them for standardisation through the normal RFC process.

8.7.5 Evidence that outlives its software

Storage monitoring and credit claims last longer than any software product, signing key or cloud provider. Future versions will need a plan for retiring a transparency log or a signature algorithm, for example by re-anchoring older evidence in a newer log before the old one closes. This is an open problem for the whole field, worth raising early in the working group.

Summary

• The standard defines three conformance tiers: Surface (self-attested), Verified (annual third-party audit) and Anchored (continuous evidence per Annex G). They measure different things; state the tier together with the date of its evidence.
• A signed manifest names the standard, the build, the SBOM and the profile. A profile manifest marks each requirement as supported, partial or excluded, with a reason or justification. The CLI template lacks the requirement list and signature and must be completed.
• The evidence package contains the SBOM, the real OpenAPI document, a test-vector matrix with positive and negative results per requirement, and the signed manifest. A skip without justification is a failure, and the package is re-published quarterly.
• The shipped CLI checks only standardSlug; test vectors, the TypeScript SDK and schema files are not shipped. Extending validation with JSON Schema 2020-12 and custom consistency checks is the first practical step.
• Facility certification and software certification are separate tracks, and neither certifies tonnes. That remains the job of MRV verification and the registry.
• The specification's deprecation windows (90 days, 180 days, 6 months, 12-month sunset) and several other statements conflict. Adopt the most conservative reading and raise the conflicts through the governance process.
• Future work covers comparable public data, durability-tiered claims, interoperable registries, electrochemical DAC and evidence that stays verifiable for decades.

Conformance checklist

This chapter closes the book. A direct air capture plant turns air into a stream of CO2 and, just as importantly, into a stream of records. The standard described in these chapters gives those records a common shape, a common interface and a common way to prove their integrity. Whether a tonne of removal is real will always be decided by measurement and verification; the value of a data standard is that it makes that decision possible to check, by anyone, long after the plant has moved on to its next cycle.