Guardrail generator

Fixing one trace is good; preventing the whole class is better. The guardrail generator reads a failure and drafts a policy assertion you can enforce as a runtime guardrail, a replay precondition, and a gate check.

From failure to guardrail

Given a diagnosed failure, Lumni proposes a concrete, checkable rule. Examples:

• False success on refunds → “The agent must not say ‘refund processed’ unless a matching refund_id exists in the system of record.”
• Schema ghost on lookups → “A tool that returns null/empty must not be followed by a model step that states specific values.”
• Missing tool call on cancellations → “A request containing ‘cancel’ must produce a cancel_subscription tool call before any success claim.”

Where a guardrail lives

A single assertion can be used in three places:

Use	Effect
Runtime guardrail	Enforced against live agent behavior
Replay precondition	Part of the pass/fail check when testing a fix
CI gate check	Blocks a candidate version that violates it

Versioning & evidence

Guardrails are versioned. Ingest each revision via /v1/ingest/policies so the evidence ledger always knows which policy version was in force for a given run — essential when an auditor asks “what control was active at the time?”

Drafts, not decrees

Generated guardrails are proposals for you to review and tune. You decide what to enforce and where — Lumni drafts and checks; it doesn’t impose.