Skip to main content
Scout runs discovery locally and stores the results on your computer. You can review them before deciding whether anything should sync to Atlas. When you run by place and issue, Scout first checks the local article corpus for usable source text and turns those articles into normal source-linked entries. If the target has not been reached and search is connected, Scout then finds more public sources.

​
Known URLs

Pass a public source when you already know what to inspect:
Add a prompt to focus extraction:

​
Files Of URLs

Use one URL per line:
Use standard input for scripts:

​
Structured Public Resources

Scout can read CSV, TSV, pipe-delimited text, and ZIP files that contain one of those formats. Use this for public bulk resources where each row already contains people, places, roles, dates, or other civic context. Header rows are detected automatically:
For headerless files, pass the column names in order:
Structured runs still create ordinary local Scout runs, pages, entries, source URLs, and source context. Review the people sample before syncing:
Structured public records may be historical. A row from an old archive is useful evidence, but it should not be treated as current contact, employment, role, or location information unless the source date and row context support that claim.

​
Place And Issue Runs

Run against a place and issue set:
If you have already built an article corpus with scout articles crawl or scout articles import, this command can extract entries from those stored articles without a search key. Connect search when you also want Scout to find new public sources:
Then run the same command:
Use --refresh when you want Scout to ignore cached fetches and extractions.

​
Crawl Controls

Scout can follow same-domain links from seed pages:
Limit crawl depth and pages per seed:
Bypass cached fetch and extraction results:

​
Headless Browser Fallback

Scout may launch a headless Chromium browser through Playwright when a public source looks useful but normal HTML fetching cannot read enough text. This is a bounded fallback for JavaScript-rendered pages, not the primary fetch path. Defaults: Scout does not open visible browser windows. Disable the fallback:
Inspect active limits:

​
Progress And Sync

Use default progress for interactive work. Use quiet mode for scripts:
Sync after a run:
For review-first workflows, run locally first, then sync from the saved run.

​
Inspect A People Sample

Use run-scoped entry listing to review the people Scout found before syncing:
JSON output includes the local run id, description, issue areas, source URLs, and source context fields so reviewers can check why each person belongs in the result set. Repeat --run-id to combine reviewed runs while leaving discarded or retry runs out of the sample. Add --unique-names when overlapping sources may mention the same person.

​
Export Entries

Use scout export entries when you need a file instead of an interactive sample. JSONL is the default and works well for large handoffs:
Export CSV when the next review step is a spreadsheet:
Exports include local entry ids, run ids, descriptions, issue areas, source URLs, source context, dataset markers, source keys, source dates, and local creation timestamps. Keep those fields attached when sharing or auditing the file.

​
Verify Counts And Currentness

Use entries stats before a large export or sync:
--min-source-backed checks rows with provenance. --min-unique-people checks exact unique person keys so duplicate runs do not inflate the count. Passing those checks does not certify currentness. Before syncing or exporting a people list, inspect source dates and source context for the relevant run. If a source is an archive, old filing, historical roster, or stale page, treat its entries as historical evidence rather than current outreach data.