A Lightweight Rule Engine

Policy as data

Rather than scattering guardrail logic as ad-hoc if statements throughout application code, store the actual rules as data - in a JSON or YAML file - so that reviewers who aren't necessarily deep in the codebase can still read, understand, and meaningfully version the policy itself, entirely separately from the enforcement algorithm that applies it. A small rule engine then loads that configuration file, validates it against an expected schema, applies each relevant rule to the request or response in turn, and returns a decision along with a stable, machine-readable reason code - something like too_long, blocked_pattern, or bad_status - rather than only a free-text explanation that's harder to build reliable metrics or tests around.

{
  "input": { "max_chars": 2000, "blocked_patterns": ["ignore previous instructions"] },
  "output": { "required_keys": ["answer", "status"], "allowed_status": ["ok", "error"] }
}

This platform's own labs use what's referred to as a NeMo-Guardrails-style engine - deliberately not the real NeMo Guardrails library itself. NeMo Guardrails is a genuinely capable, full-featured conversational safety framework used in real production systems, but its broad integration surface and dependency footprint would be disproportionate for isolated, short exercises running on a shared two-CPU lab host. This platform's small engine teaches the same core underlying pattern - declarative rails wrapped around model input and output, expressed as reviewable configuration rather than scattered code - using nothing but Python's standard library, with fully transparent, inspectable behavior.

Note: The word "style" here is doing real, deliberate work: this lab makes no claim of API or configuration compatibility with the actual NeMo Guardrails project. A production team evaluating real guardrail tooling should look directly at the genuine framework, weigh their actual policy needs, check which models it supports, and budget for its real dependency footprint and ongoing operational cost.

Whatever engine is actually used, validate its configuration file fully at application startup, not lazily the first time a rule happens to be needed. An unknown rule name, an invalid regex that fails to compile, a missing required object, or an internally impossible limit (like a maximum smaller than a minimum) should all prevent the service from reporting itself ready, rather than silently disabling protection and continuing to run unguarded. Keep genuinely safe defaults hard-coded, and when merging multiple applicable rules, always resolve conflicts toward the least permissive outcome.

Tip: Stable, fixed reason codes like too_long or bad_status are far safer to build metrics dashboards and automated tests around than parsing a human-readable sentence that might get reworded later. Any user-facing explanation text can always be derived by mapping from those stable codes afterward, rather than the other way around.