Parcel And Candidate Context
Summary
Parcel and candidate context is the evidence layer that keeps geo selections explainable. A map score is useful only if the platform can say which source facts, parcel features, prospecting policies, and candidate identifiers made a selection meaningful.
Reader Question
What source context follows a parcel or prospect candidate through geo scoring and saved-selection handoff?
Surface Or Workflow
Operators see candidate context through tooltips, selection summaries, and handoff previews. Engineers inspect canonical parcel services, prospecting contracts, and candidate resolver code when selection membership or provenance looks wrong.
Lifecycle
Source rows are canonicalized into parcel records with thin raw context. Prospecting logic classifies or filters candidate rows. Geo services derive features, assign H3 cells, and later resolve saved selections into candidate batches for handoff. Candidate context remains privacy-thin and source-backed.
Child Threads
Implementation Boundaries
services/geo/parcels owns canonical parcel handling. libs/prospecting and services/prospecting own prospecting contracts and execution helpers. services/geo/selections/candidate_resolver.py resolves saved selections into candidate context for consumers without making downstream members itself.
Tradeoffs
Privacy-thin context means the map is less like a CRM detail view, but it is a better boundary for broad geographic exploration and public-safe aggregate exports.
Visual
The current visual is a graph neighborhood. The intended visual is a lineage diagram from source row to canonical parcel, feature/candidate context, saved selection, and downstream consumer batch.
Source Evidence
services/geo/parcelsservices/geo/selections/candidate_resolver.pyservices/prospectinglibs/prospectingtests/geo/test_canonical_parcels.pytests/geo/test_selection_contracts.py