📦 Contents

Chapter 5: Operational Protocols — Capture Cycles, Storage and Safety as Data Events

Chapters 2 to 4 described what a DAC record looks like and how it travels between systems. This chapter turns to what those records exist to prove: what actually happened at the plant. PHASE-3-PROTOCOL describes pre-operation checks, the loading and stripping of sorbent beds, purification, compression and metering of the CO2, storage, leak and emergency response, and quality control of the data. Read as a data standard, every step of every procedure is a point at which something should be written down in a form a verifier can check later.

A removal claim rests on a chain of evidence that begins long before the storage event: an uncalibrated meter or a stretch of suspect data weakens every tonne that follows. The chapter therefore walks through the protocols in the order of the capture chain and asks, for each, which record it should emit and which checks a validator can run on it.

As in earlier chapters, three kinds of statement are kept apart. Specification statements are what PHASE-3-PROTOCOL (or another WIA document) says, cited by section. External references are published standards or well-established physics. Book recommendations fill gaps in the specification and are labelled as such. Most numbers in PHASE-3-PROTOCOL — durations, temperatures, thresholds — are an example configuration that a facility replaces with its own design data.

5.1 The Protocol ID System

PHASE-3-PROTOCOL gives every procedure an identifier of the form DAC-<AREA>-<TOPIC>-<NNN> and a version number (all are version 1.0 in the current draft). The areas follow the capture chain: capture operations, storage, safety, verification, data management and maintenance. Verification (DAC-MRV-001) is the subject of Chapter 6; the other five areas are covered here.

5.1.1 Why every step should emit a record

PHASE-3-PROTOCOL is written as procedures, not as data. It defines only one payload itself — the adsorption cycle record in §2.2.1 — and relies on PHASE-2-DATA for the other schemas. Yet the procedures are exactly what a verifier asks about: was the checklist completed, did regeneration reach temperature, was the stream within purity when it was metered?

The book therefore recommends a simple rule: each protocol step that changes the state of the plant, the CO2 inventory or the trustworthiness of the data emits a record carrying the protocol ID and version that governed it. The ID and version let an auditor match the record to the procedure revision that applied. Records are append-only. A correction is a new record that points to the one it corrects, never an edit in place.

A minimal common envelope for these events, proposed by the book and carried in the extension space that PHASE-2-DATA allows, looks like this:

{
  "eventType": "protocol-step",
  "protocolId": "DAC-CAPTURE-REG-001",
  "protocolVersion": "1.0",
  "facilityId": "dac-example-reykjanes-01",
  "moduleId": "m03",
  "timestamp": "2026-03-14T06:42:10Z",
  "step": "heat-up-complete",
  "recordedBy": { "type": "system", "id": "plc-m03" },
  "supersedes": null
}

The recordedBy field separates machine events from operator entries. DAC-DATA-COL-001 forbids manual entry of primary data; sign-offs and operator decisions are legitimate manual records but must never be mixed up with measurements.

5.2 Pre-Operation Checks and the Operating Envelope

DAC-CAPTURE-PRE-001 defines three checklists. The daily list covers sorbent saturation (below 90 % before starting a new cycle), energy availability, ambient conditions, airflow, data logging, CO2 purity sensor calibration, storage availability and the next day's weather. The weekly list adds physical inspection of the sorbent, pressure-vessel integrity, safety-system and emergency-shutdown tests, temperature-sensor calibration and a review of maintenance logs. The monthly list adds full sensor calibration, sorbent performance analysis, an energy-efficiency audit, third-party equipment inspection, a safety drill and a regulatory compliance check.

5.2.1 Checklists as auditable records

A checklist on paper proves little; one that is timestamped, signed and linked to its calibration certificates proves a great deal. The book recommends that each completed checklist be stored as one record, with one line per item and an explicit result for each: pass, fail or not-applicable with a reason. An item left blank is treated the same way the WIA conformance annexes treat a skipped test: as a failure (Annex G).

{
  "eventType": "checklist",
  "protocolId": "DAC-CAPTURE-PRE-001",
  "protocolVersion": "1.0",
  "checklist": "weekly",
  "facilityId": "dac-example-reykjanes-01",
  "completedAt": "2026-03-09T07:15:00Z",
  "items": [
    { "item": "esd-system-test", "result": "pass",
      "evidence": "work-order/WO-2026-0311" },
    { "item": "temperature-sensor-calibration", "result": "pass",
      "evidence": "calibration/CAL-TT-104-2026-03" },
    { "item": "pressure-vessel-integrity", "result": "not-applicable",
      "reason": "module m05 isolated for maintenance" }
  ],
  "signedBy": "operator:op-017"
}

The weekly emergency-shutdown test and the monthly safety drill are particularly valuable, because they are the only evidence that the safety systems of §5.6 would actually work.

5.2.2 The operating envelope and out-of-range actions

§2.1.2 lists acceptable ranges for five ambient parameters. Table 5-2 reproduces them as the spec's example configuration.

The spec then defines three graded responses: a minor deviation of 5–10 % is logged as a warning and operation continues; a moderate deviation of 10–20 % reduces the capture rate and increases monitoring; a major deviation above 20 % starts a controlled shutdown. What the percentage is measured against is not stated. A 10 % deviation from the optimal temperature of 20 °C (2 °C) means something very different from a 10 % deviation past the 40 °C maximum (4 °C), and for a parameter whose minimum is 0 m/s a relative deviation is undefined.

The book recommends defining deviation as the distance outside the nearest limit, divided by the width of the acceptable range, and stating that definition in the facility's configuration record. With that definition, a temperature of 43 °C against a −10 to 40 °C range is (43 − 40) / 50 = 6 %, a minor deviation. Whatever definition a facility chooses, the envelope itself should be data — a versioned configuration record — so that each deviation event can say which limits it was judged against. The deviation event should carry the measured value, the limit, the computed deviation, the resulting action and the protocol reference.

5.3 The Adsorption–Regeneration Cycle

For solid sorbent DAC, capture is a batch process. A contactor module is loaded with CO2 during adsorption, isolated, heated to release the CO2 during regeneration, cooled, and returned to adsorption. PHASE-2-DATA records the current phase in status.operationalState, whose values are adsorption, regeneration, idle, maintenance and error. PHASE-3-PROTOCOL describes what happens inside those states.

5.3.1 Adsorption (DAC-CAPTURE-ADS-001)

The spec's example adsorption phase lasts 8–12 hours. It starts with a 15-minute initialization: intake valves open, fans ramp up to the target airflow (the example uses 5,000 m³/min), the pressure drop across the contactor is checked (below 500 Pa in the example) and logging starts at one-minute intervals. During adsorption the plant keeps the airflow constant, tracks the difference between inlet and outlet CO2 concentration and follows saturation by mass balance. The instantaneous capture efficiency is defined as:

efficiency = (CO2_in − CO2_out) / CO2_in

where CO2_in and CO2_out are the concentrations at the contactor inlet and outlet. The spec's target is to load the sorbent to 80–90 % of its maximum capacity, and it triggers regeneration when saturation reaches 85 %. At the end of adsorption the fans ramp down over about ten minutes, the intake valves close and the module is isolated.

Two points deserve attention when this becomes data. First, the efficiency formula gives an instantaneous value. As the sorbent fills up, less CO2 is removed from each pass of air, so efficiency typically falls over the course of a cycle. A single efficiency field on a cycle record is ambiguous unless it says whether it is the value at the end, the average, or something else. Second, the saturation that triggers regeneration is itself an estimate — it is derived from the mass balance, not measured directly — so the record should say how it was obtained.

5.3.2 Regeneration (DAC-CAPTURE-REG-001)

Regeneration of a solid sorbent in the spec's example takes 2–4 hours and has three phases. During heat-up (roughly the first 30 minutes) the module is closed to ambient air and heated, electrically or with steam, from about 25 °C to the design temperature (the example uses 100 °C) at 2–5 °C per minute. During CO2 release the module is held at the regeneration temperature (80–120 °C in the example), and the released stream is collected, its purity monitored (target above 95 %) and its flow rate measured. During cool-down the heating stops, the module is cooled to below 40 °C at 1–3 °C per minute, and it may be purged with dry air. The ramp rates and temperatures are consistent with each other: heating 75 °C at 2–5 °C/min takes 15–38 minutes, and cooling 60 °C at 1–3 °C/min takes 20–60 minutes.

Regeneration ends with a check of regeneration efficiency:

regen_efficiency = CO2_released / CO2_captured

with a target above 95 %. A value persistently below target means CO2 is being left on the sorbent, so the next cycle starts with reduced working capacity. A value above 100 % is not good news; it means that either the captured or the released quantity is wrong. That makes the ratio a useful cross-check between two independent measurements — the adsorption mass balance and the product-side flow meter — and a validator should flag values outside a plausible band rather than cap them.

The spec also recommends waste-heat recovery and scheduling regeneration for cheap or renewable electricity (Chapter 7). Because regeneration is where most of the energy goes, its consumption must be recorded per cycle, not only as a plant total.

5.3.3 The state machine

Figure 5-1 combines the five operationalState values with the phases of the protocol. Heat-up, release and cool-down are all inside the regeneration state in PHASE-2-DATA; the book recommends recording the sub-phase in an extension field (for example x-phase) so that an energy spike during heat-up is not mistaken for a fault during release.

            start of day: DAC-CAPTURE-PRE-001 checklist passed
                                |
                                v
    +--------------+  saturation >= 0.85   +-----------------------+
    |  adsorption  | --------------------> |     regeneration      |
    |  init 15 min |                        |  heat-up  (2-5 C/min) |
    |  load        |                        |  release  (80-120 C)  |
    |  ramp-down   | <-------------------- |  cool-down (< 40 C)   |
    +--------------+  sorbent < 40 C,      +-----------------------+
           |          regen check done               |
           |                                         |
           v                                         v
       +--------+   no demand / low energy     +-------------+
       |  idle  | <--------------------------- | maintenance |
       +--------+ ---------------------------> +-------------+
           ^           planned work (MAINT)          ^
           |                                         |
           +------------------+  +-------------------+
                              |  |
                          +---------+
                          |  error  |  <-- ESD trigger, QC failure,
                          +---------+      equipment fault (any state)

Every transition in the figure should produce a record with the old state, the new state, the time and the cause. A transition into error should always reference the event that caused it — an ESD trigger, a failed QC check or a fault report — so that the later corrective-maintenance record (§5.6.4) can close the loop.

5.3.4 The cycle record

§2.2.1 gives the only payload that PHASE-3-PROTOCOL defines itself: a cycle record with the prefix ads-. Its fields are cycleId, startTime, endTime, duration, airflowRate, co2Captured, energyConsumed, efficiency and sorbentSaturation. The spec does not give units. From the surrounding text, duration is in hours, airflow in m³/min and CO2 in tonnes; energy is probably in MWh but is not stated. The book recommends an annotated version such as the following, whose values are illustrative only:

{
  "cycleId": "ads-20260314-m03-001",
  "protocolId": "DAC-CAPTURE-ADS-001",
  "protocolVersion": "1.0",
  "facilityId": "dac-example-reykjanes-01",
  "moduleId": "m03",
  "startTime": "2026-03-13T20:05:00Z",
  "endTime": "2026-03-14T06:05:00Z",
  "duration": 10.0,                  // hours
  "airflowRate": 350,                // m3/min, average over the phase
  "co2Captured": 0.11,               // t, from mass balance
  "energyConsumed": 0.05,            // MWh, fans and controls only
  "efficiency": 0.71,                // cycle average, not end value
  "x-efficiencyBasis": "cycle-mean",
  "sorbentSaturation": 0.85,         // fraction at end of phase
  "x-saturationMethod": "mass-balance",
  "regeneration": "reg-20260314-m03-001"
}

(The comments are for the reader; JSON itself does not allow them.) The last field links the adsorption record to the matching regeneration record, which the book recommends giving the prefix reg- and fields for peak temperature, time at temperature, heating energy, CO2 released, average purity and regen_efficiency. Together, the two records describe one complete cycle.

The adsorption record also supports a simple physical plausibility check. At about 420 ppm, a cubic metre of air near sea level contains roughly 0.77 g of CO2. A flow of 5,000 m³/min for 600 minutes therefore carries about 3,000,000 m³ × 0.77 g ≈ 2.3 t of CO2 through the contactor. The captured amount cannot exceed that figure multiplied by the average efficiency. In the spec's own example (0.5 t captured with an efficiency of 0.92 over 10 hours at 5,000 m³/min), the implied average efficiency is about 0.5 / 2.3 ≈ 0.22, which makes sense only if 0.92 is an end-of-cycle or peak value. This is exactly the kind of ambiguity the annotations above are meant to remove. The book's record above describes one of the fictional plant's twelve modules, whose airflow of 350 m³/min is one-twelfth of the 4,200 m³/min facility airflow in Chapter 2. For it the same calculation gives 210,000 m³ × 0.77 g ≈ 0.16 t, and 0.16 t × 0.71 ≈ 0.115 t, just above the recorded 0.11 t. A validator can run the check as:

co2_mass_through = airflow_m3_per_min × minutes × c_ambient_g_per_m3 / 1e6   // t
assert co2Captured <= co2_mass_through × efficiency_mean × (1 + tolerance)

5.3.5 Liquid solvent systems

Liquid solvent DAC does not fit the batch model. In the spec's description, solvent is circulated continuously through a packed contactor, with air drawn through counter-current and the solvent held at about 15–30 °C. The CO2-rich solvent is pumped to regeneration and replaced with lean solvent, with no cycle interruption. For carbonate-based solvents regeneration involves calcination at around 900 °C, with the lime rehydrated to regenerate the solvent; the spec mentions 100–140 °C for amine solvents.

For data, "cycle" should be replaced by a fixed time window. The book recommends hourly records with the solvent flow, CO2 loading of rich and lean solvent, the calciner's energy input and the CO2 produced. The operationalState for such a plant is usually adsorption and regeneration at the same time. Because the PHASE-2-DATA enum takes only one value, a continuous plant should record the state per subsystem (contactor, calciner) rather than per facility.

5.4 CO2 Collection, Purity and Custody-Transfer Metering

DAC-CAPTURE-COL-001 covers what happens to the CO2 stream between regeneration and storage. It has five steps: purity verification, compression, dehydration, metering and temporary storage.

5.4.1 The purity gate

The stream must contain more than 95 % CO2. The spec lists contaminant limits of below 1,000 ppm water vapour, below 3 % nitrogen and below 1,000 ppm oxygen. A stream that fails the gate is rejected or reprocessed. This is a hard decision point and must be recorded as such: a purity check record with the measured composition, the pass/fail result and, for a failure, what happened to the batch. Rejected CO2 is not stored, so it must not be counted towards a storage event. If the rejected stream is vented, that is a process loss in the net-removal calculation of Chapter 1.

The limits are expressed in mixed units — ppm for water and oxygen, per cent for nitrogen and purity — while the co2Quality.contaminants array in the PHASE-2-DATA storage-event schema expects a concentration in ppm. A nitrogen limit of 3 % is 30,000 ppm. The book recommends converting everything to one unit before comparison and keeping the original unit in an annotation, as Chapter 2 recommended for other fields.

5.4.2 Compression and dehydration

The CO2 is then compressed: the spec cites 85–150 bar for pipeline transport and above 73 bar for storage. The storage figure reflects CO2's critical point at about 31 °C and 73.8 bar, above which it becomes a dense supercritical fluid. The stream is dehydrated to below 50 ppm water, by freeze-out or desiccant, to prevent corrosion. There are thus two water limits: below 1,000 ppm at the purity gate, before dehydration, and below 50 ppm after it. A record that reports "water: 1,000 ppm" without saying where it was measured cannot be checked against either. The spec's own storage-event example reports 1,000 ppm water in the stored CO2, which is inconsistent with the post-dehydration target — another reason to record the sampling point.

Compression energy counts towards net removal. The book recommends metering it separately, because compression may be shared with other plants or provided by the storage operator.

5.4.3 The meter as source of truth

The metering step requires accurate mass-flow measurement with an uncertainty of ±2 %, continuous recording and tamper-proof metering for verification. This is the custody-transfer point: the place where CO2 leaves the capture operator's control. The book's firm recommendation is that storage event amounts are derived from custody-transfer meter readings, not from capture-side estimates. The mass balance on the sorbent and the regeneration flow are useful operational cross-checks, but they are upstream of the purity gate and of any venting, and they are not normally subject to the same metrological control as a fiscal meter.

That leads to a reconciliation that a validator should run every reporting period:

released_by_regeneration   (sum of reg- records, t)
  − rejected_at_purity_gate (sum of rejection records, t)
  − vented_or_lost          (process-loss records, t)
  ≈ metered_at_custody_transfer (meter totals, t)   ± meter uncertainty

metered_at_custody_transfer
  ≈ sum(storageEvent.amount) + change_in_buffer_inventory

A gap between the first two lines that is larger than the combined uncertainties is either a measurement problem or an unrecorded loss; both need a finding. The second equation ties the storage events of Chapter 3 to the meter, including the buffer tank that the spec allows for batch transport ("record tank inventory"). A tank inventory reading at the start and end of each period is therefore not optional; without it the two sides cannot be reconciled.

5.5 Storage Protocols as Data

PHASE-3-PROTOCOL defines three storage protocols. Most of their numbers describe geology and monitoring schedules that belong to the storage operator, not to the DAC facility. What the DAC data standard needs from them is a small, well-defined set of facts: which site, which protocol, what was injected, how the site is being monitored, and what the monitoring found.

5.5.1 Geological storage (DAC-STORAGE-GEO-001)

The spec's site-selection criteria include a depth of 800–3,000 m, porosity above 10 % for saline aquifers, permeability of 10–1,000 mD, a low-permeability caprock, no active faults within 5 km, at least one million tonnes of capacity and an injection capability of 50–500 t/day. These should be read as the standard's example configuration. Site characterization and permitting for geological storage are regulated separately — for example under the EU CCS Directive (2009/31/EC) or the US EPA Class VI well rules — and the ISO 27914 standard covers geological storage. A DAC data record should reference the site's permit and characterization documents rather than restate them.

Injection is described in three steps. Before injection: well integrity pressure test, baseline seismic and groundwater monitoring, tracer injection and setting of injection parameters. During injection: controlled rate, bottom-hole pressure kept below fracture pressure, continuous flow measurement and real-time data to the MRV system. After injection: shut-in, pressure-falloff analysis and verification of no surface leakage. The monitoring schedule in §3.1.2 and §3.1.3 is summarized in Table 5-3.

The spec sets a minimum of 30 years of post-injection monitoring. A storage event is therefore not closed once the CO2 is underground. Each monitoring campaign should produce a record that references the site (and through it the storage events there) and states its result: consistent with containment, anomaly under investigation, or leakage detected. Chapter 6 shows how a leakage finding propagates to credits already issued.

5.5.2 Mineralization (DAC-STORAGE-MIN-001)

The mineralization protocol follows the approach in which CO2 is dissolved in water and injected into basaltic rock, where it reacts with calcium, magnesium and iron to form carbonate minerals. The spec gives the reactions in a simplified form, using calcium and magnesium silicates as stand-ins for the more complex minerals in basalt:

CO2 + H2O          → H2CO3              (carbonic acid)
H2CO3 + CaSiO3     → CaCO3 + SiO2 + H2O
H2CO3 + MgSiO3     → MgCO3 + SiO2 + H2O

The spec includes a set of numbers here — a CO2-to-water mass ratio of about 1:25, a carbonated-water pH of about 3–4, an injection depth of 700–2,000 m in one place and "more than 500 m (ideally more than 700 m)" in another, more than 90 % mineralization within two years, and permanence beyond 10,000 years. The depth figures disagree with each other, and none of the figures is sourced. This book does not treat any of them as a scientific claim. They belong in the storage site's own documentation and in the verifier's assessment, with references to the published site studies.

What the data model does need is the structure of the monitoring. During injection the spec calls for water chemistry (pH, conductivity, major ions), injection pressure and temperature, and dissolution efficiency. After injection it calls for core sampling to confirm mineralization, geochemical modelling and tracer tests, with reduced monitoring after 5 years (the spec's example value) once mineralization is confirmed. Because mineralization is confirmed some time after injection, the verification of a mineralization storage event is deferred: the event is recorded at injection and reaches its final verified status only when the post-injection monitoring milestone is met. Chapter 7 covers this delayed certificate in the storage-site integration.

5.5.3 Utilization (DAC-STORAGE-UTI-001)

The utilization protocol classifies pathways into three groups. "Permanent" (more than 100 years) includes concrete curing, CO2-derived aggregates and "polyurethane production (if stable)". "Long-term" (10–100 years) includes enhanced weathering and biochar with CO2 injection. "Short-term" pathways — food and beverage carbonation, enhanced oil recovery without permanent storage and synthetic fuels — are explicitly not acceptable for credits.

This classification should be read as the standard's own, not as an endorsed scientific consensus. Some entries are debatable: polyurethane is a product whose lifetime and end-of-life fate vary widely, and enhanced weathering and biochar are usually treated as separate removal methods rather than as uses of captured CO2. The part of the protocol that clearly matters for data is the exclusion list and the verification requirements. To count as permanent removal, a utilization pathway needs a life-cycle assessment showing positive net removal (including transport and energy), chemical evidence that the CO2 is bound in the product, a product-lifetime estimate with end-of-life scenarios, and independent third-party verification with annual recertification.

In data terms: a storage event with storageMethod: "utilization" should carry the pathway, its permanence class under the standard, and references to the LCA and the product analysis. A validator should reject any credit request whose chain includes a pathway on the excluded list.

5.6 Safety, Emergency Shutdown and Maintenance as Event Streams

Safety belongs in a carbon data standard for two reasons: a safety event often interrupts the capture chain, and the data must explain the gap; and the safety record is evidence that verifiers and regulators review. The book therefore recommends treating safety and maintenance as event streams in the same store as capture and storage records, linked by time and by module.

5.6.1 Hazards and equipment (DAC-SAFETY-GEN-001)

The general safety protocol lists CO2 hazards (asphyxiation in confined spaces, dry-ice frostbite, high-pressure rupture), chemical hazards (amine solvents, caustic KOH and NaOH, hot surfaces) and mechanical hazards, and requires protective and emergency equipment such as CO2 detectors, oxygen monitors and eyewash stations. Inspection and calibration of that equipment is what the checklists of §5.2 should record.

5.6.2 Emergency shutdown (DAC-SAFETY-ESD-001)

The spec lists automatic shutdown triggers (a CO2 leak above a threshold, pressure above 110 % of design, temperature above limits, fire, power failure without backup, and a seismic event above a stated magnitude) and manual triggers (operator judgment, equipment malfunction, injury, external emergency). The shutdown sequence has three stages: immediate actions within five minutes (emergency stop, close CO2 valves, stop fans and compressors, vent to a safe location, cut non-essential power, raise alarms); follow-up actions within 30 minutes (evacuate if needed, assess, call emergency services, secure the area, start the investigation, document); and recovery over hours to days (root-cause analysis, repair, safety review and approval to restart, restart in reverse order).

The book recommends one ESD record per incident with the trigger, whether it was automatic or manual, the time of each immediate action as logged by the control system, the personnel involved, the amount of CO2 vented (if any) and the restart approval. The vented amount matters for carbon accounting: CO2 that was already captured and is released during the shutdown is a process loss and must not be counted in the next storage event.

5.6.3 Leak detection and response (DAC-SAFETY-LEAK-001)

The leak protocol detects leaks with fixed and portable sensors, visual inspection and acoustic detection. It then classifies response by leak rate: a small leak (below 1 kg/min) is isolated and repaired at the next maintenance window; a medium leak (1–10 kg/min) triggers notification, local evacuation and immediate repair; a large leak (above 10 kg/min) triggers emergency shutdown, full evacuation, emergency services, SCBA-only approach and notification of the regulator. Classifying by rate is a sensible structure for an event record, because it maps the response directly to the size of the incident.

The CO2 concentration thresholds in the spec, however, do not fit together. The ESD protocol triggers an automatic shutdown at more than 1,000 ppm in operational areas. The leak protocol defines a low alarm at 500 ppm, a high alarm at 5,000 ppm (0.5 %) with evacuation, and a critical alarm at 10,000 ppm (1 %) with emergency shutdown. The general safety protocol sets the fixed detectors to alarm at 0.5 %. A low alarm at 500 ppm is only slightly above today's outdoor background of about 420 ppm and would fire routinely near the intake; an automatic shutdown at 1,000 ppm contradicts a leak protocol that only shuts down at 10,000 ppm.

This book does not present any of these numbers as safety guidance. Workplace CO2 exposure limits, detector set-points and evacuation criteria must come from the applicable occupational safety regulation — OSHA in the United States, the EU framework and its national implementations in Europe (see EU-OSHA), and the corresponding rules in other jurisdictions — and from the facility's own hazard analysis. What the data standard should require is that the configured thresholds are recorded as a versioned configuration record, that each alarm event references the configuration it was raised against, and that the configuration names the regulation it implements.

5.6.4 Maintenance and P1–P4 priorities

DAC-MAINT-PREV-001 lists preventive tasks at five intervals: daily (visual inspection, leak checks, vibration and noise), weekly (intake filters, lubrication, sensor checks), monthly (detailed inspection, key-sensor calibration, performance testing), quarterly (sorbent sample analysis, heat-exchanger cleaning, valve testing) and annual (major overhaul with shutdown, sorbent replacement if needed, pressure-vessel inspection, electrical audit). The quarterly sorbent sample analysis connects directly to the sorbent record of Chapter 2: its result is what updates lifecycle.currentCapacity.

DAC-MAINT-CORR-001 defines a seven-step corrective procedure (detect, assess, isolate, repair, test, document, restart) and four priority levels, shown in Table 5-4.

The last column is the book's addition: a fault in a meter or analyser affects data quality, and the work order is the natural place to say which measurements were affected and for how long.

5.7 Data Management Protocols

5.7.1 Collection (DAC-DATA-COL-001)

The collection protocol requires automated logging with no manual entry for primary data, UTC timestamps on every measurement, a recording interval appropriate to the quantity (anywhere from 1 to 60 minutes), immediate redundant backup and real-time range checks. The Annex E time-synchronization note (NTPv4 with stratum-2 servers, PTP for deterministic interlocks) is what makes UTC timestamps comparable between the PLC, the meter and the storage site. Synchronization status is worth logging too: a verifier may question timestamps from a period when a logger lost sync.

5.7.2 Quality control and flags (DAC-DATA-QC-001)

The QC protocol defines five checks: range (values within expected physical limits), rate of change (to detect sensor malfunctions), cross-validation (comparison of multiple sensors), mass balance (energy and material balances close) and calibration (regular sensor calibration, monthly to annually). It then defines four flags: good (passed all checks), suspect (failed one check, review needed), bad (failed multiple checks, do not use) and missing (sensor failure or communication error).

The flag rule is simple enough to implement directly. The following pseudocode shows one way to do it; the thresholds are placeholders for the facility's own configuration.

def qc_flag(sample, prev, peers, cal, cfg):
    if sample.value is None:
        return "missing", ["no-data"]

    failed = []

    # 1. range: physical and configured limits
    if not (cfg.min <= sample.value <= cfg.max):
        failed.append("range")

    # 2. rate of change against the previous good sample
    if prev is not None:
        dt = (sample.t - prev.t).total_seconds()
        if dt > 0 and abs(sample.value - prev.value) / dt > cfg.max_rate:
            failed.append("rate")

    # 3. cross-validation against redundant sensors
    if peers:
        median = statistics.median(p.value for p in peers)
        if abs(sample.value - median) > cfg.peer_tolerance:
            failed.append("cross")

    # 4. calibration must be valid at the sample time
    if cal is None or not (cal.valid_from <= sample.t < cal.valid_until):
        failed.append("calibration")

    if not failed:
        return "good", []
    if len(failed) == 1:
        return "suspect", failed
    return "bad", failed

# 5. mass balance is checked per period, not per sample:
#    regeneration output vs. metered transfer vs. storage events (§5.4.3).
#    A period that fails it marks all contributing samples "suspect".

Two design choices in this sketch are the book's recommendations. First, the list of failed checks is stored alongside the flag, so a reviewer can see why a value is suspect. Second, flags are stored in an annotation next to the raw value and never replace it. When a reviewer later accepts a suspect value, that decision is a new annotation with a reviewer and a reason; the original flag remains visible. The effect on reporting is straightforward: only good data, or suspect data that has been reviewed and accepted, may be used in the totals that feed verification, and any substitution for bad or missing data has to follow a documented, conservative gap-filling method that Chapter 6 discusses.

5.7.3 Security (DAC-DATA-SEC-001)

The security protocol requires encryption at rest (AES-256), encryption in transit (TLS 1.3, RFC 8446), role-based access control, logging of all data access, anchoring of verified data and regular security audits. For operational data the most important of these is the audit log, because it is what shows that the records described in this chapter were not changed after the fact. Chapter 7 covers tamper-evident log designs; Chapter 6 covers anchoring. The spec's phrase "blockchain anchoring" should be read broadly: the requirement is a verifiable, append-only commitment to the data, which a transparency log can provide as well as a blockchain.

5.7.4 From protocol to record

Table 5-5 brings the chapter together. For each protocol it names the record the book recommends, the prefix or type used and the main fields. Only the ads- cycle record and the storage event (storage-, from PHASE-2-DATA) are defined by the standard; the others are the book's proposals for filling the gap between procedure and data.

PHASE-3-PROTOCOL closes with an audit cadence — internal audits quarterly, third-party audits annually, regulatory audits as required. With records like these, audits become queries rather than paper collection.

Summary

• PHASE-3-PROTOCOL defines sixteen protocols with IDs of the form DAC-AREA-TOPIC-NNN. The book recommends that every step that changes plant state, CO2 inventory or data trustworthiness emits an append-only record carrying the protocol ID and version.
• Pre-operation checklists become evidence only when each item has an explicit result; a blank item counts as a failure. The operating envelope needs a stated definition of "deviation", and its ambient-CO2 minimum is not a usable limit.
• The adsorption–regeneration cycle maps onto the operationalState enum. Cycle records should state units, whether efficiency is instantaneous or averaged, and how saturation was estimated; a simple airflow calculation bounds the CO2 a cycle can capture.
• The custody-transfer meter (±2 %) is the source of truth for storage events, reconciled against regeneration output, rejections, losses and buffer inventory.
• Storage protocols contribute site references, injection data and long-term monitoring results. Their geological and permanence numbers are the standard's example configuration, not scientific claims; utilization pathways on the excluded list can never lead to credits.
• Safety and maintenance are event streams. The spec's CO2 alarm thresholds are inconsistent, so thresholds must come from applicable regulation and be recorded as versioned configuration.
• QC flags (good, suspect, bad, missing) are stored next to raw values with the reasons for each, and only good or reviewed data feed verification — the subject of Chapter 6.