A visual, step-by-step guide to the programming construct that gives compiled LM pipelines a conscience: declare constraints, catch violations, and self-refine — with compliance and quality rising together.
Programmers express constraints with types and asserts. LM pipelines needed the same vocabulary — with retries built in.
hopes. Assertions give them checks: a constraint is a Python expression over a stage's output; when it fails, the pipeline rewinds to the offending stage and retries with the failure feedback injected into the prompt — the model corrects itself, or the escalation continues.
Before Assertions, "the output must be valid JSON with exactly three bullet points" was a sentence inside a prompt — enforced by nothing.
Prose constraints are a style guide mailed to the author — consulted at the author's discretion. Assertions are a spell-checker inside the editor: every violation is caught the moment it's typed, and the cursor jumps back to fix it. The document leaves the room clean.
The paper defines exactly two primitives — and their difference is a policy knob, not a syntax change.
The same violated condition under both flavors — watch the control flow diverge.
Under the hood: a control-flow transform on the pipeline graph — failure propagation with feedback injection.
No human in the loop and no external judge: the pipeline evaluates its own outputs with ordinary Python predicates, then asks the same model to repair its own violation with the message as guidance. Retries escalate with history — second attempts see the first failure.
Hard asserts bound retries (then fail loudly — the contract matters more than completion). Soft suggestions always terminate: refinement is best-effort, and the pipeline proceeds with the best attempt. This asymmetry is the paper's design wisdom: strictness where correctness is contractual, tolerance where it is preferential.
Four case studies in the paper; the headline is the rare double win.
Assertions normalized the idea that reliability constructs belong in the programming model, not the prompt.
The construct is clean; the governance question it opens is not — and the paper is candid about constraint design being a first-class engineering act.
DSPy Assertions' real contribution is a separation of concerns for the reliability layer: WHAT must hold (constraints as reviewable code), HOW failures are handled (backtracking + feedback), and WHEN to be strict (the hard/soft split). The construct is small; the discipline it enables — specs you can read, tests that actually run, hot-spots you can measure — is the beginning of software engineering proper for LM systems.
Check your understanding of the key concepts from the DSPy Assertions paper.
Everything you need to remember about this paper.