Schemas

Table of Contents

Schema profile files live in /schemas.
These profiles validate JSON Schema documents against provider requirements.

Versioning Strategy

Provider docs do not currently publish stable schema-profile versions.
This project uses a baseline version in YYYYMM format:

  • 202602 means the profile is aligned to the February 2026 requirement baseline.
  • When provider requirements change, add new files with a newer baseline (for example 202607) instead of mutating old files.

Requirement Reference Enums

Use these enum-like identifiers in code when selecting requirement sets:

  • OPENAI_202602
  • GEMINI_202602
  • GEMINI_202503 - older version for Gemini 2.0 models
  • MINIMAL_202602

Available Profiles And Restrictions

  • Gemini restrictions are documented as model/API behavior and are not split by SDK language.
  • openai_202602.yaml: OpenAI Structured Outputs subset. Enforces root object style and keyword subset. Additional runtime checks are still required for depth/property/string/enum limits.
  • gemini_202602.yaml: Gemini JSON Schema subset from the documented support table.
  • gemini_202503.yaml: Gemini 2.0-focused profile. Same subset as gemini_202602 plus required propertyOrdering for object schemas.
  • minimal_202602.yaml: Lowest common denominator across OpenAI and Gemini. This is the most portable profile.

Provider Requirement Pages

Validation Model

Use a two-phase validation flow:

  • Phase 1: validate the candidate schema against one profile meta-schema in /schemas.
  • Phase 2: run provider-specific code checks for constraints not fully representable in JSON Schema (for example OpenAI global budgets and model-target checks).

Passing only phase 1 is not sufficient for full provider compliance.

Table of contents