feat: add eo-dat satellite imagery dataset response type

Add the `eo-dat` (Data Product) EO response type for satellite imagery
datasets delivered as the response deliverable itself — an International
Charter acquisition handed to responders, or a UNOSAT GIS-ready data
download. This was missing from the EO response code set defined in
#42/#46 and is needed for the Charter source integration (#43).

Charter modelling: both VAPs and acquisitions are Monty Response items.
Each delivered acquisition dataset maps to `eo-dat`, with the ETL
subtlety that the Charter records an acquisition at several processing
stages — only the last, calibrated stage is kept as the `eo-dat`
Response item (the dataset responders use to build VAPs). Derived VAP
Response items reference it via `derived_from`. Earlier ETL-stage
records are intermediate artifacts, not separate Response items.

response-taxonomy.md:
- §2.1 EO products table: lead row for `eo-dat`
- §2.1 note: corrected — acquisitions (calibrated stage) are Response
  items, not only VAPs
- §3.1 classification rules: lead bullet with the ETL/calibrated rule
- §5 Sendai crosswalk: `eo-dat` → D, G
- Appendix A.3 EO crosswalk + A.4 extension note

response-best-practices.md:
- §1 principle 2 + §5 anti-pattern: `eo-dat` exception (Response item and
  acquisition item coincide, so it carries eo:/sar:/sat: directly)
- §2 extension-combinations: lead `eo-dat` row + acquisition-row contrast
- §4.4 worked example (Charter calibrated acquisition)

Because the `eo-dat` item IS the dataset, it carries eo:/sar:/sat: (and
disaster:class = acquisition for Charter) directly, the sole exception to
the acquisition-vs-response layer separation principle.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: emmanuelmathot

docs/model/response-best-practices.md

@@ -9,7 +9,7 @@ This document specifies which STAC extensions Monty Response items SHOULD or MUS
 ## 1. Governing principles
 
 1. **Extension layering over duplication.** When a third-party STAC extension covers a concept (e.g., Terradue `disaster:` for International Charter items, `processing:` for derived EO products, `eo:` / `sar:` / `sat:` for source imagery), Response items SHOULD declare that extension and use its fields directly. Do NOT replicate those fields under `monty:response_detail`.
-2. **Acquisition vs. Response layer separation.** `sat:`, `eo:`, `sar:`, `view:` extensions describe the **acquisition / source imagery** that the Response product is derived from. They apply to the linked acquisition items reached via `derived_from`, **not** to the Response product item itself. A Monty Response item for a CEMS Grading Product is a derived product — its STAC extensions describe its provenance and classification, not the raw imagery.
+2. **Acquisition vs. Response layer separation.** `sat:`, `eo:`, `sar:`, `view:` extensions describe the **acquisition / source imagery** that the Response product is derived from. They apply to the linked acquisition items reached via `derived_from`, **not** to the Response product item itself. A Monty Response item for a CEMS Grading Product is a derived product — its STAC extensions describe its provenance and classification, not the raw imagery. **Exception:** an `eo-dat` Response item *is* the delivered dataset, so it carries the imagery-layer extensions directly (see §2 and §4.4).
 3. **`monty:` is always declared.** Every Response item declares the Monty extension and carries at least `monty:response_detail.type`, `monty:corr_id`, `monty:country_codes`, `monty:hazard_codes`, and the `response` role.
 4. **`monty:response_detail` is the residual carrier.** It carries the response type code and Monty-specific metadata that is not already expressed by another declared extension on the same item.
 5. **Statistical figures go to Impact items.** Damage / exposure statistics that EO products may carry (e.g., CEMS `affected` / `total` per thematic) are **not** part of `response_detail` — they belong to separate Monty Impact items linked via `monty:corr_id`.
@@ -20,12 +20,13 @@ This document specifies which STAC extensions Monty Response items SHOULD or MUS
 
 | Response type (`monty:response_detail.type`) | Extensions to declare on the Response item | Notes |
 | --- | --- | --- |
+| `eo-dat` *(satellite imagery dataset delivered as the response deliverable)* | `monty:` **+** `eo:` / `sar:` / `sat:` *(the item IS the imagery)* **+** `disaster:` *(MANDATORY for Charter acquisitions, with `disaster:class = acquisition`)* | The most basic EO response, and the one case where the Response item and the acquisition item **coincide**: the deliverable is the dataset itself (e.g., a Charter `acquisition`, a UNOSAT GIS-ready download). Each delivered dataset is an `eo-dat` Response item. For the Charter, an acquisition is recorded at several ETL stages — keep only the **last, calibrated stage** (the dataset responders use to build VAPs); earlier-stage records are intermediate artifacts, not separate Response items. The imagery-layer extensions (`eo:` / `sar:` / `sat:`) are declared **on** the Response item; derived VAP Response items reference it via `derived_from`. See the acquisition row below and [taxonomy §2.1](./response-taxonomy.md#21-eo-response-products). |
 | `eo-ref`, `eo-fep`, `eo-del`, `eo-gra`, `eo-pop`, `eo-mon`, `eo-sr`, `eo-vap` *(CEMS-sourced)* | `monty:` **+** `processing:` *(recommended)* | No CEMS-specific STAC extension exists. CEMS `statusCode` and `monitoringNumber` are carried under `monty:response_detail` (as `status` and `monitoring_number`). `resolutionClass` is carried on the linked acquisition items (not on the Response item). `charterNumber` is modelled as a `rel: related` link (with `roles: ["response"]`) to the corresponding Charter VAP Response item. |
 | `eo-ref`, `eo-del`, `eo-gra`, `eo-pop`, `eo-vap` *(International Charter VAPs)* | `monty:` **+** `disaster:` *(MANDATORY)* **+** `processing:` *(recommended)* | Reuse `disaster:class = vap`, `disaster:activation_id`, `disaster:call_ids`, `disaster:activation_status`, `disaster:resolution_class`, `disaster:types`. Do NOT duplicate these under `monty:response_detail`. |
 | `eo-fep`, `eo-del`, `eo-gra`, `eo-pop`, `eo-mon` *(UNOSAT-sourced)* | `monty:` **+** `processing:` *(recommended)* | No UNOSAT STAC extension exists. |
 | `hum-*` *(IFRC / cluster-based humanitarian)* | `monty:` *(only)* | No directly relevant third-party extension. Sectors carried in `monty:response_detail.sectors`. |
 | `fin-*` *(IFRC DREF / EA / AA / PDNA)* | `monty:` *(only)* | Financial-amount fields are not yet part of `monty:response_detail`; tracked as a proposal in the [response taxonomy](response-taxonomy.md) and out of scope for v1. |
-| *(Acquisition / source imagery — linked via `derived_from`)* | `sat:`, `eo:`, `sar:`, `view:`, `disaster:` *(for Charter acquisitions, with `disaster:class = acquisition`)*, `processing:` | These are **not** Monty Response items themselves; they are upstream items referenced by Response items via `rel: derived_from`. |
+| *(Acquisition / source imagery — linked via `derived_from`)* | `sat:`, `eo:`, `sar:`, `view:`, `disaster:` *(for Charter acquisitions, with `disaster:class = acquisition`)*, `processing:` | These are **not** Monty Response items themselves; they are upstream items referenced by Response items via `rel: derived_from`. (Contrast `eo-dat` above: the final calibrated dataset the Charter delivers *is* kept as a Response item; earlier ETL-stage acquisition records and other non-delivered source imagery remain upstream-only and are referenced via `derived_from`.) |
 
 > The Response item's `stac_extensions` array MUST contain `https://ifrcgo.org/monty-stac-extension/v1.3.0/schema.json` (or newer). The relative ordering of extension URLs is not significant.
 
@@ -181,14 +182,53 @@ Note the absence of `monty:response_detail.status` — it is carried via `disast
 }
 ```
 
+### 4.4 Charter raw acquisition delivered to responders (`eo-dat`)
+
+Here the response deliverable is the satellite dataset itself, so the Response item and the acquisition item coincide: the imagery-layer extensions (`sat:` / `eo:`) and `disaster:class = acquisition` are carried directly on the Response item. This is the **last, calibrated** ETL stage of the acquisition — the dataset responders use to build VAPs; the derived VAP Response items reference it via `derived_from`.
+
+```jsonc
+{
+  "stac_extensions": [
+    "https://ifrcgo.org/monty-stac-extension/v1.3.0/schema.json",
+    "https://terradue.github.io/stac-extensions-disaster/v1.1.0/schema.json",
+    "https://stac-extensions.github.io/eo/v1.1.0/schema.json",
+    "https://stac-extensions.github.io/sat/v1.0.0/schema.json"
+  ],
+  "properties": {
+    "disaster:class": "acquisition",
+    "disaster:activation_id": 849,
+    "disaster:call_ids": [1421],
+    "disaster:resolution_class": "VHR",
+    "disaster:types": ["flood"],
+    "disaster:country": "ESP",
+    "eo:cloud_cover": 12,
+    "sat:platform_international_designator": "2018-014A",
+    "monty:response_detail": {
+      "type": "eo-dat",
+      "source_id": "ACT-849",
+      "producer": "Airbus",
+      "sendai_targets": ["D", "G"]
+    }
+  },
+  "links": [
+    {
+      "rel": "derived_from",
+      "href": "https://disasterscharter.org/web/guest/activations/-/article/...",
+      "type": "text/html",
+      "title": "International Charter activation ACT-849"
+    }
+  ]
+}
+```
+
 ---
 
 ## 5. Anti-patterns
 
 The following patterns SHOULD be avoided:
 
 - **Duplicating `disaster:` fields under `monty:response_detail`** on Charter items — e.g., adding a parallel `monty:response_detail` field for any concept already covered by `disaster:activation_id`, `disaster:activation_status`, `disaster:resolution_class`, etc. On Charter items declaring `disaster:`, the `disaster:` field is canonical.
-- **Carrying `sar:` / `eo:` / `sat:` fields on the Response product item.** Those describe the source imagery, which lives in separate acquisition items linked via `derived_from`.
+- **Carrying `sar:` / `eo:` / `sat:` fields on the Response product item.** For *derived* products (`eo-del`, `eo-gra`, `eo-pop`, …) those describe the source imagery, which lives in separate acquisition items linked via `derived_from`. The sole exception is `eo-dat`, where the dataset *is* the deliverable and the Response item and acquisition item coincide (see §4.4).
 - **Stuffing damage statistics into `response_detail`.** Damage counts, affected populations, building destruction counts MUST become Monty Impact items (separate STAC items, `roles: ["impact"]`) linked to the Response via `monty:corr_id` (and optionally `rel: related` with `roles: ["impact"]`). See [Response ↔ Impact Boundary Rules](response-impact-boundary.md) for the data-pattern catalogue and the decision tree that resolves, per attribute, whether something stays on the Response item or becomes a paired Impact item.
 - **Mixing source code into the type code.** Use `eo-del` (source-agnostic) rather than `eo-cems-del` or `eo-charter-del`. Source provenance lives in `monty:response_detail.source_id`, `monty:response_detail.producer`, and `derived_from` links.
 - **Creating multiple `eo-del-mon-N` codes for monitoring iterations.** Use a single `monty:response_detail.monitoring_number = N` field on the monitoring item, mirroring the CEMS API.

docs/model/response-taxonomy.md

@@ -43,6 +43,7 @@ EO response products are the primary use case. Codes are source-agnostic: a deli
 
 | Code | Name | Description | CEMS equivalent | Charter mapping | UNOSAT mapping |
 | --- | --- | --- | --- | --- | --- |
+| `eo-dat` | Data Product | Satellite imagery dataset delivered as the response deliverable itself — typically a calibrated acquisition or a GIS-ready data download | — (raw imagery, not a CEMS product type) | Acquisition (`disaster:class = acquisition`, calibrated stage) | GIS-ready data download |
 | `eo-ref` | Reference Product | Pre-event baseline mapping of territory and assets | `REF` | Reference map VAP | Phase 0 basemap |
 | `eo-fep` | First Estimate Product | Fast, rough post-event extent assessment (~hours) | `FEP` | Best-effort from early VAPs | Phase 1 PSA |
 | `eo-del` | Delineation Product | Affected area extent and event impact mapping | `DEL` | Delineation VAP (best effort) | Phase 2 flood extent |
@@ -52,7 +53,9 @@ EO response products are the primary use case. Codes are source-agnostic: a deli
 | `eo-sr` | Situational Report | Event overview report updated throughout the response | `SR` | — | — |
 | `eo-vap` | Value-Added Product | Generic EO product — used when the specific type cannot be determined | — | Charter VAP (fallback) | — |
 
-> A Charter activation (`disaster:class = activation`) is **not** a Response item — it is modelled as a Monty **Event** because it bundles multiple subsequent VAP deliveries. Only the VAPs themselves (`disaster:class = vap`) become Monty Response items.
+> A Charter activation (`disaster:class = activation`) is **not** a Response item — it is modelled as a Monty **Event** because it bundles multiple subsequent deliveries.
+>
+> Both Charter **VAPs** (`disaster:class = vap`) and Charter **acquisitions** (`disaster:class = acquisition`) become Monty Response items: VAPs map to the EO product codes above (`eo-del`, `eo-gra`, `eo-vap`, …), and each delivered acquisition dataset maps to `eo-dat`. **ETL subtlety:** the Charter records an acquisition at several stages of its own processing pipeline; keep only the **last, calibrated stage** as the `eo-dat` Response item — that is the dataset responders use to derive value-added products. Earlier-stage records of the same acquisition are intermediate processing artifacts, not separate Response items. Each VAP Response item links to the calibrated acquisition it was produced from via `derived_from`.
 
 ### 2.2 Humanitarian Response
 
@@ -92,6 +95,7 @@ For humanitarian items, the specific clusters / sectors covered are carried in `
 
 Classify a response as specifically as the source metadata supports, preferring a specific code over the `eo-vap` fallback.
 
+- **Data products** (`eo-dat`) are the most basic EO response — the deliverable is the satellite imagery dataset itself, not a derived map. Each delivered dataset is a Response item (e.g., every Charter acquisition, `disaster:class = acquisition`; a UNOSAT GIS-ready download). For the Charter, mind the ETL subtlety: an acquisition is recorded at several processing stages, and only the **last, calibrated stage** is kept as the `eo-dat` Response item — that is the dataset responders use to build VAPs; earlier-stage records are intermediate artifacts, not separate Response items. Because the `eo-dat` item *is* the dataset, it carries `eo:` / `sar:` / `sat:` (and `disaster:class = acquisition` for Charter) directly, and derived VAP Response items reference it via `derived_from`.
 - **CEMS products** are always classifiable — map the CEMS product type directly: `REF`→`eo-ref`, `FEP`→`eo-fep`, `DEL`→`eo-del`, `GRA`→`eo-gra`, `SR`→`eo-sr`. Monitoring iterations use the underlying product code with `response_detail.monitoring_number` set (see §4).
 - **Charter VAPs**: classify by the VAP title/description where delineation or grading intent is discernible (`eo-del` / `eo-gra`); otherwise fall back to `eo-vap`. Do not force a classification the source does not support.
 - **UNOSAT products**: classify by phase and product description — Phase 1 → `eo-fep`; flood extent → `eo-del`; damage density → `eo-gra`; population exposure → `eo-pop`; monitoring → `eo-mon`.
@@ -192,6 +196,7 @@ The Sendai Framework for Disaster Risk Reduction 2015–2030 defines 7 global ta
 
 | Code | Sendai targets | Rationale |
 | --- | --- | --- |
+| `eo-dat` | D, G | Data products (e.g., raw imagery) support infrastructure assessment and EO access |
 | `eo-ref` | G | Provides pre-event baseline — supports EO/early warning access |
 | `eo-fep` | D, G | Rapid post-event extent informs infrastructure damage response and EO data access |
 | `eo-del` | D, G | Affected area delineation supports critical infrastructure damage assessment |
@@ -254,6 +259,7 @@ The Sendai Framework defines 7 global targets tracked by the Sendai Monitor. All
 
 | Response concept | International Charter | Copernicus EMS | UNOSAT | Monty code |
 | --- | --- | --- | --- | --- |
+| Satellite imagery dataset | Acquisition (calibrated, `disaster:class = acquisition`) | — | GIS-ready data download | `eo-dat` |
 | Pre-event reference mapping | Reference map | `REF` | Phase 0 | `eo-ref` |
 | Rapid first estimate | Best-effort early VAP | `FEP` | Phase 1 (PSA) | `eo-fep` |
 | Affected-area delineation | Delineation map | `DEL` | Phase 2 flood extent | `eo-del` |
@@ -269,7 +275,7 @@ The Sendai Framework defines 7 global targets tracked by the Sendai Monitor. All
 | --- | --- |
 | `disaster:` ([Terradue](https://terradue.github.io/stac-extensions-disaster/v1.1.0/schema.json)) | The live data model for International Charter items; Charter VAP Response items MUST declare it alongside `monty:`. Covers `disaster:class`, `disaster:activation_id`, `disaster:activation_status`, `disaster:resolution_class`, etc. |
 | `processing:` ([stac-extensions/processing](https://github.com/stac-extensions/processing)) | Processing-chain provenance for derived EO products (CEMS, UNOSAT). |
-| `sar:` / `eo:` / `sat:` | Describe the **acquisition / source imagery** layer reached via `derived_from`, not the Response product item itself. |
+| `sar:` / `eo:` / `sat:` | Describe the **acquisition / source imagery** layer reached via `derived_from`, not the Response product item itself. The sole exception is `eo-dat`, where the delivered dataset *is* the Response item and these extensions are declared on it directly. |
 
 The per-source extension combinations are specified in [Response Best Practices](response-best-practices.md). Neither CEMS nor UNOSAT publishes a STAC extension; their source-specific values are carried under `monty:response_detail` or on linked acquisition items.