A 311 backend must reject malformed resident-assistant requests before any foundation model is invoked. Where should that validation be enforced?

A 311 backend must reject malformed resident-assistant requests before any foundation model is invoked. The correct enforcement point is API Gateway: validate request schemas and required fields there so invalid payloads never reach the Bedrock invocation path. Gateway-level schema checks protect civic cost, reduce abuse surface, and keep bad JSON out of logs and downstream Lambda handlers that would otherwise waste FM tokens or pollute observability.

Skipping validation and letting Bedrock interpret every malformed payload as creative prompt material fails by concept: the FM is not a schema validator, and malformed input increases injection and cost risk. Validating only after writing the raw payload into the production RAG index fails because untrusted junk has already contaminated retrieval storage. Relying solely on end-user browsers for JSON shape checks fails because client-side controls are bypassable and provide no server-side assurance for a public 311 API.

Exam caveat: API Gateway validation complements—but does not replace—application-level authorization, WAF rules, and Bedrock Guardrails. Schema validity means the request is well-formed, not that the content is safe or in-policy; malicious but schema-valid prompts still need content and prompt-injection controls after they pass the gateway.

Operational check: send deliberately malformed 311 assistant payloads (missing required fields, wrong types) and confirm API Gateway returns 4xx without CloudWatch evidence of Bedrock InvokeModel; send a schema-valid request and confirm it proceeds; review metrics for validation error rates as an early signal of client bugs or probing.