# Provider content parts: validating structure before generation

Validate string content and text/image part arrays before model execution using role checks, nested-field fixtures and explicit capability boundaries.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/provider-message-content-parts-contract/
Language: en

A multimodal request differs from text not only in computational size. At the API boundary it may contain an array of typed objects rather than one string. Malformed nested objects should be detected before expensive execution, but valid shape alone does not establish that the selected model supports images. Provider tests separate these layers and retain the actual failure source.

## Describe allowed content shapes

The [public OpenRouter schema](https://openrouter.ai/docs/api_reference/overview) shows string content and typed content parts, and associates permitted shapes with message roles. Use the specific selected schema rather than assuming every field named content accepts an array.

Your contract should identify which part types the endpoint actually handles. For a text-only model, accepting an arbitrary image object must not appear to confirm multimodal capability. Do not transfer one backend's capabilities to a whole catalog behind a shared alias.

## Separate validation stages

The first layer is valid JSON. The second is message and nested-field shape. The third is whether the selected model allows that part type. Source retrieval, preparation and execution may follow. Keep these stages distinct in diagnosis even if external error messages remain brief.

[RFC 8259](https://www.rfc-editor.org/rfc/rfc8259.html) defines JSON representation rather than the meaning of image_url or a user role. Successful parsing establishes only the first layer. A syntactically valid client object can remain invalid for an interface because of a wrong type or missing nested property.

## Create a small input matrix

Begin with one short text part. Add another text part, then a synthetic image reference from a controlled source if that capability is advertised. Negative variants change one feature: unknown type, missing URL, wrong nested value type or an impermissible role.

Record expected results in advance. A file-download failure is not proof of a schema error if structure already passed validation. Real user images are unnecessary. Bound external requests and choose sources that disclose neither internal addresses nor secrets.

## Check nested constraints

The [JSON Schema object reference](https://json-schema.org/understanding-json-schema/reference/object) describes required and additionalProperties. They distinguish mandatory fields from extra properties, but a service's behavior depends on its full schema. Allowed fields may also differ across supported versions.

Check whether the adapter preserves part order and avoids flattening the array into one text string. Structural loss may remain invisible in a simple test, especially when both parts contain ordinary text. Before-and-after adaptation comparison helps locate the change.

## Preserve conformance limits

Passing a structural fixture does not establish image understanding, support for every dimension or answer quality. Those need separate model tests with known expected results and resource limits. Likewise, one model's successful answer does not establish every service replica's capabilities.

The [multimodal GPU-hosting guide](/journal/multimodal-gpu-hosting/) explains compute context, while [Qwen3-VL assessment](/journal/qwen3-vl-vram-requirements/) covers artifact selection. They complement the content-part contract while keeping request shape, source delivery and useful model output distinct.