> For the complete documentation index, see [llms.txt](https://docs.dinmo.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dinmo.io/intelligence/event-propensity/configure-and-train.md).

# Configure and refresh

Choose the event you want to predict, the prediction period, and the User model containing the profiles you want to score. For example, predict which active subscriptions are likely to receive a cancellation request within the next 30 days.

## Configure the intelligence

Confirm the [data and eligibility requirements](/intelligence/event-propensity/prepare-data.md#eligibility-and-minimum-data-requirements), then make these business choices:

| Choice                   | What it controls                                                                                                                   |
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| Mode                     | Generic mode uses one behavioral Event stream. Subscription mode uses a lifecycle stream, optionally with a behavioral stream.     |
| User model               | Current population eligible for scoring. It does not filter historical training subjects.                                          |
| Event mappings           | Event identity, profile relationship, occurrence time, event names, and physical partition metadata.                               |
| Additional inputs        | Categorical and numeric Event properties authorized and useful for learning. Subscription attributes must be historized.           |
| Target event             | The action to anticipate. Generic targets can be repeatable or first-occurrence only.                                              |
| Horizon                  | A future window of 3–90 days, chosen to leave enough time for the intended action.                                                 |
| Subscription eligibility | The lifecycle movement to predict and eligible subscription states, such as active subscriptions not already pending cancellation. |

For subscription mode, map the Subscription ID and the required start, cancellation-request, and end movements. Include or exclude event values for a clear business reason, not simply to improve a metric.

A target is positive when it occurs strictly after observation time and no later than the end of the horizon: `(t, t + horizon]`. For retention, a well-tracked cancellation request can provide earlier warning than an effective subscription end.

## Review readiness and train

DinMo checks common historical coverage, positive and negative subjects in each period, partition continuity, and input cardinality before fitting a model.

| Readiness | Meaning                                                                                                                 |
| --------- | ----------------------------------------------------------------------------------------------------------------------- |
| `READY`   | Blocking requirements pass; training can proceed.                                                                       |
| `WARNING` | Blocking requirements pass, but recommended levels are not met. Training can proceed; review results before activation. |
| `BLOCKED` | A minimum requirement fails; training stops before model computation.                                                   |

Training uses information available at historical observation dates, calibrates the score, and evaluates the model on later periods not used for fitting. Multiple streams use their common reliable period; earlier lifecycle history remains available to reconstruct subscription state.

Readiness is not a performance approval. Review ranking quality, lift, calibration, class coverage, and important business slices in [Understand performance and scores](/intelligence/event-propensity/understand-scores-and-reasons.md).

## Configure scoring and refresh

1. In **Scope**, select the **User model** containing the profiles you want to score.
2. In **Finalize**, enter an **Engine name** and optionally select **Population fields** to copy alongside the scores for activation.
3. Create the intelligence. DinMo starts training automatically, then calculates the first scores once training succeeds. You do not need to create another prediction after training.

Open **Logs** to follow the training and scoring runs.

To change how often scores are refreshed, open the intelligence overview, update **Score update schedule**, and save. To request a refresh on demand, open the prediction's action menu and select **Run now**. This action is available when no scoring run is already scheduled, queued, or running.

Coordinate source updates, score refresh, and downstream [activation scheduling](/activations/sync-scheduling.md). Refreshing an activation does not itself recompute scores.

## Retraining and configuration changes

Changes to source models, historical inputs, target, horizon, selected model inputs, or lifecycle mappings require full retraining. Changing the scoring population alone does not. A name or description change does not change the learned model.

Retrain when material changes in the business or source data make the learned patterns less representative; monitor the signals described in [Use results and best practices](/intelligence/event-propensity/limits-and-best-practices.md#monitor-and-retrain).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.dinmo.io/intelligence/event-propensity/configure-and-train.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.