Match each NeMo Guardrails rail type to its job

**NeMo Guardrails** is NVIDIA's open-source framework for putting safety checks around an LLM application. It organises checks into five different rail types based on where in the request flow they run. **Input rails** run first. They inspect the user's incoming message, flag jailbreak attempts, redact PII, refuse off-topic requests, before the model ever sees the input. Cheap and fast classifiers usually live here. **Output rails** run after the model generates a response. They check the output for toxicity, sensitive data, hallucinated citations, or unsafe content before the user sees it. **Retrieval rails** sit inside the RAG path. When the retriever returns documents, this rail can filter, redact, or sanitise them before they enter the model's context. Defends against indirect injection from poisoned documents. **Dialog rails** shape the conversation itself. They say things like 'this assistant only answers questions about cooking' or 'if the user asks about medical dosing, hand off to a human.' They are about scope and flow, not just one message. **Execution rails** wrap tool calls. Before the agent calls a tool, book a flight, send a refund, query a database, this rail runs pre and post checks: is this action allowed, are the arguments valid, do we need human confirmation? Five moments, five rails. Stacking them together is how you build defence in depth.

**NeMo Guardrails** uses Colang, a small declarative language, to define rules that run at five distinct points in the request lifecycle. The point is defence in depth: no single check catches everything, so different rails address different risk classes at the moment they are best caught. **Input rail**, runs on the raw user message. Typical checks: jailbreak detection, prompt-injection patterns, PII scrub, off-topic refusal. Cheap classifiers (Llama Prompt Guard, regex, a small NeMo model) live here. **Output rail**, runs on the model's generated response. Typical checks: toxicity, hallucination patterns, PII leak, off-policy advice, structural validation against an expected schema. Heavier checks are fine here because output is on the critical path only once per turn. **Retrieval rail**, runs on the retriever's results before they enter the LLM context. Typical checks: filter out documents the user is not authorised to see, scrub embedded instructions (indirect-injection defence), drop low-confidence retrievals. Treating retrieved content as untrusted is the central insight. **Dialog rail**, runs at the conversation level, not one message. Defines `flows` in Colang: 'when user asks about competitors, deflect gracefully'; 'if conversation drifts to medical advice, hand off.' These rails encode product-policy decisions. **Execution rail**, wraps tool calls. Before dispatch: validate arguments, check allowlist, require human confirmation for irreversible actions. After dispatch: validate the result before feeding it back into the model. The rails compose. A single request typically traverses input rail, then dialog rail, then (if RAG) retrieval rail, then model, then output rail, then (if tool call) execution rail, then return.