docs(iorails): Use Guardrails entry-point not IORails

[tgasser-nv]

Description

The docs contained several references to creating IORails(config) directly. IORails shouldn't be created directly in this way, there are two possible options:

1. Backwards-compatible: Existing apps importing LLMRails, which is redirected to Guardrails when the NEMO_GUARDRAILS_IORAILS_ENGINE=1.
2. New apps: Use the Guardrails wrapper with use_iorails set. This will use IORails if possible, falling back to LLMRails if needed.

Related Issue(s)

VDR Issue 8

Checklist

• I've read the CONTRIBUTING guidelines.
• I've updated the documentation if applicable.
• I've added tests if applicable.
• @mentions of the person or team responsible for reviewing proposed changes.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR updates documentation across observability and troubleshooting guides to reflect the newer IORails routing pattern. The OpenTelemetry integration example now shows Guardrails(config, use_iorails=True) instead of direct IORails(config) instantiation. Troubleshooting guidance is updated to clarify telemetry setup prerequisites and explain that metrics are emitted only by the IORails engine.

Changes

OpenTelemetry and Metrics Documentation

Layer / File(s)	Summary
Updated OpenTelemetry console integration example docs/observability/metrics/opentelemetry-integration.md	Console output example updated to import Guardrails from nemoguardrails.guardrails.guardrails and construct it with Guardrails(config, use_iorails=True), replacing the direct IORails(config) pattern.
Updated metrics troubleshooting guidance docs/troubleshooting.md	Troubleshooting sections updated to instruct calling set_meter_provider(...) before constructing Guardrails(config, use_iorails=True) (or LLMRails(config) with NEMO_GUARDRAILS_IORAILS_ENGINE=1). Clarified that metrics are emitted only by the IORails engine and that synchronous generate() disables telemetry for an ephemeral engine.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 6

✅ Passed checks (6 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: updating documentation to recommend using the Guardrails entry-point instead of directly instantiating IORails.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Test Results For Major Changes	✅ Passed	This PR contains only documentation changes (two .md files). No source code or functionality changes. Documentation-only updates are minor per the check criteria and do not require test results.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch docs/iorails-entry-point

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

Documentation preview

https://nvidia-nemo.github.io/Guardrails/review/pr-1892

[greptile-apps]

Greptile Summary

This PR updates two documentation files to replace direct IORails(config) construction examples with the correct entry points: Guardrails(config, use_iorails=True) for new apps, and LLMRails(config) with NEMO_GUARDRAILS_IORAILS_ENGINE=1 for backwards-compatible apps. Prose references to IORails as a class name are consistently replaced with "IORails engine".

• opentelemetry-integration.md: Import and construction updated in the Console Output example; "IORails emits" wording updated to "the IORails engine emits". One phrase ("IORails metrics") on line 151 was not updated.
• troubleshooting.md: All troubleshooting steps updated to reference both entry points; section headers and description text updated to use "IORails engine" terminology throughout.

Confidence Score: 5/5

Documentation-only change; no runtime code is modified and the updated examples accurately reflect the available entry points.

Both files contain only prose and code-example updates. The changes are consistent with the described intent and the actual codebase entry points.

No files require special attention beyond the minor missed phrase in opentelemetry-integration.md.

Important Files Changed

Filename	Overview
docs/observability/metrics/opentelemetry-integration.md	Prose and code example updated from IORails(config) to Guardrails(config, use_iorails=True) with corrected import. One "IORails metrics" phrase on line 151 was not updated, and the import uses an internal module path not in the public API.
docs/troubleshooting.md	All IORails direct-construction references updated to document both Guardrails(config, use_iorails=True) and the LLMRails/NEMO_GUARDRAILS_IORAILS_ENGINE=1 backwards-compatible path. Terminology consistently updated to "IORails engine".

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Application] --> B{Entry Point Choice}
    B -->|New Apps| C["Guardrails(config, use_iorails=True)"]
    B -->|Backwards-Compatible| D["NEMO_GUARDRAILS_IORAILS_ENGINE=1 + LLMRails(config)"]
    C --> E[Guardrails wrapper]
    D --> F["LLMRails redirected to Guardrails wrapper"]
    E --> G{IORails available?}
    F --> G
    G -->|Yes| H[IORails engine - emits OTel metrics]
    G -->|No| I[LLMRails engine - no metrics]
    H --> J[generate_async / stream_async]
    I --> J

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
docs/observability/metrics/opentelemetry-integration.md:151
One residual "IORails" reference was missed in this section header sentence. The surrounding sections were updated to use "IORails engine" or "Guardrails", but this line still says "IORails metrics" as a noun, inconsistent with the rest of the PR.

```suggestion
You can export IORails engine metrics to any backend that accepts OpenTelemetry metric data, including:
```

### Issue 2 of 2
docs/observability/metrics/opentelemetry-integration.md:86
**Internal import path in public documentation**

`Guardrails` is imported directly from `nemoguardrails.guardrails.guardrails`, which is an internal module that does not appear in `nemoguardrails.__all__` and is not re-exported by the `nemoguardrails.guardrails` subpackage. Readers following this example are effectively depending on an undocumented internal path. If `Guardrails(config, use_iorails=True)` is the intended public entry point for new apps, it should be added to `nemoguardrails/__init__.py` and `__all__` so that `from nemoguardrails import Guardrails` works.

_{Reviews (3): Last reviewed commit: "Greptile feedback" | Re-trigger Greptile}