In an AI-type structured output, fields appear to be generated in schema property order (result keys come back in that order too). So a field whose definition depends on another field can get filled in before the value it depends on exists. Concrete: say you have issue_found (boolean) and issue_reason (enum, must be none when issue_found is false). If issue_reason sits earlier in the property list, you get results with issue_found: false plus a real reason populated — a combo that field's own description forbids. Nothing errors, the schema validates, every value is a legal enum member. Hit this three times on different field pairs before I clocked what was happening. You can set order via PATCH by sending the properties object in the sequence you want, but the builder has no reorder control, so raw API is the only path — and PATCH on schema is a whole-object replace, so you're rebuilding the entire schema by hand and any later dashboard edit can silently revert it. Why it seems worth building: it's a UI affordance over behavior that already exists, so no new backend semantics. And the failure mode is invisible — when you see a self-contradictory result you blame the extraction model, not field order. Evaluation schemas are inherently chained (reason fields gated by booleans, a rationale field you want written first, severity depending on category), so anyone building a serious one runs into it. Ask in priority order: drag-to-reorder in the builder; a docs line stating property order determines generation order; stretch goal, declared dependencies so ordering gets validated instead of hand-managed. Semi-related gap: the builder also can't define enum values for a string field — allowed values only live in the description prose, while the API accepts a real enum array. Same shape of thing, where the UI quietly produces a weaker schema than you think you're building. Anyone else run into the ordering behavior, or am I misreading the mechanism?
