Test, approve and go live

Pricing configuration changes all the time: a new rate card next month, a corrected loading, a scheme rate for one partner. On BimaStack every one of those changes is a version with a start date, approved by a second person, tested before it is live, and recorded so any quote can be explained later. This post covers how that works, and where to try it safely.

Everything is a versioned setting

Rate tables, formulas’ links, workflows, blocks, connections, operations and product definitions all share one mechanism. Each version has:

• A scope: your organisation, and optionally a binder, a product, a cover type or a section.
• An effective window: from a date, and optionally to one.
• A status: DRAFT, then ACTIVE once published, then SUPERSEDED.
• A history: who drafted, approved, published or retired it, when, and why.

A published version never changes. Editing makes a new version, so what priced a quote is always still there.

The most specific scope wins

• Organisation A, product X: 5%, the most specific match.
• Organisation A, product Y: 3%.
• Organisation B, product X: 2%.

This is how a negotiated scheme rate works: the same table code published at a binder’s scope overrides your standard card for policies under that binder, and the workflow reading it is unchanged. Among versions that match, the one whose window covers the date wins.

Dates: schedule ahead, look back

• Schedule a change. Publish next month’s card today with next month’s start date. Today’s version stays live and is end-dated at the new start; on the start date the whole new card applies, with no one on duty to flip it.
• Recalculate the past. A calculation for a past date reads what was live on that date: the same table, formula, workflow and product versions.
• No gaps. A version can’t be published to start before one already active; retire that one first.

Formula links: from saved text to live price

A workflow names a formula or block by a key. A calculation link (a node binding) says which saved version that key means, in a scope, from a date. So:

• saving corrected formula text changes nothing live;
• publishing a new link from the 1st makes every workflow using that key price with the correction from the 1st;
• a product can link its own version of a shared key (its own base premium formula), and the most specific scope wins;
• the editor shows, for any key in your scope, the text it runs and whether newer text is saved but not yet linked.

POST /api/settings/node-bindings
{ "scope": { "organizationId": "<organisation>", "productId": "motor-private" },
  "key": "base-premium",
  "value": { "nodeType": "FORMULA", "contentKey": "base-premium", "contentVersion": 4 },
  "effectiveFrom": "2026-11-01",
  "expectedCurrentVersion": 3,
  "reason": "corrected the minimum premium" }

Two people, every time

• Draft, approve, publish. Whoever drafts a version can’t approve it; approving your own is refused. Publishing needs an approval first.
• One exception: an organisation with a single member (an independent agent) may approve their own drafts, recorded as such. A second member brings the rule back at once. Platform content always needs a second person.
• Concurrent edits are caught. A draft says which version it was edited from; if someone else saved in between, it is refused rather than overwritten.
• The Approvals page gathers the drafts waiting for a second person.

Test before it is live

All of them use the same engine as live quotes, so a passing test means the live price will match. The Setup checklist, for any product, lists every workflow, table and link it needs, which are ready, and what each one is used by.

After it is live: computations and replay

• Every quote is recorded: the request, the quote, the definition version, every version it read, and who sold it on what basis.
• Browse them by product, outcome and time, newest first.
• Replay one: run it again at its own date against the same definition, and see what moved. “RATE_TABLE/motor-base@v1 is no longer used; @v2 is now used” means a table was republished to start on or before that quote’s date.

Sandbox: a whole BimaStack to break

Sandbox, at sandbox.bimastack.com, is a complete BimaStack running the release Production runs, with nothing real in it. Anyone can sign up, organisations are approved at once, and everything is wiped every day at 02:00 East Africa Time.

Every response carries Sandbox-Reset-At (the next wipe, an ISO instant) and Sandbox-Reset-Warning (true in the last hour before it), so your tooling can save its work in time. The site shows the same notice on every page.