Machine Learning

Set the objective. An agent builds, ships, retrains, and grades the model.

Priori Lab turns objectives into deployed models: chargeback risk, lifetime value, churn. The models train on object histories from the context layer, ship into the operational loop, and keep learning from outcomes. This page explains what Lab is and how a model goes from objective to production.

Priori Lab

A Lab notebook with code, charts, and findings — A Lab notebook: code, charts, and the findings a business user can read.

Why your ML never ships

Generic scores never saw your traffic

Off-the-shelf risk scores train on everyone's data. They have never seen your affiliates, your offers, or your dispute history, and the vendor keeps the model, so there is no way to teach them.

The backlog owns the roadmap

A churn model is a quarter of a data scientist's year: feature tables, training runs, deployment plumbing. Most models that would pay for themselves never get built.

Models die in notebooks

The prototype works, the deployment never happens. Without retraining and grading, the few models that ship decay quietly until someone notices the scores are stale.

What Lab is

Lab is a modelling environment on top of the context layer. You set an objective in business terms: predict which purchases will charge back, score lifetime value at signup, flag accounts likely to churn this month.

Features come from the graph. An object's history is already assembled: the user's campaign, purchases, refunds, and message activity are relations, not a feature-engineering project. Models train on your patterns because the graph is your business.

A statistical technique run over a governed dataset: pick the data, set the parameters, watch the run, read the result. The run is recorded.

How a model gets built

An agent does the build inside a notebook you can open and read. The top of every notebook is a business report: what the model predicts, how well, on which data, with charts and numbers rather than a wall of code. The code sits below it for anyone who wants to check the work.

You review the report and approve. The model deploys, retrains on a schedule, and gets graded against real outcomes: predicted chargebacks versus the ones that happened. When performance drifts, the grade shows it before the scores mislead anyone.

One model, readable end to end: the notebook runs live, findings render at the top, the code that produced them sits below, and the run lands in Experiments.

The Experiments ledger: runs with status, metrics, and parameters — Every run in one ledger: status, metrics, and parameters, comparable long after the fact.

In the operational loop

Scores land back on the objects. A purchase carries its chargeback risk, a user carries a lifetime value. From there the rest of the platform picks them up: Lens charts them, Sentry watches them, and Runner acts on them, holding a risky purchase or moving traffic while the numbers still matter.

Model output objects in the query builder, marked with the ML glyph — Predictions where the work happens: model output lands back in the context layer as queryable objects, marked so nobody mistakes a score for a recorded fact.

So what?

You judge traffic before the rebills mature. An LTV score at signup shows which campaigns will pay back, so you scale or cut in week one instead of waiting out the 60-day cohort.
Bad traffic gets cut before its disputes land. Dispute risk scored per sub-ID from refund and engagement patterns flags the sources whose chargebacks are still weeks from settling.
Rebills stay. Rebills are most of the revenue. A churn score flags the user while a save offer still has a chance of working.
One model improves every tool. Scores land on the objects, so Lens charts them, Sentry watches them, and Runner acts on them. Nothing needs an integration.

Book a demo All solutions