The decision
Does this submission bind automatically, go to an underwriter, or fall outside appetite?
Insurance operations
Bind what is inside appetite, refer what is not, and prove which guidelines applied
Encode underwriting guidelines as rules that bind clean submissions automatically and refer everything else with the analysis already done. Every bind records the guideline version in force, so a portfolio review can answer what the rules were on the day.
How it runs on AI Rule Engine
The submission arrives
From a broker portal, an API, or a batch. The same rules evaluate it however it came in.
Appetite rules evaluate
Class of business, geography, limits, attachment, loss history, and exclusions run as explicit conditions authored from your guidelines.
AI reads the unstructured parts
Broker emails, loss runs, and supporting documents are classified and extracted into facts. Rules decide what those facts mean for appetite.
Rules cascade to an outcome
Conclusions feed further rules until the submission settles on auto-bind, refer, or decline, with the referral reason attached.
The outcome is recorded with its version
The bind or referral is pinned to the published guideline version that produced it.
What the auditor sees
Most automation records that a decision happened. This records why it happened, on logic you can prove was in force at the time.
The guideline version on the bind
Every decision names the published version in force at the time, so a portfolio review can establish what appetite was rather than inferring it.
The referral reason, specifically
A referral carries the conditions that triggered it and the values behind them, so the underwriter opens the file already knowing why it is on their desk.
Verification before publication
Static analysis catches rules that can never fire, duplicate rules, conflicting writes, and combinations of inputs no rule covers, before a guideline change goes live.
A signed release record
Each guideline publish produces an RSA-SHA256 signed evidence record verifiable against a public key, proving the appetite in force on a date has not been rewritten since.
Approval on the change
Guideline changes move through draft and review. The approver is recorded, and the release can be blocked until its test cases pass.
Where the human stays
Referral is the default for anything the rules do not clearly cover. The underwriter receives the submission with the appetite analysis already run, sees which conditions triggered the referral, and their decision is recorded on the submission, under their name, alongside the rules that referred it.
Where AI is used, and where it is not
The boundary is enforced by how the workflow is built, not by a policy document. AI turns text into facts. Rules you wrote decide what those facts mean.
AI is asked to
- Extracting exposure data from a broker submission or loss run
- Classifying a business description into a class code
- Summarizing prior loss history for the underwriter
- Flagging language that suggests an unlisted exposure
AI is never asked to
- Deciding whether a risk is inside appetite
- Applying a limit, attachment point, or exclusion
- Binding coverage
- Pricing
What changes
Underwriters on the accounts that need them
Clean, in-appetite submissions stop consuming judgment that should go to complex risks.
Appetite changes in a day
A change in appetite is a rule edit, tested and approved, rather than a guideline revision and a retraining cycle.
Consistent risk selection
The same submission gets the same treatment regardless of who received it.
Portfolio reviews with real answers
What the guidelines were on a given date is a lookup, not an argument.
The objections you are about to raise
“Our underwriting judgment cannot be reduced to rules.”
Not all of it, and that is not the goal. Rules handle the part that is already mechanical, which is most of the volume, and refer everything else. Judgment is preserved by routing to it faster, with the analysis already done.
“We have a policy admin system with a rating engine.”
Rating and appetite are different questions. This answers the appetite and referral question over an API call and hands the result back. Rating stays where it is.
“Guidelines change too often to encode.”
Frequent change is the argument for encoding them. A rule edit is tested against saved submissions and published behind an approval, with every prior version intact and every bind linked to the version that produced it.
“How do we know a change did not break something?”
Verification runs before publication and flags dead rules, conflicting writes, and uncovered input combinations. Saved test cases run on every change and a release can be gated on them passing.
Frequently asked questions
Can rules be maintained by underwriting rather than IT?
Yes. Appetite is authored as decision tables and visual rules, which read closer to a guideline than to code. Publishing is gated by approval, so authoring access does not mean unreviewed production changes.
What happens when appetite tightens mid-quarter?
Edit the ruleset, run the saved test cases, and publish behind an approval. Submissions after the publish use the new version, and everything bound before it stays explained by the old one.
Can we simulate a guideline change before publishing?
Yes. The what-if sandbox runs a ruleset without side effects, so you can replay historical submissions against a proposed change and compare the outcomes.
Can this run inside our own environment?
Yes. Enterprise includes up to three dedicated hosts deployed into your own Azure subscription, where submission data and execution history never leave your tenant.
Related decisions
Bring us one decision you make by hand
Pick the decision that costs your team the most time and the most argument. In one working session we will model it, run it against your own examples, and show you the trace it produces. If it is not a fit, we will say so.