A new project - an underwriting rules engine, built entirely in Postgres
New project now in progress: an insurance underwriting rules engine, built entirely in PostgreSQL. Later we will add an api layer and front end as a sample.
The idea is simple on concept and a little more interesting to build: a person/applicant answers underwriting product’s questions in order, then we run those answers against those sppecific product’s rules, in order to get a decision - accept, increase_premium, refer_to_insurer, or decline.
Products, questions, and rules all live in tables, so adding a new product or tweaking a rule is just a data change, never a code change. 100% data-driven concept !!
By personal choice, I keep two evaluation strategies side by side. Model A looks at every answer and every rule and returns the single worst outcome. Model B walks trough the questions in order, and escape early the moment a rule flagged to short-circuit fully matches, without bothering to look at later answers. They can legitimately disagree with each other, and I have created a demo quote per product that shows that difference on purpose, rather than treating it as a bug to hide.
For executtion, I planned six phases in, all done as of now: core schema, the rules engine, an evaluation history table so past decisions stay auditable, some production hardening (constraints, indexes, a trigger that rejects a bad answer before it’s even written), and seed synthetic data - 8 demo products with questions, rules, and 80 passing tests. All this runs in Docker, so docker compose up -d gets a fresh instance going and my own scripts handle running the test suite or resetting the volume.
What’s next: a thin FastAPI layer on top - list products, fetch questions, submit answers, evaluate - that just calls into the SQL above with no business logic duplicated in application code. That part hasn’t started yet, so more on that once it does.