Model Instances

A Model Instance is a specific configured and running version of an AI model type in your workspace. Think of it as one deployed model with a specific purpose — for example, "Purchase Prediction for B2C customers" or "RFM segmentation — last 12 months".

Running multiple instances of the same model type

You can run multiple instances of the same model type in parallel. Each instance has its own:

• Configuration (different data sources, target actions, parameters).
• Output fields (named after the instance, visible in the audience builder).
• Daily run schedule.
• Status lifecycle.

Example: you might run three Action Prediction instances — one predicting purchase, one predicting renewal, and one predicting churn — each with different training definitions.

Naming your instances

Choose descriptive names that make it clear what the model predicts. The name you give an instance becomes part of how its output fields appear in the audience filter builder.

Good examples:

• purchase_prediction_ecommerce
• rfm_365d
• ltv_6m_subscribers

Training results

For predictive model types (Action Prediction and pcLTV), BPP stores training performance metrics after each successful run. You can view these on the model instance detail page in the "Training results" section:

• Action Prediction: accuracy metrics, feature importance rankings (which input variables mattered most), and examples of the strongest positive/negative signals.
• pcLTV: performance metrics for the LTV prediction.

These results help you assess how reliable the model is and which customer attributes drive the predictions.

Prediction results

For every Action Prediction, RFM and pcLTV model, BPP stores the latest prediction results after each successful run. You can view these on the model instance detail page in the "Predictions results" section:

• Action Prediction: current status (total users, analyzed users, likely to succeed, predicted success rate) with the probability distribution, plus a monthly evolution chart of analyzed users and predicted success rate.
• pcLTV: current state metrics (analyzed users, min / median / max pcLTV) with the pLTV distribution, four value tiers (top, high, mid, low) breaking down customers by predicted Lifetime Value, and a monthly trend of the average pcLTV.
• RFM: KPI cards for best, at-risk, lost and new customers, a 27-cluster RFM grid (Recency × Frequency × Monetary) with descriptive statistics per cluster, and a trend chart of macro-segment sizes over time.

These dashboards show how your customer base is composed today and how it evolves.

AI-powered analytical report

Each model instance can generate an Agentic Data Analysis — an automated analytical report summarising what the model found. This includes:

• Cluster descriptions and what distinguishes each segment.
• Actionable insights and recommendations based on the model output.
• Distribution of scores or segments across your customer base.

Status transitions

From status	To status	What BPP does
Draft	Ready	Creates automated job resources, sets up output tables, activates the daily schedule.
Ready / Complete	Suspended	Pauses the daily schedule — no new runs.
Suspended	Ready	Resumes the daily schedule.
Any status	Draft	Removes the automated job resources (but keeps the output data).
Running	Complete	Makes the model's output fields visible in the audience and signal builders.
Running	Error	Records the error message — output fields remain as they were.

Note: output data in your data warehouse is never automatically deleted when an instance is deactivated or deleted. Your historical model results are preserved.

Best practices

• Name instances descriptively so you can identify them in the audience builder without guessing.
• Keep instances in Draft until you are ready to activate them — Draft instances use no compute resources.
• Before deleting an instance, check whether any active audiences or signals are filtering on its output fields. Deleting the instance removes those fields from the filter picker and will break those audiences.
• Use Duplicate (if available) to safely experiment with configuration changes without affecting a running instance.