Geo Saved Selections
Summary
Saved selections turn exploratory map work into durable geo state. They record selected H3 membership, score-family context, summary fields, coverage warnings, and candidate-resolution metadata without creating marketing members or downstream workflow state.
Reader Question
What exactly is persisted when an operator saves a geo selection, and why is that the correct boundary before marketing or another module consumes it?
Surface Or Workflow
Operators save selections from the geo analysis map after filtering or lasso selection. They need the selection to be durable, inspectable, and reusable. Engineers need to know which state belongs to geo and which state belongs to a downstream audience or campaign.
Lifecycle
The UI sends selected geometry and context to the geo API. Geo services persist selection metadata, selected H3 cells, summary metrics, candidate resolver context, and status. Later, a consumer can ask geo to resolve candidate batches from that saved selection. The consumer owns its own materialization.
Child Threads
Implementation Boundaries
services/geo/selections owns saved selection persistence, summaries, and candidate resolution. app/api/geo_analysis exposes selection APIs. services/lkci_lakehouse/models/geo contains persistence models. Marketing imports by reference; it does not write geo selections.
Tradeoffs
Persisting selections by reference means downstream workflows must resolve candidate context at materialization time. That is preferable to copying raw parcel/member detail into every consuming module.
Visual
The current visual is a graph neighborhood. The intended visual is a state diagram from map selection to saved selection, candidate resolution, consumer import, and downstream materialization.
Source Evidence
services/geo/selectionsapp/api/geo_analysisapp/web/app/marketing/geo-analysisservices/lkci_lakehouse/models/geotests/geo/test_saved_selection_service.pytests/geo/test_selection_summary_service.py