Product Configurator — the product

Today the configurator is a Claude Code workspace: a human opens a directory, a model reads the specification, and the deliverable is a set of files that somebody else executes. It works, and the reason it works is worth keeping — one canonical model, every emitted artefact a projection of it, and four refusals that stop the model from inventing facts or touching a database.

What changes is everything around that core: who runs it, how the input arrives, where the output lands, and what happens when the answer is nearly right. What does not change is the core itself. The model is still written first and everything else is still a projection of it. A correction edits the model and re-projects; it never edits emitted SQL.

The workspace was built against a customer who runs both IPAL and ABACUS. That is one deployment, not the definition of the market. ABACUS is a rating engine with its own configuration schema and its own API; a customer can put it behind a policy administration system that is not IPAL and never touch SRD_IPROD.

This is not speculation about the future — it is already how the code is arranged. ABACUS is reached by two routes, and only one of them goes through a database. IPAL's premium service calls the engine directly, assembling the request from its own pricing-factor declarations. A foreign PAS reaches it the same way. The SRD_INTEGR.ABC_* packages are a proxy for the incumbent system, not part of the engine. Figure 1 puts the two shapes side by side.

In shape 1 the product needs a target adapter it does not have today. It can write ABACUS, but the customer's PAS still has to be told which covers exist and what to send in the rating request. The design's answer is not to build an adapter per PAS: it is to export a contract — the cover list, the factor list with types and allowed values, and a worked request/response pair — as JSON and as a human-readable page. Integrating that is the customer's side of the boundary.

Six services and two systems the product does not own, in figure 2. Nothing here is exotic; the only unusual decision is that the run is a first-class durable entity with its own state machine rather than a request handler, because it takes minutes to hours and must survive a restart.

The eleven steps of the current skill collapse into seven states with three gates. A gate is a place where the run stops and waits for a person — not a checkpoint the model can talk its way past.

The product must not be tied to one vendor: customers will have opinions about where their tariff documents may be sent, and some will require a model inside their own cloud tenancy. Provider independence is therefore a requirement, not a preference — but it is worth being precise about how much independence is achievable.

Two rules keep the model's mistakes inside the blast radius the design allows. The model never emits SQL that reaches a database. It emits the canonical model; the projection into SQL is deterministic code that a reviewer can read. And the model never holds a database credential — it asks the estate prober, which answers with counts.

The knowledge base travels with the product. What is in knowledge/ and memory/ today is Bulstrad's estate, and much of it is generic (the ABACUS rate-file grammar, premium vocabulary, the version-and-deploy model) while some is not (product codes, counted defaults, role names). The split has to become explicit: engine knowledge ships with the product; estate knowledge is measured per tenant on first connection and refreshed on a schedule.

This is the section a reviewer should read hardest. The argument is that ABACUS already has the safety property we need, and the write path is safe exactly to the degree that it respects it.

A tariff in ABACUS is not a set of rows that the engine reads. It is a version, and the engine reads a compiled artefact produced when that version is deployed. The design-time tables and the runtime artefact are different objects:

So an edit to design-time configuration changes nothing until the consuming version is deployed. That is normally described as a trap — it is the reason a corrected rate can look applied and price against the old numbers — but for a machine writer it is the safety net. The service writes a new version and stops.

Two loops, deliberately different. Confusing them is how a configuration drifts away from its own documentation.

A correction that lands after a version has been written to the database produces a new version, never an edit of the written one. The UI shows the chain: which version each run produced, which is deployed, and which are abandoned.

Everything a run touched, in one place, addressable by URL. The workspace directory that exists on disk today becomes the object model of the UI — the structure is already right, it simply has to be served.

The product document is the review surface, and it already exists: the workspace renders one per product from markers plus shared CSS. In the service it becomes a server-rendered page with the same content — covers and limits, the tariff with a worked example, what needs code, the gaps in the specification, the acceptance list — addressable, printable, and versioned alongside the run that produced it.

Retention and residency are tenant settings, because inputs are customer documents and some of them are commercially sensitive. A tenant must be able to say: keep inputs 90 days, keep the model and document indefinitely, and never send either to a provider outside this region.

IPAL's login is already an OIDC server: the /identity-server microservice, an Ablera component in the same backend, exposing .well-known/openid-configuration and the /connect/* endpoints, federating the password check to the customer's directory with a failover tier behind it. That it is our component and speaks a standard protocol is what makes this section short.

Roles come from the same vocabulary as the rest of the platform. IPAL already gates three different things with one role list — the menu through Routes."AllowedRoles", the API through EndPoints."AllowedRoles", and the check pipeline through its bypass roles. The configurator adds its own roles to that catalogue rather than inventing a parallel one, and appears in the menu on the same terms as any other product screen.

An honest accounting, because the workspace carries more of this than it looks and less than one would hope.

Tagged the way the configurator tags its own gaps. Each one changes the build if answered the other way, and none of them should be settled by the person who wrote this document.

Each stage is usable on its own, and each is a defensible place to stop if the next one does not earn its risk.