Explain what Colang is and why NeMo Guardrails uses a DSL rather than Python

Flashcard·Medium·4.0 · 0·~30s·Asked atCharacter Ai Fractal Analytics Hcl

Attempt it

Colang is NVIDIA's domain-specific language for declaring dialog flows and rails: input rails, output rails, retrieval rails, dialog rails, and execution rails. Flows read like a conversational script with natural-language intents (define user ask_for_refund) and named actions. The DSL exists because rails are a policy artefact that non-engineers (security, compliance, product) need to read and review; Python is too expressive and easy to bury intent inside conditionals. Colang's structure makes the rail decision tree auditable, diffable in PRs, and analysable by tooling. The runtime is implemented in Python under the hood.

Your answer

**Colang is NVIDIA's domain-specific language for defining NeMo Guardrails rails.** Rails are policy decisions about what the LLM is allowed to receive, generate, and act on. Colang lets you declare them as flows. A Colang file declares five kinds of rails: - **Input rails**, run on the user's message before it reaches the LLM (PII scrubbing, jailbreak detection). - **Output rails**, run on the model's response before it reaches the user (toxicity check, citation enforcement). - **Retrieval rails**, run on documents pulled by RAG before they enter the prompt. - **Dialog rails**, pattern-match conversation flow against named intents. - **Execution rails**, wrap tool calls with checks and confirmations. A flow reads like a script: ``` define user ask_for_refund "I want a refund" "can I get my money back" define flow handle_refund user ask_for_refund if $user_verified bot offer_refund_process else bot ask_for_verification ``` The value over plain Python is auditability. A security officer, compliance reviewer, or product manager can read the flow above, understand the policy, and approve or reject it. Translate the same logic into Python with nested conditionals and the policy gets buried in implementation detail. NVIDIA chose a DSL specifically so non-engineers can review rails as policy artefacts.

**Colang is a declarative DSL for defining NeMo Guardrails rails, input, output, retrieval, dialog, and execution.** It looks like conversational pseudocode: named user intents, named bot responses, named flows that wire them together. The runtime that executes Colang is plain Python; Colang is the surface humans read and write. The DSL exists because rails are a policy artefact, not a code artefact. The people who need to approve a rail include security, compliance, product, and legal, not just LLM engineers. A Python file expressing the same policy via nested `if`/`elif`/`try`/`except` is unreviewable by that audience. Colang collapses a typical rail into a few lines of declarative flow that maps cleanly to the policy decision being made. The DSL also makes the rail tree analyseable. Because flows are named and intents are explicit, tooling can do things plain Python cannot: enumerate every path through the dialog rails, surface coverage gaps, diff two versions of a policy in PRs, generate test cases from the intent set. NVIDIA can build static analysis on Colang in a way that would be infeasible on arbitrary Python. The trade-off is expressiveness. Colang covers the conversation-flow and rail-decision shape well; for non-rail work (custom retrievers, custom tools) you drop into Python via action handlers. The split is intentional: rails in Colang, implementations in Python. Mixing the two in one language is what you get from older guardrail frameworks, and it is exactly the readability problem Colang exists to solve.

TL;DR

Colang is NVIDIA's declarative DSL for defining NeMo Guardrails rails. The DSL exists so non-engineers can read, review, and audit policy without parsing Python control flow.

Memory aid

Easy to grasp

Imagine an airport with rules about who can fly. You could write those rules as a thick programming book full of loops and if-statements only engineers can read. Or you could write them as a short list: 'if the passenger is on the no-fly list, deny boarding; if they have a valid ticket and pass screening, allow.' Both reach the same decision, but the list is something the safety officer, the airline lawyer, and the regulator can all read. Colang is the second kind. It is a small language for writing the rules that decide what a chatbot is allowed to say and do, written so that people who are not engineers, security, compliance, product owners, can read and audit the policy without learning Python.

Key concepts

Safety and guardrails LLM frameworks

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Colang is the answer to a question most guardrail frameworks never explicitly ask: who reads the rails? In a serious enterprise deployment the answer is not 'just the LLM engineers.' It is security, compliance, product, legal, and sometimes external auditors. If the rails are written in Python, those reviewers cannot read them without learning Python, and the audit story collapses. NVIDIA built a DSL specifically so the policy is legible to its real audience.

The interview question is checking whether you understand this split, that the DSL is not for engineering convenience, it is for non-engineering reviewability. Once you see that framing, the design decisions in Colang (declarative flows, named intents, fixed grammar, Python escape hatch via actions) all line up.

What Colang declares, the five rail types

NeMo Guardrails defines five rail kinds, each running at a fixed point in the request lifecycle, and Colang has syntax for all five.

Input rails fire on the user's raw message before the LLM sees it. Typical uses: PII redaction, jailbreak detection, language gating, profanity filtering. The rail can transform the input, block it entirely, or route it to a refusal flow.

Output rails fire on the model's generated response before the user sees it. Typical uses: toxicity checking, citation enforcement, factual-claim validation against retrieved sources. Output rails are the last line of defence; if they reject, the user never sees the unsafe output.

Retrieval rails fire on documents pulled by a RAG retriever before those documents enter the prompt. This is the indirect-injection mitigation point, sanitise, tag, or block content that looks like it contains injected instructions. A retrieval rail that strips embedded <instruction> tags from web pages is a typical example.

Dialog rails express the conversational state machine. They name user intents, name bot utterances, and wire them via flows. This is the surface most distinctive to NeMo, other guardrail frameworks treat dialog as the LLM's responsibility; NeMo lets you constrain the conversation shape declaratively.

Execution rails wrap tool calls. They run before a tool fires (allowlist check, payload validation, confirmation gate) and after a tool returns (output sanitisation). Execution rails are how Colang handles agent safety.

A Colang file declares any or all of these. Each rail has a matching Python action handler when it needs to do work the DSL cannot express, calling a moderation classifier, hitting a PII detector, but the policy decision of WHEN the rail fires and WHAT happens on a hit lives in Colang.

Why a DSL and not Python

What a Colang flow actually looks like

When the DSL splits cleanly, and when it does not

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

NVIDIA NeMo Guardrails 0.10+ in 2026 ships Colang 2.0 with stronger typing for actions and improved tooling for policy diffing.
Enterprise deployments at financial institutions use Colang files in version control as the auditable policy artefact reviewed by their model-risk committee.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow does Colang's declarative shape help when you need to prove rail coverage to an auditor?

The fixed grammar lets static tooling enumerate every dialog path, every intent, and every rail decision. An auditor can be shown a coverage report generated from the Colang file: which intents are bound to refusal flows, which retrieval rails fire on which document classes, which output rails are unconditional. That kind of report is buildable on a DSL and infeasible on arbitrary Python.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Treating Colang as a 'lite' Python that engineers use because it is easier. The point is the opposite: it is a policy artefact non-engineers must read.

60 second bullets to scan on the way to the call.

The five rail types Colang covers, input, output, retrieval, dialog, execution
Why a DSL over Python, non-engineer audience needs to read policy

Primary sources. Browse if you want the original framing.