Disclaimer: All material in this post has been used with permission. Certain details have been modified for client confidentiality.
Every proxy season, the largest asset managers in the world cast votes on tens of thousands of shareholder proposals — say-on-pay, board elections, ESG resolutions, governance amendments. Each of those votes is supposed to follow the firm's own published voting guidelines, and each one is disclosed after the fact in regulatory filings. The client came to us with a deceptively simple question: before a vote happens, can we predict how a given fund will vote on a given proposal, and can we tell whether that vote is consistent with the fund's stated policy?
That is the system we built. It ingests SEC proxy statements and institutional voting data, then uses a large language model with retrieval-augmented generation to read a proposal alongside the relevant voting guidelines and produce a predicted vote — for, against, or abstain — with a written justification and a citation back to the source. A separate evaluation step scores whether a vote complies with a firm's guidelines. This post walks through how the pipeline fits together.
The Problem: Predicting a Vote Nobody Has Cast Yet
Proxy voting is dense, document-heavy work. A single annual meeting can carry a dozen or more proposals, each described across many pages of a DEF 14A filing. The firms whose behavior we model — BlackRock, Vanguard, State Street, and the proxy advisors Glass Lewis and ISS — each publish detailed voting guidelines that run to dozens of pages and shift year to year. Answering "how will Vanguard vote on this compensation proposal?" means holding both documents in your head at once and reasoning about how the policy applies to the specific facts.
That is exactly the kind of task modern language models are good at, provided you give them the right context. The core insight of the platform is that there is no statistical forecasting model here at all. The prediction is entirely a reading-comprehension problem: put the proposal and the governing guidelines in front of a capable model, ask it to reason, and make it show its work.
Where the Data Comes From
Before any prediction can happen, the platform assembles a picture of who owns what, which meetings are coming up, and how funds have voted historically. That data comes from three main sources:
- Diligent Market Intelligence (DMI) — a set of large CSV datasets covering investor voting details (2021–2024), ownership details, fund details, meeting details, and proposal details. This is the backbone of the historical record.
- The SEC EDGAR API — the source for DEF 14A proxy statements, which describe each proposal in full and provide the raw text the model reasons over.
- An ISS Governance scraper — a TypeScript/Bun service using axios to pull governance data that isn't available in the bulk datasets.
The DMI CSVs are the heavy lift. They arrive as wide, multi-year exports, and we load them into PostgreSQL using the COPY command in chunks rather than row-by-row inserts, which keeps ingestion fast even for the larger tables. Everything lands in a Postgres instance running on AWS RDS, which serves as the single source of truth for the rest of the pipeline.
Giving the Model the Right Context
A language model can only reason well about a proposal if it also has the relevant voting guidelines in front of it. Those guidelines are long PDFs, far too large to paste into a prompt wholesale, and only a few passages of any given document are actually relevant to a specific proposal. This is where retrieval-augmented generation comes in.
We use the OpenAI Assistants API with its file_search tool, backed by vector stores built from the relevant documents — for example, a specific fund's proxy voting guidelines. When the model evaluates a proposal, it retrieves the passages of the guidelines that bear on that proposal and reasons over them directly, rather than relying on whatever it happened to memorize during training. That retrieval step is what makes the justifications trustworthy: the model is quoting policy, not improvising it.
Predicting the Vote
The prediction engine runs on OpenAI GPT-4o. For each proposal, the model reads the DEF 14A description and the retrieved guideline passages, then returns a structured result: a predicted vote, a justification explaining the reasoning, and a citation pointing back to the guideline text that drove the decision. The requirement to produce a citation is deliberate — it forces the model to ground its answer in a specific policy passage and gives an analyst a way to check the work.
Those results are written to PostgreSQL in a table named proxy_voting_predictions. The schema is built for evaluation as much as prediction: each row holds a predicted_vote alongside the actual_npx_vote — the real vote once it is disclosed in the fund's N-PX filing. Storing both side by side means the platform can measure how often its predictions match reality, proposal by proposal, fund by fund.
Scoring Guideline Compliance
Predicting a vote is one half of the product. The other is checking whether a vote — predicted or actual — is consistent with the firm's own stated voting guidelines. That is a narrower, more mechanical judgment than open-ended prediction, so it runs as a separate step on a smaller, cheaper model: GPT-4o-mini.
The evaluator poses the question as a straightforward yes/no compliance check: given this proposal, this vote, and these guidelines, does the vote comply? Splitting this off from the main prediction call keeps each model focused on the task it is best suited to and keeps costs down, since the compliance pass doesn't need the full reasoning horsepower of GPT-4o.
Surfacing It All in a Dashboard
Predictions and compliance scores are only useful if the people making governance decisions can actually see them. Because everything lands in PostgreSQL, we were able to put a Metabase dashboard directly on top of the database as the visualization layer. Analysts can browse predicted votes and their justifications, compare predictions against the actual N-PX votes as they come in, and drill into compliance results without touching SQL.
Keeping the whole stack anchored on a single Postgres instance is what made this straightforward. The prediction pipeline writes to it, the compliance evaluator writes to it, and the dashboard reads from it — no separate warehouse, no data movement between systems, no synchronization to keep straight.
Why This Architecture
The temptation with a problem like this is to reach for a bespoke machine-learning model — train a classifier on historical votes and predict the next one. We deliberately did not do that. Historical voting data is uneven across funds and proposal types, guidelines change every year, and a trained classifier gives you a prediction with no explanation attached. An analyst who is told "the model says Against" with no reasoning has no way to trust or challenge it.
Grounding every prediction in retrieved guideline text and requiring a citation flips that. The model's output is auditable by construction: every predicted vote comes with the policy passage it relied on and a justification an analyst can read and push back on. And because the actual N-PX votes flow into the same table, the system's accuracy is measurable rather than assumed — you can see exactly where predicted and actual diverge.
Wrapping Up
The interesting part of this project wasn't a novel algorithm — it was framing proxy-vote prediction as a document-reasoning task and building the plumbing to do it reliably: clean ingestion of DMI, EDGAR, and ISS data into Postgres; retrieval over the right guidelines; a GPT-4o call that has to cite its sources; a lightweight GPT-4o-mini compliance check; and a Metabase view that ties it all together for the people who need it.
If your team is working through dense regulatory documents and wishes it could predict and audit decisions at scale, we'd love to talk. We specialize in building end-to-end AI systems that turn unstructured filings into decisions you can stand behind.