AWSAWS Certified Generative AI Developer - Professional2026-101.3 Implement data validation and processing pipelines for FM consumption
Validate native payloads before model invocation
Completed by the knowledge check
Learning objective
Validate model-specific InvokeModel JSON payloads against required request schemas.
Core idea
Valid JSON is only the first gate for InvokeModel. Amazon Bedrock accepts a JSON request body, but the selected model defines what the fields mean and which fields are required. A payload that works for one model family can fail for another even when both generate text.
Bind the native request validator to the same model selection that chooses the serializer and response parser. Validate the complete combination before invocation. Model routing is covered in 1.2.3; this lesson focuses on the contract at the native inference boundary.
Distinguish two schemas: the schema of the request you send to Bedrock and any schema you ask the model’s generated data to follow. A structured-output configuration cannot repair a missing required request parameter. Validation of transformed business data belongs to 1.3.10.
How it works
Check the transport envelope
InvokeModel takes modelId, body, contentType, and optional settings such as accept. The request contentType must be application/json; accept describes the desired response MIME type and defaults to application/json.
The API documents a maximum body length of 25,000,000 bytes for both the request and the response. Check the serialized byte length, not the character count of the unencoded source text. Escapes and encoded multimodal data can change the final size. Passing that byte ceiling does not establish that the input fits a model’s token context.
Serialize the native object once into the representation your SDK expects for body. Avoid double serialization: a JSON string containing escaped JSON is not the native object described in the model documentation. Keep malformed serialization separate from a model-schema error so that diagnosis identifies the broken boundary.
Validate required fields by model family
For the Anthropic Claude Messages API, the documented required top-level fields are anthropic_version, max_tokens, and messages. The version value must be bedrock-2023-05-31. Each message has a role of user or assistant and message content in the documented native representation. Application instructions belong in the native system field.
The following native body fragment demonstrates the required fields and a text block:
{
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 512,
"messages": [
{
"role": "user",
"content": [{ "type": "text", "text": "Summarize this paragraph." }]
}
]
}The output limit 512 illustrates a request setting, not a universal maximum. Claude model versions have different maximum values for max_tokens. Validate the chosen version instead of applying a family-wide ceiling recalled from another deployment.
For Amazon Titan Text, the required prompt field is inputText. Generation settings belong in the optional textGenerationConfig object. Its names include maxTokenCount, temperature, topP, and stopSequences. A Titan body is therefore structurally different from a Claude Messages body even though both arrive through InvokeModel.
Keep these native field names distinct from Converse. Converse uses inferenceConfig.maxTokens, not max_tokens or textGenerationConfig.maxTokenCount. Native Claude text blocks use type: "text" and text; Converse text blocks use the union member text. See 1.3.6 for that shared-envelope contract.
Enforce constraints and combinations
Required-field checks are insufficient. Validate field types, allowed values, nesting, and relationships between parameters. Reject a string where an output-token setting requires an integer. Validate each content block according to its type instead of checking only that content is an array.
AWS documents that Claude Sonnet 4.5 and Claude Haiku 4.5 accept either temperature or top_p, but not both. A validator that checks each parameter independently can approve an invalid combination. Apply that restriction to the named versions rather than treating it as a rule for every Claude version.
Titan Text documents temperature between 0 and 1 and topP greater than 0 and at most 1. The exclusive lower bound matters: topP: 0 does not pass the documented range. Native parameter similarity is not a license to reuse another provider’s defaults or bounds.
Prefer a deliberate allowlist for each supported model configuration. An unexpected field can signal that a caller mixed two interfaces. If you support provider extensions, version their allowed names and combinations explicitly; do not silently discard unknown fields and change the requested behavior.
Bedrock returns ValidationException with HTTP 400 when input fails its constraints. Treat a reproducible contract failure as something to correct before resubmission, not a transient capacity failure. The broader retry and fallback policy is in 1.2.5.
Pair the request with its response parser
The InvokeModel response body remains model-specific. Titan Text returns inputTextTokenCount and a results array containing outputText, tokenCount, and completionReason. Claude Messages returns a content array, stop_reason, and token counts under usage.input_tokens and usage.output_tokens.
Read completion status before accepting a result. Titan’s LENGTH indicates truncation from the configured response length; Claude’s max_tokens indicates an output-token boundary. A successful HTTP response does not mean that a generated record is complete. Preserve that distinction when normalizing native responses into an application result.
Key distinctions and trade-offs
JSON parsing versus native-schema validation: Parsing proves that the bytes form JSON. Schema validation proves that the native request has the selected model’s fields, types, and constraints. Neither establishes that the model’s answer is factually correct.
Shared API operation versus shared payload: InvokeModel standardizes the invocation operation. It does not standardize prompt fields or generated-response shapes. Converse offers a consistent messages interface for supported models; see 1.3.6. To move a caller that constructs native Claude or Titan bodies to Converse, change its serializer and response parser along with the operation.
Static rules versus configuration-specific rules: Required fields can be shared across a family, while maximum output lengths and parameter compatibility can vary by model version. Keep those layers separate so a version change does not inherit an invalid rule.
Architecture / decision scenario
A document-summary service supports a Claude Messages configuration and a Titan Text configuration. It stores one application request internally, then chooses a validated native adapter for the selected model.
The Claude adapter produces anthropic_version, max_tokens, and messages. The Titan adapter produces inputText and textGenerationConfig. Both check serialized size before calling InvokeModel, but each checks its own token-setting bounds and response fields.
A configuration change accidentally passes Claude’s max_tokens into the Titan body. The local allowlist rejects it before invocation. Another change sets both sampling controls for Claude Sonnet 4.5; the combination rule rejects that request even though each value is individually in range.
For accepted requests, the response adapter checks completionReason or stop_reason before releasing the summary. It records an incomplete result separately from invalid input, allowing the application to adjust its output budget without retrying a malformed request unchanged.
Common exam traps
- Treating JSON parse success as native-schema validation.
- Reusing a Converse body unchanged with
InvokeModel. - Omitting
anthropic_versionfrom a Claude Messages request. - Using
messagesas Titan Text’s native prompt field. - Validating sampling parameters individually but ignoring version-specific combinations.
- Assuming the API byte ceiling is the model’s token context limit.
- Parsing every native response as
output.message.
What to remember
- Select the validator, serializer, and parser together with the model.
- Validate required fields, exact names, types, ranges, and combinations.
- Measure serialized bytes and model tokens as separate constraints.
- Correct contract failures before resubmitting them.
- Check native completion status before accepting generated data.
Knowledge check
A configuration error routes a well-formed Claude Messages body to an Amazon Titan Text model through InvokeModel. The team wants the mismatch caught before invocation. Which check catches it?
InvokeModel body ceilingInvokeModel standardizes the operation, not the payload. Titan Text expects inputText and textGenerationConfig , so a parseable Claude body is still not a Titan request; only a validator bound to the selected model knows that. An output schema governs generated data and cannot repair the request.A native Claude Messages request includes messages and max_tokens but omits anthropic_version. Bedrock returns ValidationException with HTTP 400. What should the caller do?
anthropic_version set to bedrock-2023-05-31 . A validation error is a reproducible contract failure: resubmitting the same body, to any target, fails again, so the request must be corrected first.A service validates native Claude requests. For a Claude Sonnet 4.5 configuration, a caller sets both temperature and top_p, each within its documented range. Which validation rule fits?
temperature or top_p , not both, and that the restriction does not apply to older models. Validation must cover version-specific combinations, not just each field’s range, and silently dropping a field changes the requested behavior.A Titan Text InvokeModel call returns HTTP 200. The response’s results[0].completionReason is LENGTH. How should the response adapter treat the summary?
output.message , then release itLENGTH means the response was cut off at the configured response length, so a successful call can still carry an incomplete record. Recording that outcome apart from input errors lets the application adjust its output budget; resending unchanged reproduces the cut, and output.message is the Converse response shape, not Titan’s native one.