candidate-facts-ingest

name	candidate-facts-ingest
description	Gather research-stage candidate facts for one seat candidate. Use when: creating or refreshing a research/candidate-facts/<candidateId>.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

1. Read docs/INGESTION_OPERATING_MODEL.md
2. Confirm the constituency and district IDs
3. Read the district verification file for seat context
4. Collect Tier 1 and Tier 2 sources for person, party, seat, and filing state
5. If declaration sources are available, record the coverage status and useful source anchors; if they are missing, record the conservative gap instead of guessing
6. Write or update one candidate facts JSON file
7. Trigger ingestion-validator-agent and 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 missing or under_review when 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" or withheld

Handoff

• Product promotion uses candidate-edit or district-migration
• Timeline work uses candidate-timeline-ingest