How the platform is operated
Effective-dated rating, versions and release control
The hard part of running a rating platform is not calculating a premium. It is starting a program from something governed rather than from nothing, changing pricing without breaking what is already quoted, proving months later which version produced a number, and letting the people who own the pricing make the change themselves.
A rating run resolves the version in force for the policy’s effective date. There is no version to pin and no way to rate on one that was not in force.
Configuration is the product
Every commercial rating system draws a line between the part that is maintained for you and the part you control. Where that line sits determines how the system feels to operate.
In SelectRate the ISO and AAIS rating foundations sit underneath as a maintained base. The same model runs ISO and AAIS programs. Above it are two layers you own: the carrier configuration, which holds carrier-approved deviations from the base including loss cost multipliers by state, and the program configuration, which holds the pricing and rules specific to a particular program.
That is the point of the split. Business users manage rates, rules, eligibility, pricing and effective-dated changes without rebuilding the rating application. A change to a multiplier is an edit to a configured value with a date on it, not a request that joins a development queue.
Start from the standard
Before a first version exists there is still something to start from, and this is the part most rating platforms leave out. Every organization on SelectRate has a Standard Program for each governed product: one per product, not one per state, sitting directly on the published bureau foundation.
It is a real program. It rates. Its supported states come from the published content, so a newly released state appears on it without anyone doing anything. And for every value the filing leaves to the company, it states the requirement rather than filling it in: this state is ready to rate, that state needs a loss cost multiplier, this one needs the adoption date of a company dated edition. Nothing is guessed, and nothing is hidden behind a plausible default.
You inspect it, run Program Test on it, rate the sample transactions it carries, and then create your own program from it. Your program owns its own versions from that point on. The Standard Program itself is never edited, renamed or retired, by you or by us, which is what lets it stay a reliable reference for what the foundation alone produces.
The positioning is simple enough to put on one line. Start from the standard, and configure what makes your program different.
Bureau foundation, Standard Program, your program
| Layer | What it is | Who owns it |
|---|---|---|
| Governed bureau foundation | Published, effective dated ISO and AAIS content: schema, rating steps, tables, eligibility and lifecycle rules. | SelectRate |
| Standard Program | One governed program per product, on that foundation. States, readiness, the exact company value each state still needs, Program Test and sample transactions. | SelectRate, for you to use |
| Your carrier or MGA program | Created from the standard. Company values, adoption dates, rules, fees, eligibility and authorized deviations, on your own effective dated versions. | You |
Start from what is published, change what differs
Once a program exists, every field starts from its currently published values. You are not filling in an empty form, you are editing a live position.
Program default, then overrides. Set one multiplier for the whole program and override the single state that differs. The states you did not touch stay exactly as published. When you write thirty states and two of them are unusual, this is the difference between a five-minute change and an afternoon of copying numbers between rows.
The base moves without you. When a new bureau edition lands, it lands underneath your configuration. Your multipliers and rules carry forward, so there is nothing to re-code and nothing to re-enter. Testing the new edition against your own book stays part of a controlled release, as it should be.
What you can set. On ISO programs: loss cost multipliers by state, state overrides where one state differs, policy writing minimums, fees and program rules. On AAIS programs: company multipliers, minimum premiums, where inside each filed range the company rates, and the values a filing leaves to the company. The filed base itself is read-only.
Versions are dated, not overwritten
This is the mechanism everything else depends on, so it is worth being precise about.
A configuration version carries an effective date. Creating a change never disturbs what is live: the published configuration stays in force for policies dated before the new version's date. You can work on next quarter's pricing on a Wednesday afternoon without a single in-flight quote moving.
A published version goes live on its effective date, in Underwriter Workbench and on the Rating API at the same moment. There is no window where the two channels disagree, because they resolve the same configuration.
Prior versions do not go away. They stay live for prior dates, which is what makes a quote from three years ago re-rate on the version and edition it was actually written under.
You cannot pin a version. Effective date is the only temporal input the Rating API accepts, and no version identifiers are accepted anywhere in the public contract. That is a deliberate constraint rather than a missing feature. If a caller could choose a version, a premium would only be as defensible as the integration that requested it.
Fail closed
A rating system's behavior when it cannot produce a number matters more than its behavior when it can.
A program whose configuration is not effective for a quote's policy date returns no premium and says why. A date with no applicable edition fails closed with a correction. A risk the program is not configured for in that state returns no premium either. None of those returns a number.
That is the correct trade. A premium from the wrong version is worse than no premium, because no premium stops the process and the wrong premium does not.
A rating system that produces a number it cannot support is worse than one that says it cannot produce one.
Testing a change before it is published
A draft version is rateable before it is published, which is what makes testing meaningful.
Every change is tested in Program Studio before it can go forward: rate complete test risks against the draft version and against what is published, and read the worksheet behind each result. A version cannot be submitted for release until at least one test has rated, and the review step shows exactly what it changes against the published configuration, state by state. A published version takes effect on its effective date and never changes afterwards.
The worksheet is what turns that into a decision. Each value carries where it came from, whether that is a filed source, a carrier version or your own program version, so an underwriter who thinks a number is wrong can point at the step they think is wrong rather than at the total.
Nothing goes live because a release note said it was ready.
Edited without touching what is live.
The same engine that serves production traffic.
Effective from the date you set, not from the moment you saved.
Sample transactions
Testing a program you have just configured is straightforward. Understanding how a line behaves before you configure anything is the harder problem, and it is usually solved by someone inventing a test risk and hoping it is representative.
Each governed product carries ready to use sample transactions instead: known good scenarios with a stated expected behaviour, including the ones that deliberately refer rather than produce a premium. Open one, rate it against the Standard Program, change an input, rate it again. The same scenarios prefill Program Test, so the first test of your own draft is a real one.
It is a small thing that removes a real obstacle: an underwriter or an integration developer can see how a line behaves on day one, without waiting for a configured program.
The audit trail is generated, not assembled
Most systems can tell you what a premium was. Fewer can tell you why, and fewer still can do it after the people involved have moved on.
Every step is captured as the engine executes it, with the governing value and where that value came from used to calculate the premium. The worksheet is not written afterwards from a log; it is the rating.
Derived values carry provenance. A territory assignment records which filed mapping was selected, why it governed, and the document and page it came from.
Executions are immutable. The inputs, result and worksheet behind a result never change. Fetching an old rating run returns exactly what it returned the first time, including its worksheet.
Revisions are separate from runs. Changing the inputs increments the quote's revision. Rating the same inputs twice does not, which means you can rate the same risk twice and prove the result is reproducible rather than coincidental.
Judgment stays distinguishable. The engine's indicated premium and the final premium are reported separately on every result, so judgment applied on top of the rate is always distinguishable from the rate.
Policy transactions are recorded too. Endorsements, cancellations, reinstatements and renewals each add an entry to the policy's transaction ledger with its calculation, and accepted entries never change. A factor override on an endorsement or a cancellation requires a reason, and the transaction records who made it and when. Policy lifecycle rating
The whole premium is explainable because every value traces to the layer and the version that produced it, not because every value came from a filed page.
Who can change what
Role-based access runs across Program Studio, Underwriter Workbench and the Rating API. In Program Studio, a Program Admin configures, tests and submits versions; a viewer sees everything and changes nothing.
Before a version is submitted for release, the review step lists exactly what it changes against the published configuration, state by state, and proposed changes waiting for review are listed on the program overview. Published versions are immutable, and every quote, policy and worksheet records the version it was rated with, so historical results stay reproducible after later changes.
For the API specifically, the distinction worth understanding is that scopes gate verbs and grants gate programs. Holding the scope that permits rating does not entitle a client to any particular program. Entitlement is granted per program by the organization that owns it, there is no wildcard at request time, and a request naming a program the client has not been granted returns 403 without disclosing whether that program exists.
Downstream, each partner gets its own API client, granted the programs you choose. Every call carries a correlation id.
Common questions
What do we start from on a brand new program?
The Standard Program for that product. It sits on the published bureau foundation, tells you which states are ready to rate and which are waiting on a specific company value, and can be tested and rated before you configure anything. You create your own program from it, and your program owns its versions from then on.
Can we schedule a rate change for a future date?
Yes. A version is published with an effective date and goes live on that date in Workbench and on the API at once. Until then the currently published configuration remains in force.
What happens to quotes written before a change?
Nothing. They were rated on the version in force for their policy date, and they re-rate on that version.
Can a caller request a specific configuration version?
No, by design. Effective date resolves the version, and no version identifiers are accepted in the public API contract.
How do we test a change before it is live?
In Program Studio. Rate complete test risks against the draft version and against what is published, and read the worksheets. A version cannot be submitted for release until at least one test has rated.
Can a worksheet be produced for an old quote?
Yes. Executions are immutable and old runs stay retrievable with their worksheet intact.
Change a rate on the call.
The clearest way to see this is to configure a real change and test it against a real submission, in one sitting.