AI can now write pricing logic faster than anyone can check it. That flips the problem. The question is no longer how quickly a model can be written, but how quickly a person can be sure it's right. Which makes the format of the model a governance choice, not just an engineering one.
Code or configuration
There are broadly two ways an AI can produce a rater.
It can write code. A general-purpose language gives it total freedom, and it will produce something fast. What you get back is a program: branches, helper functions, special cases. Checking it needs an engineer, and checking it against the rating guide needs an engineer who also understands rating guides.
It can write configuration. Here the AI fills in a constrained, declarative structure: typed inputs with descriptions, rate tables as rows, formulas, and underwriting rules with names. It can do less. That is the point. What it does do, anyone in the pricing team can follow.
What readable looks like
Take the pet insurance model on our developer pages. It has:
- Inputs with labels and plain descriptions, so
vet_fee_limitshows up as "Annual vet-fee limit", explained as the most the policy pays for vet treatment each policy year. - Rate tables kept as tables. The region factors are seven rows, Greater London at 1.30 down to Northern Ireland at 0.85, which you can hold against the rating guide line by line.
- Formulas written out. The risk premium is
round({{base_premium}} * {{pet_age_factor}} * {{breed_factor}} * {{region_factor}} * {{excess_factor}} * {{neuter_factor}}, 2), and tax is 12% on top. - Rules with names. "Pet older than 14 at inception" declines. "7,000 limit on a high-risk breed" refers.
- Tests saved with the version, each one a set of inputs and the price or decision it should produce.
An underwriter can review that without reading code. An auditor can follow it. And an AI agent can read and edit it accurately, because the structure tells it where everything is.
Constraints help the AI too
It is tempting to think a more flexible format makes an AI more capable. For pricing, the opposite tends to hold. A constrained format gives an agent:
- A schema to check against. Every Swallow model follows one JSON Schema, and the server validates against it, so structural mistakes surface straight away rather than at quote time.
- A short list of step types. Collection lookups, calculations, exclusions, refers, excesses and endorsements line up with how rating guides are already written.
- Precise targets. "Change the London factor" means one cell in one table, not a function rewrite.
- Fast feedback. The suite can run after every edit.
Every version is a file you can compare
Because a declarative model is data, each version can be stored, compared and reproduced. "What changed between the last two versions?" becomes a comparison of two files, and Swallow's Review area shows which steps were added, removed or amended. Add a per-quote debug trace, which lists every lookup and formula with the values it used, and you can show how any price was produced on any date.
When the format isn't enough
Some products need something a declarative step can't express: a call to an outside data source, or an unusual aggregation. Swallow handles this with dedicated external and code steps. The code step runs sandboxed JavaScript and is kept for when it's genuinely needed. If most of a model reads like a rating guide and one small, well-tested step doesn't, reviewers know exactly where to spend their attention.
This matters more as AI enters regulated decisions. We look at the wider picture in AI in regulated industries: explainability.
In short
Writing pricing logic is no longer the slow part. Reviewing it is. A format that people can read and that AI can edit precisely keeps both the speed and the confidence. Every Swallow model is built this way, and you can see a complete one on our model building page.
