Get the decision logic out of your codebase
Credit policy lives in if-statements across three services, a spreadsheet on somebody’s laptop, and one person’s head. Changing a threshold means a ticket, a sprint and a deploy - and nobody can answer what the current policy actually is.
AI-assistedauthoring
Impactanalysis
Approvalbefore release
Decisiontraces
Four things have to be true of decision logic you can run a regulated business on. You have to be able to build it without an engineer, prove a change is safe before it ships, explain any outcome months later, and own what you built.
A credit policy in. A decision flow out.
Ninety seconds, start to finish. The document goes in, the assistant proposes every artifact it intends to build, and a person approves before anything is created.
Transcript
This is a credit policy. Three pages of rules, scoring and pricing. Written by a risk team, not an engineer.
Watch what happens when you hand it to Decisimo.
It reads the document and pulls out every requirement, then works out which ones are rules, which is a scorecard, and which is a pricing tree.
Then it tells you exactly what it will build, and draws the flow before building anything.
Every value is checked back against your document. It cannot invent one.
And nothing is built until you approve it.
Now it builds the real, executable logic.
Open any one of them and the real rules are there, with their real conditions. Age. Sanctions. Affordability. Every one of them editable.
And the pricing tree carries every branch the document described. Loan type, then product category, then amount, with every rate exactly as written.
Every artifact created, from a single PDF. Versioned, testable, ready to review.
With a live endpoint, an API key, and test data drawn from the logic itself.
From a policy document to a running decision flow. No code.
Decisimo. Decision logic that's easy to build, and easy to change.
AI writes the first draft. You approve every line.
Most vendors mean a support chatbot when they say AI. Here it is how the decision logic gets written and maintained - with a human accepting each change.
From a policy document
Upload the credit policy or underwriting manual as a PDF. The system reads it, decomposes the requirements, and proposes a complete decision flow - the rule sets, decision tables, lookups and routing, as real entities ready to review.
Change it in plain language
Every artifact has its own conversation. Describe the change - "add a debt-to-income cut-off of 45% for self-employed applicants" - and the assistant proposes the exact edit against the logic that already exists.
A plan, not a save button
Proposals arrive as a list of discrete changes, each individually approvable, each with a visual diff of exactly what will change. Nothing is applied silently. The human is not a rubber stamp in the flow; the human is the flow.
The artifacts underneath
Rule sets, decision tables with open and closed intervals, decision trees, scorecards, mathematical formula functions, imported ML models, and REST or XML data lookups called in parallel.
It cannot make up your numbers
Every AI proposal is walked by a grounding layer that checks each claimed value - every threshold, limit, identifier and code - against what you actually said and what exists in your data. Anything ungrounded is caught and sent back to be corrected. This is an engineering control, not a prompt instruction, and it is the answer to the first thing a risk buyer thinks about AI-authored policy.
Show the change is safe before it ships
Every change to live decisioning is a risk event. Most teams cannot quantify one beforehand.
- Unit tests on every artifact, with test data generated from the logic’s own thresholds, not hand-written.
- Decision table validation that catches overlapping and unreachable rows before they reach production.
- Regression suites captured from real runs. Save a real execution as a test case, then re-run the suite after any change and see what moved, against which expectation.
- Impact analysis before deploying. Run a scenario set through the current and the proposed logic, and see which decisions change and by how much.
- Champion and challenger on live traffic, so a new policy proves itself before it becomes the policy.
- Approval sequences and computed release diffs. Nothing reaches production outside a release, and the diff is calculated, not remembered.
Answer the question months later
The question is never "do you have logs". It is whether a non-engineer can open one decision and explain it to whoever is asking.
- Step-by-step execution trace. Which steps ran, in what order, what each received and returned, and how long each took.
- Rule-level and scorecard-level explanation. Which rule fired, on which value, from which input path - and every predictor contribution to a score.
- Data transformation traceability. Phase by phase: how many records came in, how many were filtered and why, what was grouped and aggregated, what came out.
- Revision history on every entity. The version of the logic that made a decision six months ago is still there, and still readable.
- Platform audit log. Every view, edit, test, export, deployment and login, with actor, time and IP.
Leave whenever you like
An exit strategy you can put in the file, rather than a promise to help with a migration.
- Decision results in a database you own. Configure a sink to your own Postgres and results are written into a table in infrastructure you control.
- Decision logic exports as a Markdown file. Readable, portable, reviewable - not compiled bytecode you could never reconstruct.
- Execution where you need it. Regional endpoints for latency and residency, or an execution node in your own environment.
- Ordinary integration. REST and JSON in, REST and JSON out. Nothing in your architecture becomes Decisimo-shaped.
- Your data contracts stay yours. Bureau and provider credentials sit in a vault you control, pointing at your own contracts.
What is actually in the box
The full surface, for the evaluation spreadsheet.
| Area | Capabilities |
|---|---|
| Decision artifacts | Rule sets with numeric, text and date comparisons including starts-with and ends-with matching · decision tables with open and closed intervals · decision trees · scorecards · custom functions built as mathematical formulas, without writing code · imported ML models · data objects and attribute vectors |
| Data | REST/JSON and XML data sources called in parallel · OAuth2-authenticated sources · ready-made provider integrations · OCR for document extraction · LLM services callable as part of a flow · JSONPath mapping, timeouts and fallbacks |
| Flow | Visual decision flow builder · conditional branching · champion/challenger forks · components reused across flows |
| Testing and assurance | Unit tests on every artifact · test data generated from the logic’s own thresholds · regression tests captured from real runs · impact analysis over scenario sets · decision table overlap and gap validation |
| Governance | Versioned releases with lineage · computed release-to-release diffs · approval sequences · revision history on every entity · platform audit log · role-based access rights |
| Execution | Regional real-time endpoints · batch over FTP, S3 and GCS · on-premise execution nodes · deployment management |
| Explainability | Step-by-step execution traces · rule-level and scorecard-level explanation · phase-by-phase data transformation traceability |
| Security | Encrypted credential vault with step-up authentication and key rotation · SSO · two-factor · IP restrictions · role-based access · customer-owned result sinks |
| AI | Policy document ingestion and flow proposal · per-artifact conversational authoring with diffs · grounding verification · per-step human approval · generated test data, release notes and explanations |
| Case work | Case files with derived task order · human review, AI, OCR, decision logic, external data and memo tasks · impact analysis across open cases · sandbox testing · immutable case design releases |
Decisions that take milliseconds, and decisions that take weeks
The same artifacts, the same governance, two execution models.
- Real-time decisioning for logic that completes straight through: a request arrives, the flow runs, an answer comes back.
- Case work for decisions that need a person or wait on evidence: the case file accumulates, and re-runs what changed evidence invalidated.
Three different things get called a decision engine
They solve different problems at very different prices. Working out which one is in front of you is most of the evaluation.
The enterprise rules platform
Deep, proven, and designed when the assumption was that IT owned the rules. Powerful enough for almost anything, and it takes a trained specialist to change a threshold. Budget in six figures, implementation in quarters, and a certified partner doing the implementing.
The smart decision table
Quick to start and genuinely pleasant to use. You meet the ceiling the first time you need a model inside the flow, three providers called in parallel, an approval before release, or a regression suite that proves the change was safe.
The well-funded newcomer
Modern, capable and priced for enterprise budgets, usually with a forward deployed engineer to build it with you. That is a consultant by another name, and a dependency that stays on the invoice. Price it at your real decision volume rather than the demo’s, and ask what year two costs.
Where we sit
Enough platform to run regulated decisioning - testing, approvals, traces, releases - operated by the people who own the policy, not by a specialist, at a price a mid-market book can carry. Where the newer platforms send a forward deployed engineer to build it with you, we point the AI assistant at your policy document and your own team approves what it proposes. If you have enterprise budget and an enterprise team, the first category may serve you well. And if your decisions fit comfortably in a decision table, a lighter tool will cost less and take less time to live with. There is no sense paying for governance you do not need yet.
Questions to ask anyone, including us
Every one of these separates the three categories. Ask them in a demo, not in an RFP, and ask to see the answer instead of hearing it.
- Can a risk analyst change a threshold and put it live, without an engineer? Ask to watch someone do it, end to end, in the demo.
- Show me the diff before it saves. If the tool cannot show what is about to change, nobody can approve it.
- Re-run last quarter’s decisions against the proposed logic. Which decisions change, and by how much? A tool that cannot answer this makes every policy change a leap.
- Open a decision from eight months ago and explain it to me. In the interface, without a developer, against the version of the logic that was live at the time.
- New evidence arrives that invalidates a conclusion a case already reached. What happens? If the answer involves a person noticing, that is the answer.
- What is in the contract about leaving? Where do the decision results go, in what format does the logic export, and can execution run in our own environment?
- Who builds the logic, and who maintains it in year two? If the answer is a forward deployed engineer, ask what happens when that engagement ends, and whether your own team can change a rule without them.
- What does this cost at our volume? Not the demo volume. Ask for the number at today’s decisions per month and at three times that.
Longer version: how and why to choose a decision engine.
You can vibecode a rule engine this weekend
True, and not the interesting part. Evaluating conditions against a payload was never the expensive bit, and with an AI pair it is a couple of afternoons. Here is what turns up in month six.
- The analyst still cannot touch it. You have moved the bottleneck from "engineering writes the rules" to "engineering vibecodes the rules". The person who understands the policy is still filing a ticket and waiting.
- One author, no reviewer. Generated code making credit decisions, with the review history of a side project. Six months on, nobody can say why the threshold is 45% or who agreed to it.
- Git history is not decision history. It tells you the code changed. It does not tell you which version of the logic made the decision a customer is complaining about, what data it saw, or which rule fired.
- The assurance is the product. Regression suites captured from real runs, impact analysis before deploy, computed release diffs, approval sequences, and a trace a non-engineer can read. That is the part that takes quarters, and it is the part an auditor asks about.
- Someone has to keep it alive. Bureau APIs change, a model needs swapping, a regulator asks for evidence. That is now your on-call rotation, forever, for a system that decides who gets credit.
Build the engine. That part is genuinely cheap now. Then price the eighteen months of everything around it, and ask who carries it when the person who wrote it leaves.
Questions we get asked
Do we have to use the AI to build decision logic?
No. Everything the assistant proposes can be built by hand in the same editors, and plenty of teams do. The assistant drafts and maintains; it never has the last word.
What stops the AI inventing a threshold?
A grounding layer verifies every value in a proposal against your source document and your data before it is offered to you, and anything ungrounded goes back for correction. Then you still approve it change by change.
How is this different from the rules engine we already have?
Classic engines gave the rules to IT. They also have no AI authoring, no built-in regression testing, no impact analysis, no computed release diff, and no trace a non-engineer can read.
Why not build this in-house?
You will build the engine in a quarter. You will not build the versioning, approvals, regression suites, impact analysis, trace UI and grounding checks - and those are the parts an auditor asks about.
Can a non-engineer really change production policy?
That is the design. A risk analyst edits the logic, runs the regression suite, reads the impact analysis, and submits it to the approval sequence you defined. Engineering integrated once.