What is the main thing BrewSLM adds over your by-hand script?

Explicit stage contracts and an auditable RunEvent for each stage

Which by-hand step maps to the Train stage (08)?

the LoRA Trainer loop (minimal-lora-trainer)

What feeds the observability timeline and failure-cluster surface?

The RunEvent stream emitted by each stage

Which stages did your Track 2 script NOT have?

Introspect, Preflight, and Clean

Track 3 · With BrewSLM · Lesson 1

From script to platform: the BrewSLM lifecycle

After this lesson you can map your by-hand script onto BrewSLM's eleven-stage lifecycle and explain what the platform adds: per-row accountability, gates, and an auditable RunEvent for every stage.

Level: intermediate Read time: ~9 min Prerequisites: Project gallery (Track 2)

In the Track 2 capstone you wrote a single script: load a model, build and tokenize data, train a LoRA adapter, evaluate against a baseline, and ship. That script works — and now you understand every line of it. Track 3 takes that same pipeline and runs it through BrewSLM, so you can see exactly which platform surface stands in for each thing you did by hand, and what it buys you when you do this not once but fifty times.

The eleven-stage lifecycle

Your script had a handful of phases. BrewSLM names eleven explicit stages, each with declared inputs, outputs, a contract, and a RunEvent it emits — no mystery boxes:

01 Ingest        →  pull rows from a source
02 Introspect    →  guess the data's shape
03 Map (dry-run) →  preview the mapping + rejections
04 Map (commit)  →  write mapped rows
05 Clean         →  (optional) PII, quality, chunks
06 Prepare       →  build the manifest + train/eval splits
07 Preflight     →  will this run? memory, deps, gates
08 Train         →  recipe + checkpoints + loss/eval traces
09 Evaluate      →  eval pack + gates decide promotability
10 Export        →  GGUF / safetensors / HF / vLLM
11 Deploy        →  (optional) versioned endpoint + drift checks

From Track 2

Your script maps almost one-to-one: build-a-dataset → Ingest/Map (01–04); tokenize/collate + split → Prepare (06); the LoRA Trainer loop → Train (08); evaluate-by-hand → Evaluate (09); merge-and-ship → Export/Deploy (10–11). The new stages — Introspect, Preflight, Clean — are the safety rails you didn't write.

Every stage emits a RunEvent

The single most important difference from a script is the audit spine. Each stage writes one or more RunEvent rows via emit_event(), with a reason code from a lint-gated taxonomy and a severity (info / warning / error / critical). One stream feeds the observability timeline, the failure-cluster surface, the support bundle, and the audit explorer. When your by-hand script failed, you read a stack trace; when a BrewSLM stage fails, it emits a named event like training_oom that every downstream view picks up automatically.

It starts with a project

Everything in BrewSLM hangs off a project: a base model, its data, its recipes, its experiments, its deployments, and its event history. Where your script kept state in local files and variables, the project is the durable container that makes the pipeline resumable, auditable, and shareable. Create one, point it at a base model, and you're at stage 01.

Key idea

BrewSLM isn't doing anything you didn't do by hand — it's doing the same pipeline with explicit contracts and an audit trail. You learned the internals first precisely so the platform is transparent, not magic. The rest of this track walks the eleven stages in order.

Key terms

BrewSLM lifecycle: The eleven explicit stages from Ingest to Deploy, each with inputs, outputs, a contract, and a RunEvent.
RunEvent: An audit row emitted by a stage (reason code + severity) that feeds every observability surface.
project: The durable container for a base model, its data, recipes, experiments, deployments, and event history.
contract: The declared guarantee of a stage — what it promises about its inputs and outputs.

Check yourself

Answers are saved to this browser.

Progress is stored locally in your browser.