docs: clarify AI inference validation scope (praxis-proxy#624)

Signed-off-by: Francisco Javier Arceo <farceo@redhat.com>

Author: franciscojavierarceo

.claude/CLAUDE.md

@@ -208,6 +208,11 @@ See `docs/filters/extensions.md` for the full guide.
    `tests/integration/tests/suite/examples/`
 7. Run `cargo xtask sync-example-readme --fix`
 
+For AI inference filters, follow
+`docs/developing/adding-filters.md#ai-inference-validation`:
+validate only fields needed for local proxy behavior and
+leave backend-owned API semantics to the inference backend.
+
 ## Adding a Protocol
 
 1. Implement `Protocol` trait under `protocol/src/`

docs/developing/adding-filters.md

@@ -21,3 +21,15 @@ first.
 All testing requirements from [conventions.md](conventions.md#testing)
 apply. A feature without tests and an example is not
 complete.
+
+## AI Inference Validation
+
+AI inference filters should validate only fields they
+need for local proxy behavior, such as routing,
+transformation, persistence, metering, or security
+policy decisions. Do not validate backend-owned API
+semantics such as required inference fields, parameter
+types or ranges, nested message/tool structures, or
+unknown extension fields unless the filter must act on
+that value itself. Preserve the original request and
+let the inference backend perform protocol validation.

docs/proposals/00484_anthropic-messages-api-filters.md

@@ -60,18 +60,18 @@ The scope covers five capabilities:
 
    [mid-conversation system messages docs]: https://platform.claude.com/docs/en/build-with-claude/mid-conversation-system-messages
 
-2. **Request validation**: validate only the fields
-   that affect gateway/filter behavior: `messages`
-   is non-empty, `max_tokens` is present and > 0,
-   and `model` is non-empty. All other fields are
-   forwarded to the inference backend unmodified —
-   the backend handles parameter ranges, model
-   availability, role ordering, and content-level
-   validation. Unlike the Responses API, `Anthropic`
-   Messages does not require persistence or stateful
-   orchestration, so the validation filter is
-   lighter: no shared state struct, no store
-   initialization.
+2. **Request validation**: validate only request
+   properties the gateway or filters must act on
+   locally. All other fields are forwarded to the
+   inference backend unmodified; the backend handles
+   Anthropic API requirements such as required fields,
+   parameter types and ranges, model availability, role
+   ordering, and content-level validation. Unknown
+   fields are expected and must be preserved. Unlike
+   the Responses API, `Anthropic` Messages does not
+   require persistence or stateful orchestration, so
+   the validation filter is lighter: no shared state
+   struct, no store initialization.
 
 3. **Format transformation**: bidirectional conversion
    between `Anthropic` Messages and `OpenAI` Chat