A 10-K goes in. Nine agents argue over what it means. A Monte Carlo engine simulates 10,001 versions of the future. A storyteller turns the numbers into a thesis. A CIO signs off, or sends it back for another pass.
Out comes a full investment report.
That sentence is, in compressed form, what I have been building for the last several weeks. With Pillar 3 now in place, the valuation architecture is finished. Three stages, one system, filings to thesis.
This piece is a walk through what each stage does, what each stage explicitly does not do, and where the project goes from here.
The principle: agents author judgment, code does math
Before describing the stages, the design principle that runs through all three.
Anywhere a number can be calculated from data, no agent gets to touch it. Anywhere a structured opinion is needed about what a 10-K actually means, no piece of code gets to invent it. The line between the two is hard-coded into the system. Calibrated volatilities, working capital days, cost of debt, beta, all computed. Drift priors, FX exposures, peer selection, capital structure thresholds, all proposed by agents and adjudicated by other agents.
This is the discipline that makes the rest of the architecture defensible. When something goes wrong, you can always tell whether the failure was a model error or a judgment error, and which agent or which line of code is responsible.
Stage 1: Onboarding
Onboarding runs once per ticker. Its job is to read the 10-K, peer filings, and any prior configuration, and emit a single structured file called segments.json. Everything downstream depends on it.
Four phases run in sequence. Phase 0 fetches the raw filings. Phase 1 is a data-quality loop with retry logic, since SEC filings are not always well-formed. Phase 2 splits into two parallel tracks: a Ticker Analyst reads the company’s own filing in depth, while a Peer Analyst runs the same exercise across comparable filers in a red-team configuration. Phase 3 is the Reviewer layer, where each track’s output is challenged by an independent agent. Phase 4 is the Manager, who weighs the two tracks, adjudicates contested fields, and writes the final configuration.
Every numerical assumption proposed by an agent must be backed by a filing citation. No citation, no override. The Manager’s reasoning is logged for every field where the two tracks disagreed.
The output, segments.json, is the contract that bridges Stage 1 and Stage 2. Once written, it stays. Subsequent valuation runs read from it without re-invoking the agent pipeline, which keeps both cost and reproducibility under control.
Stage 2: Valuation
Stage 2 is fully deterministic. Same inputs, same outputs, every time. No agents, no improvisation, just math.
The engine reads ten years of SEC filings via EDGAR, market data via yfinance, and the configuration written in Stage 1. It builds a financial-analysis report covering twenty-eight ratios, parses the segment structure, computes the cost of capital using a Hamada-relevered CAPM, and calibrates the stochastic processes that drive the forecast.
Two valuation paths run in parallel. A seven-year discounted cash flow on free cash flow to the firm, used as a single-path sanity check. And a 10,001-path Monte Carlo simulation built on Geometric Brownian Motion for revenue dynamics and an Ornstein-Uhlenbeck process for cost ratio mean reversion. The Monte Carlo is the primary output. The DCF is the discipline that catches simulation pathologies before they propagate.
Stress scenarios and tornado sensitivity sit on top. Four predefined stress paths, including a severe recession, a margin compression, an FX shock, and a working-capital squeeze. The tornado isolates the three assumptions to which the valuation is most sensitive, which is often more useful than the central estimate itself.
Outputs include the DCF per share, the Monte Carlo median, the 25th and 75th percentile range, the four stress scenarios, the top three tornado drivers, an Excel workbook with thirty-three sheets, and a full stdout log. The Excel is the audit trail. Every number in the final report can be traced back to a cell.
Stage 3: Investment Report
This is the newest layer. Where Stage 1 builds the configuration and Stage 2 runs the math, Stage 3 turns the output into a narrative that an investor can actually read.
The pipeline runs four phases. Phase 1A and 1B are twin Analysts drafting in parallel, independently, from the same Excel and segment data. Parallel drafting was a deliberate choice. Two analysts working from the same numbers will reach overlapping but not identical conclusions, and the differences are usually where the interesting insight lives.
Phase 2 is a Reviewer who consolidates the two drafts, resolves disagreements, and produces a single structured content file called report_content.md. Phase 3 is the Storyteller, an agent whose job is purely narrative: take the consolidated content and turn it into prose that flows. Phase 4 is the CIO. The CIO either approves, or sends the narrative back to the Storyteller for revision, with a maximum of three cycles before forced approval.
The CIO’s veto is the most important agent in the pipeline. It is the only one designed to say no.
Once approved, a deterministic builder assembles the final report into three formats: a Word document of roughly twenty-eight pages, a PowerPoint deck of twenty slides, and the underlying Markdown source. A trace file logs every agent’s input, output, and reasoning, in case the report ever needs to be audited.
What it does not do
Three honest limitations are worth naming.
Peer ticker hallucination is real. The Peer Analyst occasionally proposes comparables that look right semantically but do not actually trade in the same market structure. The Reviewer catches most of these, but not all.
The Reviewer can be over-cautious. When management is genuinely right about a forward outlook that breaks from history, the Reviewer’s instinct is to pull the prior back toward the historical CAGR, which is the wrong move in those cases.
The self-healing XBRL loop has not been stress-tested on a genuinely broken filer. Most US large-caps file clean XBRL. The system has not yet seen a small-cap with a chaotic filing history.
These are known issues. They go on the next quarter’s roadmap.
What comes next
Two things, in order.
First, two full valuation reports go out this week as worked examples. Real companies, real filings, the entire methodology stack applied. The output of the system, not a description of it. They will land on this Substack and on LinkedIn.
Then, the next build. A valuation model is only as useful as the questions you point it at. The architecture as it stands today answers “what is this worth?” with rigor. It does not yet answer “which companies should we even be asking about?”
That is the screener. A tool that scans the market, applies a coarse filter on financial health, valuation gap, and earnings quality, and surfaces the candidates worth feeding into the pipeline. Valuation tells you the answer. The screener tells you which questions to ask. Together they close the loop from universe to investment decision.
Which would you like to see first? The two worked examples, or the screener architecture? And while you wait, drop a ticker in the comments. The most requested names will be the next ones the system runs.The third pillar is in place, the architecture is finished, and the question shifts from how to build it to where to point it.
A 10-K goes in. Nine agents argue over what it means. A Monte Carlo engine simulates 10,001 versions of the future. A storyteller turns the numbers into a thesis. A CIO signs off, or sends it back for another pass.
Out comes a full investment report.
That sentence is, in compressed form, what I have been building for the last several weeks. With Pillar 3 now in place, the valuation architecture is finished. Three stages, one system, filings to thesis.
This piece is a walk through what each stage does, what each stage explicitly does not do, and where the project goes from here.
The principle: agents author judgment, code does math
Before describing the stages, the design principle that runs through all three.
Anywhere a number can be calculated from data, no agent gets to touch it. Anywhere a structured opinion is needed about what a 10-K actually means, no piece of code gets to invent it. The line between the two is hard-coded into the system. Calibrated volatilities, working capital days, cost of debt, beta, all computed. Drift priors, FX exposures, peer selection, capital structure thresholds, all proposed by agents and adjudicated by other agents.
This is the discipline that makes the rest of the architecture defensible. When something goes wrong, you can always tell whether the failure was a model error or a judgment error, and which agent or which line of code is responsible.
Stage 1: Onboarding
Onboarding runs once per ticker. Its job is to read the 10-K, peer filings, and any prior configuration, and emit a single structured file called segments.json. Everything downstream depends on it.
Four phases run in sequence. Phase 0 fetches the raw filings. Phase 1 is a data-quality loop with retry logic, since SEC filings are not always well-formed. Phase 2 splits into two parallel tracks: a Ticker Analyst reads the company’s own filing in depth, while a Peer Analyst runs the same exercise across comparable filers in a red-team configuration. Phase 3 is the Reviewer layer, where each track’s output is challenged by an independent agent. Phase 4 is the Manager, who weighs the two tracks, adjudicates contested fields, and writes the final configuration.
Every numerical assumption proposed by an agent must be backed by a filing citation. No citation, no override. The Manager’s reasoning is logged for every field where the two tracks disagreed.
The output, segments.json, is the contract that bridges Stage 1 and Stage 2. Once written, it stays. Subsequent valuation runs read from it without re-invoking the agent pipeline, which keeps both cost and reproducibility under control.
Stage 2: Valuation
Stage 2 is fully deterministic. Same inputs, same outputs, every time. No agents, no improvisation, just math.
The engine reads ten years of SEC filings via EDGAR, market data via yfinance, and the configuration written in Stage 1. It builds a financial-analysis report covering twenty-eight ratios, parses the segment structure, computes the cost of capital using a Hamada-relevered CAPM, and calibrates the stochastic processes that drive the forecast.
Two valuation paths run in parallel. A seven-year discounted cash flow on free cash flow to the firm, used as a single-path sanity check. And a 10,001-path Monte Carlo simulation built on Geometric Brownian Motion for revenue dynamics and an Ornstein-Uhlenbeck process for cost ratio mean reversion. The Monte Carlo is the primary output. The DCF is the discipline that catches simulation pathologies before they propagate.
Stress scenarios and tornado sensitivity sit on top. Four predefined stress paths, including a severe recession, a margin compression, an FX shock, and a working-capital squeeze. The tornado isolates the three assumptions to which the valuation is most sensitive, which is often more useful than the central estimate itself.
Outputs include the DCF per share, the Monte Carlo median, the 25th and 75th percentile range, the four stress scenarios, the top three tornado drivers, an Excel workbook with thirty-three sheets, and a full stdout log. The Excel is the audit trail. Every number in the final report can be traced back to a cell.
Stage 3: Investment Report
This is the newest layer. Where Stage 1 builds the configuration and Stage 2 runs the math, Stage 3 turns the output into a narrative that an investor can actually read.
The pipeline runs four phases. Phase 1A and 1B are twin Analysts drafting in parallel, independently, from the same Excel and segment data. Parallel drafting was a deliberate choice. Two analysts working from the same numbers will reach overlapping but not identical conclusions, and the differences are usually where the interesting insight lives.
Phase 2 is a Reviewer who consolidates the two drafts, resolves disagreements, and produces a single structured content file called report_content.md. Phase 3 is the Storyteller, an agent whose job is purely narrative: take the consolidated content and turn it into prose that flows. Phase 4 is the CIO. The CIO either approves, or sends the narrative back to the Storyteller for revision, with a maximum of three cycles before forced approval.
The CIO’s veto is the most important agent in the pipeline. It is the only one designed to say no.
Once approved, a deterministic builder assembles the final report into three formats: a Word document of roughly twenty-eight pages, a PowerPoint deck of twenty slides, and the underlying Markdown source. A trace file logs every agent’s input, output, and reasoning, in case the report ever needs to be audited.
What it does not do
Three honest limitations are worth naming.
Peer ticker hallucination is real. The Peer Analyst occasionally proposes comparables that look right semantically but do not actually trade in the same market structure. The Reviewer catches most of these, but not all.
The Reviewer can be over-cautious. When management is genuinely right about a forward outlook that breaks from history, the Reviewer’s instinct is to pull the prior back toward the historical CAGR, which is the wrong move in those cases.
The self-healing XBRL loop has not been stress-tested on a genuinely broken filer. Most US large-caps file clean XBRL. The system has not yet seen a small-cap with a chaotic filing history.
These are known issues. They go on the next quarter’s roadmap.
What comes next
Two things, in order.
First, two full valuation reports go out this week as worked examples. Real companies, real filings, the entire methodology stack applied. The output of the system, not a description of it. They will land on this Substack and on LinkedIn.
Then, the next build. A valuation model is only as useful as the questions you point it at. The architecture as it stands today answers “what is this worth?” with rigor. It does not yet answer “which companies should we even be asking about?”
That is the screener. A tool that scans the market, applies a coarse filter on financial health, valuation gap, and earnings quality, and surfaces the candidates worth feeding into the pipeline. Valuation tells you the answer. The screener tells you which questions to ask. Together they close the loop from universe to investment decision.
Drop a ticker in the comments. The most requested names will be the next ones the system runs.
