RFC: geo_cells / geo_cells_exclude targeting — hierarchical cell-grid systems as a declared geographic unit

[EvgenyAndroid]

Summary

Add geo_cells / geo_cells_exclude to the targeting overlay, a new enums/cell-system.json enum (h3, s2, geohash, custom), and an explicit geo_cells property on execution.targeting in get_adcp_capabilities. This is a standalone, non-breaking additive change against current stable.

The proposal adds a unit, not a mechanism. Cell entries inherit the hard-restriction enforcement semantics already established for geo overlays (#5756) — capability pre-screening before create_media_buy, seller-obligated honoring, INVALID_REQUEST on unsupported fields. No new enforcement path.

Revised 2026-07-26. This body folds in the four required fixes and the Option C capability shape accepted in-thread, the X-B scope resolution and its Fix 3 sentence, the privacy-considerations note, and live links to the two companions (#6013, #6014). See the revision note at the end for a line-by-line changelog.

---

Problem

The targeting overlay's geographic vocabulary is keyed to administrative units (geo_countries, geo_regions, geo_metros, geo_postal_areas) plus point-based geo_proximity. Administrative units have three structural limits for measurement-grade targeting:

1. They don't interoperate across borders. metro-system.json enumerates nielsen_dma, uk_itl1, uk_itl2, eurostat_nuts2 — four incompatible systems for one concept. A multi-market geo experiment cannot use a consistent randomization unit.
2. They come in one resolution each. DMAs (~210 in the US) are too coarse for high-powered geo-split designs; postal areas vary wildly in size and are unstable across census vintages. There is no clean ladder between them.
3. They redraw. ZIP boundaries change with each decennial vintage. A unit that moves cannot anchor longitudinal measurement.

Why geo_proximity.geometry doesn't already cover this. A buyer can convert cells to polygons and send them via geo_proximity.geometry today, so the delivery footprint is achievable with the current spec. But geo_proximity entries are trade areas from arbitrary points, not units of analysis: they don't tile, don't roll up hierarchically, don't compose across campaigns, and carry no stable identifier a delivery report or experiment can reference. Polygons solve delivery; they cannot solve measurement.

Hierarchical cell grids provide the missing properties by construction: globally uniform, multi-resolution with clean parent/child rollup, and fixed for all time. The unit is purely additive — sellers keep their native geo encodings and convert in and out via open-source warehouse-native tooling.

---

Proposed changes

1. New enum: static/schemas/source/enums/cell-system.json

Structurally parallel to metro-system.json, including the custom token.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "/schemas/enums/cell-system.json",
  "title": "Cell Grid System",
  "description": "Hierarchical cell-grid systems for geographic targeting. All listed systems are open specifications.",
  "type": "string",
  "enum": ["h3", "s2", "geohash", "custom"]
}

All three named systems are open specifications (h3: Apache-2.0, s2: Apache-2.0, geohash: public domain). Three systems rather than h3-only: s2 is the native cell system for GCP/Google Maps infrastructure; geohash is embedded in Elasticsearch, PostGIS, Redis GEO, and most document stores with a geo index. An h3-only enum forces sellers on those stacks through a coordinate transform where none is needed. Three systems also clarifies custom: it is for genuinely proprietary systems, not a fallback for well-known ones.

Cross-party identification of custom systems (custom_system_id) is specified in the conversion companion (#6013) rather than here.

2. static/schemas/source/core/targeting.json: add geo_cells and geo_cells_exclude

Mirrors geo_metros item shape (no additionalProperties constraint, matching live schema precedent), with resolution added as a third required property.

"geo_cells": {
  "type": "array",
  "description": "Restrict delivery to specific grid cells. Each entry declares the cell system, the resolution, and cell indexes at that resolution. Seller must declare supported systems and resolutions in get_adcp_capabilities.",
  "items": {
    "type": "object",
    "properties": {
      "system": {
        "$ref": "/schemas/enums/cell-system.json"
      },
      "resolution": {
        "type": "integer",
        "minimum": 0,
        "description": "Cell resolution within the declared system (e.g., 0–15 for h3, 0–30 for s2, 1–12 for geohash). Valid range is system-specific and validated by the seller, not the schema. All values in this entry MUST be valid cell indexes at this resolution."
      },
      "values": {
        "type": "array",
        "description": "Cell indexes within the system (e.g., ['882a100d25fffff'] for an h3 r8 cell). H3 values MUST be in canonical lowercase hex form.",
        "items": { "type": "string" },
        "minItems": 1
      }
    },
    "required": ["system", "resolution", "values"]
  },
  "minItems": 1
}

geo_cells_exclude takes the identical shape, consistent with the existing *_exclude family.

Normative validation requirements (seller-enforced, not schema-encoded). Per-system resolution ranges and cell index format are not encoded in the JSON schema — mirroring how postal system codes are not regex-validated. However, sellers MUST:

• Resolution agreement (Fix 1). The resolution declared on an entry MUST agree with the resolution encoded in every entry in values[]. All three named systems encode resolution intrinsically (h3 in the index, s2 in the token, geohash in string length), so cross-field drift is detectable even though JSON Schema cannot express it. Sellers MUST reject disagreeing entries with INVALID_REQUEST and the offending field path.
• Reject entries whose resolution is outside the valid range for the declared system with INVALID_REQUEST and the offending field path.
• Reject entries whose values contain strings that are not valid cell indexes at the declared resolution, with INVALID_REQUEST and the offending field path.
• Reject H3 values not in canonical lowercase hex form with INVALID_REQUEST. Silent case-insensitive acceptance would create two valid representations of the same cell, breaking string-equality key lookups.

Mixed-resolution entries within one system are a buyer-side bug; deterministic rejection is more useful than silent coercion.

3. Delivery obligation and its boundary (Fix 3)

A geo_cells overlay is a delivery-routing constraint. The seller MUST NOT deliver impressions outside the declared cell set, using whatever internal geo representation it chooses (native cell support, admin-unit crosswalk, or polygon conversion via geo_proximity.geometry semantics).

The restriction binds the output footprint, not the seller's internal representation. A conversion whose executed footprint extends beyond the declared cell set is non-conformant, regardless of the internal method that produced it. Conservative conversions (exact cell-boundary polygons, inscribed circles, fully-contained admin crosswalks) satisfy this; overshoot conversions (circumscribed circles, intersection-mode crosswalks) do not.

Cell-grain attribution is a separate capability. It is declared in reporting_capabilities and requested via reporting_dimensions (#6014). Supporting the overlay does not imply cell-grain reporting, and vice versa.

This is the complete normative surface required for correctness, including experiment safety: overshoot is what contaminates a holdout, and overshoot is already non-conformant here. Footprint identity between two conformant sellers — one inscribing circles, one polyfilling whole cells, both staying inside the declared set — is an optimization rather than a safety property, and is specified in #6013 rather than gating this RFC (see Resolved design questions).

4. Capability declaration in get_adcp_capabilities response schema

Add geo_cells as an explicit named property on media_buy.execution.targeting. The live execution.targeting object does not use additionalProperties: false at the top level, so this is an accepted additive sibling of geo_metros.

Resolution is a precision tier, not a vocabulary choice, so the right precedent is keyword_targets.supported_match_types rather than geo_metros booleans — a boolean-to-object migration later would be a breaking change. Per-system field names follow each system's native terminology.

"geo_cells": {
  "type": "object",
  "additionalProperties": true,
  "description": "Cell-based targeting. Absent system key = system not supported. Absent resolution field within a system = all resolutions supported; present and non-empty = constrained to listed values.",
  "properties": {
    "h3": {
      "additionalProperties": true,
      "properties": {
        "supported_resolutions": {
          "type": "array", "minItems": 1, "uniqueItems": true,
          "items": { "type": "integer", "minimum": 0, "maximum": 15 }
        }
      }
    },
    "s2": {
      "additionalProperties": true,
      "properties": {
        "supported_levels": {
          "type": "array", "minItems": 1, "uniqueItems": true,
          "items": { "type": "integer", "minimum": 0, "maximum": 30 }
        }
      }
    },
    "geohash": {
      "additionalProperties": true,
      "properties": {
        "supported_precisions": {
          "type": "array", "minItems": 1, "uniqueItems": true,
          "items": { "type": "integer", "minimum": 1, "maximum": 12 }
        }
      }
    },
    "custom": { "additionalProperties": true }
  }
}

Absence semantics (Fix 4). An empty array is never valid (minItems: 1); absence is the single way to express "all." A seller that does not declare a system is disqualified from receiving that system's cell targeting before create_media_buy — no new pre-screening semantics. The custom key exists so sellers supporting proprietary grids have a conformant declaration path (Fix 2); its identification field is specified in #6013.

5. Non-normative documentation

• docs/media-buy/advanced-topics/targeting.mdx: extend the existing RCT-holdout worked example with a cell-based variant (treatment/holdout assignment at declared resolution).
• New guidance page (docs/media-buy/advanced-topics/geo-units.mdx): resolution selection (statistical power vs. footprint), weighted crosswalks between cells and metro/postal/regions, interim delivery path via geo_proximity.geometry polygon conversion for sellers without native cell support, and the US statutory "precise geolocation" boundary (the 1,750 ft radius definition falls between H3 r7 and r8, so resolution choice doubles as a compliance declaration).

Privacy considerations. A seller declaring support for a given resolution is making a precision claim and a privacy claim at once. Resolution alone is not a privacy control — risk is driven by the population inside a cell, not the cell's area. Sellers supporting fine resolutions in sparse geographies need a stated aggregation or suppression strategy (both a resolution floor and an audience floor, declared together) for cells that fall below it, and should not silently roll a sparse cell into its parent — see #6014 §6 for the reporting-side version of this same resolution. Because cell IDs discretize location rather than exposing an exact point, clean-room mediation is not inherently required at the resolutions this RFC's use cases target; that property is a function of the declared resolution and cell population, not of the cell system.

---

Resolved design questions

Question	Resolution
Three-system enum vs. h3-only?	Three systems (h3, s2, geohash). Native-system avoidance of forced coordinate transforms on GCP/Elasticsearch stacks; custom purpose is clearer with three named alternatives.
Per-system resolution bounds: if/then schema vs. SDK invariant?	Seller-enforced, normatively specified but not schema-encoded. Mirrors postal-code precedent; draft-07 if/then across three systems adds maintenance burden without meaningful validator benefit given seller-side INVALID_REQUEST enforcement.
H3 index form: canonical lowercase vs. case-insensitive?	Canonical lowercase required, seller MUST reject otherwise. Two representations of one cell break string-equality key lookups.
3.1 scoping vs. standalone additive?	Standalone additive. Non-breaking; bundling into 3.1 couples timing to a heavier milestone unnecessarily.
geo_cells vs. geo_postal_areas buyer guidance?	Determined by measurement stack, not protocol preference. If downstream analysis is postal-keyed, use postal targeting and crosswalk at analysis time; if outcome data is already cell-keyed, use cell targeting directly.
Capability shape: booleans vs. object?	Object, per-system field names, minItems: 1 / uniqueItems: true, additionalProperties: true throughout. Resolution is a precision tier, not vocabulary membership; a boolean→object migration later would be breaking.
Empty supported_resolutions = all resolutions?	No — superseded. Empty arrays are invalid (minItems: 1); absence of the field means all resolutions. Empty-means-all inverts every other array in the schema.
X-A (normative conversion rules pre-merge) vs. X-B (hard restriction sufficient)?	X-B, plus the output-footprint sentence in §3. Overshoot is already non-conformant under the delivery restriction, so contamination — the experiment-fatal case — is excluded without containment-mode logic. Footprint identity between conformant sellers is an optimization and is specified in #6013.

---

Companions (linked, not bundled)

• RFC: Cell Interoperability and Execution Conversion — companion to #5969 #6013 — Cell Interoperability and Execution Conversion. Containment modes, circle modes (inscribed / circumscribed / area-equivalent), conversion quality metrics, crosswalk provenance and versioning, and custom_system_id. This is the layer that lets a seller without native cell support execute cell overlays against the primitives it already runs on.
• RFC: Cell-grain delivery reporting — companion to #5969 #6014 — Cell-grain delivery reporting. cell as a fifth geo_level in the existing delivery breakdown, so delivery reads back in the unit it was targeted in, at a capability-declared resolution, with silent parent rollup prohibited.
• Geo targeting constraints for Sponsored Intelligence sessions #5755 — SI geo eligibility. If cell-system.json exists, Sponsored Intelligence geo eligibility extends to cell grids via the shared system enum reference with zero additional spec work.

---

Affected spec files

• static/schemas/source/enums/cell-system.json — new
• static/schemas/source/core/targeting.json — add geo_cells, geo_cells_exclude
• static/schemas/source/protocol/get-adcp-capabilities-response.json — add explicit geo_cells property on media_buy.execution.targeting
• docs/media-buy/advanced-topics/targeting.mdx — cell-based RCT worked example
• docs/media-buy/advanced-topics/geo-units.mdx — new: crosswalks, resolution selection, interim geometry path, compliance and privacy notes

Related

• Seller geo-targeting capability declaration for DMA-level targeting #5756 — confirmed hard-restriction semantics and capability pre-screening for geo overlays (the enforcement contract this RFC rides on)
• RFC: Generalized attribute-value confidence schema for publisher-declared audience signals #5758 — generalized confidence schema; declared resolution as the spatial quality declaration (spatial carve-out)

---

Revision note (2026-07-26)

Changes from the original filing, all traceable to in-thread acceptance:

1. §2 — added the Fix 1 resolution-agreement MUST as an explicit normative bullet.
2. §3 — new section. Fix 3 delivery-routing vs. attribution prose, plus the accepted output-footprint sentence resolving X-A/X-B.
3. §4 — capability block replaced with the Option C shape: additionalProperties: true throughout, per-system field names (supported_resolutions / supported_levels / supported_precisions), minItems: 1 / uniqueItems: true, and a custom key (Fix 2 — the previous block made custom undeclarable).
4. §5 — added the privacy-considerations note (joint resolution + audience floor; no silent parent rollup; clean-room mediation not inherently required at target resolutions).
5. Resolved design questions — the empty-array row is marked superseded (Fix 4); rows added for capability shape and the X-A/X-B outcome.
6. Companions — placeholder references replaced with RFC: Cell Interoperability and Execution Conversion — companion to #5969 #6013 and RFC: Cell-grain delivery reporting — companion to #5969 #6014.

[bokelley]

Triage

Classification: Feature request (RFC)
Bucket(s): spec / protocol, schema
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Technically sound, needs 4 fixes before merge — (1) normative MUST that declared resolution agrees with the resolution encoded in cell tokens (H3/S2/geohash encode resolution intrinsically; cross-field drift is undetectable by JSON Schema); (2) custom system is in the enum but undeclarable in the capability block (additionalProperties: false + no custom key = sellers supporting custom grids have no conformant declaration path); (3) normative prose required distinguishing delivery-routing (expensive: cell→polygon→native-geo conversion) from impression-attribution (tagging + reporting) — conflating them produces divergent seller implementations; (4) supported_resolutions: [] "empty = all" is a footgun inverting every other array in this schema.
• ad-tech-protocol-expert-deep: Capability shape (RFC's Option B) is correct over booleans — resolution is a precision tier, not a vocabulary choice; right precedent is keyword_targets.supported_match_types, not geo_metros. Boolean→object is a future breaking migration. Proposes Option C (below): per-system field names, minItems: 1, uniqueItems: true, additionalProperties: true throughout. Option A is deceptively cheap now and a major-bump cost later.
• adtech-product-expert: Defer — no SSP/DSP/publisher ad server exposes H3/S2/geohash natively today; the primary use case (RCT holdout measurement) cannot close the loop without by_cell[] delivery reporting, which is explicitly deferred as a follow-on; custom without custom_system_id is a coordination dead-end for the parties who need it most.

My take: The non-breaking classification is sound and the core item shape is coherent; the protocol experts converge on "fix and ship" while the product expert calls for deferral pending operator pull and the companion reporting schema. This is a timing and adoption-sequencing question for the WG.

@bokelley, your call:

Option X — Proceed with required revisions. Adopt the RFC with the following fixes before merge:

// Corrected capability shape (Option C) replacing RFC's geo_cells proposal
"geo_cells": {
  "type": "object",
  "additionalProperties": true,
  "description": "Cell-based targeting. Absent key = system not supported. Absent resolution field within a system = all resolutions supported; present and non-empty = constrained to listed values.",
  "properties": {
    "h3": {
      "additionalProperties": true,
      "properties": {
        "supported_resolutions": {
          "type": "array", "minItems": 1, "uniqueItems": true,
          "items": { "type": "integer", "minimum": 0, "maximum": 15 }
        }
      }
    },
    "s2": {
      "additionalProperties": true,
      "properties": {
        "supported_levels": {
          "type": "array", "minItems": 1, "uniqueItems": true,
          "items": { "type": "integer", "minimum": 0, "maximum": 30 }
        }
      }
    },
    "geohash": {
      "additionalProperties": true,
      "properties": {
        "supported_precisions": {
          "type": "array", "minItems": 1, "uniqueItems": true,
          "items": { "type": "integer", "minimum": 1, "maximum": 12 }
        }
      }
    },
    "custom": { "additionalProperties": true }
  }
}

Also required: normative MUST that resolution in each item agrees with the resolution encoded in values[] entries; normative prose distinguishing delivery vs. attribution mode.

Option Y — Spec Backlog, gated. Park until (a) at least one seller implementer confirms pull and (b) a companion by_cell[] delivery-reporting issue is filed, so cell targeting and cell reporting ship as a coherent measurement unit rather than a half-closed loop.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_013WAuLJvN4r3CNY6gw3WBW4

---

Generated by Claude Code

[EvgenyAndroid]

Accepting all four required fixes and the Option C capability shape as proposed — responses in order, then the Option X/Y question:

Fix 1 (resolution agreement MUST): accepted. All three named systems encode resolution intrinsically (h3 in the index, s2 in the token, geohash in string length), so the rule is cheap to enforce and catches cross-field drift JSON Schema can't. Proposed normative text: "The resolution declared on an entry MUST agree with the resolution encoded in every entry in values[]. Sellers MUST reject entries where they disagree with INVALID_REQUEST and the offending field path."

Fix 2 (custom undeclarable): accepted — Option C's custom: { additionalProperties: true } gives the declaration path. Given the product expert's point that custom without cross-party identification is a coordination dead-end for exactly the parties who need it, I'd propose folding a minimal custom_system_id (string, required on targeting entries when system is custom; declarable inside the capability custom object) into the revision rather than deferring it to a third issue — but I defer to the WG on whether that stays in-scope or files separately.

Fix 3 (delivery vs. attribution modes): accepted. Proposed normative prose: "A geo_cells overlay is a delivery-routing constraint: the seller MUST NOT deliver impressions outside the declared cell set, using whatever internal geo representation it chooses (native cell support, admin-unit crosswalk, or polygon conversion via geo_proximity.geometry semantics). Cell-grain attribution is a separate reporting capability, declared in reporting_capabilities and requested via reporting_dimensions; supporting the overlay does not imply cell-grain reporting, and vice versa." The reporting half is specified in the companion below.

Fix 4 (empty-array footgun): accepted — Option C's absence semantics with minItems: 1 / uniqueItems: true is strictly better than either empty-means-all or mandatory-full-enumeration: no empty array is ever valid, and absence is the single way to say "all." The per-system field naming (supported_resolutions / supported_levels / supported_precisions) matching each system's native terminology is right, as is the keyword_targets.supported_match_types precedent over geo_metros booleans — resolution is a precision tier, not a vocabulary membership.

On Option X vs. Y — I'd argue X, because both of Y's gates are now closed or closing:

Gate (b) is closed: the delivery-reporting companion is filed as #[NUMBER]. One note on its shape — it is not a parallel by_cell[] array. The delivery response already carries a complete per-level geo apparatus (by_geo via geo-delivery-metrics.json with conditional per-level validation, reporting_dimensions.geo, supports_geo_breakdown, mandatory truncation flags). The companion adds cell as a fifth geo_level and inherits all of it: one enum value, one conditional branch, one request field, one capability extension. A parallel array would duplicate four surfaces that would then drift. It also resolves the reporting-grain question deterministically: sellers report at the requested, capability-declared resolution; silent parent-cell rollup is prohibited; coarsening is the buyer's exact operation via the cell hierarchy.

Gate (a) is a question I can put to operators this week: this RFC comes out of an active discussion with seller-side operators in audio and CTV connected to the forming signal working group, where sub-metro, cross-border experiment units are the stated need. I'll solicit implementer confirmation there and report back on this issue. Worth noting the adoption bar is deliberately low: a seller with existing geo_proximity.geometry support can honor cell overlays via polygon conversion on day one — the RFC adds the identifier layer, not a new delivery capability — so "no SSP/DSP exposes H3 natively" is not the dependency it appears to be.

Happy to turn the accepted revisions into a PR against targeting.json, cell-system.json, and the capability schema if that's the preferred next step.

[rickcentralcontrolcom]

I like the direction this has taken. It addresses the underlying requirement I was originally trying to describe, but in a cleaner, more general way than my initial proposal.

From the measurement perspective, the use case is already well established. Geo-based incrementality experiments are routinely used across CTV, retail media, search, social, and other channels. They depend on explicit assignment of treatment and holdout geographies, requiring both inclusion and exclusion rules that can be enforced consistently during media delivery.

While I can't point to an AdCP deployment requiring cell-based targeting today, the measurement workflow itself is not new. A standardized spatial targeting mechanism would provide a common way to express those constraints across sellers, while supporting downstream matching to offline outcomes for incrementality measurement. The proposed cell-based approach also seems like a more flexible, globally applicable foundation than relying on administrative boundaries such as DMAs or ZIP codes.

[nwoodman-spec]

I support adding hierarchical cells to AdCP. One gap to flag: the RFC assumes a fairly direct path from cell declaration to native seller execution, and that path will take time.

Native cell targeting and cell-level delivery reporting will not be broadly available across DSPs, SSPs, publisher ad servers, clean rooms, and measurement systems for a while. During that transition, administrative geographies, platform location IDs, polygons, and centroid-plus-radius proximity targets remain the actual execution primitives. So the spec should describe cells two ways: as a native targeting unit where supported, and as an interchange and measurement unit that converts deterministically into the geographies platforms already execute. Without that conversion layer, geo_cells can be valid and still go unexecuted.

The conversions are not neutral. Two sellers handed the same geometry can return different inventory, reach, exclusions, and experiment populations depending on the conversion rule they pick. Those rules belong in the spec, not with each implementer. The rest of this comment specifies them.

1. Polygon to cell: declare the containment mode

H3 polygonToCells defaults to center containment. That is useful because a non-overlapping partition of admin polygons produces a non-overlapping partition of cells. It does not fully cover the source boundary: a cell whose center sits just outside the polygon is dropped even when it overlaps. H3's experimental API exposes the other modes explicitly (center, fully contained, overlapping, bounding-box overlapping). (H3 regions API)

A seller using center containment and one using intersection containment return different results for the same DMA. The conversion should declare its mode:

{
  "system": "h3",
  "resolution": 8,
  "source_geometry": { "type": "administrative_area", "system": "nielsen_dma", "values": ["501"] },
  "conversion": { "operation": "polygon_to_cells", "containment": "center" }
}

At minimum the vocabulary should distinguish center, fully_contained, and intersects. The spec should also state whether boundary cells may carry an overlap weight, and that the weight is an analytical crosswalk, not an instruction to deliver a fraction of a cell's impressions:

{ "cell": "882a100d25fffff", "coverage_fraction": 0.63 }

2. Cell to proximity: inscribed vs circumscribed, and why it changes the experiment

Where a seller executes on centroid-plus-radius (Google Ads proximity takes a center and radius, not an H3 boundary, per Google Ads Help), a cell converts to a circle. There are two useful circles and they are not interchangeable.

Inscribed circle: the centroid plus the minimum distance from the centroid to any edge. It sits fully inside the cell, and adjacent inscribed circles meet at the shared edge without overlapping, so treatment and control units stay mutually exclusive. It leaves the corners of the cell uncovered. For a regular hexagon of circumradius R:

inscribed radius = (sqrt(3)/2)R  =~ 0.8660R
covered area     = pi / (2*sqrt(3))  =~ 0.9069   (9.31% of the cell uncovered)

This is the conservative mode for exclusive assignment.

Circumscribed circle: the centroid plus the maximum distance to any vertex. It fully covers the cell and extends past it, so circles from adjacent cells overlap and create duplicate eligibility and treatment contamination near edges. For a regular hexagon:

circumscribed radius = R
circle area          = 2*pi / (3*sqrt(3))  =~ 1.2092   (20.92% larger than the cell)
overlap of two adjacent circles = R^2 * (pi/3 - sqrt(3)/2)  =~ 6.97% of one cell, per adjacent pair

The 6.97% is per adjacent pair, not a grid-wide total, but it shows the circumscribed circle is not a neutral stand-in for the cell. It changes both reach and exclusivity.

Declare the mode rather than leave it to the implementer:

{ "operation": "cell_to_proximity", "circle_mode": "inscribed",    "radius_method": "minimum_center_to_boundary_distance" }
{ "operation": "cell_to_proximity", "circle_mode": "circumscribed", "radius_method": "maximum_center_to_vertex_distance" }

An area-equivalent circle (circle area equal to cell area) is a third option. It preserves area but neither full coverage nor exclusivity, so it should not be the default for delivery or experimentation.

One implementation note: H3 cells are spherical, not regular planar hexagons, and H3 includes 12 pentagons. Implementations should compute these radii from each actual cell boundary (cellToBoundary, cellToLatLng, per H3 cellToBoundary) rather than from the resolution table's average edge length.

3. Reverse conversions

Where a seller cannot execute cells natively, a cell should convert to whatever the downstream platform already accepts: exact polygon or multipolygon, centroid plus radius (per section 2), platform-native admin or location IDs, or a weighted crosswalk to postal, metro, or region inventory. Polygon conversion is deterministic from the cell boundary. Radius conversion is approximate and must declare which circle it used.

4. Preserve requested vs executed geography in reporting

This extends the reporting companion. When the buyer requests a cell and the seller executes a polygon, radius, or admin crosswalk, the report should retain the requested cell system, ID, and resolution; the executed geometry type and conversion mode; the effective radius or polygon; the source and version of any admin crosswalk; and whether the footprint was conservative, expansive, or area-equivalent. Otherwise a report can claim delivery against an H3 cell when the media ran against an expanded circle or an approximate postal crosswalk. For incrementality, market tests, frequency management, and treatment/control separation, that difference is material.

The clean way to say it: distinguish the requested unit, the executed footprint, and the reported attribution unit. They coincide in a native implementation and diverge during adoption.

5. Custom systems need an identifier

+1 to specifying custom_system_id. A custom token without unambiguous cross-party identification cannot interoperate, and a registry path also lets future open cell systems declare themselves without reopening the enum.

Recommendation

Add a section to the RFC, "Cell Interoperability and Execution Conversion," that normatively defines polygon-to-cell containment modes, cell-to-polygon conversion, cell-to-proximity conversion (inscribed, circumscribed, or a declared alternative), preservation of requested vs executed geography in reporting, and crosswalk provenance and versioning.

Cells are useful before every bidder speaks H3 natively. Their near-term value is as a stable hierarchical reference that converts into the admin boundaries, polygons, location IDs, and proximity targets the ecosystem runs on today. The spec should standardize that bridge so every buyer and seller does not build a different one.

[bokelley]

Triage — Re-engagement

Classification: RFC scope question (seller-side conversion semantics)
Status: ready-for-human — new decision point added to Option X

New input from @nwoodman-spec: Sellers without native cell support must convert buyer-provided cells to execution primitives (admin areas, polygons, proximity circles). These conversions are non-neutral: H3 center containment and intersection containment produce different cell sets from the same admin boundary — two conformant sellers executing the same geo_cells request can deliver to materially different footprints. For RCT holdouts this is treatment contamination, not just implementation variance.

Relationship to accepted Fix 3: Fix 3 bounds the delivery obligation ("MUST NOT deliver outside declared cells"). The conversion comment reveals that obligation is ambiguous when the execution primitive is a polygon or radius derived from the cells — the derived shape's boundary may extend past or fall short of the declared cell boundary depending on the mode chosen.

New scope question for Option X:

X-A — Normative conversion rules (Fix 5, scope-expanding): The spec declares containment modes (center, fully_contained, intersects), recommends center for experiment exclusivity, and requires sellers to declare their conversion mode in the capability response. Additive but expands the RFC beyond its stated "unit, not a mechanism" scope.

X-B — Hard-restriction sufficient: Wire contract = "MUST NOT deliver outside declared cells"; conversion is seller-internal. Conversion normalization, circle-mode declaration, and reporting provenance (sections 2–4 of the comment) file as a companion issue alongside the by_cell[] reporting dimension.

custom_system_id (section 5) is already flagged in EvgenyAndroid's response and can follow the same companion path under either option.

@bokelley: does Option X require X-A before merge, or is X-B the right scope boundary with conversion as a follow-on?

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01878cPdurwKVcoonHuSEmZW

---

Generated by Claude Code