name: candidate-facts-ingest
description: 'Gather research-stage candidate facts for one seat candidate. Use when: creating or refreshing a research/candidate-facts/.json file before any product publish step.'
Candidate Facts Ingest
When to Use
- New or corrected candidate for a constituency
- Filing-status refresh for one candidate
- Confidence or verification refresh before product projection
- Declaration/affidavit coverage needs a staged facts refresh or an explicit gap note
Output
research/candidate-facts/<candidateId>.json
Procedure
- Read
docs/INGESTION_OPERATING_MODEL.md - Confirm the constituency and district IDs
- Read the district verification file for seat context
- Collect Tier 1 and Tier 2 sources for person, party, seat, and filing state
- If declaration sources are available, record the coverage status and useful source anchors; if they are missing, record the conservative gap instead of guessing
- Write or update one candidate facts JSON file
- Trigger
ingestion-validator-agentand surface any findings; treat them as advisory unless standards-keeper adds a hold
Guardrails
- One candidate per task
- Do not write to
public/data/by default - Do not guess age, education, photo, or biography fields
- Do not invent affidavit/declaration coverage; record
missingorunder_reviewwhen the source trail is absent - Use a new candidate file instead of silently mutating history when the person-seat mapping changes
- If the best read is weak, keep
verificationStatus: "under_review"orwithheld
Handoff
- Product promotion uses
candidate-editordistrict-migration - Timeline work uses
candidate-timeline-ingest