Guardrail Loops for LLM Repair

Canonical Field Note: https://nxus.systems/field-notes/guardrail-loops-for-llm-repair

An LLM can give advice that is fluent, plausible, and wrong.

The small example is funny:

I need to get my car washed and the carwash is only 50 meters away. Should I drive there or just walk?

Walking sounds reasonable until you ask what moved. Walking moves the person. It does not move the car.

That is the failure class this Field Note explores. Not bad grammar. Not poor tone. A violated precondition.

The pattern is:

LLM draft
  -> structured facts
  -> inspection selector
  -> selected guardrails
  -> repair packet
  -> revised answer
  -> inspection again

The repair is not the finish line.

The repaired answer still has to pass inspection.

Hybrid Reasoning, Not One Giant Prompt

The important part is not that every answer needs every guardrail. The important part is matching the reasoning mechanism to the failure:

• CLIPS for explicit rules.

• Solver/Z3 for feasibility.

• ZEN for policy decision tables.

• Bayesian Networks for uncertain evidence and review-risk scoring.

The public nxusKit example keeps the scenarios deliberately small:

The same separation maps cleanly onto organizational ownership. Marketing owns coupon policy. Logistics owns pallet constraints. QA or safety owns cold-chain requirements. A platform team owns the loop that turns findings into repair evidence.

That is much better than asking every team to edit one monolithic prompt.

The First Gate Is Structure

The example first turns the model's answer into inspectable facts:

{
  "goal": {
    "object": "car",
    "outcome": "wash",
    "target_location": "car_wash"
  },
  "objects_required": [
    {
      "object": "car",
      "required_location": "car_wash",
      "current_location": "home",
      "present_at_required_location": false
    }
  ],
  "objects_moved": [
    {
      "action_id": "walk-to-car-wash",
      "object": "person",
      "from": "home",
      "to": "car_wash"
    }
  ]
}

Now the workflow is not arguing with prose. It has facts another system can inspect.

The Second Gate Is Repair

The system does not just say "try again." It builds a repair packet from the failed findings. Then it inspects the revised answer too, because repairs can introduce new defects.

That is the part I think teams should take seriously.

If model behavior changes across provider, version, load, context, or runtime settings, the workflow should still show:

• draft answer;

• extracted facts;

• selected inspections;

• failed findings;

• repair packet;

• repaired answer;

• final inspection status.

The final paragraph alone is not enough.

Full Field Note, public example links, and references: https://nxus.systems/field-notes/guardrail-loops-for-llm-repair