RE PitchSimpleINSPIRE Rule Engine
Book a walkthrough
SPRISKA · COMMERCIAL PACKAGE POLICY · NEW BUSINESS REFERENCE SET

Every rule your business runs —
standardised, generated, governed.

SimpleINSPIRE closes the gap between business intent and IT execution — unifying human intent with automated technical execution so carriers configure, manage and deploy complex rules at scale. Proven today on Commercial Package Policy New Business; architected for every line and lifecycle stage, from underwriting to claims.

Built on the logic you already know
Stored proceduresREST APIs725 NB rulesPROD + RE
// one rulebook● CLASSIFIED
Rule #10 — Effective date window
SI06 · Commercial Property · v2.0.0
ClassifiersSelection queryStored procedureREST APITest casesProvenance
SeverityHard Stop (Error)
Trigger stagePage · Rate
VersionsPROD v1.0.0 · RE v1.1.0-RE
Coverage✓ 6 test cases
Same rule. Every lens. One record.
FOR INSURANCE PLATFORMS BURDENED BY FRAGMENTED LEGACY LOGIC

The next-generation rule standardisation, generation & governance platform.

Fragmented legacy logic and message-to-logic drift make rules slow to change and impossible to trust. Unlike rigid traditional systems, SimpleINSPIRE unifies human intent with automated technical execution — ingesting legacy code, reverse-engineering it through an AI-assisted extract-and-review wizard, and emitting production-ready SQL, stored procedures and REST APIs, all under a tamper-evident hash-chained audit trail and a human-in-the-loop governance gate.

It closes the gap between business logic and technical deployment — turning compliance into an agile asset.

THE PLATFORM AT A GLANCE

Six modules. One record. One engine that acts.

This is how the promise is delivered. Six modules read and write the same authoritative rule — classify it, turn intent into code, inherit your legacy logic, analyse the whole book, and answer questions in plain language. A fix in one module is evidence in another.

Domain 01CORE

Rule Library

See the whole rulebook at last — one classified record per rule: number, line, area, severity, stage, version and coverage, all searchable.

Classified gridExact-# searchInherited rowsExcel export
Domain 02CORE

Rule Drawer

Turn intent into execution — open any rule to run it, generate its query / SP / REST API, document it, and version it.

Run ruleGenerate SQL+APIPDF specVersioning
Domain 03NEW

New Rule — Configurator

Catch the bad rule before it ships — author against the standard with a status workflow, a live simulator and parameters, not hard-coded values.

StepperSimulatorParametersAI draft
Domain 04CORE

Imports

Modernise legacy logic without a big-bang rewrite — ingest deployed procedures, reverse-engineer them with confidence tags, keep PROD authoritative.

Intake queueExtract & reviewReconciliationImport directory
Domain 05

RE Analytics

Surface what was buried — distribution, concentration, conflict worklists and RE-enablement & migration across the whole book.

HeatmapWorklistsMigrationInspire RE - AI
Domain 06NEW

Rules Assistant

Put the rulebook in everyone's hands — ask in plain language, get a grounded, cited answer linking the rule, its code and its tests.

GroundedCitedConnected answerPDF export

Governed by construction

Every change is versioned and supersedes — never overwrites. Each action lands on a tamper-evident, hash-chained audit trail, and a human-in-the-loop gate approves anything compliance-relevant before it ships.

Hash-chained auditVersioned lineageHuman gate
The grounded assistant Ask the Rulebook reads across the rulebook and turns a question into the connected picture — rule → code → tests → provenance. Around it sit the Artifacts and Documents registers, the Test Case Repository, and a hash-chained Log.
THE PRINCIPLES BEHIND THE PROMISE

Five operating principles

Turning compliance into an agile asset only works if the foundations hold. These five tenets are what make the claims on the previous pages true — not slogans, but the way the platform is built.

01

One record, every lens

Each rule is classified once across six dimensions; the library, analytics, generation, assistant and governance all read the same atom.

6 classifier dimensions · 725 NB rules
02

See what no code review shows

Classification surfaces the message-to-logic drift a read-through misses — contradictory windows, hard-coded ranges, rules that can never fire.

57 buried issues · 44 duplicate groups
03

Record → action

The engine doesn't just flag. It generates the query, procedure and API, drafts test cases, and proposes the fix — a human approves.

classify → generate → approve → log
04

Versioned, never overwritten

Modifying a rule creates a new version that supersedes the last; full lineage is preserved and coverage travels with each version — nothing is ever lost.

supersede, don't overwrite · coverage per version
05

Grounded, not an oracle

Imports stay the source of truth and the engine offers a candidate, never an overwrite; AI answers are grounded and cited, with a human-in-the-loop gate.

PROD authoritative · human-in-the-loop
Domain 01CORE
Rule Library

You can't govern, cost or fix what you can't see in one place.

Validations live across deployed procedures, APIs and spreadsheets that disagree. The Rule Library makes one classified record per rule — number, line of business, area, severity, stage, version and coverage — searchable, sortable and exportable.

Classified gridExact rule-# searchInherited PROD/RE rowsFilters & export
Nobody can give one trustworthy view of the rulebook — it's split across procedures and sheets.
What the engine does → Every rule is classified across six dimensions into a single grid of 725 NB rules; each row opens to its full definition.
① Classified inventory ↗ open live
A line-of-business filter can silently hide the very rule you searched for.
What the engine does → An exact rule-number lookup (e.g. #726) resolves directly and bypasses active scope filters, with a transparency note.
② Search tuned for engineers ↗ open live
Inherited production logic looks the same as native rules — you can't tell what's deployed.
What the engine does → Inherited rows are distinguished and carry both PROD and RE version tags; the RE candidate appears as its own sub-row.
⑤ PROD / RE at a glance ↗ open live
rule_engine_ui.html#tab=libraryOpen full
rule_engine_ui.html#tab=librarySimpleINSPIRESearch rule #, name, artifacts…Rule LibraryRE AnalyticsImportsArtifactsLogPKLINES OF BUSINESSAll lines725Commercial Property318Inland MarineGeneral LiabilitySEVERITYHard Stop (Error)ReferralWarningSTAGEPageRateBind725 rules · classified across 6 dimensions⬇ Excel#VERSIONLOBFIELDSEVERITYSTAGETEST10#10 · v2.0.0Comm. Prop.Effective dateHard StopPage · Rate✓ 611#11 · v1.2.0Comm. Prop.DocumentsReferralPage✓ 3726PROD v1.0.0 ⬇Terrorism disc.Hard StopBind↳ RE v1.1.0-RE — generated candidate · diff vs PROD88#88 · v1.0.0Comm. Prop.Zip codeHard StopPage259#259 · v1.0.0Comm. Prop.AddressWarningRate✓ 2‹ 1 2 3 … 30 ›💬 Ask the Rulebook123456
The classified Rule Library — the numbered callouts mark each feature.  ·  open the live screen ↗
725
NB rules on one record
6
classifier dimensions
#726
exact-lookup bypass
✓ / ⚠ / ○
coverage per rule
Principles at work01 · One record02 · See what's hidden
Domain 02CORE
Rule Drawer

One definition becomes runnable, generatable and provable.

Open a rule and it stops being prose. The drawer turns its classifiers into a unit you can run, compile to three artifacts, document, and version — with production truth and the rule-engine candidate side by side.

Run ruleGenerate query / SP / APIPDF specPROD + RE versioning
A rule in prose can't be executed or turned into code without a developer rewriting it.
What the engine does → Generate produces the selection query, stored procedure and REST API from one definition; Run traces every guard and reports the verdict.
③ One definition → three artifacts ↗ open live
Changing a rule risks losing the prior logic and the reasoning behind it.
What the engine does → Modify saves a new version and supersedes the original; lineage is preserved and an unchanged save is blocked.
⑤ Versioned lineage ↗ open live
For deployed rules, you can't see what the engine would change versus what's live.
What the engine does → Inherited rules keep PROD v1.0.0 as source of truth and RE v1.1.0-RE as the candidate, with a production-versus-RE diff and per-version download.
⑤ PROD vs RE, provable ↗ open live
rule_engine_ui.html#tab=library&rule=10Open full
rule_engine_ui.html#tab=library&rule=10SimpleINSPIRESearch rule #, name, artifacts…Rule LibraryRE AnalyticsImportsArtifactsLogPKRule #10 — Effective date window✓ VerifiedSI06 · Commercial Property · v2.0.0 · New BusinessPropertyConditional RequirementHard Stop (Error)Page · RateIF effective_date > today + 90 THENHard Stop (Error): "Effective date too far in future"▶ RunGenerate SQL + APIPDF specTestsSelection queryStored procedureREST APISELECT * FROM submission sWHERE s.effective_date > DATEADD(day,90,GETDATE()) -- rule #10 · v2.0.0v2.0.0 supersedes v1.0.0 · full lineage preserved · download any versionInherited rules: PROD v1.0.0 vs RE v1.1.0-RE diff123456
The Rule Drawer for rule #10 — the numbered callouts mark each feature.  ·  open the live screen ↗
3
artifacts per rule
PROD + RE
versions side by side
DRAFT / PUBLISHED
watermarked spec
diff
what would change
Principles at work03 · Record → action04 · Govern by construction
Domain 03CORE
Imports — Step one: bring the deployed world in

Modernise deployed logic without a big-bang rewrite.

Bring stored procedures and APIs in through one consistent intake, reverse-engineer them into conforming rules with confidence tags and a human gate, and keep the deployed code as the system of record — landing them on the same classified standard you author new rules against.

File intake queueConfidence-tagged extractionReconciliationProduction-authoritative directory
Migrating deployed procedures wholesale is risky and slow.
What the engine does → Source is added to the Intake queue; a three-step wizard extracts fields, stages, severity and message, each tagged hi / review / low.
① Reverse-engineer with a gate ↗ open live
Auto-converting logic with AI risks silently changing what production does.
What the engine does → Extraction never auto-commits — a person confirms; the source is reconciled against the generated candidate as an exact match (≥92%) or an N% diff.
⑤ Human-confirmed reconciliation ↗ open live
Editing deployed code directly to 'fix' a rule is how drift starts.
What the engine does → The Import directory is read-only and production-authoritative; change happens only by revising the bound rule, never the deployed artifact.
③ PROD stays the source of truth ↗ open live
rule_engine_ui.html#tab=imports&iview=directory&itype=SPOpen full
rule_engine_ui.html#tab=imports&iview=directory&itype=SPSimpleINSPIRESearch rule #, name, artifacts…Rule LibraryRE AnalyticsImportsArtifactsLogPKASSET TYPESStored proceduresREST APIsVIEWIntake queue24Import directoryProduction-authoritative stored proceduresread-only · change only by revising the bound ruleOBJECTBOUND RULERECONCILETESTSusp_ValidateEffDate#726 · v1.1.0-REexact ≥92%usp_ZipCheck#88 · v1.0.092% matchusp_AddressVerify#259 · v1.0.087% · diffusp_TerrorismDisc#726 · v1.1.0-REexact ≥92%↳ Extract & review in queue123456
The Import directory — the numbered callouts mark each feature.  ·  open the live screen ↗
1
consistent intake path
hi / review / low
extraction confidence
≥92%
exact-match threshold
read-only
production directory
Principles at work05 · Safe by default03 · Record → action
Domain 04NEW
New Rule — Step two: author on the same standard

Catch the bad rule before it ships — not in an agent's quote.

Author against the same standard your imported rules conform to, with a Draft → Verified → Approved → Published workflow, a simulator that traces every guard, and configurable parameters that keep message text and logic from drifting apart.

Status stepperLive simulatorParameters, not hard-codingAI-assisted draft
Hard-coded values in messages drift out of step with the logic that enforces them.
What the engine does → Anything that varies by state, product or client is captured as a parameter (a dbo.fn_RuleParam lookup) rather than written into the text.
④ Parameters, not hard-coding ↗ open live
Rules are tested only after they reach production, where mistakes are expensive.
What the engine does → The pass / fail simulator replays a rule against a transaction context and sample value, surfacing conflicts before publication.
⑤ Quality at author-time ↗ open live
Authoring a conforming rule from scratch is slow and inconsistent.
What the engine does → An AI-assisted draft turns a plain description into a structured starting rule for human review, advanced through the status stepper.
① Faster, governed authoring ↗ open live
rule_engine_ui.html#tab=createOpen full
rule_engine_ui.html#tab=createSimpleINSPIRESearch rule #, name, artifacts…Rule LibraryRE AnalyticsImportsArtifactsLogPKNew Rule — ConfiguratorDraftVerifiedApprovedPublishedWHENpolicy.effective_date > today + {param}EFFECTIVE01/01/2026 → —THENHard Stop (Error)"Effective date too far in future"Simulator — trace every guardRun simulationTxn: New Business · Stage: Page · effective_date = today + 120✗ Rule fires — Hard Stop (Error) · guards: txn ✓ stage ✓ window ✓Selection queryStored procedureREST APICREATE PROCEDURE usp_Rule10 @effdate DATE AS …123456
The New Rule configurator — the numbered callouts mark each feature.  ·  open the live screen ↗
4
status states
live
guard-by-guard simulation
0
hard-coded thresholds
human
approves every publish
Principles at work02 · See what's hidden03 · Record → action
WHAT YOU HAVE JUST SEEN, TOGETHER

Two doors. One standard. No leap of faith.

You have now seen both doors — Imports reverse-engineers what is already deployed, and the Configurator authors what is new. Step back and it is one journey: the old world of scattered code, baselined onto a single standard, then built forward on it — without ever disrupting what is running.

THE WORLD TODAY

Logic locked in deployed code

  • Rules live inside stored procedures & APIs, scattered across the system
  • Message text drifts from the logic that enforces it
  • Every change is a developer rewrite and redeploy
  • The reasoning lives with the few who wrote it
  • No single, trustworthy view of the rulebook
STEP ONE · IMPORTS

Reverse-engineer the deployed world onto the standard

  • Drop the .sql / .json you already run into the Intake queue
  • The extract-and-review wizard maps it to the standard, confidence-tagged
  • Reconcile ≥92% · a human confirms before anything inherits
  • PROD stays the source of truth — nothing is overwritten
STEP TWO · CONFIGURATOR

Author new rules on the same standard

  • Build against the same classified schema your imports conform to
  • Status workflow, live simulator, parameters — not hard-coding
  • Generate SQL / stored procedure / REST API from one definition
  • Versioned, hash-chained and governed from day one

Two steps, one standard. Imports baselines the deployed past; the Configurator builds the future — both on the same governed model. Production keeps running until you choose to migrate, so there is no leap of faith.

What standardisation brings to the table Consistency by constructionSelf-generating codeGovernance & auditPortfolio analyticsGrounded AIFaster, safer change
Domain 05
RE Analytics

See the shape of the whole rulebook — and what it implies.

Scattered across procedures, the portfolio view was impossible. RE Analytics reveals distribution, concentration and cadence, lists the conflicts and duplicates to act on, and tracks migration to the engine on a need basis.

Concentration heatmapConflict worklistsRE-enablement & migrationInspire RE - AI
57 issues — contradictory windows, hard-coded ranges, duplicates — sat buried in deployed code for years.
What the engine does → Worklists surface conflict-flagged rules, shared patterns and referrals; a Category × LOB heatmap shows where logic concentrates, each cell split RE-enabled vs production.
③ See what was hidden ↗ open live
There's no way to plan or measure a move to the engine.
What the engine does → The RE-enablement & migration view splits enabled vs production-only by type and line, tiers pending work S/M/L, and drills every count to the rules or files behind it.
⑤ Migrate on a need basis ↗ open live
Asking analytical questions of the rulebook needs an engineer and a query.
What the engine does → Inspire RE - AI answers questions grounded in the rule digest for the selected scope — no SQL required.
⑥ Analytics anyone can query ↗ open live
rule_engine_ui.html#tab=insightsOpen full
rule_engine_ui.html#tab=insightsSimpleINSPIRESearch rule #, name, artifacts…Rule LibraryRE AnalyticsImportsArtifactsLogPKRE Analytics — Commercial Property638Page110Rate707Hard Stop57ReferralConcentration — Category × LOBWorklists 8Conflicts41Shared patterns57Referrals38%RE-enabled vs prodMigration effortS× 9 itemsM× 6 itemsL× 3 itemsInspire RE - AIAsk about this scope — grounded in the rule digest…Ask123456
RE Analytics — the numbered callouts mark each feature.  ·  open the live screen ↗
57
buried issues surfaced
Category × LOB
concentration heatmap
S · M · L
migration effort tiers
drill
from chart to rule
Principles at work01 · One record02 · See what's hidden
Domain 06NEW
Rules Assistant — Ask the Rulebook

Put the rulebook in everyone's hands — without making it an oracle.

A floating assistant on every screen answers plain-language questions only from the actual rules, cites each by number and version, and returns the connected picture — rule, its code, its tests — so knowledge no longer lives in a few heads.

Plain-language questionsGrounded & citedConnected answerPDF export
The reasoning behind a rule lives with the few people who wrote it.
What the engine does → Ask the Rulebook retrieves the relevant rules and answers only from them, citing each by number and version — knowledge anyone can query.
② Democratised, grounded knowledge ↗ open live
Teams fear AI on regulated logic because it can hallucinate.
What the engine does → The assistant is grounded-not-oracle: a question that matches nothing returns an honest no-match; it never invents a rule, and a human still authors and approves.
⑥ Safe AI adoption ↗ open live
Understanding a rule means hunting across code, tests and specs separately.
What the engine does → Each result links the rule definition, its stored procedure, its REST API and its test cases in one connected card, exportable to PDF.
④ One question → the whole picture ↗ open live
rule_engine_ui.html#ask=1Open full
rule_engine_ui.html#ask=1SimpleINSPIRESearch rule #, name, artifacts…Rule LibraryRE AnalyticsImportsArtifactsLogPK💬 Ask the Rulebook⤢ ✕Which rules block a future effective date?Rule #10 enforces a 90-day cap on the effectivedate; submissions beyond it hard-stop.cited: #10 · v2.0.0#10 — connected• Selection query• Stored procedure• REST API• 6 test casesRules at Bind?Zip-code rules?Grounded · always cited · honest no-match⬇ PDF123456
Ask the Rulebook — the numbered callouts mark each feature.  ·  open the live screen ↗
every screen
floating access
cited
rule # and version
honest
no-match, never invented
rule+code+tests
one connected answer
Principles at work05 · Safe by default01 · One record
Domain 07CORE
Test Case Repository

Scaling the rulebook shouldn't mean breaking the system.

Every rule carries its own regression suite. The engine derives structured unit cases per rule and version, each with a traceable ID, so go-live and every change after it are backed by evidence — not hope.

Per rule & versionStructured IDsFIRE · PASS · BNDExport
Change one rule and you can silently break three others — with no way to prove it didn't happen.
What the engine does → Cases are saved per rule and per version; coverage travels with the version, so a new version starts uncovered until its own cases pass.
① Coverage per version ↗ open live
'It works' is an opinion unless you can show which paths were tested.
What the engine does → Each case is a named path — FIRE, PASS, boundary, stage, role, date-window — with an expected outcome the engine checks.
③ Evidence, not opinion ↗ open live
Test artifacts get lost across spreadsheets and tickets.
What the engine does → Every case has a structured ID — TC-CLIENT-Rule-Version-Kind-Seq (e.g. TC-SPRISKA-R10-V2.0.0-BND-03) — searchable, filterable and exportable.
② Traceable by ID ↗ open live
rule_engine_ui.html#tab=testsOpen full
rule_engine_ui.html#tab=testsSimpleINSPIRESearch rule #, name, artifacts…Rule LibraryRE AnalyticsImportsArtifactsLogPKTest Case Repository — SPRISKAthe regression suite for go-live · saved per rule and versionSearch rule # or TC-ID…All kinds ▾⬇ ExportTEST CASE IDRULEKINDEXPECTEDVERSIONTC-SPRISKA-R10-V2.0.0-FIRE-01#10FIREFIRE — ERRORv2.0.0TC-SPRISKA-R10-V2.0.0-PASS-02#10PASSPASS (no msg)v2.0.0TC-SPRISKA-R10-V2.0.0-BND-03#10BNDFIRE — ERRORv2.0.0TC-SPRISKA-R10-V2.0.0-STG-04#10STGPASS (stage)v2.0.0TC-SPRISKA-R88-V1.0.0-DTW-01#88DTWFIRE — ERRORv2.0.0ID scheme: TC-CLIENT-Rule-Version-Kind-Seq · kinds FIRE · PASS · BND · STG · ROLE · DTW123456
The Test Case Repository — the numbered callouts mark each feature.  ·  open the live screen ↗
per rule + version
coverage that travels
6 kinds
FIRE·PASS·BND·STG·ROLE·DTW
TC-…-BND-03
structured IDs
✓ / ⚠ / ○
status in the Library
Principles at work04 · Govern by construction03 · Record → action
Domain 08CORE
Transaction Log

If you can't prove what changed and who changed it, you can't govern it.

Every meaningful action — rule creation, generation, publication, exports, AI questions, workspace switches and configuration changes — is timestamped and hash-chained, so the record is complete and tampering is evident.

Hash-chainedEvery actionUS-Eastern timestampsTamper-evident
Regulators and auditors ask 'who changed this rule, when, and on whose authority?' — and most systems can't answer.
What the engine does → Every action is logged with user, client, event, detail and references, in US-Eastern time — a complete who/what/when.
① A complete record ↗ open live
An audit trail you can quietly edit is worth nothing.
What the engine does → Each entry's chain value commits to everything before it; altering any row breaks the chain, so tampering is evident.
⑤ Tamper-evident by construction ↗ open live
Finding the one relevant event in thousands is its own problem.
What the engine does → Filter by event type and search detail, refs, client or user; references deep-link to the rule or artifact involved.
④ Searchable & linked ↗ open live
rule_engine_ui.html#tab=logOpen full
rule_engine_ui.html#tab=logSimpleINSPIRESearch rule #, name, artifacts…Rule LibraryRE AnalyticsImportsArtifactsLogPKTransaction Log — provable traceabilityevery action timestamped & hash-chained · chain head a7f3…9c2All event types ▾Search detail, refs, user…LOG IDTIMESTAMP (EST)USEREVENTDETAILCHAINLOG-04812026-06-12 14:22P. KannanPUBLISHRule #10 v2.0.0 published🔒 okLOG-04802026-06-12 14:19P. KannanGENERATESP + REST API for #10🔒 okLOG-04792026-06-12 11:03P. KannanINHERIT#726 baselined from PROD🔒 okLOG-04782026-06-11 16:47S. RaoAI-ASKAsk the Rulebook query🔒 okLOG-04772026-06-11 16:30S. RaoEXPORTLibrary → Excel🔒 okEach entry's chain value commits to everything before it — tampering is evident.123456
The Transaction Log — the numbered callouts mark each feature.  ·  open the live screen ↗
every action
captured
hash-chained
tamper-evident
US-Eastern
consistent timestamps
refs → rule
one-click trace
Principles at work04 · Govern by construction05 · Safe by default
Domain 09
Artifacts · Documents · Admin

The registers and controls that make the rest trustworthy.

Behind the six modules sit the stores and controls that hold everything together: the generated code, the circulated specifications, and the multi-client administration that keeps each carrier's rulebook and AI configuration separate and governed.

ArtifactsDocumentsProfile & workspacesPer-client AI
Generated code with no identity or lineage can't be trusted in production.
What the engine does → Artifacts are read-only, versioned, checksummed and dated; to change one you revise the rule, and the artifact follows.
① Provenance on every artifact ↗ open live
Underwriters need a spec to sign off — not a database query.
What the engine does → Documents are watermarked DRAFT or PUBLISHED PDF specs with version, author and timestamp; drafts circulate, published specs are the record.
④ A spec you can circulate ↗ open live
One engine, many carriers — their rules and AI keys must never bleed together.
What the engine does → Profile holds three isolated client workspaces, each with its own baseline and per-client AI model and key, managed-proxy by default.
⑤ Isolated, governed workspaces ↗ open live
rule_engine_ui.html#tab=artifactsOpen full
rule_engine_ui.html#tab=artifactsSimpleINSPIRESearch rule #, name, artifacts…Rule LibraryRE AnalyticsImportsArtifactsLogPKArtifacts — generated SQL & REST APIsread-only · versioned · checksummed · regenerate from the ruleART-SPRISKA-0182STORED PROC#10 · v2.0.0checksum a91f…PublishedART-SPRISKA-0183REST API#10 · v2.0.0checksum 7c20…PublishedDocuments — rule specifications, ready to circulatewatermarked DRAFT or PUBLISHED PDF · version · author · timestampDOC-SPRISKA-0094Rule #10 — Effective date windowPUBLISHEDPDF · v2.0.0DOC-SPRISKA-0095Rule #11 — Required documentsDRAFTPDF · v1.0.0Drafts circulate for UW sign-off; published specs are the runtime record.RULE SPECIFICATIONPDFRule #10 — Effective dateHard Stop (Error) · Page · RatePUBLISHEDv2.0.0 · P. Kannan · 2026-06-12 (EST)Profile & workspaces — Priya Kannan · Rule Administratorthree client workspaces · per-client AI model & key · managed proxy by defaultSPRISKAPRODCommercial Package PolicyAI · claude-sonnet-4-6MERIDIANUATBusinessowners PolicyAI · claude-haiku-4-5ATLASUATExcess & SurplusAI · claude-sonnet-4-6123456
Artifacts, Documents and Profile / workspaces — the numbered callouts mark each feature.  ·  open the live screen ↗
read-only
versioned + checksummed
DRAFT / PUBLISHED
watermarked specs
3 workspaces
per-client isolation
per-client
AI model & key
Principles at work04 · Govern by construction01 · One record
FROM A PROVEN REFERENCE SET TO A LIVING PLATFORM

This is the engine you couldn't picture — now working on the rules you know.

The 725 New Business rules are the first reference set. Done well on logic SPRISKA knows intimately, they de-risk the whole platform — and everything here generalises to more lines, more transaction types, deeper analytics and AI-assisted authoring.

Now

Reference set proven

One LOB / NB validated on logic the client knows — the platform de-risked.

Next

Database integration

Connect to the SPRISKA datastore; coverage and analytics repoint with no rework.

Then

Scale & author-time AI

More lines and transaction types; conflict detection, impact preview, parameter fast-path.

Later

Templates & composition

Shared patterns become reusable templates; non-experts compose test-covered bundles.

RE Pitch · SimpleINSPIRE Rule Engine · Simplesolve · SPRISKA Commercial Package Policy