Real-time decisioning from edit to live endpoint
Your automated lending policy is written in one tool, tested in another, approved by email and deployed by engineering. Decisimo takes each change from edit to live endpoint in one product.
The path from an edit to the live endpoint
A change reaches the endpoint only as a release, after the checks your team chose. The calling system keeps the same URL.
Author
Build a decision flow from shared rule sets, tables, trees, scorecards, functions and subflows.
Test
Test each artifact with chosen inputs, run the flow in the testing studio and check tables for overlapping rows.
Regress
Save a test run as a regression case and rerun the suite to see what passed, changed or failed.
Assess impact
Run the current and proposed policy on the same rows and keep the decisions that changed.
Compare
Compare releases rule by rule and row by row, then draft release notes from the comparison.
Approve
Use an ordered sign-off sequence where each approval is assigned to a named role.
Release
Deploy the release to the endpoint, which answers calls on the same URL.
Revise
Keep saved revisions with who saved them and when, then compare any two and revert most.
One decision flow joins the parts of a decision
A decision flow joins rule sets and decision tables, decision trees, scorecards, functions, models, data sources, forks and subflows. Shared artifacts can be called by any flow. A model trained in Python, R or Julia can be served as a model step. A fork routes each request by its conditions.
The answer and its reason come back in one call
The endpoint accepts one REST call with JSON in and JSON out. Each decision table row writes a decision and a reason; the caller can request the steps that ran and the rules that fired. Each decision's input and output can be written to the customer's own Postgres database. Every threshold and reason code in the screenshots belongs to a demo case.
Where the endpoint runs and how it calls data
The endpoint runs in a region granted to the account, with production regions in Europe, the United States, Singapore and the Gulf. Data sources in one step are called in parallel, and the step waits for its slowest source. If a source fails, its values remain absent with an error flag for the rules to handle.
Questions we get asked
Can a policy owner change a rule without an engineer?
A policy owner can edit a decision flow and its shared artifacts in the portal. The change can then run through testing, comparison and release before it reaches the endpoint.
How can I run a new policy beside the current one before it decides?
A challenger release runs in shadow on a set share of live requests. Its answers are written to the customer's database and never returned to the caller.
What happens when a data provider fails during a decision?
The source's values remain absent and an error flag is recorded. The rules decide what the missing values mean.
How can I show a reviewer what changed between two releases?
Compare the releases to see added, removed and changed steps, with before and after values for rules, rows and predictors. The comparison supports governance review, with release notes drafted from it.
Can we bring our own model to the endpoint?
A model trained in Python, R or Julia can be uploaded and served over HTTP as a model step. Formula models and tree ensembles can also run inside the engine.
When a decision takes days
Evidence arriving over days or a person’s review belongs in a case rather than one request. The endpoint handles decisions that arrive as one request at a time.
Put your next policy change on its path
Start free to build a decision flow and release it to an endpoint.