"Highly Configurable" Means Little: A Six-Level Scale for a Term Every Vendor Claims

Second part of a series of articles that tries to cut through the fluff in insurance core system marketing and to align terms for core system buyers.

In this 4-part series

1. Cloud-Native — Read here

2. Configurability — Current article

3. API Counts — Coming soon

4. Microservices — Coming soon

"Configurable" is one of the most used (or overused?) word in insurance core system sales. Every vendor claims their system is "highly configurable" (we are guilty of it as well). And almost every vendor is, in some narrow sense, telling the truth. That is what makes the claim worthless and shifts the verification to the buyer. 

The claim only becomes meaningful when you ask four questions. What can be configured? Who configures it? What is the configuration experience? And how do changes take effect? 

Ask those four questions of five core system vendors and you may get answers so different they barely describe the same concept. 

The configurability spectrum from L1 to L6 

Before the SAE J3016 standard gave the world the now-familiar levels of driving automation, the car market was flooded with proprietary terms: ProPilot, Pilot Assist, DrivePilot, AutoPilot. Each implied more autonomy than it delivered. The fix was the shared SAE J3016 scale from level 0 (no driving automation) to level 5 (full driving automation). 

Insurance core systems have no equivalent standard for configurability. So, we defined our own six-level framework to calibrate any system, including our own Graphene platform. 

Below the scale sits plain code (L0): changes that require engineers and a full software development lifecycle. That is customisation, not configuration.

From there we proceed through six L1 to L6:

Three subtleties matter as much as the table itself: 

• First, no system sits at one level. A core system spans multiple levels: one configuration can be at L2, another at L5. Don’t accept a single label for a whole platform. Ask for the level per type of change you care about: a complete new product or workflow, a rate or rule revision, a PDF document or notification template. 

• Second, the jump from L1 to L2 is not about file formats. Both may use XML or JSON. The difference is whether a change still travels through the CI/CD pipeline or can be loaded into the running system.  

• Third, L5 is not a prettier L4. A form that mirrors the database is still a form; the user must think in the vendor's underlying technical data structure. A business-oriented tool lets them think in products, benefits and rules. The gap between the two, in experience, maintainability and who can safely operate it, is enormous.  

To be fair to the older generation of core system: raw configurability is not the whole story. Some venerable platforms offer huge changeable scope through proprietary code (e.g., Guidewire with Gosu), and for certain tier-1 insurers that trade-off may be rational. Configurability without the scope is a nice-to-have toy; but scope without configurability means very long implementation lifecycles and bills. 

What to probe as a buyer 

Don't ask whether the system is configurable. Ask, for each change that matters to your business: which level is it at? Then verify the claim. Have the vendor make the live change in the demo and watch who does it, in what tool, how it takes effect and how it gets promoted across environments. The distance between the sales answer and the demo answer is usually the most informative data point in the whole evaluation. 

Why this matters in the agentic AI era 

L6 is not science fiction; it is where the spectrum is pointing and what we have already built at Peak3 (but not yet fully scaled as of mid-2026). Business users will upload unstructured product specifications or describe a product change in natural language, and agents will draft, visualise and validate the configuration. These are the agents that change the business at design time (see also: The Three Levels of an AI-Native Insurance Core).  

The catch is that an AI agent can only configure what exists as structured, exposed configuration. Logic trapped in code or tightly coupled with application UIs gives an agent nothing to work with. The position on this spectrum today largely determines your agentic readiness tomorrow.  

Moving up a level was always about speed-to-market and business empowerment. Now it also decides whether AI can work for you at all.