Business rules management system
Decisions your team can read and your code can call.
Zelquint keeps the rules your business runs on as DMN decision tables. Write them, test them, keep every version, promote them through your environments, and serve every decision from one API.
Matched rule 2
- decision
- "approve"
- rate
- 6.9
| F | creditScore | debtRatio | decision | rate | Note |
|---|---|---|---|---|---|
| 1 | >= 760 | < 0.30 | "approve" | 5.4 | Prime |
| 2 | >= 680 | < 0.36 | "approve" | 6.9 | Standard |
| 3 | >= 620 | < 0.43 | "refer" | null | Manual review |
| 4 | - | - | "decline" | null | Otherwise |
An example decision with hit policy First: the first rule whose conditions all hold gives the result.
Business rules don't belong in if-statements. When a policy lives in code, every change waits for a release and only engineers can read it. Zelquint keeps it in a decision table its owners can change, test and ship.
Out of the codebase
A rule that used to be an if-statement becomes a row in a table, so changing it no longer waits for a release.
In the business's words
Conditions are FEEL, which reads close to the policy it encodes, with ranges, lists and dates built in.
On an open standard
Decisions are DMN, the OMG standard, so the rules you write belong to you and not to one engine or vendor.
A rule's whole life, in one place
Everything between a policy and the answer your service gets: write it, test it, keep each version and promote it through your environments.
Write rules in the browser
Name a decision's inputs and outputs, then add a row per rule with FEEL in every cell. The people who own a policy edit it directly, with no ticket in between.
Test before it ships
Keep sample inputs with the outputs you expect, and run them against every change.
Every version kept
Each change is a new version with its author and a note, and an earlier one is always a step away.
Promote through environments
Each project has its own environments. A version runs in development and staging first, then the same table moves to production, with nothing copied by hand.
Rules that read like the policy
Every condition is FEEL, the expression language DMN defines. Ranges, lists, dates and arithmetic are built in, so a rule says what the policy says.
- Input
- Operator
- Value
- Function
applicant.creditScore in [620..760)
An interval, with each end open or closed.
Seven answers to “which rule wins?”
When more than one rule matches, the table's hit policy decides the result. DMN defines seven, and each decision states the one it uses.
| Policy | Returns | Example |
|---|---|---|
| UUnique | The one rule that matches. Rules never overlap. | "approve" |
| AAny | Any match, when every match gives the same output. | "approve" |
| PPriority | The match whose output ranks highest. | "refer" |
| FFirst | The first match, in the order of the rules. The hero's loan offer uses it | "approve" |
| CCollect | Every match, or their sum, count, minimum or maximum. | [5.4, 6.9] |
| RRule order | Every match, in the order of the rules. | ["approve", "refer"] |
| OOutput order | Every match, sorted by output priority. | ["refer", "approve"] |
One call from any service
Decisions live behind a small HTTP API, so any language that can send JSON can ask Zelquint for an answer.
JSON in, JSON out
Send the decision's inputs as a context and get its outputs back, with the rules that matched.
Keys scoped to a project
Each service gets its own project API key, and revoking one leaves the others working.
A pinned contract
Every request names its API version in a header, so a caller never meets a change it didn't ask for.
MCP for AI assistants
AI tools reach the same projects through Zelquint's MCP server, signing in with OAuth.
curl -X POST "$ZELQUINT_URL/projects/lending/decisions/loan-offer/evaluate" \ -H "Authorization: Bearer $ZELQUINT_API_KEY" \ -H "X-API-Version: 1.0" \ -d '{ "environment": "production", "context": { "creditScore": 720, "debtRatio": 0.31 } }'
200 OK
{ "data": { "outputs": { "decision": "approve", "rate": 6.9 }, "matched_rules": [2] } }
Every change on the record
Rules that move money and access need an owner and a history. Zelquint keeps both for every decision.
- anjust now
analyst@example.comenvironment:update
project/lending/environments/staging
- ow4 min ago
owner@example.comapi_key:manage
project/lending/api-keys/checkout
- ow8 min ago
owner@example.comrole:manage
project/lending/roles/reviewer
- ci12 min ago
ci-deploydecision:publish
project/lending/environments/production
- an16 min ago
analyst@example.comdecision:update
project/lending/decisions/loan-offer
Roles and policies
Owner, editor and viewer roles come built in. Custom roles and policies grant exactly the actions each member needs.
Two-factor sign-in
Members protect their accounts with an authenticator app, with recovery codes for a lost phone.
Project API keys
Each service gets its own key for one project, with an expiry date when you want one.
Audit log
Every change records who made it, what changed and when, for the project and its organization.
Questions, answered
What a BRMS is, how Zelquint fits with the rest of your stack, and who can change what.