Methodology
How the data is built
Pipeline, conventions, verification & provenance
Every figure in Proxima traces back to a filing made with the SEC. This page explains, at a high level, how a proxy statement becomes structured data — the pipeline that builds it, the conventions the data follows, how the output is verified, and how you can report a correction if something looks wrong.
01Pipeline: From Filing to Structured Record
The pipeline runs in three stages. First, a token-free, deterministic ingest layer discovers, downloads, and classifies every compensation-relevant filing a company makes with the SEC — proxy statements (DEF 14A), annual and quarterly reports (10-K/10-Q), Section 16 insider filings (Forms 3/4/5), 8-Ks, ownership filings (SC 13D/G), and merger proxies (DEFM14A) where applicable. This stage uses rule-based triage, not a language model, so it runs at no per-filing cost.
Second, the proxy statement itself is read by 23 specialized extraction agents, each scoped to one section of the filing — the Summary Compensation Table, Outstanding Equity Awards, Grants of Plan-Based Awards, Pension Benefits, Nonqualified Deferred Compensation, Director Compensation, Beneficial Ownership, PSU performance conditions, severance and change-in-control terms, hedging/pledging and clawback policy, peer groups, and more. Agents transcribe what the filing states; they are instructed not to infer, estimate, or fill in a figure the filing does not itself report.
Third, an assembly and reconciliation layer merges the per-agent outputs into a single canonical record per company per fiscal year — resolving executive names consistently across tables (a fuzzy name-resolution pass reconciles nicknames, punctuation differences, and honorific-only references to the same person), cross-checking totals against their components, and producing the structured record served throughout the product.
02The "null" vs. "Not Disclosed in Proxy" Convention
Every extracted field follows one rule, applied consistently by every agent: a JSON value of null means the field does not apply to this executive or company — for example, a pension value for an executive who is not a participant in any defined-benefit plan. The string "Not disclosed in proxy" means the field does apply, but the company's filing did not state a value for it.
The distinction matters for comparison. Collapsing both cases into a blank would make "this company doesn't offer this benefit" indistinguishable from "this company offers it but didn't disclose the amount" — two very different facts when you're comparing pay practices across companies. This convention is fixed in every extraction agent's instructions and is not overridden on a per-company basis.
03Ground-Truth Verification
49 tickers have been fully hand-verified end-to-end — every extracted figure checked directly against the proxy statement it was drawn from.
Beyond that manually verified set, an automated fingerprint-based validator audits the full extraction corpus for internal consistency on every calibration run. In the most recent pass, the validator scanned 150 complete fiscal-year extraction directories, segmenting 123 as modern-schema and 27 as legacy-schema by content fingerprint — the presence of source citations and quoted text in the output, not a self-reported completion flag. Across the 123 modern-schema directories, the validator surfaced 432 warnings and, after a checker-bug fix, exactly 2 remaining errors — both true-positive transcription slips confined to a raw-text companion field, not the extracted value itself. All 123 modern-schema directories passed with warnings at most except the 2 carrying those true-positive errors — which are the validator working as designed, flagging genuine raw-field contradictions for correction. After the checker fix, the modern-schema corpus carries zero false-positive errors.
The same harness gates changes to the validator itself: fixes are driven by specific rows it mis-flagged (for example, a bare parenthetical footnote marker such as "(2)" being misread as a negative number) and are only accepted after a regression test pins the corrected behavior — so a fix can remove a false warning but can never silently mask a real one.
04Provenance
Every sourced datum in Proxima is traceable back to the filing it came from. Where a figure or disclosure is shown, a citation identifies the specific SEC filing it was transcribed from and, where supported, links directly to the underlying passage in the source document via an EDGAR text-fragment deep link — so a number displayed in Proxima is never more than a click away from the filing language it was built from.
05Corrections
If a figure or disclosure shown in Proxima looks inconsistent with the underlying filing, you can report it directly from the sourced datum in question. Reported corrections are reviewed against the source filing by hand, and where the report is confirmed, the record is corrected.
We aim to resolve verified corrections within 5 business days of a report being filed.
06Data Coverage
Proxima's primary source is the DEF 14A annual proxy statement, supplemented by the filing types that inform it over the course of a fiscal year — Forms 3/4/5 (insider transactions), 8-K (including Item 5.02 executive changes and Item 5.07 say-on-pay vote results), 10-K/10-Q, Schedule 13D/G ownership filings, and merger proxies (DEFM14A) for companies in a pending or completed acquisition.
Coverage grows continuously as each proxy season's filings are ingested and extracted. A company that has been acquired or has gone private is retained in the historical record rather than removed — the compensation history it disclosed while public remains queryable.
Questions about this methodology? Contact aspoerl@gmail.com.