The version control problem in software engineering was considered solved by the early 2000s. Git became the standard by roughly 2010. Every software engineer working today treats it as baseline infrastructure, as unremarkable as the ability to name files. You want to know what the codebase looked like three months ago, you check out that commit. You want to know who changed a specific function and why, you read the commit history. The question "what version ran in production last Friday" has an answer that takes five seconds to retrieve.
Actuarial pricing teams are answering the same question by searching their email inbox for a forwarded workbook. The pricing model that filed rates in Q3 exists somewhere. It might be in a shared drive folder named "Pricing Q3 FINAL" or in a zip archive attached to a close-out email or on the laptop of the actuary who ran it. Whether it is the same file that actually generated the filed rates, or a subsequent version that was opened and saved after the filing, is not knowable without additional investigation.
This is not a corner case. It is the normal operating condition for actuarial pricing in organizations that have not invested in dedicated modeling infrastructure.
Why Pricing Model Version Control Is Harder Than Software
Software version control works cleanly because code is text. Text diffs are human-readable, comparisons are exact, and the content can be meaningfully compared line by line. Spreadsheet models are not text. The version-relevant content of a pricing workbook includes formula logic, cell references, named ranges, parameter values, external links, and the embedded data assumptions that drive the output. Diffing two versions of a pricing workbook to understand what changed between them requires opening both, looking through all of this manually, and making judgment calls about which differences are intentional changes versus which are incidental modifications from a save operation.
This difficulty explains why most actuarial teams do not attempt systematic version comparison between quarterly pricing model runs. The effort required is too high relative to the apparent benefit in any given quarter. The cost of this decision accumulates invisibly until a question is asked that requires looking backward: a rate filing is challenged, a profitability analysis produces results inconsistent with expected pricing, or an external audit asks for the methodology documentation for a prior period.
We are not saying that all pricing teams should learn to use git on workbooks. That is technically possible with tools like Excel file diffing utilities, but the friction is high and the adoption rate among actuarial teams is close to zero. The more tractable approach is a modeling system that manages version control internally, stores a complete record of each model run as a structured artifact, and exposes the version history through an interface designed for actuarial rather than software engineering workflows.
What Needs to Be Versioned
The minimum set of versioned artifacts for a pricing model run includes: the model specification (which rating variables, which relativities, which credibility methodology, which base rates), the input data (loss triangles, premium data, rate change indices, credibility weights), the assumption set (trend factors, development factors, expense ratios), and the output (the rate level indication, by segment and in aggregate). Each of these should be stored as an immutable record associated with a specific run, identified by timestamp, user, and a description of the purpose of the run.
Beyond the minimum, the version record becomes significantly more useful if it also captures the comparison to the prior run: what changed in the model specification, what changed in the data inputs, and by how much the output changed. This comparison view is what transforms a version archive into a working tool rather than a compliance archive. When the Q3 rate indication is 5 percentage points higher than the Q2 indication, the version comparison immediately surfaces whether the change came from updated trend factors, from new development data in the loss triangle, or from a methodology change in the credibility calculation. Without this comparison, the actuary must reconstruct the attribution manually, which takes time and is subject to error.
The Rate Filing and Regulatory Review Connection
Rate filings submitted to insurance regulators typically require documentation of the actuarial methodology underlying the filed rates. The filing documentation references specific factors, trend selections, and development patterns. When a state insurance department examines the filing, they may ask the carrier to demonstrate that the filed rates were produced using the methodology described in the filing documentation.
If the pricing model that produced the filed rates exists as a well-identified, immutable artifact with a complete record of the inputs, assumptions, and methodology in force at the time, demonstrating this alignment is straightforward. If the model is a quarterly workbook that has been opened and modified since the filing date, with the filing-period version maintained only in a shared drive archive of uncertain provenance, the demonstration requires reconstruction and the regulator has a legitimate basis for skepticism about the claim that the archived version matches what was actually filed.
This is not a theoretical concern. Rate filing examinations regularly surface discrepancies between documented methodology and the actual model, and the discrepancies usually arise from the version control gap described here rather than from intentional misrepresentation. The difference in the regulatory interaction between "here is the exact model artifact that generated the filed rates, accessible in thirty seconds" and "here is what we believe to be the relevant workbook, we will need to verify this" is substantial in both duration and tone.
Branching: When You Need to Test a Methodology Change
One of the most practically useful features of proper version control in pricing is the ability to run alternative model specifications against the same data set without overwriting the production model. In software engineering terms, this is branching: making a copy of the current state, modifying it, testing the results, and then deciding whether to merge the changes back into the main model or discard them.
Actuarial pricing teams need this capability constantly. Before adopting a new trend methodology, you want to run the new methodology against historical data to see how it would have affected the indicated rates compared to the current approach. Before changing the credibility blending formula, you want to compare the outputs of the new formula to the current formula across a range of exposure sizes to validate that the change behaves as expected. These analyses require running the alternative version alongside the production version with identical input data, which is essentially branching.
In a spreadsheet workflow, this typically means creating a copy of the workbook, modifying the copy, running both, and then manually comparing the outputs. The copy must be carefully maintained as a distinct artifact, the comparison must be done manually, and the decision to adopt or discard the change must be documented separately. A system that handles branching natively keeps the analysis structured and the decision trail automatic. The production model is not touched until the analysis is complete and the change is explicitly adopted, at which point the new version becomes production with the comparison analysis captured as part of the version record.
The Case for Treating Pricing Models as Software
The actuarial profession's relationship with version control reflects a historical divide between two domains that have operated with different tooling conventions. Software engineering built its workflows around the assumption that the artifact being managed is code, which is text, which is naturally versioned with text-based tools. Actuarial practice built its workflows around spreadsheets, which are not text, and for which the software engineering toolchain is an awkward fit at best.
The resolution is not to force actuaries into software engineering workflows. It is to build infrastructure that provides version control semantics, an immutable run history, comparison views, and branching support through an interface that fits the way actuarial pricing work is actually done. The underlying technical mechanisms are not fundamentally different from what software version control provides. The user interface and the artifact model need to be calibrated to actuarial rather than programming workflows.
This is what we built for pricing models in HyperCal. Every model run is a stored artifact. Every assumption change is logged with a timestamp and attributed to the user who made it. The comparison between any two runs is generated automatically. The history of the production model is accessible without inbox search or drive archaeology. The question "what version ran for the Q3 filing" has an answer that takes thirty seconds to retrieve rather than thirty minutes.
