Structured-output workflows have a weird failure mode:
A schema can be valid JSON Schema, pass local checks, look reasonable in code review… and still fail once it hits a provider API.
The problem is that “valid schema” and “accepted by OpenAI / Anthropic / Gemini structured-output constraints” are not always the same thing.
Examples I kept running into:
<ul>
<li>unsupported schema keywords</li>
<li>provider-specific nesting limits</li>
<li>optional vs required field mismatches</li>
<li>enum/object-shape edge cases</li>
<li>schemas that pass local validation but fail at runtime</li>
<li>schema drift between prompt code, app code, and CI</li>
</ul>
That pushed me toward a simpler pattern:
Treat structured-output schemas like production contracts.
Not just prompt helpers.
Not just type hints.
Not just Zod/Pydantic objects sitting near the API call.
Actual contracts that should be checked before runtime.
The workflow I wanted:
<ol>
<li>define the schema</li>
<li>lint it against provider-specific constraints</li>
<li>catch portability issues early</li>
<li>fail in CI before production API calls fail</li>
<li>keep the schema usable across providers where possible<img src="https://media.daily.dev/image/upload/s--StxZEO85--/f_auto/v1782676477/ugc/content_d92a9b25-c158-4ee6-b26d-02a2259d4e2f?_a=BAMAMicg0" alt="SchemaFit Ensure compatible structured outputs.png"></li>
</ol>
That is what I’m testing with SchemaFit:
<a href="https://schemafit.danmercede.com/" target="_blank" rel="noopener nofollow">https://schemafit.danmercede.com/</a>
It is meant to sit before structured-output API calls and act more like a schema compatibility gate than a full framework.
Where I think this fits:
<ul>
<li>OpenAI / Anthropic / Gemini structured-output workflows</li>
<li>CI checks for agent or LLM app schemas</li>
<li>teams using Instructor, BAML, LiteLLM, Vercel AI SDK, Pydantic, or Zod</li>
<li>systems where schema drift causes production issues</li>
<li>provider-portability testing</li>
</ul>
Where it probably does not fit:
<ul>
<li>quick prototypes</li>
<li>one-off prompts</li>
<li>single-provider projects with simple schemas</li>
<li>teams already fully abstracted behind a higher-level framework</li>
</ul>
The broader point:
Structured output is only reliable if the contract is validated before the model call.
Curious how others are handling this.
Are you checking structured-output schemas before runtime, or mostly discovering provider-specific failures when the API rejects them?

Squad for devs building apps with GenAI and LLMs! Connect, share, exchange ideas, and get feedback. 

Build With GenAI

JSON Schema validation for LLM structured outputs is more complex than standard schema validation — a schema can be valid JSON Schema yet still be rejected by OpenAI, Anthropic, or Gemini due to provider-specific constraints like unsupported keywords, nesting limits, or enum edge cases. The post advocates treating structured-output schemas as production contracts and validating them against provider-specific rules before runtime, ideally in CI. SchemaFit is introduced as a tool designed to act as a schema compatibility gate for structured-output workflows, catching portability issues early across providers and tools like Instructor, BAML, Pydantic, and Zod.

Your JSON Schema can be valid and still fail an LLM provider