Direct air capture (DAC) is easy to describe and hard to account for. A machine pulls ambient air across a material that binds carbon dioxide, releases that CO2 as a concentrated stream, and hands it to a pipeline, an injection well or a mineralization site. What makes DAC difficult is not that description but what must be proven afterwards. How many tonnes left the atmosphere? How many of them came back as emissions from the energy that ran the plant? How many will stay stored, and for how long? Who has already claimed them? Every one of those questions is answered by data, and data from different operators, storage sites, verifiers and registries is useful only if it follows shared rules.
This chapter lays the groundwork for the rest of the book. It explains why capturing CO2 from air is physically harder than capturing it from a smokestack, how the three main technology families work, what happens to a molecule of CO2 from the contactor to the storage site, and why a credible removal claim has to be expressed as net removal rather than gross capture. It then introduces the WIA Direct Air Capture standard: its identifiers, its five-layer architecture, its seven-step data flow and the documents that make it up. The chapter closes with a map of the book and of the companion simulator.
Throughout the book three kinds of statement are kept apart. Specification statements are what the WIA standard itself says, cited by document and section (for example, FOUNDATION §4.4). External references are published standards such as ISO 14064-2, which the WIA standard builds on but does not replace. Book recommendations are the authors' proposals for filling gaps or resolving inconsistencies in the specification; they are always labelled as such and carry no normative weight.
Carbon capture technologies differ first of all in where they take CO2 from. Point-source carbon capture and storage (CCS) attaches a capture unit to a flue-gas stream at a power plant, cement kiln or chemical plant. DAC takes CO2 from the open atmosphere. That single difference has three consequences: DAC works with a far more dilute source, it can in principle be sited anywhere, and it can address emissions that have already happened.
Ambient air currently contains roughly 420 parts per million (ppm) of CO2 by volume, or about 0.042 %. Flue gas from a coal-fired boiler typically contains on the order of 12–15 % CO2 by volume, and flue gas from a natural-gas combined-cycle plant roughly 3–4 %. Air is therefore several hundred times more dilute than coal flue gas and around a hundred times more dilute than gas-turbine exhaust.
A rough calculation shows what this means physically. At 420 ppm, and with a molar mass of 44 g/mol for CO2 against about 29 g/mol for dry air, one kilogram of air carries about 0.64 g of CO2. To collect one tonne of CO2 even at 100 % capture, a plant must therefore process on the order of 1,600 tonnes of air, which at a typical near-surface air density of about 1.2 kg/m³ is roughly 1.3 million cubic metres. Real contactors capture only part of the CO2 in each pass, so the actual volume is larger. This is why every DAC design is dominated by large contact areas, fans and low pressure drop, and why airflow appears as a first-class measurement in the WIA operational record (Chapter 2).
Separating a gas from a mixture takes a minimum amount of work, and that minimum grows as the target gas becomes more dilute. For an ideal separation of a trace component, the minimum work per mole is approximately RT·ln(1/x), where x is the mole fraction. At 25 °C and x = 420 ppm this gives about 19 kJ per mole of CO2, or roughly 0.44 GJ (about 0.12 MWh) per tonne. The same estimate for 12 % flue gas gives about 5 kJ/mol. These are thermodynamic floors, not engineering targets: real plants must also move air, heat and cool sorbent or solvent, and compress the product. Actual energy use is therefore a multiple of the floor, and it varies with technology, climate and plant design.
Two things follow for anyone building data systems. First, specific energy (energy per tonne of CO2, expressed in MWh/t or GJ/t) is the single most important efficiency metric of a DAC plant, and the standard reports it in both the facility and the operational records. Second, because energy is large, the source of that energy decides whether a plant removes CO2 at all. A plant running on carbon-intensive electricity can emit a substantial fraction of what it captures. A data standard that records captured tonnes without recording the energy mix cannot support a removal claim.
Point-source CCS reduces new emissions: the CO2 would otherwise have left the stack. Carbon dioxide removal (CDR) takes CO2 that is already in the atmosphere and stores it durably. DAC with durable storage is a CDR method; so are, for example, bioenergy with CCS, enhanced rock weathering, biochar and forestation. The methods differ in how directly the removed quantity can be measured and in how long the carbon stays out of the atmosphere.
| Approach | CO2 source | Removes past emissions? | How the captured quantity is measured | Main data challenge |
|---|---|---|---|---|
| Point-source CCS | Flue gas (percent-level CO2) | No – avoids new emissions | Metering of the captured stream | Baseline: what would have been emitted |
| DAC with storage | Ambient air (~420 ppm) | Yes | Metering of the captured stream plus storage monitoring | Energy and embodied emissions; storage permanence |
| Bioenergy with CCS | Biomass combustion or conversion | Yes, if biomass is sustainably sourced | Metering plus biomass supply-chain accounting | Land use and supply-chain emissions |
| Nature-based removal (forests, soils) | Atmosphere via photosynthesis | Yes | Sampling, remote sensing and models | Measurement uncertainty and reversal risk |
The practical advantage of DAC for a data standard is visible in the fourth column. The captured CO2 leaves the plant as a physical stream that can be metered, and that meter reading can be tied to a storage event. This makes a chain of evidence from atmosphere to storage feasible. The corresponding weakness sits in the fifth column: the gross number is easy to measure, but a removal claim depends on the deductions, and those are spread across energy suppliers, material suppliers and storage operators.
The WIA foundation document (FOUNDATION §2.2) groups DAC into three families. The facility schema in PHASE-2-DATA carries them as the enumeration technology.type with the values solid-sorbent-dac, liquid-solvent-dac, electrochemical-dac and hybrid-dac.
Solid sorbent systems use a porous support, typically functionalised with amines, that binds CO2 at ambient conditions. Air is blown through a bed or structured contactor until the sorbent approaches saturation. The unit is then closed and the sorbent is regenerated, commonly by a temperature–vacuum swing adsorption (TVSA) step in which the bed is heated and the pressure lowered so that CO2 desorbs. The specification gives a regeneration range of 80–120 °C. That temperature level matters for plant design: it can be supplied by low-grade heat such as waste heat, geothermal heat or heat pumps, rather than by combustion. Solid sorbent plants are usually built from many identical modules. Modularity helps with scaling, but it also means a facility produces many parallel cycle records, one per module, that must be aggregated consistently.
Sorbents degrade over repeated cycles through oxidation, loss of amine and exposure to contaminants, so working capacity declines over time. This is why the standard gives the sorbent its own record type, with loading, degradation and lifecycle fields (Chapter 2, §2.4).
Liquid solvent systems circulate an alkaline solution, typically potassium hydroxide (KOH), over large packed contactors. CO2 in the air reacts with the hydroxide to form carbonate. In the widely described design the carbonate is transferred to a calcium loop: it reacts with calcium hydroxide to precipitate calcium carbonate, which is then heated in a calciner to release a concentrated CO2 stream and regenerate calcium oxide. The calcination step runs at roughly 900 °C; the specification writes this as ">900 °C for calcination". High-temperature heat is therefore the central design question for this family, and how that heat is supplied directly affects net removal. Liquid systems are usually built as large, centralised plants with high throughput per site. They draw on chemistry long used in industry, but that does not by itself make DAC plants of this type mature.
Electrochemical approaches use electrical potential rather than a temperature swing to capture and release CO2. Examples include cells with redox-active carriers that bind CO2 in one oxidation state and release it in another, and electrochemically driven pH-swing processes. The specification describes them as "voltage-driven" and "emerging". For data purposes they differ from the other two families in one important way: energy input is almost entirely electrical, so metering electricity and its carbon intensity is close to the whole energy story. On the other hand, the performance parameters of cells, such as current efficiency and cell degradation, have no dedicated fields in the current schemas. Chapter 8 returns to this gap.
hybrid-dac valueThe enumeration also contains hybrid-dac, but the specification never defines it. A plant might combine a solid sorbent with electrochemical regeneration, or pair DAC with a point-source unit that shares compression and storage. Book recommendation: an implementation that uses hybrid-dac should state the combined processes in an extension field, and should keep separate energy and capture metering for each process so that net removal can still be calculated per process.
| Property | Solid sorbent | Liquid solvent | Electrochemical |
|---|---|---|---|
technology.type | solid-sorbent-dac | liquid-solvent-dac | electrochemical-dac |
| Capture medium | Amine-functionalised porous solid (other sorbent classes exist) | Alkaline solution, typically KOH | Redox-active carriers or pH-swing electrolytes |
| Release mechanism | Temperature–vacuum swing | Calcium loop with high-temperature calcination | Change in electrical potential |
| Regeneration temperature (specification) | 80–120 °C | around 900 °C (calciner) | No thermal swing |
| Dominant energy form | Low-grade heat plus electricity for fans and vacuum | High-temperature heat plus electricity | Electricity |
| Typical build | Many identical modules | Large centralised plant | Stacked cells, potentially modular |
| Maturity (qualitative) | Operated at demonstration and early commercial scale | Demonstrated; large plants in development | Mostly laboratory and pilot scale |
| Data emphasis | Per-module cycles, sorbent degradation | Heat source and fuel, solvent make-up | Electricity metering, cell performance |
The comparison is qualitative on purpose. Published figures for energy use, cost and capacity vary widely between designs and reporting boundaries, and this book does not repeat vendor claims as if they were measured facts. What the table shows is that each family stresses different parts of the data model. A standard that fits only one of them would fail the others.
Whatever the technology, a tonne of CO2 passes through the same sequence of physical stages. Each stage produces measurements, and each measurement ends up in one of the record types defined in PHASE-2-DATA.
AMBIENT AIR (~420 ppm CO2)
|
v
[1] ADSORPTION / ABSORPTION airflow, CO2 in/out, sorbent saturation
| (sorbent or solvent approaches saturation)
v
[2] REGENERATION heat or electrical input, temperature, pressure
| (TVSA, calcination or electrochemical release)
v
[3] CONCENTRATED CO2 STREAM purity, contaminants, flow
|
v
[4] COMPRESSION / DEHYDRATION electricity, custody-transfer meter reading
|
v
[5] TRANSPORT pipeline, ship or truck; losses
|
v
[6] STORAGE
+-- geological-storage injection data, post-injection monitoring
+-- mineralization injection data, mineralisation monitoring
+-- utilization product, LCA, end-of-life assessment
+-- ocean-storage (listed in the enum; see text)Stages 1 and 2 alternate in a cycle, and the operational record carries the current phase as operationalState (adsorption, regeneration, idle, maintenance or error). Stage 3 is where CO2 purity is measured; the operational protocols set a purity gate that the product must pass before it moves on (Chapter 5). Stage 4 is where the custody-transfer meter sits, and that reading is the natural source of truth for the amount handed over to storage. Stages 5 and 6 produce the storage event record (Chapter 3).
The facility schema records a storage method and a permanence class, and the storage event schema repeats the method. The values are enumerations, and it is important to read them as labels defined by the standard, not as scientific findings.
| Field | Values | How to read them |
|---|---|---|
storage.method (facility) | mineralization, geological-storage, ocean-storage, utilization, hybrid | The pathway the facility uses. hybrid exists only in the facility record. |
storageMethod (storage event) | mineralization, geological-storage, ocean-storage, utilization | The pathway of one specific delivery. A hybrid facility reports each delivery under one concrete method. |
storage.permanence | permanent, >10000-years, >1000-years, varies | Durability class claimed for the pathway. The thresholds are the standard's category boundaries, not measured storage lifetimes. |
Two cautions apply. First, the foundation document associates geological storage with ">1000 years" and mineralization with ">10,000 years", but it gives no source, and actual durability depends on site selection, injection practice and monitoring. A data system should store the class exactly as declared and link it to the monitoring plan that supports it. It should not derive the class from the storage method. Second, the utilization protocol (PHASE-3 §3.3) sorts utilization pathways into permanent, long-term and short-term groups and excludes short-term uses such as beverage carbonation and synthetic fuels from crediting. Some of its placements are open to question, for example listing polyurethane as "permanent (if stable)" and enhanced weathering and biochar as "utilization". Chapter 5 presents that classification as the specification's own. The ocean-storage value appears in the enumerations but has no protocol of its own in PHASE-3, so an implementation that uses it has no standardised monitoring requirements to point to.
The number a DAC plant can measure most easily is gross capture: the mass of CO2 in the product stream. The number a buyer, a registry or a national inventory needs is net removal: how much less CO2 is in the atmosphere because the plant operated and its product was stored. The two can differ considerably.
Net removal (t CO2) = CO2 durably stored
− emissions from energy used to operate the plant and handle the CO2
− embodied (life-cycle) emissions of plant, sorbent or solvent, and consumables, allocated to the period
− process losses and leakage between capture and storage
Each term brings a separate data requirement.
geothermal, solar, wind, hydro, nuclear, natural-gas, grid-mix) and a renewable flag; the operational record adds a renewablePercentage. A grid-mix value is useless for accounting unless the emission factor and its source are recorded too.A simple example with invented figures shows the effect. Suppose a facility's storage partner confirms 1,000 t of CO2 stored in a reporting period. Energy use in the same period, multiplied by recorded emission factors, gives 150 t. The period's share of embodied emissions from the life-cycle assessment is 50 t, and metered losses between plant and wellhead are 10 t. Net removal is then 1,000 − 150 − 50 − 10 = 790 t. That is the quantity a verifier could consider for crediting, before any further conservative deduction for measurement uncertainty (Chapter 6). The same plant on a more carbon-intensive grid could see its net figure fall much further, which is why the energy term cannot be left out of the data model.
Project-level greenhouse-gas accounting of this kind follows ISO 14064-2 (quantification, monitoring and reporting of emission reductions and removal enhancements at project level), and third-party verification follows ISO 14064-3. The WIA foundation document also lists ISO 27916. That standard deals with CO2 storage in connection with enhanced oil recovery; it is not a general verification standard for DAC, and this book does not treat it as one. The WIA standard does not redefine these accounting methods. Its job is to ensure that every quantity those methods need exists as a typed, timestamped, traceable field.
FOUNDATION §4 states six principles. Read as policy they sound like aspirations. Read as engineering, each implies specific fields, processes or checks, and that reading is used throughout this book.
| Principle | What the specification says | What it requires in data or process | Where in this book |
|---|---|---|---|
| Transparency | Report capture rates, energy per tonne, sorbent efficiency, storage method and verification status in standard formats | Operational records with capture, energy and sorbent blocks; public aggregation with tiered access | Ch. 2, Ch. 7 §7.5 |
| Verifiability | Claims independently verifiable through audits, continuous monitoring, tamper-evident records and open APIs | Verification report records, stable IDs linking capture to credits, signed evidence and hash anchoring | Ch. 3, Ch. 6 |
| Interoperability | Integrate with other facilities, storage infrastructure, registries, energy systems and climate accounting | Shared schemas, discovery endpoint, documented API and field mappings to registry formats | Ch. 4, Ch. 7 |
| Accuracy | CO2 capture ±5 %, energy ±3 %, storage verification >95 % confidence, hourly or better resolution | Uncertainty fields next to quantities; calibration records; sampling and aggregation intervals | Ch. 2 §2.6, Ch. 6 §6.3 |
| Permanence | Durable storage with long-term monitoring plans | Permanence class plus a linked monitoring plan; retention rules that outlive the plant | Ch. 3 §3.1, Ch. 5 §5.5 |
| Additionality | Removal beyond business-as-usual; no double counting; clear baseline | One-tonne-one-credit linkage; retirement status that propagates; baseline documentation in the methodology field | Ch. 3 §3.4, Ch. 6 §6.4 |
Two principles need further comment. Accuracy is the only one with numbers attached, and those numbers only make sense if each reported quantity carries its uncertainty and the calibration that supports it. A capture figure without an uncertainty cannot be checked against a ±5 % target. Additionality is largely a question of economics and methodology rather than data. The one part of it that data can enforce is the ban on double counting: the same tonne must not back two credits, and a retired credit must not reappear. That is a referential-integrity problem, and it is solved by the ID chain described in Chapter 3.
The standard appears under two names. The slug direct-air-capture is used wherever software has to find the standard: in the signed manifest's standardSlug field, in the discovery path /.well-known/wia/direct-air-capture, in the command-line tool direct-air-capture.sh and in the repository folder. The designation WIA-ENE-050 appears in the headings of the specification documents and places the standard in the energy (ENE) category of the WIA series. They refer to the same standard. Book recommendation: machine-readable artefacts should use the slug, which is what the manifest and discovery mechanisms check, and human-facing documents may cite both, for example "WIA-ENE-050 (direct-air-capture)".
FOUNDATION §3.2 describes five layers. They separate concerns that are often mixed together in a plant's own software.
+--------------------------------------------------------------+
| 5 APPLICATION dashboards, carbon markets, compliance |
| reporting, research data |
+--------------------------------------------------------------+
| 4 VERIFICATION third-party auditors, credential issuance, |
| hash anchoring, registry submission |
+--------------------------------------------------------------+
| 3 INTEGRATION storage sites, pipelines, energy systems, |
| MRV systems |
+--------------------------------------------------------------+
| 2 DATA formatters to WIA schemas, validation, |
| STANDARDIZATION aggregation, API gateway |
+--------------------------------------------------------------+
| 1 FACILITY sensors and IoT devices, process control, |
| local time-series storage |
+--------------------------------------------------------------+The facility layer is the plant's own world: sensors, the process control system that switches between adsorption and regeneration, and a local historian. The standard does not prescribe how this layer works internally. The data standardization layer is where WIA begins. Formatters convert vendor-specific tags into WIA records, validators check them against the schemas, aggregators combine modules into facility totals, and an API gateway exposes the result. The integration layer connects the plant to its counterparts: storage operators, pipeline networks, energy suppliers and MRV systems. The verification layer is where independent parties examine the evidence, where certificates and verifiable credentials are issued, and where records may be hash-anchored and submitted to registries. The application layer holds everything built on top: public dashboards, trading platforms, regulatory and voluntary reports and research datasets.
The layering has a practical consequence. A plant can conform to the data standardization layer without running any blockchain or registry integration, and a registry can consume verified records without seeing raw sensor data. Conformance tiers (Chapter 8) are built on this separation.
FOUNDATION §3.3 describes the data flow as seven steps.
| Step | What happens | Main output |
|---|---|---|
| 1 CAPTURE | Sensors and process control produce raw process data | Vendor-specific time series |
| 2 STANDARDIZE | Raw data is mapped to WIA schemas and validated | Real-time capture records, sorbent records |
| 3 STORE | Validated data is written to a time-series database and archived | Retained records under the retention rules |
| 4 VERIFY | Capture, energy and storage data go to MRV and third-party audit | Verification report |
| 5 CERTIFY | Verified quantities are expressed as credentials; hashes may be anchored | Verifiable credential, anchoring receipt |
| 6 REGISTER | Certificates are submitted to a carbon registry and credits are issued | Carbon credit record with serial number |
| 7 PUBLISH | Aggregated data is exposed through public APIs and dashboards | Open-data aggregates |
Note that the physical storage of CO2 does not appear as its own step; "STORE" in step 3 means storing data. The storage event for the CO2 itself is generated in the integration layer and enters the flow as evidence at step 4. Keeping these two meanings of "storage" apart avoids a common modelling mistake: treating a database write as proof that CO2 has been injected.
The standard's README describes four PHASE documents covering data format, API interface, protocol and integration. The repository actually contains six files, and their roles do not match their names exactly.
| File | Actual content | Main use in this book |
|---|---|---|
PHASE-1-FOUNDATION.md | Purpose, terminology, architecture, principles, accuracy and retention, related standards, governance, roadmap | Ch. 1, Ch. 2 §2.6, Ch. 8 |
PHASE-1-DATA-FORMAT.md | A generic template: manifest, conformance tiers, discovery, time and versioning; no DAC schemas | Ch. 4 §4.1, Ch. 8 |
PHASE-2-DATA.md | The DAC schemas: facility, operational, sorbent, storage, verification and credit records, API envelope, validation and schema versioning | Ch. 2, Ch. 3 |
PHASE-2-API-INTERFACE.md | The same generic template as PHASE-1-DATA-FORMAT with the phase name changed | Ch. 4 §4.1 |
PHASE-3-PROTOCOL.md | Operational, storage, safety, MRV, data management and maintenance protocols | Ch. 5, Ch. 6 |
PHASE-4-INTEGRATION.md | REST, GraphQL and WebSocket interfaces; storage, energy, registry, credential, enterprise and open-data integration | Ch. 4, Ch. 6, Ch. 7 |
Three consequences follow. First, the most concrete schemas are in PHASE-2-DATA, not in the file called DATA-FORMAT. Second, the actual API definitions are in PHASE-4 §2 and PHASE-2-DATA §8, while the shipped api/openapi.yaml is only a stub. Chapter 4 shows how to derive a complete OpenAPI 3.1 document. Third, the roadmap in FOUNDATION §9 uses "Phase 1" to "Phase 5" in yet another sense, as stages of adoption from foundation to ecosystem. When this book says "PHASE-2-DATA" it means the file; when it says "Phase 5" it means the roadmap stage.
Several appendices (Annex E to I) are repeated almost word for word in all six files. They cover implementation notes, the adoption roadmap, test vectors and conformance evidence, versioning and deprecation, and interoperability profiles. This book discusses them once, in Chapter 8. Some annexes refer to "Annex A" and "Annex D", which do not exist in any file. Where the repeated annexes and the main text disagree, for example on deprecation windows, the disagreement is noted rather than silently resolved.
The chapters follow the path of a tonne of CO2 through the data system, from the plant record to the conformance claim.
| Chapter | Topic | Main sources |
|---|---|---|
| 1 | Fundamentals, net removal, architecture and document map | FOUNDATION |
| 2 | Data Format I: facility, operational and sorbent records; units; measurement requirements; consistency checks | PHASE-2-DATA §2–4, FOUNDATION §5.1 |
| 3 | Data Format II: storage events, verification reports and carbon credits as one chain of evidence; API envelope; validation and versioning | PHASE-2-DATA §5–10 |
| 4 | The API: discovery, authentication, REST, GraphQL, WebSocket and writing a full OpenAPI document | PHASE-4 §2, PHASE-1-DATA-FORMAT, PHASE-2-API-INTERFACE |
| 5 | Operational protocols: capture cycles, CO2 collection, storage, safety and data management as data events | PHASE-3 |
| 6 | MRV, uncertainty, registries, verifiable credentials and on-chain anchoring | PHASE-3 §5, PHASE-4 |
| 7 | Integration with storage sites, energy systems, enterprise reporting and open data; reference architecture and security | PHASE-4 |
| 8 | Conformance tiers, manifests, evidence packages, the CLI, certification, governance and future directions | Annexes E–I, FOUNDATION §8–9, cli/ |
Readers with different roles can take different paths. Plant software and controls engineers should read Chapters 2, 5 and 7 closely. MRV and registry developers should concentrate on Chapters 3 and 6. Verifiers and auditors will find the evidence requirements in Chapters 3, 6 and 8. Product managers can read this chapter and Chapter 8 for the overall picture, and Chapter 6 for how credits are produced.
The standard ships with a browser-based simulator with five tabs. It is a teaching tool, not a reference implementation. Its code samples use fixed example values, such as a maximum sorbent loading and a cycle lifetime, that should not be read as typical real-world performance.
| Tab | What it shows | Related chapters |
|---|---|---|
| Data Format | Sample facility and capture records | Ch. 2, Ch. 3 |
| Algorithms | Sorbent efficiency and lifetime calculation, capture-rate optimisation | Ch. 2 §2.4 and §2.7, Ch. 5 §5.3, Ch. 7 §7.3 |
| Protocol | Capture operation and storage protocol steps | Ch. 5 |
| Integration | Integration architecture between plant, storage and monitoring | Ch. 4, Ch. 7 |
| QR & VC | Carbon removal certificate as a verifiable credential and QR code | Ch. 6 §6.5 |
The specification's examples name real operators and sites, with operational figures that are not published data and in some cases contradict each other. This book does not reuse those figures. Where an example needs a facility, it uses a fictional identifier such as dac-example-reykjanes-01. Where an example needs numbers, they are chosen for easy arithmetic and are labelled as illustrative. Endpoints written in the specification as if they were live services are shown as example.com addresses or marked as illustrative.
hybrid-dac value. Each family puts weight on different parts of the data model.direct-air-capture and WIA-ENE-050), and six specification files whose names do not fully match their content. This chapter's document map is the guide for the rest of the book.