A DAC plant never works alone. The CO2 it captures leaves through a pipeline or a truck bay and ends up with a storage operator. The electricity and heat it uses come from a grid or a dedicated supplier, and they decide a large part of its net removal. Its verified tonnes end up in a buyer's accounts, in sustainability reports and, in aggregate, in public statistics. Chapters 2 to 6 described the records and protocols inside the WIA data model. This chapter covers what happens at the edges, where those records are exchanged with systems the facility does not control.
PHASE-4-INTEGRATION names six integration domains: storage, energy, registry, MRV, public data and enterprise. Registry and MRV integration were covered in Chapter 6. This chapter covers the other four, then describes a reference implementation that ties them together and the security controls that apply to every interface. The same rule runs through the whole chapter: each exchange with an outside party should leave a record that a verifier can later match against the facility's own data. An integration that moves CO2 or energy without leaving that record breaks the chain of evidence built in Chapter 3.
+---------------------------+
renewable / grid --->| Energy coordination |<--- forecasts, DR events
operators | (scheduler, IEEE 2030.5) | (Section 7.3)
+-------------+-------------+
| setpoints, curtailment
v
+------------------+ telemetry +-------------------------+ records +------------------+
| DAC facility |-------------->| WIA data platform |------------>| MRV / verifier |
| (modules, meters,| MQTT / WSS | collector, validator, | package | (Chapter 6) |
| custody meter) | | time-series DB, API, | +------------------+
+--------+---------+ | evidence store |
| CO2 product +---+---------+-------+---+ exports +------------------+
v | | +--------------->| Enterprise & |
+------------------+ /injection/* | | | reporting systems|
| Pipeline operator|<------------------+ | | (Section 7.4) |
| (ISO 27913 scope)| request/schedule/ | open data, +------------------+
+--------+---------+ status/confirm | partner feeds
v v
+------------------+ reserve/execute/ +------------------+
| Storage site | monitoring/ | Public & research|
| (geological or | verification | consumers |
| mineralization) |-------------------->| (Section 7.5) |
+------------------+ to the platform +------------------+A note on the examples. The specification writes its partner APIs against named real operators and against hosts such as api.wia.org and open-data.wia.org. None of these is presented here as a live service. The examples below use example.com hosts, fictional identifiers such as dac-example-reykjanes-01 and site-example-basalt-01, and round illustrative numbers.
Once CO2 leaves the compressor, the facility no longer holds the evidence it needs. The amount that counts for a removal claim is the amount the storage operator confirms, not the amount that left the plant (Chapter 1). Integration with transport and storage partners therefore has two jobs. It has to coordinate physical logistics such as capacity, schedules and pressure limits. It also has to bring the partner's measurements back into the facility's evidence chain so that a verifier can reconcile them.
PHASE-4 §3.1 defines four operations against a pipeline operator: POST /injection/request reserves transport capacity, POST /injection/schedule fixes a delivery slot, GET /injection/status/{id} tracks progress and POST /injection/confirm records that the CO2 was delivered. The specification cites ISO 27913, the ISO standard for pipeline transportation systems within CO2 capture, transport and storage. ISO 27913 covers the pipeline's design and operation, not its data exchange, so the four operations are WIA's own interface on top of a pipeline run to that standard.
The confirm call matters most, and the specification's example leaves it empty. A confirmation that says only "delivered" is not evidence. The version below adds the custody-transfer meter's identity, its start and end readings and a reference to its calibration record, so the delivered quantity can be recalculated from the readings and linked to a calibrated instrument.
POST https://pipeline.example.com/api/v1/injection/request
{
"facilityId": "dac-example-reykjanes-01",
"amount": 10.0,
"unit": "t",
"targetDate": "2026-03-02",
"destinationSite": "site-example-basalt-01",
"co2Quality": { "purity": 98.5, "waterPpm": 40 }
}
200 OK
{
"requestId": "pipe-req-0142",
"status": "approved",
"scheduledDate": "2026-03-02T08:00:00Z",
"pipelineSegment": "segment-example-sw-01"
}
POST https://pipeline.example.com/api/v1/injection/confirm
{
"requestId": "pipe-req-0142",
"deliveredAmount": 9.97,
"unit": "t",
"meter": {
"meterId": "ct-meter-02",
"readingStart": 18214.52,
"readingEnd": 18224.49,
"calibrationRef": "cal-2026-01-ct-meter-02"
},
"deliveryWindow": {
"start": "2026-03-02T08:00:00Z",
"end": "2026-03-02T15:10:00Z"
}
}Three details are worth noting. First, deliveredAmount equals readingEnd − readingStart. A validator should check this, just as Chapter 2 checked specificEnergy against energy and captured mass. Second, the delivered amount (9.97 t) differs from the requested amount (10.0 t). That is normal, and the storage event must use the metered figure, never the requested one. Third, the confirmation carries a requestId that the storage event can reference. That reference is how a verifier gets from a storage event back to a specific delivery.
Besides the transactional calls, the specification lists the operating data the facility and the pipeline operator share: flow rate in t/h, pressure in bar, temperature in °C, CO2 purity in percent and cumulative metered tons. It allows two transport styles, real-time streaming over MQTT or WebSocket, and hourly REST summaries, and it requires TLS 1.3 with mutual authentication for both.
The choice depends on who acts on the data. If the pipeline operator uses the facility's flow and pressure for control, for example to manage line pack or protect against over-pressure, only a stream is fast enough, and MQTT is the more natural fit. It is a publish/subscribe protocol designed for many small telemetry messages, and it provides delivery-guarantee levels. If the data is used only for reconciliation and billing, hourly REST summaries are simpler to secure and audit. Many deployments use both: a stream for operations, and an hourly signed summary that becomes the record of reference.
topic: wia/dac/dac-example-reykjanes-01/transfer/ct-meter-02
qos: 1 (at least once; the receiver de-duplicates on seq)
{
"seq": 88121,
"timestamp": "2026-03-02T09:15:00Z",
"flowRate": { "value": 1.42, "unit": "t/h" },
"pressure": { "value": 14.8, "unit": "bar" },
"temperature": { "value": 21.6, "unit": "Cel" },
"co2Purity": { "value": 98.4, "unit": "%" },
"cumulative": { "value": 18215.97, "unit": "t" },
"qc": "good"
}Every quantity in this message is an object with an explicit unit. The temperature unit is written in its UCUM form (Cel). This follows the unit advice from Chapter 2. The specification's list mixes t/h, bar, °C and percent, and a partner that assumes MPa or kelvin will fail silently. The seq field handles MQTT's "at least once" semantics: a message can arrive twice, and the receiver discards a sequence number it has already stored. The qc flag uses the good / suspect / bad / missing vocabulary from Chapter 5, so a partner's data quality is recorded in the same terms as the facility's own.
PHASE-4 §3.2 defines a second API for the storage site: POST /injection/reserve, POST /injection/execute, GET /injection/monitoring/{id} and GET /verification/{id}. It cites ISO 27914, the ISO standard for geological storage of CO2, which covers site selection, characterization, injection, monitoring and closure. The pipeline API and the storage-site API both use paths under /injection, but they belong to different counterparties with different base URLs. A client library should keep them in separate namespaces so that a status call is never sent to the wrong party.
The monitoring endpoint returns what the facility needs to keep a storage event's permanence claim current: injection pressure against its permitted limit, seismic observations and groundwater chemistry. The specification's example ties these readings to a named real site. The version below uses a fictional site and adds a linkedStorageEvent field so that the monitoring stream attaches to the storage event from Chapter 3 rather than floating free.
{
"injectionId": "inj-example-2026-03-0007",
"siteId": "site-example-basalt-01",
"linkedStorageEvent": "storage-example-reykjanes-01-20260302-001",
"monitoring": {
"wellheadPressure": { "current": 18.0, "limit": 25.0, "unit": "bar" },
"seismic": { "eventsSinceLastReport": 0, "lastSurvey": "2026-02-15" },
"groundwater": { "pH": 7.9, "lastSample": "2026-02-27" }
},
"status": "stable",
"observedAt": "2026-03-02T16:00:00Z"
}The pressure limit, survey dates and pH are placeholders. Real limits come from the site's permit and monitoring plan, and this book gives none of them as guidance. What matters for the data model is the pattern. Each monitoring snapshot names its storage event, carries its observation time in UTC and reports a status. A status other than stable should create a record on the facility side, because it may later require a reduction in credited tonnes.
| Partner operation | Direction | WIA record or field produced | Check a validator should run |
|---|---|---|---|
/injection/request, /injection/schedule (pipeline) | Facility → pipeline | Transfer plan referencing the facility and target site | Target site exists in the facility's storage configuration |
/injection/confirm (pipeline) | Pipeline ↔ facility | Custody-transfer entry; source of amount in the storage event | Delivered = end − start reading; meter calibration valid on that date |
/injection/reserve, /injection/execute (site) | Facility → site | injectionData in the storage event (T, P, rate, duration) | rate × duration ≈ amount (Chapter 3) |
/injection/monitoring/{id} (site) | Site → facility | Monitoring snapshots linked to the storage event | Snapshot times follow the monitoring plan's schedule; no gaps beyond its tolerance |
/verification/{id} (site) | Site → facility | Storage verification certificate; moves the event to verified | Certificate amount ≤ delivered amount; certificate issuer is the site of record |
Mineralization in basalt, of the kind pioneered in Iceland, gets its own section in the specification (§3.3, written against a named operator). The data exchange is split into three phases, and the phase structure carries over to any mineralization partner.
The last phase causes the main integration problem: the evidence that CO2 has become stable carbonate arrives long after the tonnes left the plant. The storage event from Chapter 3 therefore needs a status that can stay open for a long time and still be audited while it is open. The state sequence below is a suggestion for the mineralization pathway. It extends the pending-verification status that the storage events endpoint already returns.
storage event status (mineralization pathway)
submitted
| site confirms receipt and dissolution data
v
injected ----------------------------> anomaly-reported
| monitoring milestones received | (investigation; may
| per the site's monitoring plan | reduce the amount)
v v
pending-verification <---------------------+
| site issues verification certificate
v
verified (only now eligible for a credit request)Two design rules follow from this. First, a credit request (Chapter 6) must not reference a storage event before it reaches verified, unless the registry methodology in use explicitly allows issuance against interim evidence. In that case the credit record should say which evidence it relied on. Second, the transition into anomaly-reported must be possible even after credits exist. The chain of evidence from Chapter 3 depends on records that are linked, not overwritten. A late adverse finding does not quietly change the original record. It produces a new, linked record that can trigger the registry's reversal or buffer procedure.
Energy is the largest variable term in the net-removal formula from Chapter 1, and it is the only term the operator can change from hour to hour. Energy integration therefore has two goals that sometimes conflict: lowering the emissions attributed to each captured tonne, and responding to the grid as a flexible load.
PHASE-4 §4.1 describes a scheduler that fetches a 24-hour forecast (solar irradiance, wind, geothermal availability and grid carbon intensity) and assigns an operation to each hour with a function called optimizeDACSchedule. Its logic is simple. Above 80 % renewable share it runs regeneration on all modules, between 50 % and 80 % it runs adsorption, and below 50 % it idles.
The main idea is sound. For solid-sorbent plants, regeneration usually needs much more energy per hour than adsorption because it heats the sorbent (Chapter 1 gave the typical TVSA range as 80–120 °C). Moving regeneration into hours with clean supply therefore lowers the energy term more than moving adsorption. But the sample treats each hour as an independent choice, and a DAC module is a state machine (Chapter 5). A module can regenerate only after it has loaded CO2. Chapter 5 uses a trigger of 85 % saturation as its example. Once saturated, it can capture nothing more until it regenerates. A schedule that calls for regeneration in a clean hour when no module is saturated is impossible. A schedule that idles saturated modules through a long low-renewable period gives up capture without saying so.
The sample has two further weaknesses. It uses "renewable percentage" as its signal, but the net-removal calculation needs the emission factor of the electricity actually consumed. Grid carbon intensity in gCO2e/kWh is the more direct input, and the specification already lists it as a forecast source. The sample also leaves no trace: nothing records why a module idled, so a verifier cannot tell a scheduling decision from an outage. The per-module planner below addresses all three points. Its thresholds are configuration values chosen by the operator, not normative numbers.
// Illustrative scheduler. Thresholds are configuration, not normative values.
function planHour(hour, module, cfg) {
const clean = hour.gridIntensity <= cfg.lowIntensity; // gCO2e/kWh
const saturated = module.saturation >= cfg.regenTrigger; // e.g. 0.85
if (hour.drEvent && hour.drEvent.accepted) {
return { op: module.state === 'regeneration' ? 'hold-warm' : 'idle',
reason: 'demand-response:' + hour.drEvent.eventId };
}
if (saturated && clean) {
return { op: 'regeneration', reason: 'saturated-and-clean-window' };
}
if (saturated && hour.hoursToNextCleanWindow > cfg.maxWaitHours) {
return { op: 'regeneration', reason: 'wait-limit-exceeded' };
}
if (saturated) {
return { op: 'idle', reason: 'waiting-for-clean-window' }; // fans off
}
return { op: 'adsorption', reason: 'capacity-available' };
}The reason string is not decoration. It should be copied into the operational record's status block for that hour. Then the verification package from Chapter 6 can show that idle time was a deliberate choice, and the facility's availability figures can separate scheduled idling from faults. The maxWaitHours guard also matters. Without it, a long spell of dirty power would hold saturated modules idle indefinitely. Some operators would accept that, but others need a minimum throughput, and that trade-off belongs in configuration, not in hidden code.
The specification cites IEEE 2030.5, the Smart Energy Profile application protocol, as the grid-side standard. IEEE 2030.5 defines resources for demand response and load control, among other functions. The specification lists three capabilities a DAC plant can offer: curtailment within five minutes, load shifting of up to 24 hours and load adjustment for frequency regulation. How much of this a real plant can deliver depends on its technology. Fans on an adsorbing module can be stopped quickly. A regeneration step that is halfway through heating may have to be held warm or completed, which is why the planner above uses a hold-warm state rather than switching straight to idle.
The specification's example demand-response event contains a defect that a JSON parser will not report. The object has two members named unit:
{
"requestedReduction": 500,
"unit": "kW",
"duration": 2,
"compensation": 50,
"unit": "$/MWh"
}unit overwrites the firstRFC 8259 says that names within a JSON object SHOULD be unique and leaves the behavior for duplicates to the implementation. Most parsers keep the last value, so requestedReduction ends up labeled in dollars per megawatt-hour. duration has no unit at all. The fix is to make each quantity an object that carries its own unit, as in the telemetry message, and to write durations in ISO 8601 form. The corrected exchange below also adds a response deadline and asks the plant to report the effect on capture. That second addition lets a curtailment event appear in the facility's records as an explanation for lost output.
POST https://dr.example.com/grid/demand-response/event
{
"eventId": "dr-example-20260302-001",
"type": "load-reduction",
"facilityId": "dac-example-reykjanes-01",
"requestedReduction": { "value": 400, "unit": "kW" },
"start": "2026-03-02T17:00:00Z",
"duration": "PT2H",
"responseDeadline": "PT5M",
"compensation": { "amount": 40, "currency": "EUR", "per": "MWh" }
}
200 OK
{
"eventId": "dr-example-20260302-001",
"status": "accepted",
"committedReduction": { "value": 380, "unit": "kW" },
"modules": ["module-01", "module-03", "module-05"],
"impact": {
"deferredRegenerations": 3,
"estimatedCaptureDeferred": { "value": 0.6, "unit": "t" }
}
}The compensation figure is an example, as is the specification's 50 $/MWh. Real tariffs and programs depend on the market. The response lists the modules that shed load and the capture deferred as a result. A facility that joins such programs should store each accepted event as its own record, linked to the affected hours, for the same reason as the planner's reason field.
Whatever the scheduling strategy, the energy integration has to deliver one number per period that a verifier will accept: the emissions from the energy the plant used. That requires metered consumption per source, an emission factor per source and time interval, and a statement of the accounting method. Hourly factors against hourly consumption give a different result from an annual average factor. Contractual instruments such as renewable energy certificates are treated differently by different methodologies. The data model should keep consumption and factors separate, record the factor's source and timestamp, and let the registry methodology decide how to combine them. It should not store a single pre-computed "green" flag.
Most buyers of removal credits never call a DAC facility's API. They get their data through a carbon-accounting platform or a sustainability reporting process. PHASE-4 §8.1 illustrates this with a function that posts directly to a named commercial vendor's API, using an endpoint that is not published by that vendor and should not be copied. The same sample sets verificationStandard to ISO 27916, which covers CO2 storage through enhanced oil recovery and is not a general verification standard for DAC.
A better design is a vendor-neutral export. The WIA platform publishes one well-defined removal record, and thin adapters map it to each target system's import format. The record should say what kind of removal it is, on what basis the quantity was computed (net removal, not gross capture), and which evidence stands behind it: verification report, credit serial numbers and retirement status. Verification of GHG statements is covered by ISO 14064-3, and that is the reference to use for the verification standard. The registry methodology is a separate field.
{
"exportId": "exp-example-2025-017",
"schema": "wia-dac-removal-export/1.0",
"reportingEntity": "org-example-buyer",
"activity": {
"category": "carbon-removal",
"method": "direct-air-capture",
"storageMethod": "mineralization",
"quantity": { "value": 250, "unit": "t CO2" },
"basis": "net-removal"
},
"period": { "start": "2025-01-01", "end": "2025-12-31" },
"evidence": {
"facilityId": "dac-example-reykjanes-01",
"verificationReportId": "verify-example-reykjanes-01-2025",
"creditSerials": ["EXAMPLE-SERIAL-0101 … EXAMPLE-SERIAL-0350"],
"retirement": {
"status": "retired",
"beneficiary": "org-example-buyer",
"retiredAt": "2026-04-20T10:00:00Z"
},
"methodology": "registry methodology reference (text)",
"verificationStandard": "ISO 14064-3"
},
"mappings": {
"csv": "removals.csv#row=17",
"xbrl": "concept name from the filer's chosen taxonomy"
}
}The retirement block is what makes the export safe to use in a corporate claim. A company should report removals it has retired in its own name or on its behalf, not credits it merely holds. The export also keeps the credit serial range, so an auditor can check the retirement against the registry directly without trusting the export.
For the reporting frameworks the specification names (GRI, CDP, TCFD and SASB), the export's job is to supply consistent figures, not to fill in the disclosures. GRI 305 is the GRI topic standard for emissions. CDP collects data through questionnaires. The TCFD recommendations are now built into the ISSB standards of the IFRS Foundation, which also maintains the SASB standards. In each case the reporting company decides where removals appear, and most frameworks expect removals to be reported separately from gross emissions rather than netted against them. The four export formats in the specification serve different consumers:
Transparency is the first of the six principles in Chapter 1. PHASE-4 §7 turns it into three channels: an unauthenticated open-data API, an embeddable dashboard widget and an application-based research access program. PHASE-1-FOUNDATION §7.2 adds the governing rule, a tiered access model with public, partner and private levels, together with aggregation and anonymization to protect individual facilities.
The specification's open-data example returns global statistics for 2025 with facility counts, capacities, captured tonnes, an average efficiency and a breakdown by country. Those figures are invented and should not be quoted. The shape of the response is useful, but it lacks two things a publisher needs: a statement of method, and protection for small groups. If a country has one DAC facility, its "aggregate" is that facility's data, so aggregation alone protects nothing. The response below suppresses any cell with fewer than a minimum number of facilities and says so. The threshold of three is an example; the data-governance policy sets the real value.
GET https://open-data.example.com/dac/v1/statistics?year=2026&groupBy=country
200 OK
{
"year": 2026,
"generatedAt": "2027-02-01T00:00:00Z",
"method": {
"source": "verified storage events only",
"minFacilitiesPerCell": 3,
"suppressedCells": 2
},
"rows": [
{ "country": "XA", "facilities": 4, "verifiedStored": { "value": 1200, "unit": "t" } },
{ "country": "XB", "facilities": null, "verifiedStored": null,
"suppressed": "fewer-than-3-facilities" }
]
}Note also "source": "verified storage events only". A public statistic should state whether it counts gross capture, stored tonnes or verified net removal. Mixing these three produces headline numbers that cannot be compared with anything else. The country codes here use the ISO 3166-1 user-assigned range, so they cannot be mistaken for real countries.
The widget lets a facility or partner embed live figures on its own site. The specification loads it from a widgets.wia.org host that is not a live service. The version below uses an example host and adds Subresource Integrity, so a compromised script host cannot inject code into every embedding page.
<div id="dac-widget"></div>
<script src="https://widgets.example.com/dac/v1/widget.js"
integrity="sha384-(hash of the published file)"
crossorigin="anonymous"></script>
<script>
DACWidget.init({
container: '#dac-widget',
facilityId: 'dac-example-reykjanes-01',
metrics: ['capture-rate', 'energy', 'verified-stored'],
refreshInterval: 60 // seconds; public tier only
});
</script>A widget reads from the public tier only. It should show rates and verified totals, not the sorbent-level or airflow detail that the partner tier protects.
Researchers get more than the public tier through a four-step process: proposal, data-use agreement, credentials and access to anonymized detailed data. The detailed data includes minute-level operations, sorbent performance, energy strategies and environmental correlations. Some of this is exactly what the foundation document says must be protected. Sorbent formulations are named as trade secrets, and sorbent performance over time can reveal a formulation to a competitor. The tier boundaries therefore belong in the schema, not in a policy document, as Table 7-2 shows.
| Record group | Public | Partner (under agreement) | Private |
|---|---|---|---|
| Facility identity, location, technology family, declared capacity | Yes, if the facility opts in | Yes | Yes |
| Verified stored and credited tonnes per period | Yes (aggregated where required) | Yes | Yes |
| Hourly capture and energy records | Summaries only | Yes, anonymized for research | Yes |
| Sorbent records (type, capacity, degradation) | No | Type family only, or under NDA | Yes |
| Sorbent formulation, supplier terms | No | No | Yes, encrypted |
| Maintenance logs with staff identifiers | No | Pseudonymized | Yes |
Anonymizing operational time series is harder than removing a facility name. A capture profile with a known capacity and location can often be linked back to its source. Research extracts should be coarsened: shifted timestamps, capacity bands instead of exact figures, and no location finer than the region. They should also be reviewed against the data-use agreement before release.
The specification does not prescribe a software architecture, but its requirements add up to one. PHASE-1-FOUNDATION §5 asks for a time-series database (InfluxDB and TimescaleDB are named as examples), daily incremental and weekly full backups, geographic replication, a 99.9 % availability target and full API audit logging. The book suggests the five-stage pipeline below as a starting point.
| Concern | Specification source | Suggested practice |
|---|---|---|
| Time-series database | FOUNDATION §5.3.1 | Any engine with retention policies and continuous aggregates; keep raw and aggregate tables under separate retention. |
| Backups | FOUNDATION §5.3.1 | Daily incremental, weekly full; restore tests on a schedule, with the result logged as a record. |
| Replication | FOUNDATION §5.3.1 | A second region for the evidence store at minimum; the replica must honor the same access tiers. |
| Availability | FOUNDATION §5.2.2, §7.1.3 | Example target 99.9 %, which allows roughly 8.8 hours of downtime per year; the edge buffer must cover longer outages so no readings are lost. |
| Real-time latency | FOUNDATION §5.2.2 | Example target under 5 s from measurement to API; measure it at p95 and report it (Annex E error-budget note). |
| Rate limits | PHASE-4 §9.2 | Example tiers 100 / 1,000 / 10,000 requests per hour for public, authenticated and partner clients; set actual limits per deployment. |
| Audit logging | PHASE-4 §9.3 | All API calls, with the fields in Listing 7-10; stored in the evidence store, not the application log. |
The availability figure deserves one comment. An API outage and a data gap are different failures. A 99.9 % target for the API is reasonable. A data gap, on the other hand, is permanent: a missing hour of custody-transfer readings cannot be reconstructed, and a verifier will usually treat it conservatively. That is why the edge buffer, not the central cluster, is the most important availability component in a DAC deployment.
Every interface in this chapter crosses an organizational boundary, and several of them move data that turns into money through credits. PHASE-4 §9 lists four authentication methods (OAuth 2.0 for delegation, API keys for machine-to-machine use, mTLS for high-security connections and JWTs for stateless tokens), plus rate limiting and audit logging. Applied together, they should follow a few rules.
read:facility, write:capture) extend naturally to partners. A storage site gets write:storage (Table 4-1), bound to events at its own site, and nothing else. A pipeline operator can confirm deliveries but cannot create storage events. A reporting adapter gets read-only access to verified and retired records.{
"seq": 5530127,
"timestamp": "2026-03-02T16:04:11.284Z",
"clientId": "svc-storage-sync",
"subject": "mtls:CN=site-example-basalt-01",
"scope": "write:storage",
"method": "POST",
"endpoint": "/storage/events",
"requestDigest": "sha256:(digest of canonical request body)",
"responseStatus": 201,
"resourceId": "storage-example-reykjanes-01-20260302-001",
"sourceIp": "203.0.113.24",
"prevHash": "sha256:(hash of entry 5530126)",
"entryHash": "sha256:(hash of this entry without entryHash)"
}The entry stores a digest of the request body instead of the body itself, which keeps the log small and keeps personal or commercially sensitive content out of it. The source IP uses a documentation address range.
Personal data. DAC data is mostly about machines, but not entirely. Maintenance logs, checklist sign-offs, access badges and on-call rosters identify employees, and research extracts can contain them indirectly. The specification lists GDPR and CCPA for employee data, and the API interface document adds K-PIPA (Korea's Personal Information Protection Act) and others. The practical rule is to keep personal identifiers out of operational and evidence records wherever a role or pseudonymous ID will do, to keep the mapping table in the private tier, and to state in the deployment policy which privacy regime applies at each site. Evidence records have permanent retention, so a personal identifier written into one is effectively permanent too.
verified unless the methodology says otherwise.unit key and should be restructured.Chapter 8 turns from building these integrations to proving them: conformance tiers, signed manifests and the evidence package an auditor will ask for.