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.
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 rather than 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 rather than 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.
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.