In early 2025, we ran an early access program with a small cohort of non-life carriers who agreed to use HyperCal for their live quarterly close processes over a six-month period. The purpose was to test whether the platform we had built actually addressed the workflow and documentation problems we had identified during our initial research, and to learn from the gaps where it did not. This post is a summary of what we found: what worked, what required adjustment, and where our initial assumptions about the problem were simply wrong.
Writing this publicly is slightly uncomfortable, because it involves admitting that our understanding of the problem when we started the program was incomplete. We think the discomfort is worth it. The actuarial community is small, and teams considering infrastructure investments benefit from honest accounts of what actually changes in practice versus what vendor descriptions suggest will change. We would rather write that clearly than let the standard "customers saw significant improvements" framing stand without specifics.
What We Set Out to Learn
Our hypotheses going into the early access program were based on qualitative research: conversations with actuarial teams about their quarterly close processes, walkthrough sessions where teams described their actual sequence of events for recent closes, and review of reserve opinion memoranda from several carriers. From that research, we had identified three primary friction points: data assembly before the model can run, sequential review under time pressure, and documentation assembly at the end of the close window.
We built HyperCal to address these three friction points with a shared data layer that automates the triangle construction and reconciliation step, a concurrent review interface that allows reviewers to track calculation progress in real time, and a documentation framework that captures assumption rationale at the time of selection rather than after the fact. The early access program was the first test of whether these architectural choices actually solved the problems they were designed to address.
What the Data Assembly Results Showed
The data assembly hypothesis held up more strongly than we expected. Carriers that implemented the direct integration between their claims administration system and HyperCal's triangle construction module reduced the time from "close window opens" to "model ready to run" by roughly two to three days in their first close cycle using the platform, relative to their prior manual data assembly process. This improvement was consistent across the early access cohort.
What we had not anticipated was the secondary effect on data quality confidence. In the prior spreadsheet-based process, actuaries routinely spent time during data assembly questioning whether the data was correct before running the model. Was this number the right payment category? Did this extract include the right accident year cut-off? The automated integration, because it applied a fixed and documented extraction logic, resolved this uncertainty by making the extraction methodology transparent. Actuaries reported that they spent less time second-guessing the data and more time analyzing the output, which is where their expertise is actually needed.
We had not built a feature specifically to address data quality confidence; it was a side effect of the transparency that the automated integration provided. This turned out to be one of the more valuable outcomes of the program, and we have since built explicit documentation for the extraction logic into the standard onboarding process.
Where the Concurrent Review Hypothesis Was Partially Wrong
The concurrent review interface was the feature we were most uncertain about before the early access program, and the area where the results were most nuanced. Our hypothesis was that reviewers who could monitor calculation progress in real time, rather than waiting for a completed output to arrive in their inbox, would begin their review earlier and compress the overall review timeline.
In practice, the concurrent access did not change the review behavior of CFOs and finance directors in the cohort, who continued to review only completed outputs. The change in behavior was limited to the senior actuarial reviewers, who did use the real-time access to begin reviewing development pattern selections while the calculation was still running, and who reported that this allowed them to flag methodology questions earlier in the process rather than after the final figures were compiled.
This is a real improvement, but it is more modest than we had projected. The review chain still runs mostly sequentially because the non-actuarial reviewers at the end of the chain are not equipped to engage with intermediate outputs. We adjusted our messaging to describe this feature accurately rather than implying it would compress the entire review chain, and we are exploring what information format would allow earlier engagement from finance and management reviewers without requiring them to interpret actuarial outputs they are not trained to evaluate.
Documentation Results: The Most Significant Change, and the Hardest to Implement
The documentation framework produced the most significant outcome of the early access program, and also the most significant implementation friction. The structured assumption capture, which prompts the actuary to document the basis for each development factor selection and the alternatives considered at the time of selection, resulted in reserve opinion memoranda that were qualitatively different from what the early access cohort had been producing previously. Two carriers in the cohort specifically noted that their reserve memos were more complete and their documentation of assumption rationale was more thorough than anything they had produced under the prior process.
The implementation friction was substantial. Actuaries accustomed to selecting development factors from a weighted average calculation and moving on found the structured documentation prompt to be an interruption to their workflow. "I know why I'm selecting this factor; I shouldn't have to write it down every time" was a representative comment. This resistance is understandable. The documentation discipline feels like overhead when you are the actuary who made the selection and you have the rationale available in your head. The overhead is visible immediately; the benefit, which accrues when someone else needs to understand the rationale later, is not visible at the time of selection.
We spent a significant portion of the early access period on this adoption challenge. The approach that worked best was not making the documentation mandatory through a system gate, but rather making it visible: showing each actuary what their documentation looked like six weeks after the close, when the details had faded, and asking them whether the written record was sufficient to answer the questions they themselves had at that point. In most cases, the answer was no, which created the motivation for more thorough contemporaneous documentation without us having to mandate it through the system architecture.
What We Were Wrong About: The Role of Familiarity in the Close Process
The assumption that was most significantly wrong going into the early access program was about the relationship between the close process and the actuarial team's familiarity with their own book. We had assumed that the primary barrier to a more efficient close was infrastructure: better tools would compress the process by eliminating the manual steps. What we discovered is that a substantial portion of the close cycle's elapsed time is not manual overhead but is the time that experienced actuaries spend reading and interpreting their specific book's patterns, because that reading requires their institutional knowledge and cannot be automated.
An experienced actuary looking at this quarter's development triangle for their casualty auto book knows whether this quarter's pattern is unusual relative to the prior eight quarters of patterns they have looked at for the same book. That contextual interpretation is part of what the quarterly close is for. Automating the data assembly and the calculation steps does not eliminate this interpretation time; it makes more of the close window available for it.
This is the correct outcome, but it required a shift in how we described HyperCal's value proposition. The initial framing emphasized cycle time compression. The more accurate framing, which we landed on during the early access program, is that HyperCal compresses the infrastructure overhead so that the available close window is more fully occupied by the analysis that requires actuarial judgment, rather than by data preparation and documentation assembly that does not.
Current State and What Comes Next
Based on the early access program results, we made three significant changes to the platform before opening broader access. First, we redesigned the data integration layer to support more source system formats, because we had underestimated the variation in data structures across the claims administration systems used by the carriers in the cohort. Second, we revised the documentation framework to reduce the friction in assumption capture while maintaining the completeness that made the memoranda more useful. Third, we built a close retrospective view that shows the actuary how their current-quarter documentation compares to prior quarters, specifically to address the adoption challenge around contemporaneous documentation.
Park Ji-hwan built the technical infrastructure for all three changes over the course of Q1 and Q2 2026, alongside the ongoing development of the calculation engine. Yoon Seo-jin led the actuarial methodology review that informed the revised documentation framework. The early access carriers contributed to the design of both changes through working sessions where we reviewed their actual close workflows and identified specific gaps between what the platform was producing and what their processes required.
We are opening the platform to a broader set of carriers from Q3 2026 with the benefit of this testing. If you are an actuarial team at a non-life carrier and the friction patterns described in this post resemble your experience, we are interested in talking. Not to sell you on a comprehensive transformation of your actuarial function, but to understand whether the specific problems we have solved in the platform match the specific problems your team is dealing with. That alignment is what determines whether the platform is actually useful for your situation, and we have learned that the only way to assess it accurately is through direct conversation.
