Skip to main content
If you call an LLM on every ticket, message, document or event to classify it, you are running the pipeline Brussle replaces. That pipeline includes a queue, workers, retries, a cache, a schema, versioning, cron jobs and evaluation. This guide moves one workload over. It assumes you have labelled examples of what the classifier should say.

​
1. Measure accuracy on your own data first

The engine is not your current classifier, and yours is the only data that decides whether it is good enough. Before you migrate anything, compare the engine against your current classifier on your labelled examples. We run this with you: send us the labelled set and your current classifier’s outputs, and you get back the engine’s accuracy on your data, and what judging it would cost, next to your incumbent. If the engine loses on your data, stop there. You can also measure it yourself: write the labelled documents to a namespace, post the labels as outcomes, and read the judgment’s calibration report.

​
2. Turn each prompt into a judgment

Most classification prompts map onto one of three types: Move the prompt’s instructions into question and criteria, and the parts of the record it reads into a context recipe. Prompts that sent the same record for five separate classifications become five judgments that share one recipe, which are answered together. The engines cannot abstain. A choice judgment always gets a none_of_the_above escape option, and its probability comes back as escape_p. Use it where your prompt said “otherwise, answer other”.

​
3. Mirror your writes

Send every create, update and delete from your system of record to the write API. Upsert whole records after each change, as in keep your data in sync; writes are idempotent, so your sync can retry freely. Documents stay yours: Brussle is not your system of record. To load the records you already have, see import existing data. Choose each judgment’s freshness policy. A judgment your pipeline ran on every change, whose results you filter on, is on_change. One you only show on a detail page can be on_read, which costs nothing until someone looks.

​
4. Backfill with the estimate in front of you

Existing records have no answers yet. Ask for a backfill estimate first:
The estimate shows the duration next to the cost, because engine rate limits can make large backfills take days. Set a namespace budget, then confirm.

​
5. Compare, then cut over

Run both systems side by side on live traffic. Query where they disagree, and open a few of those documents in the dashboard to see the exact context the engine saw and its raw output. Tune thresholds on the answers you now have, not on a new prompt. With 100 or more outcomes, 20 of each kind, the threshold recommender (Team and above) picks one for a precision or recall target. To cut over, read answers from queries or from a get of the document. Don’t make a user’s request wait for a new answer: wait_for on a write is for scripts and tests. See tradeoffs. Then turn off the old pipeline. Every answer from then on is versioned and kept with the context that produced it.