RADAR — automated job discovery into the workspace

RADAR is the entry point for jobs that the user did not paste manually and that did not come from MCP or a collaborator. It is one of the pipeline stages defined in lib/domain/src/pipeline/stages/radar.ts and is the only stage that can create new rows in the workspace's job set; every other stage operates on existing rows.

Inputs

A workspace's RADAR configuration captures:

  • The brief — title patterns, seniority, must-have / must-avoid terms, target geographies and commute caps.
  • The source list — job-board search URLs, company career pages, RSS feeds, and JobCache-side discovery endpoints.
  • The schedule — when RADAR runs (manual, daily, hourly).

The configuration lives in the settings sub-doc so peers see the same brief and the same source set. There is no separate per-user discovery state.

What RADAR does

For each enabled source, RADAR:

  1. Fetches the source (directly or via a relay/proxy when the host is hostile).
  2. Extracts candidate URLs and shallow metadata (title, company, posted date) without yet running the full extract stage.
  3. Deduplicates against the workspace's existing jobs (URL normalisation
    • JobCache canonical-id when known).
  4. Enqueues unseen candidates as fresh process_request rows targeting the extract stage.

The dedup step is why RADAR can run on a schedule without churning the dashboard — a hundred unchanged listings produce zero new rows.

What RADAR does not do

  • RADAR does not score, tailor, or evaluate. It only finds candidates. Everything downstream is the normal pipeline.
  • RADAR does not bypass the workspace's BYOK chains. Any LLM call it makes for candidate filtering routes through resolveChain with the RADAR consumer's seeds.
  • RADAR does not write into the shared JobCache ad/role index. New canonical ads are promoted into that index by the JobCache product, not by a per-workspace RADAR run.

Surfaces

  • ui/src/lib/components/toolbar/modals/JobImport.svelte is the toolbar entry point for configuring sources and triggering an immediate RADAR run.
  • The dashboard's "Added by RADAR" filter group is the default place to triage what a scheduled run produced overnight.
  • Cell-origin tinting tags every RADAR-created row with actorClass: 'system' and actorId: 'cv-internal:radar-scrape' (or the equivalent vendor source when relevant), so the dashboard makes the provenance obvious without an extra column.

Why RADAR is a real stage, not a script

Treating RADAR as a pipeline stage rather than an out-of-band script means it inherits the same things every other stage gets: the process_request queue, the browser/CF backend self-selection, singleflight locks, telemetry, and the ability for an MCP agent to trigger it through the same protocol a human uses from the toolbar.

Source: wiki/content/canon/cv-radar-discovery.md