Ordering Guard & Validation Battery
We built this battery because every LLM vendor on Earth agreed on exactly one thing — conversation history is an array of items — and then, having exhausted their capacity for consensus, went off and invented their own conflicting rules for what that array is allowed to look like.
Beyond that single, trivial concession, they agree on literally nothing. Anthropic demands that thinking blocks precede tool calls within an assistant turn — unless you are in adaptive mode, in which case Anthropic demands you stop caring (source). Google Gemini 3 hard-fails with a 400 Bad Request if you omit a thought_signature on your first function call, while Gemini 2.5 merely considers it a polite suggestion (source). Amazon Nova rejects requests if conversation roles fail to alternate strictly between user and assistant (source). DeepSeek, Kimi, MiniMax, and Qwen each enforce bespoke, mutually incompatible rules about whether historical reasoning traces must be preserved verbatim, pruned after the latest turn, or stripped entirely upon model switch (DeepSeek, Kimi K3, MiniMax, Qwen 3).
IMPORTANT
Rules are ADVISORY by default. This catalog's rules were derived from vendor DOCUMENTATION. A live audit measuring each rule against its own vendor's native API found that 16 of 17 blocked turn state the vendor actually accepts — including converse-text-before-tool-use, the rule named after Bedrock Converse, tested on Converse, which accepted both orderings. Only thought-signature-required (Gemini 3) was confirmed enforced.
So a rule now REPORTS by default and gates only when you set severity: 'blocking' on it. You keep the catalog's knowledge — which primitive broke which vendor's stated contract — without rejecting dispatches the model would have served. Opt into blocking per rule once you have verified the constraint on the surface you dispatch through; see Which API Surface a Rule Applies To.
What it is
A declarative rule engine that validates — and, where it's safe to, repairs — the ordering of Message, Thought, and ToolCall primitives against per-vendor profiles before your executor ever sees them. You describe what a model actually requires as data (an OrderRule, an AlternationRule, a PreservationRule — seven typed shapes cover every rule this catalog has found); the battery evaluates your real turn state against it and either lets the dispatch through, fixes what it safely can, or tells you exactly which primitive broke which rule and why.
Nobody has a native mental model for why a Thought needs to sit before a ToolCall for one vendor and gets silently discarded by another, because there isn't a good reason for the industry to have landed here — it's the accumulated residue of a dozen labs solving "how do I resume a reasoning trace" in a dozen mutually unaware rooms. This battery doesn't fix that. It just means you stop discovering it by getting a 400 in production, or worse, no error at all.
Left ungoverned, primitive ordering degrades in two distinct ways. Vendor rules get violated outright — a signature omitted, a role sequence broken, historical reasoning silently dropped across a turn. And separately, a raw timestamp sort (createdAt) is not a safe substitute for a real ordering guarantee: two primitives stamped during the same executor tick sort arbitrarily, and nothing about that failure looks like a bug until an engineer is debugging why a model just rejected its own previous turn.
The ordering_guard battery makes both of those problems declarative, testable, and — for the subset that's safe to auto-repair — self-healing before your executor ever fires.
Four rules that came from measurement, not documentation
Most of this catalog encodes what vendors SAY they require. Four rules encode what they were OBSERVED to do, and two of those catch a failure mode with no error attached to it at all — the provider returns HTTP 200 and simply produces nothing, or silently drops a field:
| Rule | What it caught |
|---|---|
tool_identity | A functionResponse naming a tool the request doesn't declare. Gemini returns an empty candidate a large fraction of the time; a gateway forwards it as finish_reason: stop with content: null and no error, so the caller records a successful turn that produced nothing. |
schema_integrity | A tool schema whose required names a key its properties omits — unsatisfiable. Nova answers with a normal 200 that just omits the field; 25 production responses were silently missing it. |
tool_call_id_format | An id over 64 chars (Codex 400s) or outside [A-Za-z0-9_-] (Converse rejects). Both fail on every credential, so one bad id exhausts a provider pool. |
non_empty_turn | An assistant turn carrying neither content nor a tool call. Mistral 400s explicitly; Gemini answers a terminal thought-only turn with MALFORMED_RESPONSE. |
If you use this model, you probably need —
There's only one question that matters when you're wiring this up: I'm dispatching to model X — what validation recipe do I enable?
The table below answers it for the vendor's native API. If your traffic goes through an OpenAI-compatible gateway in front of a non-OpenAI vendor, read Which API Surface a Rule Applies To first — the gateway may be performing these normalisations itself, which changes what a recipe can tell you.
| If you're dispatching to... | You probably need | Because |
|---|---|---|
Claude 4.5 or earlier, thinking:{type:'enabled'} | 'anthropic-manual-thinking' | Anthropic hard-enforces thinking-block-first in manual mode. (source) |
| Claude 5.x, or Opus/Sonnet 4.6+ on adaptive thinking | 'anthropic-adaptive-thinking' | Thinking-first requirement is relaxed; manual recipe will false-positive. (source) |
| Claude via Bedrock Converse | Hosted recipe unioned with 'bedrock-converse' | Bedrock Converse adds a hosting-layer requirement: all text blocks before any toolUse block — observed in practice, not spelled out in AWS's own reference. (source) |
| Gemini 3 (incl. 3 Flash, excl. 3 Pro Image) | 'gemini-3' | Missing thoughtSignature on the first functionCall is a hard 400 rejection. (source) |
| Gemini 2.5 | 'gemini-2-5' | Same signature exists but is advisory only; the Gemini 3 recipe would over-block. (source) |
| Amazon Nova (any version) | 'nova' | Strict user/assistant alternation; unusually intolerant of sequential same-role messages. (source) |
| DeepSeek R1 / V3.1 / V3.2 reasoner / V4 | 'deepseek-thinking' or 'deepseek-v4' | Historical reasoning content must be resent every turn or context continuity breaks. (source) |
| DeepSeek V3 base (non-thinking) | 'deepseek-v3-base' | No reasoning capability; avoids paying for an unneeded preservation check. |
| Kimi K2 (K2 / K2.5 / K2.6 / K2.7 Code) | 'kimi-k2' | Guard against dropped tool calls in history (a confirmed historical template regression). (source) |
| Kimi K3 | 'kimi-k3' | Extends full-history preservation to both tool calls and reasoning content. (source) |
| MiniMax M2 / M3 | 'minimax-m2' or 'minimax-m3' | Dropping <think> blocks between tool calls measurably degrades output; the vendor tells you not to do it. (source) |
Qwen 3.x (enable_thinking) | 'qwen-3' | Reasoning older than the latest non-tool-call user turn is pruned; recent reasoning is preserved. (source) |
| Qwen 2.5 and earlier | 'qwen-2-5' | No native thinking template concept; standard tool-result adjacency baseline only. |
| Gemma 4 | 'gemma-4' | Strict alternation + non-blocking advisory against resending stale prior-turn thinking. (source) |
| Gemma 3 | 'gemma-3' | Strict alternation across its two-role (user/model) conversational structure. |
| Llama 3.x | 'llama-3' | No parallel tool calls supported; caps tool calls at 1 per turn. (source) |
| Llama 4 | 'llama-4' | Parallel tool calls supported; drops the Llama 3 cardinality cap. (source) |
| GPT-OSS (Harmony format) | 'gpt-oss' | Harmony spec requires every function tool call to carry a commentary-channel tag. (source) |
| Codex / GPT-5-Codex (Responses API) | 'codex-responses' | Replayed reasoning items carry encrypted blobs that must remain unmodified across turns. (source) |
| IBM Granite 3.x | 'granite-3-x' | Requires a producer-set role-remap marker confirming Granite 3.x's split tool-call/tool-response wire roles. (source) |
| IBM Granite 4.x | 'granite-4-x' | Requires a producer-set role-remap marker confirming Granite 4.x's inline tool-call/remapped-response wire roles. (source) |
| OpenAI-shape baseline (Mistral, Nemotron, Cohere, Phi, MAI, Jamba, Falcon, Palmyra, ERNIE, GPT-4 legacy) | The matching family key (e.g. 'mistral') or atomic profile 'openai_shape_baseline' | Standard tool-calling baseline: tool results live on ToolCall, disallowing intervening messages. |
| xAI Grok | 'grok' (or atomic profile 'permissive') | Genuinely documented as having zero role-order limitations. (source) |
| ByteDance Seed, Meta Muse Spark / Glimmer | Matching baseline recipe (e.g. 'bytedance-seed') | UNCONFIRMED placeholders. Vendor documentation gaps exist; verify before trusting in enforce mode. |
The Gemma 4 and DeepSeek V4 reality check
If you think ordering validation is an academic exercise in pedantry, consider recent history:
- Google Gemma 4's official launch chat template shipped with severe structural bugs in
chat_template.jinjathat broke tool-calling multi-turn conversations and turn-tag balance, causing thought-channel leakage into visible output until patched. - DeepSeek V4 community templates shipped with missing tool-role handling that silently discarded tool definitions and tool-result messages before dispatch—a catastrophic silent data loss failure mode rather than a clean 400 rejection.
- Kimi K2's early chat template suffered regressions that dropped historical tool calls across multi-turn sessions.
Model vendors regularly ship broken chat templates. This battery is your insurance policy.
Guides & Deep Dives
- Which API Surface a Rule Applies To: Read this before enabling a recipe. An ordering rule is a claim about a model reached through a specific API, not about the model. A gateway that translates your request into the vendor's native shape may already perform the normalisations these rules check for — in which case the guard is evaluating turn state the vendor never sees.
- Two Operating Modes: Understand the difference between strict validation (
enforce) and automated timeline repair (mutate), review available repair strategies, and see quick start wiring examples. - Atomic Behaviors Catalog: Browse the catalog of 16 granular profile rules that validate individual constraints like role alternation, thinking order, and adjacency.
- Rule Types Reference: Detailed specification of the seven declarative rule contracts (
OrderRule,RequiredMetadataRule,AlternationRule,AdjacencyRule,PreservationRule,RoleRemapRule,StaleContentAdvisoryRule). - Family Recipes Catalog: The complete matrix of all 38 pre-configured model family recipes and their composed atomic behaviors.
- Gemini Sentinels & Replay: Learn how to handle Gemini 3's mandatory thought signatures during history translation or model switching via documented bypass sentinels and automated fallback repair.
- Advisories & Placeholder Recipes: How non-blocking advisories work, how to selectively disable them, and guidance on unconfirmed baseline recipes.
- Writing a Profile & Recipe: Step-by-step instructions on composing custom family recipes, authoring new atomic behavior profiles, and utilizing extensibility escape hatches.