Input control defines how you pass data from a flow to a guardrail. Correct input setup ensures consistent evaluation per record:
-
Pass the correct context for evaluation
-
Combine structured record data with supporting text
-
Include documents/images only when supported
Note
When providing a raw file as input, map the actual file blob data to the blobKey field to pass its contents. For example, if your file blob is stored in raw_data, map blobKey to raw_data (where raw_data contains the full binary/base64 file data, not a file path or URL).
The platform determines the mode based on your mappings:
-
Record (JSON): Decisions depend on structured flow data. When you pass the current flow record as structured data, the guardrail receives a stringified JSON version of the record.
-
Text: Tells the guardrail to evaluate plain text (instructions or content).
-
Blob (files): Indicates that the model must evaluate files, such as PDFs and images. Multiple files are allowed per run, subject to model support and limits.
-
Mixed: Consider a combination of Record + Text + Blob in one request. This mode is common when you want structured data plus explanatory text or reference documents.
Input mapping: The mapping panel constructs what the guardrail evaluates. It contains separate destinations for each of the following input types:
-
Record data
-
Text
-
Files/blobs
-
Conversation/session identifier (optional, where supported)
Response mapping: Enter response mappings to write guardrail results back into your record for downstream steps to reference:
-
Flagged
-
Categories/entities/triggers
-
Confidence/score
-
Explanation (custom policy)
Validate the mapped output in the Preview to after making any changes.
Note
Guardrail mappings have clearly separate destinations for record, text, files, and an optional conversation identifier. Avoid using unsupported file types, which will result in a record failure.