Geocoding And Radar
Summary
Geocoding is a shared capability that helps geo and prospecting normalize location evidence. Radar is an external provider boundary, not a dependency that should leak into map UI, marketing materialization, or prospecting policy.
Reader Question
How does the platform use provider-backed geocoding while keeping provider semantics out of geo scoring, saved selections, and downstream workflows?
Surface Or Workflow
The workflow starts when a source row, customer location, prospect, or parcel needs location normalization. Operators usually see the result indirectly as map coverage, candidate confidence, or selection quality rather than a raw provider response.
Lifecycle
Jobs and services prepare candidate addresses or source rows, call geocoding capabilities, persist normalized location context, and let geo/prospecting services consume stable internal fields. Provider errors or ambiguous matches should be recorded as data that can be retried or diagnosed.
Child Threads
provider-boundary-guardrails: provider clients and retry/error behavior.geocoding-job-family: repeatable geocoding entrypoints.- Parcel And Candidate Context
Implementation Boundaries
integrations/ext_radar owns Radar-specific behavior. services/geocoding owns internal capability logic. jobs/geocoding provides repeatable entrypoints. Geo and marketing should consume normalized internal context, not provider response shapes.
Tradeoffs
Provider-backed geocoding adds external failure modes. Keeping it behind capability and integration boundaries makes scoring and audience workflows more stable and testable.
Visual
The current visual is a graph neighborhood. The intended visual is a provider boundary sequence from source row to geocoding service, Radar adapter, normalized location context, and geo/prospecting consumer.
Source Evidence
services/geocodingintegrations/ext_radarjobs/geocodingtests/geo/test_geocoding_config.pytests/integrations/test_devnet_wedge_runtime_defaults.py