Your scoring model in production: from notebook to decision, without rewriting it
How to take your own machine learning model into a live credit policy: Python model upload, versioning, execution as a flow node and custom logic.
Updated July 2026 · 6 min read
In short
You take your own scoring model to production by uploading it to the decision engine and using it as one more node in the policy, with no reimplementation. The engine does not train: it executes pre-trained models, versioned and traceable per decision.
Your data team trains a model that improves predictive power… and that is where the real problem starts: how does it get from the notebook to deciding in production? The traditional answer is a months-long engineering project. The alternative: let the decision engine execute the model as one more node in the policy.
Written bySantiago Etchegoyen · CTO at uFlow
CTO at uFlow. Responsible for the decision engine's architecture: API integration, orchestration of credit bureaus and data sources, running models in production, and platform security.
The last mile of scoring models
The gap between data science and production is where models go to die: reimplementing them in the core systems stack takes months and — worse — introduces the risk that what ships is not exactly what was trained.
uFlow's design principle is a healthy separation of responsibilities: the decision engine does not train models — it executes pre-trained ones. Your data team trains wherever it wants with whatever tooling it prefers; the engine puts those models to work deciding, versioned and traced.
Uploading and versioning the model
Models — classical machine learning, neural networks, statistical models, custom Python implementations — are uploaded as files in the AI models section, with version control and history.
That versioning complements policy and transaction versioning, so you can determine which model version took part in a given decision, according to your traceability configuration. When the regulator asks why the March score differs from the April one, the answer exists.
The model as a node in the policy
Inside the flow, the Model node selects an uploaded model, maps its input features and publishes the results with a configurable prefix. The output — typically a probability or a score — is then used in downstream conditions like any other variable.
The discipline we recommend: the model informs, the policy decides. Wrapping the model output in explicit rules — hard limits, regulatory exclusions, cutoff matrices — keeps the decision explainable even when the core of the scoring is statistical.
Custom logic with Python, in moderation
For transformations, validations or calculations the standard nodes do not cover, the Python node runs your own code: it declares its input variables, operates on them and returns new variables to the policy, with error handling to feed contingency paths.
Moderation matters: the more logic lives in standard nodes — matrices, calculators, decision tables — the more readable and auditable the policy stays for non-technical reviewers. The Python node is the escape hatch, not the default pattern.
Technical documentation
How this is implemented in the engine, step by step.
Common questions
What types of model can the engine execute?+
Pre-trained Python models — from classical machine learning to your own implementations — uploaded in the AI models section and executed as a node in the policy. The specific formats, libraries and limits depend on your platform version and configuration: the details live in the technical documentation.
Does the decision engine retrain or tune the models?+
No — and that is deliberate: the engine only executes pre-trained models. Retraining stays with your data team, with the advantage that deploying a new version means replacing the model file, not reimplementing anything. Comparing a candidate against the incumbent is done with champion/challenger.
Related topics
Champion / Challenger: testing a new credit policy without risking the portfolio
How to evaluate a new credit policy against the one already in production, measuring its real impact on a slice of live traffic before you adopt it.
Model riskModel risk management: governing scoring and ML models in credit decisions
Scoring and ML models sharpen credit decisions but add model risk: bias, drift, weak explainability. Govern them with validation, monitoring and audit trails.
ProductHow the uFlow decision engine does it
Governance, versioning and traceability built into the engine, without slowing the business down.
Explore all guides or read the glossary.
Would this work for your decisioning process?
Transform your credit assessment process with the decision engine.