6 Matching Annotations
  1. Last 7 days
    1. In the United States, Trump 2024 campaign senior adviser Tony Fabrizio released a polling memo to donors in May 2024 claiming Trump led in all seven battleground states (Caputo, 2024).

      I researched this case. It does not appear so clear of a biased call (and the polls were internal to the campaign)

    1. 0.1 Hand-validation of the extracted vote shares We validate the extracted vote shares against a sample of polls coded by hand off the rendered PDFs.

      This section is very good and results make sense. There is only one possible thing to address: Why is that we only focus on 1st round results here and use both rounds in the main text? The generated sample mixed some 2nd round results, but these ere matched using 1st round candidate slate.

    1. decide whether to carry the multi-model / vision build further; Henrik's prototype didn't beat the current pipeline, the hand-validation decides. spec.

      We are now able to compare different extraction pipelines using the hand validated sample. This could be a new TODO list item.

  2. Jul 2026
    1. Hand-code the gold standard — your Streamlit app + RAs read each sampled poll's rendered PDF and type the reported shares; this scores the extractor and answers "is the +7 pp real?". Sample + worksheet are ready, N is your call. AN-130.

      I think we can use sample with size 500. The candidate slate can be obtained via TSE's CSVs data then the Streamlit app will only show a window with a PDF and a column with candidates' names (party/number) a blank numeric fields so RAs enter the PDF's estimates from the correct estimulated scenario. Does that work for you? What I need:

      • The actual sample of 500 polls
      • The candidate slate of each one in a CSV that have a column linking to each poll PDF (perhaps with a public link to each PDF in a Dropbox folder, so it is easier to create an online app to share with RAs)
      • A .md documenting the data format, conventions, etc., so I can use Claude/Codex to adapt the data to a Streamlit app
    1. Quota-choice test (income quotas) — not testable in the registry, and that's itself informative: 97% of polls declare income quotas (it's the Brazilian sex/age/education/income standard, no use-vs-don't-use variation), and 0% publish the income distribution they target. If the renda channel operates, it operates below what the relatório discloses — consistent with the Channel-B / unsupervised-margin story.

      Quota targets are in the main sample design description, in the CSVs, not in the PDFs' relatórios. Most polling firms (I would say 95%) disclose their quota targets because that is mandatory by the electoral legislation.

    2. Sample-design areas vs prior results (Hidalgo geo-upgrade) — built it, not just assessed it: downloaded Hidalgo's geocoded polling-station panel and joined 2020 votes to bairros. The vote-side match tops out at ~30% — a resolution mismatch (votes aggregate to polling places/schools, coarser and offset from the residential bairros polls sample), which geometry can't fix. So the existing stronghold-oversampling test (already in the paper, a well-powered null) can't be sharpened this way. Reusable geocoding primitives committed to politica for future use.

      This does not seem worth pursuing. Bairros in Brazilian municipalities are not official divisions. Municipalities define their own bairros and most of the time these definitions are vague and not public. Moreover, as most polling firms use area-level sampling, evaluating bias from past results can capture sample variability. Thus, trying to geomerge bairros with electoral results is not promising.