Welcome to the fifth and final lesson of our journey in Laying the Foundations for Code Translation with Haystack! At this point, you've already built a pipeline that can clean up messy inputs, translate code between languages, and generate clear explanations. It's now time to address a crucial aspect: protecting our system from misuse. In this lesson, you'll learn how to add guardrails that keep your code translator focused on its intended purpose and safe from exploitation. Get ready!

Before we dive into implementation, let's build some intuition around why guardrails are so important for LLM-powered systems. Large language models are incredibly flexible, but that flexibility can be a double-edged sword. For example, users might try to:

• Trick the system into ignoring its instructions (prompt injection);
• Use the translator for general text generation instead of code translation;
• Overload the system with irrelevant or malicious requests.

Without proper safeguards, your code translator could end up doing things it was never meant to do. Guardrails act as intelligent filters, ensuring that only genuine code translation requests are processed. This not only protects your resources but also helps maintain a clear, reliable user experience.

The first step in building our guardrail is to detect whether a user's input actually contains code. For this, we'll create a custom component that uses an LLM to classify each input as either "accepted" (contains code) or "rejected" (does not contain code).

This class sets up the LLM we'll use for classification. Now, let's add the method that actually performs the check:

Here, we craft a precise prompt for the LLM, instructing it to be strict about what counts as code. The method then processes the model's response, making sure only valid labels are returned. This approach leverages the LLM's understanding while keeping our system's behavior predictable.

Once we can classify inputs, the next challenge is to route them appropriately. We want code-containing inputs to proceed to translation, while everything else should be stopped early. Haystack's ConditionalRouter component is perfect for this job.

This router checks the classification result. If the input is "accepted," it passes the original text along the "allow" path. If "rejected," it sends a simple "reject" message. This branching ensures that only valid requests reach the translation logic, while others are filtered out efficiently.

Now, let's see how these components fit into the overall pipeline. The key is to connect the classifier and router at the very start, so every input is checked before any translation work happens.

With these connections, the pipeline first classifies the input, then routes it based on the result. Only inputs that pass the guardrail continue to the preprocessor and translation steps. This structure keeps your system secure and efficient, as invalid requests are stopped right at the entrance.

It's important to provide clear feedback when a request is rejected. In our translation function, we check the pipeline's output to determine whether the request was processed or blocked:

Let's break down this updated snippet:

• The pipeline is initialized and executed with the given input_data.
• If the input passes the guardrail (i.e., is classified as "accepted"), it continues through the pipeline, eventually reaching the translation and postprocessing steps.
• In this case, the pipeline output will include a "postprocessor" key, and the translation result will be available under result["postprocessor"]["result"].
• If the input is blocked by the guardrail (i.e., classified as "rejected"), the pipeline halts early and does not execute the translation or postprocessing steps. As a result, the output will not contain the "postprocessor" key.
• Therefore, checking for the presence of "postprocessor" in the result is functionally equivalent to checking whether the guardrail allowed the request to proceed.

This approach keeps the code simple and robust, while still providing clear and consistent feedback to the user.

Congratulations—your code translation system is now equipped with smart, LLM-powered guardrails! By combining precise input classification and conditional routing, you’ve built a translator that’s not just powerful, but also safe and focused on its true purpose. This is a major milestone: your pipeline can now stand up to tricky inputs and stay on track, no matter what comes its way.

Up next is the practice section, where you’ll get hands-on experience reinforcing these guardrails and seeing them in action. Once you’ve completed the exercises, you’ll have wrapped up this foundational course—well done! But the journey doesn’t stop here. In the next course, you’ll take your protected translation system to the next level by exposing it through a web API, making it ready for real-world use. Get ready to unlock even more possibilities!