The business wants to change a rating factor next Monday. Walk me through what actually has to happen.

It is not a configuration change

The instinct from ordinary product engineering is that a factor is a number in a table, so changing it is an update statement. In personal lines in much of the world it is not: the rating algorithm and its tables are filed with a regulator, and in the United States that filing goes to each state's insurance department separately.

Three consequences follow immediately, and a candidate who names them has understood the domain rather than the system.

The change is per jurisdiction. "The rating algorithm" is really fifty algorithms sharing a skeleton, each with its own approved values and its own effective date, and a change may be approved in some states and pending in others.

It has an effective date that is not the deployment date. The new rate applies to business written on or after a date the regulator agreed. Deploying the code on Monday does not make the rate live on Monday, and deploying it late does not move the date.

It applies to new and renewing business from that date, not to policies already in force. An existing annual policy keeps its price until renewal, at which point it is re-rated with whatever is filed and effective then.

Effective dating is the design

Because of the above, rates are never overwritten. Every table is a set of versions with validity periods, and a quote selects the version that was effective for its own dates.

rate_table: motor_liability_base, state IL
version  effective_from  effective_to  filing_ref     status
   14    2025-04-01      2026-08-01    IL-2025-0412   superseded
   15    2026-08-01      null          IL-2026-0778   approved

The selection rule is the part to get right and the part interviews probe. The version is chosen by the policy's effective date, not by today's date and not by the quote's creation date. A quote issued in July for a policy incepting in September is priced on version 15, because that is what will be in force when cover attaches. Selecting on now() is the single most common implementation bug here, and it produces quotes that silently reprice depending on when someone opened them.

In-flight quotes are the awkward case

A quote is an offer with a validity period, commonly thirty days. So on the day a rate changes there is a population of outstanding quotes priced on the old version, and somebody has to decide what happens to them.

The usual answer is that a quote is honoured at the price quoted for its stated validity period, because withdrawing a price a customer was given is both a conduct problem and a commercial one. That means the quote must have stored the version it used, not merely the number it produced, so that binding it later reproduces the same calculation rather than re-running against current tables.

The alternative — re-rate on bind and show the customer a different number than they were quoted — is a decision some carriers make deliberately for long-dated quotes, and it has to be disclosed. Either way it is a product decision the system must be able to express, not a default that falls out of how the code happens to work.

Reproducibility is the requirement that shapes everything

A market conduct examination samples policies and asks the carrier to demonstrate that each was priced with the filed algorithm. Answering that means reconstructing a calculation from years ago, exactly.

So the record against a quote is not the premium. It is the inputs, the version of each table used, the filing reference, the order of operations, the rounding applied at each step, and the resulting figure. Recomputing from today's tables is not evidence of anything, because the tables have moved.

This is also why the sequence of a rating calculation is a specification rather than an implementation detail. Changing the order in which a discount and a term factor are applied changes the last penny, and across a book that is both a real number and a deviation from what was filed.

Testing is a replay, not a unit test

The regression technique that fits this problem is unlike normal software testing: keep a corpus of historical quotes with their known outputs, and re-run every one against each build.

The failure it catches is specific and common. Rating tables share components — a territory table used by three products, a rounding helper used by all of them — so a change aimed at one product moves the price of another. Nobody notices until a filing audit or a customer complaint, because nothing errors. A corpus replay turns that into a failing build.

The corpus has to be per jurisdiction and per version, and it grows rather than being replaced, because the purpose is to prove that old calculations still reproduce.

Rollback is not a redeploy

Ask what happens when the change is wrong and has been live for a day. Reverting the code does not undo the quotes issued and the policies bound at the wrong price, and those are contracts.

The realistic handling is that the versioned data makes the exposure computable — every policy priced on version 15 is identifiable — and the remediation is a business decision: honour, re-rate at renewal, or refund the difference, usually with the regulator informed. What the engineering must provide is the list, quickly and defensibly.

Worth naming the one part that genuinely is a deploy: elements of the pipeline that are not filed, such as which quotes go to a referral queue or how a broker portal displays a price, can change on a normal release cadence. Knowing which side of that line a given change falls on is what lets a team move quickly on the things that permit it.

Deploying the code and making the rate effective are two different dates, and the system's real obligation is to reproduce, years later, exactly which version priced a given policy.