RHOAIENG-37346:Refactor Guardrails for Safety JTBD #1036
Conversation
WalkthroughRemoved a legacy Guardrails Orchestrator assembly and several legacy modules; added new AI-safety landing pages, Guardrails assemblies, deployment/configuration/detector/gateway reference docs and procedures; renamed/retitled multiple modules; introduced SAFE_LABELS and expanded orchestrator/gateway/TLS/OTel configuration schemas. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Client
participant Gateway
participant Orchestrator
participant RegexDetector as Regex Detector
participant HFDetector as HF Detector
Note over Client,Gateway: Client submits content or chat request
Client->>Gateway: POST /v1/chat (preset endpoint)
alt Gateway enforces preset
Gateway->>Orchestrator: forward request / apply preset pipeline
else Direct to Orchestrator
Client->>Orchestrator: POST /orchestrator (content)
end
par Parallel detectors
Orchestrator->>RegexDetector: POST /api/v1/text/contents (payload)
Orchestrator->>HFDetector: POST /api/v1/text/contents (payload)
and Responses
RegexDetector-->>Orchestrator: detection JSON
HFDetector-->>Orchestrator: detection JSON
end
Orchestrator->>Gateway: aggregated enforcement decision
Gateway->>Client: final response (allowed / flagged / blocked)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
modules/using-a-hugging-face-prompt-injection-detector-with-the-guardrails-orchestrator.adoc (1)
4-5: Update module ID to reflect the new title for consistency.The title has been updated to emphasize the safety outcome ("Preventing Prompt Injection"), but the ID on line 4 still reflects the old phrasing ("using-a-hugging-face-prompt-injection-detector-with-guardrails-orchestrator"). For consistency and maintainability, consider updating the ID to reflect the new title.
-[id="using-a-hugging-face-prompt-injection-detector-with-guardrails-orchestrator_{context}"] +[id="preventing-prompt-injection-using-hugging-face-detector_{context}"]
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
assemblies/configuring-the-guardrails-orchestrator-service.adoc(1 hunks)modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc.adoc(1 hunks)modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc(1 hunks)modules/using-a-hugging-face-prompt-injection-detector-with-the-guardrails-orchestrator.adoc(1 hunks)
🔇 Additional comments (3)
modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc (1)
4-5: Verify that the main assembly references this updated module ID.The title and ID have been updated to emphasize the safety outcome ("Filtering flagged content") rather than the operation. Ensure the main assembly file (
configuring-the-guardrails-orchestrator-service.adoc) includes this module using the updated ID.modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc.adoc (1)
6-11: Enhanced abstract and prerequisites strengthen production-readiness messaging.The expanded abstract clearly articulates the use of preset guardrail pipelines for consistent safety policies in production, and the new Prerequisites section appropriately establishes that the guardrails gateway image must be configured beforehand. These changes align well with the PR's focus on safety-outcome messaging.
assemblies/configuring-the-guardrails-orchestrator-service.adoc (1)
4-11: Update assembly ID and verify title reflects safety-outcome JTBD messaging.The ID and title have been successfully updated from an operational focus ("Configuring") to a safety-outcome focus ("Enable AI safety"). This aligns well with the PR objectives. Ensure external cross-references and inbound links are updated accordingly, as this is a high-traffic assembly page.
assemblies/configuring-the-guardrails-orchestrator-service.adoc
Outdated
Show resolved
Hide resolved
assemblies/configuring-the-guardrails-orchestrator-service.adoc
Outdated
Show resolved
Hide resolved
...drails-enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc
Outdated
Show resolved
Hide resolved
skrthomas
force-pushed
the
RHOAIENG-37346
branch
2 times, most recently
from
98b8888 to
75dbb24
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
assemblies/configuring-the-guardrails-orchestrator-service.adoc (1)
49-56: Fix critical include file reference with duplicate.adocextension.Line 55 must reference a file with one of the recognized AsciiDoc extensions (.asciidoc, .adoc, .ad, .asc, or .txt). The current reference includes a duplicate extension:
include::modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc.adoc[leveloffset=+1]This will cause the include directive to fail during documentation builds, as the file path is malformed. Additionally, line 54 uses
leveloffset=+2for the regex detector while lines 52–53 useleveloffset=+1, creating an inconsistent heading hierarchy within the same section.Apply this diff to fix the file reference and standardize leveloffsets:
include::modules/guardrails-orchestrator-hap-scenario.adoc[leveloffset=+1] include::modules/using-a-hugging-face-prompt-injection-detector-with-the-guardrails-orchestrator.adoc[leveloffset=+1] -include::modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc[leveloffset=+2] -include::modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc.adoc[leveloffset=+1] +include::modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc[leveloffset=+1] +include::modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc[leveloffset=+1]
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
assemblies/configuring-the-guardrails-orchestrator-service.adoc(1 hunks)modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc.adoc(1 hunks)modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc(1 hunks)modules/using-a-hugging-face-prompt-injection-detector-with-the-guardrails-orchestrator.adoc(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc
🚧 Files skipped from review as they are similar to previous changes (1)
- modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc.adoc
🔇 Additional comments (4)
modules/using-a-hugging-face-prompt-injection-detector-with-the-guardrails-orchestrator.adoc (1)
4-5: Heading change improves the preventive posture of the module.The updated heading shifts from a neutral/descriptive tone ("Using...") to an action-oriented, safety-focused tone ("Preventing..."), which better aligns with the PR objectives to emphasize AI safety practices. The change is clear and effective for users seeking guidance on prompt injection prevention.
Note: The module ID at line 4 (
using-a-hugging-face-prompt-injection-detector-with-guardrails-orchestrator_{context}) was not updated to reflect the new heading. If backward compatibility with existing links is not required, consider updating the ID to match the new heading (e.g.,preventing-prompt-injection-with-hugging-face-detector_{context}). Otherwise, this is a non-issue.assemblies/configuring-the-guardrails-orchestrator-service.adoc (3)
4-5: Assembly title and ID updated to emphasize safety-first approach.The assembly-level title and ID changes align well with the PR objectives. The new title "Enabling AI safety with Guardrails" and ID
enable-ai-safety-with-guardrails_{context}better communicate the purpose and focus of the documentation section.
11-35: Content restructuring improves clarity on Guardrails components.The reorganization from a concise detector listing to descriptive component descriptions (Deploy, Configure & Use, Monitor, Enable OpenTelemetry) provides users with a clear roadmap of what they can accomplish. This is a solid documentation improvement that sets expectations upfront.
40-47: Verify intentionality of leveloffset hierarchy for detector/gateway modules.Lines 44–46 use
leveloffset=+2, creating a sub-subsection level under "Deploying and Configuring Guardrails components," while lines 40–43 useleveloffset=+1. This creates a heading hierarchy where built-in detectors, Hugging Face models, and gateway configuration are visually nested deeper than the Orchestrator deployment itself.If this nesting is intentional (to group detector/gateway topics as child topics of deployment), the current structure is correct. However, if these modules should be peer topics at the same level as the Orchestrator, use
leveloffset=+1consistently.Please confirm whether the
leveloffset=+2on lines 44–46 is intentional to create a sub-topic hierarchy, or should be changed toleveloffset=+1for consistency with sibling modules.
assemblies/configuring-the-guardrails-orchestrator-service.adoc
Outdated
Show resolved
Hide resolved
| ifdef::context[:parent-context: {context}] | ||
| [id="using-a-hugging-face-prompt-injection-detector-with-guardrails-orchestrator_{context}"] | ||
| = Using a Hugging Face Prompt Injection detector with the Guardrails Orchestrator | ||
| = Preventing Prompt Injection by using a Hugging Face Prompt Injection detector |
There was a problem hiding this comment.
If this title is OK, I'll go ahead and update the id=, but that creates a kind of pain of needing to update it in multiple places, so I want to be sure the titles are okay from stakeholder POV before I make deep changes.
There was a problem hiding this comment.
"Mitigating" is usually a safer word. "Preventing" is stronger and may not be 100% guranteed.
| [id="configuring-the-guardrails-orchestrator-service_{context}"] | ||
| = Configuring the Guardrails Orchestrator service | ||
| [id="enable-ai-safety-with-guardrails_{context}"] | ||
| = Enabling AI safety with Guardrails | ||
|
|
||
| The TrustyAI Guardrails Orchestrator service is a tool to invoke detections on text generation inputs and outputs, as well as standalone detections. |
There was a problem hiding this comment.
Do we want to leave this mention of "TrustyAI Guardrails" here? Or remove the "TrustyAI" bit?
There was a problem hiding this comment.
So in the spirit of decoipling function from tool. Whenever we have to refer to something concrete, we can reference the tool that does the function.
In this case, the phrasing looks okay here but ti will be important to always communicate "tool x makes function y happen" in this case, maybe a blurb on how the trustyAI orchestratore service helps with enabling AI safety with guardrails.
There was a problem hiding this comment.
So, a potential updated text might read: " The Guardrails Orchestrator is a service included in TrustyAI to perform detections on text generation inputs and/or outputs." ?
skrthomas
force-pushed
the
RHOAIENG-37346
branch
2 times, most recently
from
24ecbd0 to
c694fa9
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc (1)
4-4: Unresolved: Update ID to follow AsciiDoc lowercase convention.The ID still contains mixed-case "LLM", which deviates from AsciiDoc ID conventions (all lowercase with hyphens). This was flagged in a previous review and needs to be corrected for consistency across the documentation.
Apply this diff:
-[id="enforcing-configured-safety-pipelines-for-LLM-inference-using-guardrails-gateway_{context}"] +[id="enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway_{context}"]
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
assemblies/configuring-the-guardrails-orchestrator-service.adoc(1 hunks)modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc(1 hunks)modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc(1 hunks)modules/using-a-hugging-face-prompt-injection-detector-with-the-guardrails-orchestrator.adoc(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc
- modules/using-a-hugging-face-prompt-injection-detector-with-the-guardrails-orchestrator.adoc
🔇 Additional comments (3)
assemblies/configuring-the-guardrails-orchestrator-service.adoc (3)
7-7: Unresolved: Address user question about "TrustyAI" branding.A previous reviewer asked whether to retain or remove the "TrustyAI" reference here. Please clarify the documentation's branding approach: should this mention "TrustyAI Guardrails" or just "Guardrails Orchestrator"?
44-44: Verify leveloffset hierarchy for sub-modules.Lines 44 and 54 use
leveloffset=+2while most sibling modules in the same sections useleveloffset=+1. This creates deeper nesting for those modules. Confirm this is intentional (i.e., the built-in detector and regex detector are genuinely sub-topics) or standardize to+1for consistency.If these should be at the same level as their siblings, apply this diff:
-include::modules/configuring-the-built-in-detector-and-guardrails-gateway.adoc[leveloffset=+2] +include::modules/configuring-the-built-in-detector-and-guardrails-gateway.adoc[leveloffset=+1]-include::modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc[leveloffset=+2] +include::modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc[leveloffset=+1]Also applies to: 54-54
55-55: Fixed: File extension and include reference corrected.The include statement now correctly references the module file with a single
.adocextension. The previous double extension issue has been resolved. ✅
modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc
Outdated
Show resolved
Hide resolved
skrthomas
force-pushed
the
RHOAIENG-37346
branch
2 times, most recently
from
c464d0a to
5212a44
Compare
|
@zanetworker @RobGeada PTAL at this PR for the Guardrails refactoring and let me know your thoughts/comments/feedbacks |
|
Do we have llama stack with guardrails here somewhere? LLama stack will need to interlink between the llama stack docs and our safety docs. |
| [id="configuring-the-guardrails-orchestrator-service_{context}"] | ||
| = Configuring the Guardrails Orchestrator service | ||
| [id="enable-ai-safety-with-guardrails_{context}"] | ||
| = Enabling AI safety with Guardrails |
There was a problem hiding this comment.
I'd stop an Enabling AI Safety, then guardails be hover, metadata, subtitle as discussed.
There was a problem hiding this comment.
Potentially Guiardrails would be one sub topic in the future (not the only thing to do in AI safety, amongst others like safety validation, safety hub, etc).
There was a problem hiding this comment.
I think for the sake of our file architecture, since we have the topmost book as Enabling AI Safety, i.e. the tile you see on the main docs page, we have to keep this name/id distinct, so I think we have to include "with guardrails" so that we have some unique IDs.
There was a problem hiding this comment.
I'd then vote for removing (with guardrails) so that when they click on Enable AI safety, they can find examples of guardrails. Just trying to not pin us down to "just" guardrails because there will be more. If other folks have strong opinions, we can discuss how we plan on moving/restructuring for the future.
There was a problem hiding this comment.
I see it looks like this, if "Enabling AI Safity" is what appears when I go to RHOAI docs high-level, then great, then we drill into enabling/using as you have it.
There was a problem hiding this comment.
Ok perfect, that is how we have it then. I think this works.
| ifdef::context[:parent-context: {context}] | ||
| [id="using-a-hugging-face-prompt-injection-detector-with-guardrails-orchestrator_{context}"] | ||
| = Using a Hugging Face Prompt Injection detector with the Guardrails Orchestrator | ||
| = Preventing Prompt Injection by using a Hugging Face Prompt Injection detector |
There was a problem hiding this comment.
Probably for future reference, but can we decouple between "Deployment/configuration of the system" and "using the system", they are different personas usually.
Should we have a section for Guardrail use-cases where this would be one application of guardrails
Guardrails Use-Cases
PII & Sensitive Data Detection
- Protecting User Privacy by Detecting Email Addresses (email)
- Preventing Credit Card Leakage with Luhn-Validated Detection (credit-card)
- Safeguarding Social Security Numbers in User Inputs (us-social-security-number)
- Detecting Phone Numbers to Prevent Contact Information Leakage (us-phone-number)
- Identifying IPv4 Addresses for Network Security Compliance (ipv4)
- Detecting IPv6 Addresses in Technical Documentation (ipv6)
- Validating UK Postal Codes for Geographic Data Privacy (uk-post-code)
- Creating Custom PII Detectors with Regex Patterns ($CUSTOM_REGEX)
-
- Preventing Prompt Injection by using a Hugging Face Prompt Injection detector
Prompt Security
- Preventing Prompt Injection Attacks with DeBERTa Classifier (protectai/deberta-v3-base-prompt-injection-v2)
- Detecting Jailbreak Attempts with Granite Guardian (ibm-granite/granite-guardian-*)
Content Safety & Moderations
- Content Safety & Moderation
- Filtering Toxic Content with Granite Guardian HAP (ibm-granite/granite-guardian-hap-38m)
- Detecting Hate, Abuse, and Profanity in User Messages (HAP models)
- Identifying Harmful Content Across Multiple Risk Categories (Granite Guardian models)
- Blocking Social Bias in LLM Responses (Granite Guardian models)
- Preventing Unethical Behavior Suggestions (Granite Guardian models)
- Filtering Sexual Content from Conversations (Granite Guardian models)
- Detecting Violence and Harmful Instructions (Granite Guardian models)
- Identifying Profanity in User-Generated Content (Granite Guardian models)
...
https://github.com/trustyai-explainability/guardrails-detectors/tree/main/detectors
There was a problem hiding this comment.
@zanetworker I am in favor of breaking these up into two sections and it wouldn't be difficult to do that in this PR by adding a new assembly and siphoning these "Use case" inclusions that you've highlighted there. In this particular iteration of the refactor, I tried to group the Config/Use cases; whereas previously the use cases were sort-of meshed with the config pieces, I grouped them separately into Configs then Use cases. The Monitoring user inputs with the GOrch service is interesting because it is a use-case for filtering hateful and profane language but it has a ConfigMap piece to it as well, but it is mostly a scenario piece. I will add another commit shortly where I reorganize the use cases into a separate assembly and re-title the "Monitoring user inputs with the Guardrails Orchestrator service to a variation of your suggested title "Detecting Hateful and profane language".
There was a problem hiding this comment.
Regarding the question/comment about the llamastack in Guardrails, I think in the re-org it accidentally got deleted 😬 so thanks for asking about it. I re-added it.
The Guardrails with TAI content is both in the Guardrails section and in a standalone section Using TrustyAI with Llama Stack. Since this procedure to set up Llama Stack with Trusty AI is in both places, I've reorganized the appearance in the Guardrails section to appear in the use-case as a Detecting PII scenario, hoping to catch people intending to do the setup in the TrustyAI with Llama Stack section.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
assemblies/using-llama-stack-with-trustyai.adoc (1)
15-15: Bullet point at line 15 misaligns with the updated module title.Line 15 still uses the generic "Using the trustyai-fms Guardrails Orchestrator with Llama Stack" wording, but line 20 now includes the PII-focused module
detecting-pii-by-using-guardrails-with-llama-stack.adoc. Update the bullet point to accurately reflect that the example focuses on PII detection.Apply this diff to align the bullet point:
-* Using the trustyai-fms Guardrails Orchestrator with Llama Stack +* Detecting personally identifiable information (PII) by using Guardrails with Llama StackAlso applies to: 20-20
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
assemblies/configuring-the-guardrails-orchestrator-service.adoc(0 hunks)assemblies/enabling-ai-safety.adoc(1 hunks)assemblies/using-guardrails-for-ai-safety.adoc(1 hunks)assemblies/using-llama-stack-with-trustyai.adoc(1 hunks)modules/detecting-hateful-and-profane-language.adoc(1 hunks)modules/detecting-pii-by-using-guardrails-with-llama-stack.adoc(2 hunks)modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc(1 hunks)modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc(1 hunks)modules/using-a-hugging-face-prompt-injection-detector-with-the-guardrails-orchestrator.adoc(1 hunks)monitoring-data-science-models.adoc(1 hunks)
💤 Files with no reviewable changes (1)
- assemblies/configuring-the-guardrails-orchestrator-service.adoc
✅ Files skipped from review due to trivial changes (1)
- assemblies/enabling-ai-safety.adoc
🚧 Files skipped from review as they are similar to previous changes (3)
- modules/using-a-hugging-face-prompt-injection-detector-with-the-guardrails-orchestrator.adoc
- modules/enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc
- modules/filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc
🔇 Additional comments (6)
monitoring-data-science-models.adoc (1)
32-34: Clean structural reorganization of the monitoring index.The change cleanly replaces the outdated single Guardrails Orchestrator assembly with two focused assemblies for AI safety enablement and guardrails usage. The blank-line separator improves readability. Ensure that both referenced assemblies (
enabling-ai-safety.adocandusing-guardrails-for-ai-safety.adoc) are present in the repository and that their IDs match the expected context conventions.modules/detecting-pii-by-using-guardrails-with-llama-stack.adoc (2)
4-5: Well-focused module naming and ID updates.The renaming from generic "using Guardrails Orchestrator with Llama Stack" to specific "Detecting PII by using Guardrails with Llama Stack" improves discoverability and clarifies the example's scope.
14-14: Description clarification enhances context.The reword clearly positions the Guardrails Orchestrator as a Llama Stack safety component for PII detection. The narrative flow is improved.
modules/detecting-hateful-and-profane-language.adoc (1)
4-5: Focused and clear module reframing.The HAP module ID and title are now use-case-specific and more discoverable. The description reword emphasizing HAP detection aligns well with the new name. This follows the positive refactoring pattern established in the PII module.
Also applies to: 8-8
assemblies/using-guardrails-for-ai-safety.adoc (2)
6-17: Well-organized assembly structure with logical subsections.The three-subsection organization (Detecting PII, Securing Prompts, Moderating Content) provides clear categorization of guardrails use cases. All includes use consistent
leveloffset=+1formatting. The introductory context at line 6 is appropriately focused.Note on interlinking: The PR comments from @zanetworker mention that interlinking between the llama-stack documentation and the safety/guardrails documentation needs attention. This assembly includes
detecting-pii-by-using-guardrails-with-llama-stack.adoc, which bridges these topics. Verify that the llama-stack assembly (assemblies/using-llama-stack-with-trustyai.adoc) includes appropriate cross-references back to this safety assembly for bidirectional navigation.
19-20: Proper context restoration.The parent-context conditional blocks follow standard AsciiDoc assembly patterns.
skrthomas
force-pushed
the
RHOAIENG-37346
branch
3 times, most recently
from
6fc4169 to
f4ca79c
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
enabling-ai-safety.adoc (1)
1-20: Ensure cross-references and navigation from related documentation.The creation of a new dedicated safety documentation entry point is good for organization, but you should verify that:
- The included assemblies contain proper cross-references (xrefs) to related documentation, particularly the LLaMA stack documentation mentioned in the PR comments.
- Navigation paths from parent/related documentation (e.g., monitoring, model deployment guides) link appropriately to this new page or its sections.
- The document is discoverable from the main documentation navigation structure.
This aligns with zanetworker's comment about the need for interlinking between LLaMA stack docs and safety/guardrails documentation.
If you need help auditing or adding cross-references in the included assemblies or related documentation, I can help verify the interlinking structure.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
assemblies/enabling-ai-safety-with-guardrails.adoc(1 hunks)enabling-ai-safety.adoc(1 hunks)monitoring-data-science-models.adoc(0 hunks)
💤 Files with no reviewable changes (1)
- monitoring-data-science-models.adoc
🚧 Files skipped from review as they are similar to previous changes (1)
- assemblies/enabling-ai-safety-with-guardrails.adoc
🔇 Additional comments (2)
enabling-ai-safety.adoc (2)
1-14: Front matter and AsciiDoc configuration look correct.The Jekyll front matter, document attributes, and AsciiDoc configuration are properly structured. The use of
:context: safetyaligns with the assembly-based documentation approach.
18-18: Verify included assembly paths and structure.The includes reference two new assemblies that split the previous consolidated Guardrails documentation. Ensure that:
- The assembly file paths (
assemblies/enabling-ai-safety-with-guardrails.adocandassemblies/using-guardrails-for-ai-safety.adoc) are correct relative to this file's location.- The leveloffset=+1 produces the intended heading hierarchy.
Per your PR comments, also verify that interlinking between the LLaMA stack documentation and these Guardrails assemblies is properly handled to support cross-referencing and discoverability.
Also applies to: 20-20
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
modules/mitigating-prompt-injection-by-using-a-hugging-face-prompt-injection-detector.adoc (1)
43-47: Consider clarifying prerequisite scope.The prerequisite about configuring the Guardrails Orchestrator service (lines 43–47) is specific to Scenario 1. Given the updated title emphasizes "Mitigating Prompt Injection" more broadly, consider adding a brief clarification that this prerequisite applies to the Orchestrator API scenario, while Scenario 2 supports standalone detection without it. This would help users navigate the document based on their use case.
Example clarification:
ifdef::upstream[] -* You are familiar with how to configure and deploy the Guardrails Orchestrator service. See link:{odhdocshome}/monitoring_data_science_models/#deploying-the-guardrails-orchestrator-service_monitor[Deploying the Guardrails Orchestrator]. +* (For Scenario 1 only) You are familiar with how to configure and deploy the Guardrails Orchestrator service. See link:{odhdocshome}/monitoring_data_science_models/#deploying-the-guardrails-orchestrator-service_monitor[Deploying the Guardrails Orchestrator]. endif::[] ifndef::upstream[] -* You are familiar with how to configure and deploy the Guardrails Orchestrator service. See link:{rhoaidocshome}{default-format-url}/monitoring_data_science_models/configuring-the-guardrails-orchestrator-service_monitor#deploying-the-guardrails-orchestrator-service_monitor[Deploying the Guardrails Orchestrator] +* (For Scenario 1 only) You are familiar with how to configure and deploy the Guardrails Orchestrator service. See link:{rhoaidocshome}{default-format-url}/monitoring_data_science_models/configuring-the-guardrails-orchestrator-service_monitor#deploying-the-guardrails-orchestrator-service_monitor[Deploying the Guardrails Orchestrator] endif::[]
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
assemblies/using-guardrails-for-ai-safety.adoc(1 hunks)modules/mitigating-prompt-injection-by-using-a-hugging-face-prompt-injection-detector.adoc(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- assemblies/using-guardrails-for-ai-safety.adoc
🔇 Additional comments (1)
modules/mitigating-prompt-injection-by-using-a-hugging-face-prompt-injection-detector.adoc (1)
4-5: ID and title changes are safe—no broken cross-references detected.The old ID is not referenced anywhere in the codebase, and the new ID is correctly defined and included in the
using-guardrails-for-ai-safety.adocassembly. The refactoring aligns with the JTBD approach, broadening the scope from Orchestrator-specific to outcome-focused documentation.
| The following sections describe the Guardrails components, how to deploy them and provide example use cases of how to protect your AI applications using these tools: | ||
|
|
||
| Deploy a Guardrails Orchestrator instance:: | ||
| The guardrails orchestrator is the main networking layer of the guardrails ecosystem, and “orchestrates” the network requests between the user, generative models, and detector servers. |
There was a problem hiding this comment.
generative models
this should be singular - it's only one generative model per orchestrator
| Configure and use the built-in detectors:: | ||
| The Guardrails framework provides a set of “built-in” detectors out-of-the-box, that provides a number of simple detection algorithms. You can use the following detector with `trustyai_fms` orchestrator server, which is an external provider for Llama Stack that allows you to configure and use the Guardrails Orchestrator and compatible detection models through the Llama Stack API.: | ||
| + | ||
| * *Regex Detectors*: Pattern-based content detection for structured rule enforcement. These are the built-in detectors in the Guardrails Orchestrator service. Learn more about the link:https://github.com/trustyai-explainability/guardrails-regex-detector[guardrails-regex-detector]. |
There was a problem hiding this comment.
There are a number of other built-in detection algorithms beyond just regex - I can write up a doc about them
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
modules/guardrails-orchestrator-detectors.adoc (1)
16-24: Use proper AsciiDoc code block syntax instead of inline backticks.The code examples use inline backticks (``) to delimit JSON/YAML blocks (lines 16-24 and 53-62). While readable, this is not standard AsciiDoc markup. Replace with properly delimited code blocks using
[source,json]or[source,yaml]for syntax highlighting and consistency with other examples in the documentation suite.Example fix for lines 53-62:
-``` +[source,json] +---- { "contents": [ "Some message" ], "detector_params": { - `regex`: [credit-card, email] + "regex": ["credit-card", "email"] } } -``` +----Also applies to: 53-62
modules/guardrails-orchestrator-parameters.adoc (1)
44-59: Clarify the structure and placement of the detectors section.Lines 44-59 list detector patterns (social-security-number, email, yaml-with-schema, etc.), but their placement and relationship to the parameter table is unclear. These appear to be additional detector types but are positioned outside the main parameter table structure. Consider either:
- Moving this content into a structured parameter table row, or
- Placing it in a separate "Supported Detectors" section with clear heading, or
- Cross-referencing the
modules/guardrails-orchestrator-detectors.adocfile which already documents these detectorsmodules/guardrails-enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc (1)
29-44: Define the$MODELvariable in the curl example.Line 36 references
$MODELin the curl command payload, but this variable is not defined in the procedure. Users need to know what value to substitute. Consider adding a prerequisite or clarifying step that explains how to identify or set the model name.Example fix:
. Query the model with guardrails `pii` endpoint: + +Before running the curl command, set the MODEL variable to your deployed model name: + +[source,terminal] +---- +export MODEL="your-model-name" +---- + [source,terminal] ---- curl -v $GUARDRAILS_GATEWAY/pii/v1/chat/completions \
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
assemblies/enabling-ai-safety-with-guardrails.adoc(1 hunks)modules/configuring-the-built-in-detector-and-guardrails-gateway.adoc(3 hunks)modules/deploying-the-guardrails-orchestrator-service.adoc(2 hunks)modules/guardrails-auto-config.adoc(3 hunks)modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc(4 hunks)modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc(1 hunks)modules/guardrails-detectors.adoc(0 hunks)modules/guardrails-enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc(1 hunks)modules/guardrails-filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc(1 hunks)modules/guardrails-gateway-config-parameters.adoc(1 hunks)modules/guardrails-orchestrator-configmap-parameters.adoc(1 hunks)modules/guardrails-orchestrator-detectors.adoc(1 hunks)modules/guardrails-orchestrator-parameters.adoc(2 hunks)
💤 Files with no reviewable changes (1)
- modules/guardrails-detectors.adoc
🔇 Additional comments (21)
modules/guardrails-filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc (2)
1-64: Module structure and content are well-organized.This new procedure file effectively documents the regex detector filtering workflow with clear prerequisites, actionable steps, and a concrete example response. The CR example correctly demonstrates
enableBuiltInDetectors: trueandenableGuardrailsGateway: trueconfiguration.
12-45: The review comment is based on an incorrect premise.The Guardrails Orchestrator detector interface uses the v2 API (e.g.,
/api/v2/text/detection/content). The code in the file under review correctly uses this endpoint, so there is no inconsistency to resolve. The concern raised appears to assume v1 is the authoritative version, but v2 is the current standard.Likely an incorrect or invalid review comment.
modules/guardrails-orchestrator-configmap-parameters.adoc (1)
1-90: Configuration documentation is comprehensive and well-structured.The example ConfigMap and parameter table clearly document orchestrator configuration structure, including TLS configuration guidance, service definitions, detector registration, and passthrough headers. The cross-reference to
tlsSecretsparameter in the GuardrailsOrchestrator CR (line 87) properly connects to the orchestrator parameters documentation.modules/guardrails-orchestrator-detectors.adoc (1)
1-62: Detector reference content is thorough and well-organized.The categorization of built-in detectors (regex, file_type, custom) with specific algorithm names provides users with clear options for configuration. The usage example effectively demonstrates how
detector_paramsselects algorithms from different taxonomies.modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc (3)
4-5: Title and runtime name are appropriately generalized.The title change from specific "prompt-injection" detector to generic "Hugging Face Detector serving runtime" and the corresponding ServingRuntime name change from
guardrails-detector-runtime-prompt-injectiontoguardrails-detector-runtimeproperly position this as a generic detector template supporting anyAutoModelForSequenceClassificationmodel. This aligns with the broader refactoring toward a unified detector framework.Also applies to: 24-24
54-65: SAFE_LABELS parameter is well-documented with clear examples.The new
SAFE_LABELSenvironment variable documentation (lines 54-55, 60-65, 133-139) clearly explains the concept of safe vs. unsafe prediction labels and provides concrete examples showing how labels map to guardrailing triggers. The parameter table correctly documents the default value as[0].
45-45: Document the rationale for reducing worker count or verify against official recommendations.The change to
--workers=1(line 45) and related documentation (lines 137-139) deviates from the official Guardrails detector runtime example which uses--workers=4. For async FastAPI/Uvicorn applications, best practice is to start with workers approximately equal to the number of vCPUs assigned to the container, making--workers=1a notable reduction. Either explain the rationale (e.g., resource constraints, testing environment) or verify this aligns with your intended configuration.modules/guardrails-orchestrator-parameters.adoc (1)
15-42: Parameter expansion is comprehensive and well-organized.The addition of new parameters (
guardrailsGatewayConfig,autoConfig,enableBuiltInDetectors,enableGuardrailsGateway,logLevel,tlsSecrets) and the expansion ofotelExporterwith sub-parameters (otlpProtocol,otlpTracesEndpoint,otlpMetricsEndpoint,enableTraces,enableMetrics) properly document the extended orchestrator configuration surface. The cross-reference anchor[[tlsSecrets-param]](line 36) enables linking from other modules.modules/guardrails-gateway-config-parameters.adoc (2)
58-103: Constraint documentation through examples is exemplary.The detailed Note section (lines 58-103) provides clear guidance on route preset constraints by showing invalid, valid, and edge-case examples. The explanation that inputs/outputs from the same server cannot coexist in a route is critical information, and the three progressively illustrative examples effectively communicate the rule and its exceptions.
1-103: New gateway configuration module is well-structured and comprehensive.The introduction, example ConfigMap, parameter table, and constraint documentation provide users with everything needed to configure gateway presets. Cross-references to
detector-server-name-paramandguardrails-detector-server-infoproperly connect to related documentation in other modules.modules/deploying-the-guardrails-orchestrator-service.adoc (1)
35-110: Orchestrator configuration example is significantly enhanced with TLS and multi-detector setup.The expanded example ConfigMap (lines 39-81) now demonstrates TLS configuration for both chat generation and multiple detectors (
built_inandsome-other-detector), with corresponding TLS blocks and numbered callout explanations (lines 82-110). This substantial enhancement provides users with a realistic, production-ready configuration template. The cross-reference totlsSecretsmounting guidance (line 108) is properly anchored.modules/guardrails-auto-config.adoc (3)
3-3: Documentation ID naming is more consistent.The ID change from
auto-configuring-guardrails_{context}toguardrails-auto-config_{context}(line 3) brings this module into alignment with other guardrails documentation naming patterns (e.g.,guardrails-orchestrator-detectors,guardrails-gateway-config-parameters), improving discoverability and consistency.
8-8: Abstract clarifies TLS and auto-discovery capabilities.The reworded abstract (line 8) now explicitly mentions that auto-configuration handles TLS credential discovery, mounting, and automatic orchestrator forwarding of authentication headers. This is a significant capability that should be prominently documented—users need to know that they don't have to manually manage TLS secrets when using auto-config.
47-50: Feature behavior documentation for enableGuardrailsGateway and enableBuiltInDetectors is clear.The new documentation (lines 47-50) explains that:
- When
enableGuardrailsGateway: true, a template gateway config is auto-generated and can be modified, with divergence tracking via label- When
enableBuiltInDetectors: true, the built-in detector is auto-added to orchestrator configThis is valuable operational guidance for users making configuration choices. The mention of label-based divergence tracking (
trustyai/has-diverged-from-auto-config) provides actionable information for users who customize the generated configs.modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc (1)
135-162: Verify the orchestrator route naming and health endpoint.The verification steps assume a route named
guardrails-orchestrator-sample-health(line 135) and an HTTP endpoint at/health(line 140). These values depend on the CR name and actual route naming conventions configured by the operator. Verify that:
- Route naming matches the operator's actual convention (e.g.,
{cr-name}-healthor similar pattern)- The
/healthendpoint and response format match the actual orchestrator implementation- The sample response on line 162 correctly represents the orchestrator version output
Ensure the route name in step 2 matches the actual
guardrails-orchestrator-sampleCR name created in step 3 (line 113).modules/guardrails-enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc (1)
21-27: Verify conditional documentation links reference correct anchors.Lines 21-27 include conditional links to configuration documentation. Both the upstream and non-upstream links reference anchor
configuring-the-built-in-detector-and-guardrails-gateway_monitor. Ensure these anchors exist in the target documentation:
- Upstream:
{odhdocshome}/monitoring-data-science-models/#configuring-the-built-in-detector-and-guardrails-gateway_monitor- Non-upstream:
{rhoaidocshome}{default-format-url}/monitoring_data_science_models/configuring-the-guardrails-orchestrator-service_monitor#configuring-the-built-in-detector-and-guardrails-gateway_monitorNote: The non-upstream path includes
configuring-the-guardrails-orchestrator-service_monitorin the URL which differs from the upstream path.modules/configuring-the-built-in-detector-and-guardrails-gateway.adoc (3)
38-75: Verify ConfigMap field names and structure match orchestrator schema.The ConfigMap example (lines 38-75) defines detector and route configurations. Ensure the YAML field names are correct:
- Line 50:
server: built_in— verify this is the correct field name for specifying the built-in detector- Line 51:
input: true— verify this controls input filtering (vs. output)- Lines 63-71: The
routessection appears incomplete on line 71 (showsdetectors:with no following list)Cross-reference these against the FMS-Guardrails Orchestrator schema to confirm accuracy.
94-102: Resolve inconsistency in orchestrator configuration references.Line 94 specifies
orchestratorConfig: "fms-orchestr8-config-nlp", but this ConfigMap name is not defined in the current procedure. In contrast, the deployment procedure (File 2, guardrails-deploying-the-guardrails-orchestrator-service.adoc) references a user-provided orchestrator ConfigMap.Clarify whether:
fms-orchestr8-config-nlpis a pre-existing ConfigMap that users should provide, or- This should reference a ConfigMap created in a separate step, or
- This example requires a cross-reference to a configuration module that defines the orchestrator ConfigMap structure.
112-133: Resolve inconsistency between verification endpoints across modules.This module's verification (lines 112-133) uses:
- Route name:
guardrails-orchestrator-health(line 116)- Endpoint:
/info(line 117)- Response format: Shows
"services"object with"chat_generation"and"regex"statusHowever, guardrails-deploying-the-guardrails-orchestrator-service.adoc (File 2) uses:
- Route name:
guardrails-orchestrator-sample-health(line 135)- Endpoint:
/health(line 140)- Response format: Shows
"fms-guardrails-orchestr8": "0.1.0"version stringThese differences need reconciliation. Verify which endpoints and response formats are correct, and ensure consistency across both procedures.
assemblies/enabling-ai-safety-with-guardrails.adoc (2)
35-50: All included modules are properly structured and verify successfully.Verification confirms all referenced modules exist, contain proper AsciiDoc module-type declarations, and correctly use the
{context}variable for dynamic ID resolution (e.g.,[id='guardrails-detectors_{context}']). Include directives have valid syntax with appropriate leveloffset values, and secondary anchors are properly defined. No missing files, broken references, or structural issues detected.
46-47: Fix the link path and anchor mismatch.The link on line 46 has two issues:
Semantic mismatch: Link text "Adding a model server to your data science project" doesn't align with anchor
#detecting-pii-by-using-guardrails-with-llama-stack_.Path pattern inconsistency: Similar guardrails-related links in the codebase (e.g.,
modules/mitigating-prompt-injection-by-using-a-hugging-face-prompt-injection-detector.adoc:46) use the pattern/monitoring_data_science_models/configuring-the-guardrails-orchestrator-service_monitor#..., but this link uses/monitoring_data_science_models#...directly without an intermediate path component.The current link should either be corrected to match the correct documentation section or updated to point to the appropriate PII detection anchor if that section exists in RHOAI docs.
modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc
Outdated
Show resolved
Hide resolved
| .`custom` | ||
| * _(Dev-preview)_ Custom detectors defined via a `custom_detectors.py` file. See $release-note. |
There was a problem hiding this comment.
Replace placeholder $release-note with actual cross-reference or documentation link.
Line 49 contains See $release-note for custom detectors, which is a template placeholder. This should be replaced with an actual link to release notes or a cross-reference to relevant documentation. As written, users cannot find the referenced material.
🤖 Prompt for AI Agents
In modules/guardrails-orchestrator-detectors.adoc around lines 48 to 49, the
text contains a placeholder "See $release-note" which should be replaced with a
concrete reference; update that sentence to point to the appropriate release
notes or documentation page (either an internal AsciiDoc cross-reference like
<<release-notes-id,Release Notes>> or a full URL to the release notes/docs) so
readers can navigate to the referenced material, and ensure the link text is
descriptive (e.g., "See the release notes for custom detectors" or "See the
Custom Detectors documentation") to improve discoverability.
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
assemblies/enabling-ai-safety-with-guardrails.adoc(1 hunks)modules/configuring-the-built-in-detector-and-guardrails-gateway.adoc(0 hunks)modules/deploying-the-guardrails-orchestrator-service.adoc(0 hunks)modules/guardrails-auto-config.adoc(3 hunks)modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc(4 hunks)modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc(1 hunks)modules/guardrails-gateway-config-parameters.adoc(1 hunks)modules/guardrails-orchestrator-configmap-parameters.adoc(1 hunks)modules/guardrails-orchestrator-detectors.adoc(1 hunks)modules/guardrails-orchestrator-parameters.adoc(0 hunks)
💤 Files with no reviewable changes (3)
- modules/configuring-the-built-in-detector-and-guardrails-gateway.adoc
- modules/guardrails-orchestrator-parameters.adoc
- modules/deploying-the-guardrails-orchestrator-service.adoc
🚧 Files skipped from review as they are similar to previous changes (6)
- modules/guardrails-gateway-config-parameters.adoc
- assemblies/enabling-ai-safety-with-guardrails.adoc
- modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc
- modules/guardrails-auto-config.adoc
- modules/guardrails-orchestrator-configmap-parameters.adoc
- modules/guardrails-orchestrator-detectors.adoc
🔇 Additional comments (1)
modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc (1)
45-45: Verify workers reduction from 4 to 1.The workers argument was reduced from
4to1. Confirm this change is intentional and aligns with performance/resource expectations. If this reflects a recommended baseline configuration, consider adding a note in the narrative explaining the rationale.
modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (4)
modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc (2)
54-55: YAML value must be quoted to pass as a string (unresolved from prior review).Environment variable values in Kubernetes must be strings. The YAML at line 55 shows a bare array literal
value: [0], but sinceSAFE_LABELSis documented as a "JSON-formatted list" (line 62), the value must be quoted to be passed to the container as a string:- name: SAFE_LABELS - value: [0] + value: "[0]"
131-133: Complete the SAFE_LABELS table description (unresolved from prior review).The description cell at lines 131–133 is incomplete. Expand it to clarify the parameter's purpose and format, referencing the narrative explanation at lines 61–63:
| `SAFE_LABELS` | `[0]` -| A JSON-formatted list +| A JSON-formatted list specifying prediction labels that constitute a "safe" response (e.g., `[0, 1]` for a four-class model); default `[0]`modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc (2)
87-88: Clarify the ISVC acronym in the inline command.The
oc get isvccommand at lines 87–88 does not explain that ISVC stands for InferenceService. Readers unfamiliar with Kubernetes/KServe terminology may not understand what the command retrieves. Add a brief inline clarification.Apply this diff to clarify the acronym:
-* `inferenceServiceToGuardrail` - The name of the inference service you want to guardrail. This should exactly match the model name provided when deploying the model. For a list of valid names, you can run -`oc get isvc -n $NAMESPACE` +* `inferenceServiceToGuardrail` - The name of the inference service you want to guardrail. This should exactly match the model name provided when deploying the model. For a list of valid names, run `oc get isvc` (InferenceService) with `-n $NAMESPACE` to list all inference services in your namespace.
76-77: Add proper cross-reference link to "Auto Configuring Guardrails" documentation.Line 76–77 references "Auto Configuring Guardrails" in italics, but this should use AsciiDoc cross-reference syntax to link to the actual documentation module. Use the format
<<guardrails-auto-config_{context}, Auto Configuring Guardrails>>to ensure readers can navigate to that section.Apply this diff to add the proper cross-reference:
-To access this, include the `autoConfig` parameter inside your Custom Resource, and see _Auto Configuring Guardrails_ for documentation on its usage. +To access this, include the `autoConfig` parameter inside your Custom Resource, and see <<guardrails-auto-config_{context}, Auto Configuring Guardrails>> for documentation on its usage.
🧹 Nitpick comments (4)
assemblies/enabling-ai-safety-with-guardrails.adoc (2)
11-34: Consider reorganizing section structure for clarity (feedback from prior review).The prior review flagged that this section mixes component definitions (Detectors, Orchestrator Configuration, Guardrails Gateway Configuration, Deploying the Orchestrator, Guardrails AutoConfig) with procedural/action items (Monitor user-inputs, Enable telemetry). This may confuse readers about whether the items are prerequisites, steps, or reference topics.
Consider restructuring into clearer groupings: e.g., (1) Components/Concepts, (2) Deployment steps, (3) Advanced configurations, or (4) Observability & monitoring.
7-9: Clarify the relationship between tool and function.Past review feedback noted the importance of communicating "tool x makes function y happen." The current phrasing ("TrustyAI Guardrails Orchestrator service is a tool to invoke detections...") is acceptable, but consider whether a brief callout explaining how the TrustyAI Orchestrator enables AI safety with guardrails (the assembly title) would strengthen the connection for readers.
modules/guardrails-auto-config.adoc (1)
46-50: Verify related documentation is accurate for auto-config behavior.The new descriptions of
enableGuardrailsGateway(lines 47–48) andenableBuiltInDetectors(lines 49–50) reference auto-generated resources (<ORCHESTRATOR_NAME>-gateway-auto-configConfigMap, divergence labels, sample gateway config). Ensure that the related parameter documentation files (modules/guardrails-orchestrator-configmap-parameters.adocandmodules/guardrails-gateway-config-parameters.adoc) fully document these auto-generated ConfigMaps and their modifiable fields so readers can effectively customize them.modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc (1)
85-86: Improve clarity and formatting of theautoConfigparameter description.The multi-line bullet points under
autoConfig(lines 85–91) are well-structured but could be clearer by consistently formatting the parameter names in monospace. Additionally, the transition between the bullet items and the "See Auto Configuring Guardrails" note could be more explicit.Consider reformatting the bullet list for consistency and readability:
| `autoConfig` *(optional)* | A list of paired name and value arguments to define how the Guardrails AutoConfig. Any manually-specified configuration files in `orchestratorConfig` or `guardrailsGatewayConfig` takes precedence over the automatically-generated configuration files. -* `inferenceServiceToGuardrail` - The name of the inference service you want to guardrail. This should exactly match the model name provided when deploying the model. For a list of valid names, you can run -`oc get isvc -n $NAMESPACE` -* `detectorServiceLabelToMatch` - A string label to use when searching for available detector servers. All inference services in your namespace with the label `$detectorServiceLabelToMatch: true` is automatically configured as a detector. +* `inferenceServiceToGuardrail`: The name of the inference service you want to guardrail. This must match the model name exactly as provided during deployment. Run `oc get isvc -n $NAMESPACE` to list available inference services. +* `detectorServiceLabelToMatch`: A string label to identify available detector servers. All inference services in your namespace with the label `$detectorServiceLabelToMatch: true` are automatically configured as detectors. + -See _Auto Configuring Guardrails_ for more information. +See <<guardrails-auto-config_{context}, Auto Configuring Guardrails>> for more information.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
assemblies/enabling-ai-safety-with-guardrails.adoc(1 hunks)modules/guardrails-auto-config.adoc(4 hunks)modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc(4 hunks)modules/guardrails-configuring-the-opentelemetry-exporter.adoc(1 hunks)modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc(1 hunks)modules/guardrails-filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc(1 hunks)modules/guardrails-gateway-config-parameters.adoc(1 hunks)modules/guardrails-orchestrator-configmap-parameters.adoc(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- modules/guardrails-configuring-the-opentelemetry-exporter.adoc
🚧 Files skipped from review as they are similar to previous changes (2)
- modules/guardrails-orchestrator-configmap-parameters.adoc
- modules/guardrails-gateway-config-parameters.adoc
🔇 Additional comments (4)
modules/guardrails-filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc (1)
1-64: Well-structured new procedure document.This procedure document is complete, clear, and well-integrated with the broader Guardrails documentation updates. The example CR, curl command, and response output are all consistent and helpful for users.
modules/guardrails-auto-config.adoc (1)
60-80: LGTM: Placeholder-based verification commands are pragmatic for auto-config.The shift from hardcoded examples to placeholder-based view commands (e.g.,
<auto-generated config map name>) is appropriate for auto-generated resources with dynamic naming. This approach encourages users to discover actual resource names rather than rely on brittle documentation examples.modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc (2)
103-105: Excellent documentation of optional parameters.The
logLevel,tlsSecrets, andreplicasparameter descriptions are clear, comprehensive, and provide helpful context (e.g., default values, valid options, field requirements). The anchor at line 104 fortlsSecrets-paramenables internal cross-referencing if needed elsewhere.
131-163: Verification steps are well-structured and realistic.The verification section provides clear commands and realistic example outputs that help readers understand what to expect. The dual-step approach (checking pod status, then querying the health endpoint) is a best practice for verifying deployment health.
skrthomas
force-pushed
the
RHOAIENG-37346
branch
2 times, most recently
from
7176499 to
7669722
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (2)
modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc (2)
54-55: Quote SAFE_LABELS value as a JSON string (unresolved critical issue).This issue was flagged in previous review but remains unresolved. In Kubernetes YAML, environment variable values must be strings. Line 55 shows
value: [0]as a bare YAML array literal; it must be quoted so the container receives a JSON string:- name: SAFE_LABELS - value: [0] + value: "[0]"
131-133: Expand SAFE_LABELS table description for clarity (unresolved minor issue).This issue was flagged in previous review but remains unresolved. The table description is too brief. Align it with the clear explanation provided in lines 62–63 to clarify that SAFE_LABELS specifies which prediction labels are considered "safe":
| `SAFE_LABELS` | `[0]` -| A JSON-formatted list +| A JSON-formatted list specifying safe prediction labels; default `[0]` treats label 0 as safe
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
assemblies/enabling-ai-safety-with-guardrails.adoc(1 hunks)assemblies/using-guardrails-for-ai-safety.adoc(1 hunks)modules/guardrails-auto-config.adoc(4 hunks)modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc(4 hunks)modules/guardrails-configuring-the-opentelemetry-exporter.adoc(1 hunks)modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc(1 hunks)modules/guardrails-filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc(1 hunks)modules/guardrails-gateway-config-parameters.adoc(1 hunks)modules/guardrails-orchestrator-configmap-parameters.adoc(1 hunks)modules/guardrails-orchestrator-detectors.adoc(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (6)
- modules/guardrails-orchestrator-detectors.adoc
- assemblies/enabling-ai-safety-with-guardrails.adoc
- modules/guardrails-auto-config.adoc
- modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc
- modules/guardrails-configuring-the-opentelemetry-exporter.adoc
- modules/guardrails-filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc
🔇 Additional comments (5)
assemblies/using-guardrails-for-ai-safety.adoc (3)
4-4: Document ID now correctly matches the filename.The critical ID mismatch issue from the previous review has been resolved. Line 4 correctly declares
[id="using-guardrails-for-ai-safety_{context}"]which now aligns with the filenameusing-guardrails-for-ai-safety.adoc. Internal cross-references should now resolve correctly.
3-3: Context handling follows standard AsciiDoc assembly patterns.The context variable preservation and restoration logic (lines 3 and 19–20) correctly implements the nested assembly pattern for conditional rendering based on parent context. This ensures proper context isolation when the assembly is included by higher-level documents such as
enabling-ai-safety.adoc.Also applies to: 19-20
9-10: All included modules exist and paths are correct—no action needed.Verification confirms all five modules referenced in the assembly file (
./assemblies/using-guardrails-for-ai-safety.adoc) exist in the repository and are correctly referenceable:
- Line 9-10, 13, 16-17 include statements all match existing module files
- No missing modules or path mismatches detected
- Module structure includes valid AsciiDoc IDs
The documentation build will succeed without errors related to missing includes.
modules/guardrails-gateway-config-parameters.adoc (1)
45-45: Cross-references are valid — no issues found.Verification confirms both anchor IDs exist in their corresponding documentation files:
detector-server-name-paramanchor found inmodules/guardrails-orchestrator-configmap-parameters.adoc:76guardrails-detector-server-infoanchor found inmodules/guardrails-orchestrator-detectors.adoc:10The cross-references on lines 45 and 49 are correctly formatted and properly linked.
modules/guardrails-orchestrator-configmap-parameters.adoc (1)
84-84: Cross-reference anchor is correctly defined.The anchor
[[tlsSecrets-param]]exists at line 104 inmodules/guardrails-deploying-the-guardrails-orchestrator-service.adocwithin the GuardrailsOrchestrator parameter documentation. The cross-reference is valid and points to the appropriate Custom Resource parameter section.
| ---- | ||
| + | ||
| The above serving runtime example matches the default template used with {productname-long}, and should suffice | ||
| for the majority of use-cases. The main relevant configuration parameter is the `SAFE_LABELS` environment variable. This specifies which prediction label or labels from the `AutoModelForSequenceClassification` constitute a "safe" response and therefore should not trigger guardrailing. For example, if `[0, 1]` is specified as `SAFE_LABELS` |
There was a problem hiding this comment.
Why is safe in quotations? Also, consider removing the word 'therefore' (minimalist principles)
| ---- | ||
| <1> This references the config map that was created in Step 1 of "Deploying the Guardrails Orchestrator service". | ||
| + | ||
| * `orchestratorConfig`: This references the config map that was created in Step 1 of "Deploying the Guardrails Orchestrator service". |
There was a problem hiding this comment.
: References the configMap that was created in step 1 of "Deploying the Guardrails Orchestrator service".
| = Deploying the Guardrails Orchestrator | ||
|
|
||
| [role='_abstract'] | ||
| You can deploy a Guardrails Orchestrator instance in your namespace to monitor elements, such as user inputs to your Large Language Model (LLM). |
There was a problem hiding this comment.
no need for the comma before 'such' ?
|
|
||
| .Prerequisites | ||
| * You have cluster administrator privileges for your {openshift-platform} cluster. | ||
| * You have installed the {openshift-cli} as described in the appropriate documentation for your cluster: |
There was a problem hiding this comment.
Ought to give a link here
| ---- | ||
|
|
||
| .Verification | ||
| . Confirm that the orchestrator and LLM pods are running: |
There was a problem hiding this comment.
... using the following commands:'
BSynRedhat
left a comment
BSynRedhat
left a comment
There was a problem hiding this comment.
I have left a few comments for your attention
BSynRedhat
left a comment
BSynRedhat
left a comment
There was a problem hiding this comment.
I'm approving it so my approval doesn't block you, but it needs another PR from a TW as there are a few questions I've included that may need rewriting.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc (1)
131-133: Complete the SAFE_LABELS table description.The description cell for
SAFE_LABELSis incomplete and does not match the detail provided in lines 62–63. Expand the table entry to clarify thatSAFE_LABELSspecifies which prediction label(s) are considered safe and reference the default behavior.| `SAFE_LABELS` | `[0]` -| A JSON-formatted list +| A JSON-formatted list specifying safe prediction labels; default `[0]` treats label 0 as safe
🧹 Nitpick comments (5)
modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc (2)
17-17: Align "Huggingface" capitalization to match documentation standards.Line 17 uses "Huggingface" but the file elsewhere uses "Hugging Face" (e.g., lines 10, 12). Standardize to "Hugging Face" for consistency.
-This YAML file contains an example of a custom serving Huggingface runtime: +This YAML file contains an example of a custom serving Hugging Face runtime:
62-63: Clean up text per minimalist principles and remove unnecessary quotations.The text on lines 62–63 contains issues flagged in prior reviews:
- Remove the word "therefore" (minimalist principle)
- Remove quotation marks around "safe" (unnecessary)
- Use "label(s)" instead of "label or labels" for brevity
-The main relevant configuration parameter is the `SAFE_LABELS` environment variable. This specifies which prediction label or labels from the `AutoModelForSequenceClassification` constitute a "safe" response and therefore should not trigger guardrailing. For example, if `[0, 1]` is specified as `SAFE_LABELS` +The main relevant configuration parameter is the `SAFE_LABELS` environment variable. This specifies which prediction label(s) from the `AutoModelForSequenceClassification` constitute a safe response and should not trigger guardrailing. For example, if `[0, 1]` is specified as `SAFE_LABELS`assemblies/enabling-ai-safety-with-guardrails.adoc (3)
13-34: Standardize capitalization of key terms throughout section descriptions.Capitalization of "Orchestrator" and "Guardrails" is inconsistent:
- Line 17: "Configuring the Orchestrator::" vs Line 18: "Configure the orchestrator"
- Line 26-27: "Guardrails" (capital) vs "guardrails" (lowercase)
Apply consistent capitalization rules across headings and descriptions (e.g., title case for heading terms, sentence case for descriptions, or define them as proper nouns if they are product/tool names).
24-24: Fix spacing in abbreviation formatting.Line 24 has "Large Language Model(LLM)" which is missing a space before the opening parenthesis. Should be "Large Language Model (LLM)".
40-40: Add missing article before tool name.Line 40: "with
trustyai_fmsorchestrator" should read "with thetrustyai_fmsorchestrator" for better grammar.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
assemblies/enabling-ai-safety-with-guardrails.adoc(1 hunks)modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc(4 hunks)
🔇 Additional comments (4)
assemblies/enabling-ai-safety-with-guardrails.adoc (4)
7-9: Verify clarity of TrustyAI vs Guardrails Orchestrator service distinction.The introduction mentions "TrustyAI Guardrails Orchestrator service" and then references "FMS-Guardrails Orchestrator" from IBM. For readers unfamiliar with the architecture, the relationship between TrustyAI, the Guardrails Orchestrator, and FMS-Guardrails may not be immediately clear. Consider whether an explicit clarification about TrustyAI's role would help orient readers before diving into deployment.
Does this distinction need clarification based on target audience familiarity, or is the current framing sufficient?
35-48: Module references and include structure look good.The assembly properly orchestrates the include statements with appropriate leveloffsets. The HF detector config at line 43 using leveloffset=+2 indicates hierarchical positioning that aligns with the documentation model.
37-41: Conditional Additional Resources section is properly structured.The ifdef/endif logic and link placeholders follow AsciiDoc conventions. The reference to Llama Stack integration for PII detection appropriately extends the Guardrails documentation scope.
1-6: AsciiDoc assembly structure and metadata are correct.Module type declaration, document ID, context handling, and footer cleanup follow proper AsciiDoc assembly patterns.
Also applies to: 51-52
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
assemblies/enabling-ai-safety-with-guardrails.adoc(1 hunks)modules/detecting-pii-by-using-guardrails-with-llama-stack.adoc(2 hunks)modules/guardrails-auto-config.adoc(3 hunks)modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc(1 hunks)modules/guardrails-enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc(2 hunks)modules/guardrails-orchestrator-configmap-parameters.adoc(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- modules/guardrails-orchestrator-configmap-parameters.adoc
- modules/detecting-pii-by-using-guardrails-with-llama-stack.adoc
- modules/guardrails-auto-config.adoc
- modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc
🔇 Additional comments (4)
modules/guardrails-enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc (3)
8-8: Content is clear and production-focused.The revised abstract effectively communicates the purpose of Guardrails Gateway and its production use case. The narrative is well-structured and helps users understand when and how to use this feature.
46-51: Example response clearly demonstrates guardrails behavior.The example output effectively shows users what a successful PII detection response looks like, making the procedure more practical and understandable.
22-27: Verify link targets exist in external documentation.The referenced section ID
configuring-the-built-in-detector-and-guardrails-gateway_monitoris not defined in the current repository—it's an external link. Lines 22 and 26 reference this section in:
- Upstream docs:
{odhdocshome}/monitoring-data-science-models/- Downstream docs:
{rhoaidocshome}{default-format-url}/monitoring_data_science_models/configuring-the-guardrails-orchestrator-service_monitorManual verification from the documentation maintainer is needed to confirm these sections exist at the target locations.
assemblies/enabling-ai-safety-with-guardrails.adoc (1)
35-35: All included modules and cross-references verified successfully—no issues found.All seven included module files exist, and the cross-reference link on line 40 resolves correctly. The assembly is properly structured with no broken documentation references.
| Define preset guardrail pipelines with corresponding unique endpoints. | ||
|
|
||
| Deploying the Orchestrator:: | ||
| Create a Guardrails Orchestrator to begin securing your Large Language Model(LLM) deployments. |
There was a problem hiding this comment.
Fix spacing in LLM abbreviation.
Line 24 has a spacing issue: "Large Language Model(LLM)" should include a space before the parenthesis to match standard conventions.
-Create a Guardrails Orchestrator to begin securing your Large Language Model(LLM) deployments.
+Create a Guardrails Orchestrator to begin securing your Large Language Model (LLM) deployments.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Create a Guardrails Orchestrator to begin securing your Large Language Model(LLM) deployments. | |
| Create a Guardrails Orchestrator to begin securing your Large Language Model (LLM) deployments. |
🤖 Prompt for AI Agents
In assemblies/enabling-ai-safety-with-guardrails.adoc around line 24, fix the
spacing for the LLM abbreviation: change "Large Language Model(LLM)" to "Large
Language Model (LLM)" by inserting a space before the opening parenthesis so it
follows standard spacing conventions.
eturner24
left a comment
eturner24
left a comment
There was a problem hiding this comment.
Super minor comments, happy to approve as-is.
| The link:https://github.com/opendatahub-io/odh-model-controller/blob/incubating/config/runtimes/hf-detector-template.yaml[guardrails-detector-huggingface-runtime] is a KServe serving runtime for Hugging Face predictive text models. This | ||
| allows models such as the link:https://huggingface.co/ibm-granite/granite-guardian-hap-38m[ibm-granite/granite-guardian-hap-38m] to be used within the TrustyAI Guardrails ecosystem. |
There was a problem hiding this comment.
| The link:https://github.com/opendatahub-io/odh-model-controller/blob/incubating/config/runtimes/hf-detector-template.yaml[guardrails-detector-huggingface-runtime] is a KServe serving runtime for Hugging Face predictive text models. This | |
| allows models such as the link:https://huggingface.co/ibm-granite/granite-guardian-hap-38m[ibm-granite/granite-guardian-hap-38m] to be used within the TrustyAI Guardrails ecosystem. | |
| The link:https://github.com/opendatahub-io/odh-model-controller/blob/incubating/config/runtimes/hf-detector-template.yaml[guardrails-detector-huggingface-runtime] is a KServe serving runtime for Hugging Face predictive text models. This allows models such as the link:https://huggingface.co/ibm-granite/granite-guardian-hap-38m[ibm-granite/granite-guardian-hap-38m] to be used within the TrustyAI Guardrails ecosystem. |
This should all be on one line, but not a showstopper for release.
| } | ||
| } | ||
| ---- | ||
| + |
There was a problem hiding this comment.
| + |
This doesn't render correctly in the preview and I think you can just remove this plus sign (replace it with an empty line) to fix.
| - containerPort: 8000 | ||
| protocol: TCP | ||
| ---- | ||
| + |
There was a problem hiding this comment.
| + |
See my other comment about this plus mark
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc (1)
128-130: Expand the SAFE_LABELS parameter description for table self-containment.The table description at line 130 is minimal ("A JSON-formatted list") compared to the comprehensive narrative at lines 60–61. While the narrative provides context, the table row should be more self-descriptive to aid quick reference.
Previous reviewers flagged this in commit 7669722. Consider updating to:
A JSON-formatted list specifying safe prediction label(s); default
[0]treats label 0 as safeThis allows the table to stand alone without requiring readers to cross-reference the narrative section.
🧹 Nitpick comments (2)
modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc (2)
10-12: Clarify line wrapping for single-sentence context.Lines 10–12 describe the runtime's purpose across multiple lines in what reads as a single logical statement. Consider consolidating for readability (as previously noted).
60-61: Consider removing quotes and simplifying language for minimalist style.The phrase "constitute a 'safe' response" uses quotation marks around "safe" (flagged by prior reviewer) and could be simplified per minimalist documentation principles. Additionally, "therefore" could be removed.
Current phrasing:
The main relevant configuration parameter is the
SAFE_LABELSenvironment variable. This specifies which prediction label or labels from theAutoModelForSequenceClassificationconstitute a "safe" response and therefore should not trigger guardrailing.Suggested revision:
The main relevant configuration parameter is the
SAFE_LABELSenvironment variable. This specifies which prediction label(s) from theAutoModelForSequenceClassificationconstitute a safe response and should not trigger guardrailing.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc(4 hunks)modules/guardrails-orchestrator-detectors.adoc(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- modules/guardrails-orchestrator-detectors.adoc
🔇 Additional comments (2)
modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc (2)
53-54: SAFE_LABELS environment variable is properly quoted.The YAML correctly quotes the JSON array as a string:
value: "[0]". This ensures the environment variable is passed correctly to the application.
84-143: Configuration tables are well-structured and comprehensive.The parameter and server configuration tables clearly document the serving runtime setup, with proper default values and clear descriptions. The addition of
SAFE_LABELSto the parameters table is well-placed and aligns with the YAML example.
skrthomas
force-pushed
the
RHOAIENG-37346
branch
from
03cd14c to
b05de39
Compare
skrthomas
force-pushed
the
RHOAIENG-37346
branch
from
b05de39 to
9297d28
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
modules/detecting-hateful-and-profane-language.adoc (1)
51-56: Fix YAML indentation in ConfigMap example.The
servicekey on line 53 is indented inconsistently relative totypeon line 52. Both should align at the same indentation level as siblings underhap. The extra space beforeservice:will cause YAML parsing errors.Apply this diff to correct the indentation:
hap: type: text_contents - service: <2> + service: <2> hostname: guardrails-detector-ibm-hap-predictor.test.svc.cluster.local port: 8000 chunker_id: whole_doc_chunker
♻️ Duplicate comments (1)
modules/deploying-the-guardrails-orchestrator-service.adoc (1)
102-102: Same cross-reference anchor issue noted in previous file.Line 102 contains the same potentially broken cross-reference
<<tlsSecrets-param,tlsSecrets>>as inmodules/guardrails-orchestrator-configmap-parameters.adoc(line 84). Ensure thetlsSecrets-paramanchor exists in the related GuardrailsOrchestrator Custom Resource documentation.
🧹 Nitpick comments (2)
modules/guardrails-enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc (1)
8-29: Standardize "Guardrails Gateway" capitalization throughout the module.The document title and abstract use "Guardrails Gateway" (both words capitalized), but lines 11, 22, and 26 use "Guardrails gateway" (with lowercase 'g' on gateway). For consistency across the documentation, ensure the proper term is always capitalized as "Guardrails Gateway".
Apply this diff to standardize the capitalization:
-.Prerequisites -* You have configured the Guardrails gateway image. +.Prerequisites +* You have configured the Guardrails Gateway image.-Based on the example configurations provided in link:{odhdocshome}/monitoring-data-science-models/#configuring-the-built-in-detector-and-guardrails-gateway_monitor[Configuring the built-in detector and Guardrails gateway], the available endpoint for the guardrailed model is `$GUARDRAILS_GATEWAY/pii`. +Based on the example configurations provided in link:{odhdocshome}/monitoring-data-science-models/#configuring-the-built-in-detector-and-guardrails-gateway_monitor[Configuring the built-in detector and Guardrails Gateway], the available endpoint for the guardrailed model is `$GUARDRAILS_GATEWAY/pii`.-Based on the example configurations provided in link:{rhoaidocshome}{default-format-url}/monitoring_data_science_models/configuring-the-guardrails-orchestrator-service_monitor#configuring-the-built-in-detector-and-guardrails-gateway_monitor[Configuring the built-in detector and Guardrails gateway], the available endpoint for the model with Guardrails is `$GUARDRAILS_GATEWAY/pii`. +Based on the example configurations provided in link:{rhoaidocshome}{default-format-url}/monitoring_data_science_models/configuring-the-guardrails-orchestrator-service_monitor#configuring-the-built-in-detector-and-guardrails-gateway_monitor[Configuring the built-in detector and Guardrails Gateway], the available endpoint for the model with Guardrails is `$GUARDRAILS_GATEWAY/pii`.modules/guardrails-auto-config.adoc (1)
76-76: Capitalizeconfigmapfor consistency.Line 76 uses lowercase "configmap" but line 69 uses "ConfigMaps" (capitalized). For consistency throughout the file and aligned with Kubernetes terminology conventions, use
ConfigMapinstead.- $ oc get configmap/<auto-generated config map name> -n <your_namespace> -o yaml + $ oc get ConfigMap/<auto-generated config map name> -n <your_namespace> -o yaml
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (24)
assemblies/configuring-the-guardrails-orchestrator-service.adoc(0 hunks)assemblies/enabling-ai-safety-with-guardrails.adoc(1 hunks)assemblies/using-guardrails-for-ai-safety.adoc(1 hunks)assemblies/using-llama-stack-with-trustyai.adoc(1 hunks)enabling-ai-safety.adoc(1 hunks)modules/configuring-the-built-in-detector-and-guardrails-gateway.adoc(3 hunks)modules/deploying-the-guardrails-orchestrator-service.adoc(2 hunks)modules/detecting-hateful-and-profane-language.adoc(2 hunks)modules/detecting-pii-by-using-guardrails-with-llama-stack.adoc(2 hunks)modules/guardrails-auto-config.adoc(3 hunks)modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc(4 hunks)modules/guardrails-configuring-the-opentelemetry-exporter.adoc(1 hunks)modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc(1 hunks)modules/guardrails-detectors.adoc(0 hunks)modules/guardrails-enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc(2 hunks)modules/guardrails-filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc(1 hunks)modules/guardrails-gateway-config-parameters.adoc(1 hunks)modules/guardrails-orchestrator-configmap-parameters.adoc(1 hunks)modules/guardrails-orchestrator-detectors.adoc(1 hunks)modules/guardrails-orchestrator-parameters.adoc(2 hunks)modules/mitigating-prompt-injection-by-using-a-hugging-face-prompt-injection-detector.adoc(1 hunks)modules/sending-requests-to-the-regex-detector.adoc(0 hunks)modules/using-hugging-face-models-with-guardrails-orchestrator.adoc(0 hunks)monitoring-data-science-models.adoc(0 hunks)
💤 Files with no reviewable changes (5)
- modules/sending-requests-to-the-regex-detector.adoc
- modules/using-hugging-face-models-with-guardrails-orchestrator.adoc
- modules/guardrails-detectors.adoc
- monitoring-data-science-models.adoc
- assemblies/configuring-the-guardrails-orchestrator-service.adoc
✅ Files skipped from review due to trivial changes (1)
- assemblies/enabling-ai-safety-with-guardrails.adoc
🚧 Files skipped from review as they are similar to previous changes (10)
- modules/guardrails-configuring-the-opentelemetry-exporter.adoc
- assemblies/using-guardrails-for-ai-safety.adoc
- modules/detecting-pii-by-using-guardrails-with-llama-stack.adoc
- modules/guardrails-orchestrator-detectors.adoc
- modules/guardrails-configuring-the-hugging-face-detector-serving-runtime.adoc
- modules/guardrails-orchestrator-parameters.adoc
- enabling-ai-safety.adoc
- assemblies/using-llama-stack-with-trustyai.adoc
- modules/guardrails-deploying-the-guardrails-orchestrator-service.adoc
- modules/guardrails-filtering-flagged-content-by-sending-requests-to-the-regex-detector.adoc
🔇 Additional comments (10)
modules/guardrails-enforcing-configured-safety-pipelines-for-llm-inference-using-guardrails-gateway.adoc (2)
1-5: Critical fixes from previous review have been applied successfully.The double
.adocextension has been corrected to a single extension, the document ID has been normalized to lowercase-with-hyphens convention, and references have been updated accordingly. The document is now properly named and structured.
14-44: Procedure content is clear and well-structured.The two-step procedure (environment setup followed by example query) is practical and provides both command syntax and expected output. The curl example with realistic input and error response demonstrates PII detection effectively.
modules/detecting-hateful-and-profane-language.adoc (1)
77-82: Endpoint path inconsistency between descriptions and curl commands.Line 77 describes the endpoint as
api/v2/chat/completions-detections(plural), but the curl command at line 82 usesapi/v2/chat/completions-detection(singular). The same inconsistency appears in step 5 (line 103 vs line 108).Confirm which endpoint path is correct and update the descriptions to match the actual curl commands to avoid reader confusion.
Also applies to: 103-108
modules/mitigating-prompt-injection-by-using-a-hugging-face-prompt-injection-detector.adoc (2)
1-454: Content quality looks good; procedure is well-structured and actionable.The prerequisites are clear, both scenarios are well-documented with complete YAML examples, and the verification steps are practical. The distinction between the Orchestrator API approach (Scenario 1) and standalone Detector API approach (Scenario 2) is well articulated.
4-5: Cross-references verified and documentation structure intact.Verification confirms:
- No references to the old ID exist anywhere in the codebase (so no broken links from this change)
- The new ID is already properly integrated into the assembly file
assemblies/using-guardrails-for-ai-safety.adocline 17 via an include statement- The module is correctly positioned in the documentation structure
The refactoring is complete with no outstanding cross-reference issues.
modules/configuring-the-built-in-detector-and-guardrails-gateway.adoc (1)
1-125: Documentation structure and examples look solid.The PROCEDURE module clearly walks through deploying the built-in detector and guardrails gateway. The ConfigMap and GuardrailsOrchestrator CR examples are well-annotated and the verification steps are practical. No structural or content issues identified.
modules/guardrails-orchestrator-configmap-parameters.adoc (1)
84-84: Verify the cross-reference anchor fortlsSecretsparameter.A previous review comment (kpunwatk) flagged that the
<<tlsSecrets-param,tlsSecrets>>hyperlink doesn't work. To create a cross reference, you first need to define the location where the reference will point (i.e., the anchor). Please confirm that thetlsSecrets-paramanchor is properly defined in the GuardrailsOrchestrator Custom Resource documentation file.modules/guardrails-gateway-config-parameters.adoc (1)
1-104: Configuration reference is clear and comprehensive.The gateway configuration parameters are well-documented with practical examples. The NOTE section clearly explains constraints on detector/server combinations with multiple valid/invalid scenarios. Parameter table descriptions are concise and actionable.
modules/deploying-the-guardrails-orchestrator-service.adoc (1)
29-115: Comprehensive orchestrator configuration documentation.The expanded ConfigMap example is detailed and well-annotated. The progression from chat_generation to detectors to TLS to passthrough_headers clearly shows the configuration hierarchy. Annotations are practical and reference the reasoning behind each field. Deployment and verification steps are straightforward and actionable.
modules/guardrails-auto-config.adoc (1)
1-80: Auto-configuration guidance is clear and practical.The procedure guides users through simplified Guardrails setup with auto-detection of detectors and TLS handling. The CR example is complete with explanations of key configuration options (enableGuardrailsGateway, enableBuiltInDetectors). Verification steps using grep and viewing auto-generated ConfigMaps are straightforward. Page ID and abstract improvements enhance document discoverability.
6 participants
Description
How Has This Been Tested?
Merge criteria:
Link to docs preview: https://opendatahub-documentation--1036.org.readthedocs.build/en/1036/enabling-ai-safety/index.html
NOTE: This preview is a basic asciidoc preview. It isn't how the content will look on docs.redhat.com or odh, but its a nice way to preview content in PRs.
New TOC:
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.