--- url: 'https://adk.nht.io/batteries/validation/recipes.md' description: >- Complete reference matrix of all 38 pre-configured model family recipes in the validation battery and their composed atomic behaviors. --- # Family Recipes Catalog ## LLM summary — Family Recipes Catalog * Reference catalog for all **38 family recipe keys** supported by the validation battery. * Middleware accepts recipe keys directly in `profiles: ['']`. * Family recipes are pure data compositions of atomic behaviors (e.g. `openai_shape_baseline`, `strict_alternation`, `thinking_before_tool_use`, `full_history_preservation:`). * Covers Anthropic, Gemini, Nova, Bedrock, DeepSeek, Qwen, GLM, Kimi, MiniMax, Mistral, Llama, Nemotron, Gemma, OpenAI/GPT-OSS, Cohere, Phi, Granite, Grok, and unconfirmed baselines. Family recipes represent concrete model deployments. Rather than authoring custom rule arrays from scratch, configure your guard middleware with any of the 38 pre-defined family recipe keys. Thirty-eight is not a claim that we've catalogued every vendor on Earth — it's how many mutually incompatible tool-calling conventions our own research pass turned up before we stopped counting and started shipping. It's a floor, not a census, and it grows every time we go looking again or a new lab invents a new way to disagree. When passed as strings in `OrderingGuardOptions.profiles`, recipe keys are resolved and composed automatically by the middleware. ## Complete Family Recipes Matrix | Recipe Key | Composed Atomic Behaviors | Description / Model Invariants | | ----------------------------- | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | `anthropic-manual-thinking` | `thinking_before_tool_use`, `payload_field_preservation:signature` | Claude 4.5 and earlier manual thinking mode: thoughts must precede tool calls in the active turn; thought signatures must remain stable. | | `anthropic-adaptive-thinking` | `payload_field_preservation:signature` | Claude 5.x and adaptive thinking mode: relaxed thinking placement; thought signatures must remain stable. | | `gemini-3` | `thought_signature_required`, `function_response_adjacency` | Google Gemini 3 and 3 Flash: mandatory `thoughtSignature` on first `functionCall`; messages may not immediately follow tool calls. | | `gemini-2-5` | `thought_signature_advisory`, `function_response_adjacency` | Google Gemini 2.5: advisory `thoughtSignature` on first `functionCall`; messages may not immediately follow tool calls. | | `nova` | `strict_alternation`, `openai_shape_baseline` | Amazon Nova: strict user/assistant role alternation; messages may not immediately follow tool calls. | | `bedrock-converse` | `converse_text_before_tool_use` | AWS Bedrock Converse hosting layer: within one assistant turn, all text messages must precede any tool call. | | `deepseek-v3-base` | `strict_alternation`, `openai_shape_baseline` | DeepSeek V3 (non-thinking): strict role alternation; messages may not immediately follow tool calls. | | `deepseek-thinking` | `strict_alternation`, `full_history_preservation:thought` | DeepSeek R1 / V3.1 / V3.2 reasoner: strict alternation; historical reasoning traces must be preserved across turns. | | `deepseek-v4` | `strict_alternation`, `full_history_preservation:thought` | DeepSeek V4 (Pro/Flash): strict alternation; historical reasoning traces must be preserved across turns. | | `qwen-2-5` | `openai_shape_baseline` | Alibaba Qwen 2.5 and earlier: standard tool-result adjacency baseline. | | `qwen-3` | `openai_shape_baseline`, `reasoning_pruned_after_latest_turn` | Alibaba Qwen 3.x (`enable_thinking`): recent reasoning preserved; historical reasoning older than latest user turn may be pruned. | | `glm-4-5` | `openai_shape_baseline` | Z.AI GLM-4.5: standard tool-result adjacency baseline. | | `glm-4-7` | `openai_shape_baseline`, `payload_field_preservation:clear_thinking` | Z.AI GLM-4.7 and GLM-5: preserved thinking flag (`clear_thinking`) kept stable across iterations. | | `kimi-k2` | `openai_shape_baseline`, `full_history_preservation:toolCall` | Moonshot Kimi K2 family: historical tool calls must never be dropped across multi-turn sessions. | | `kimi-k3` | `openai_shape_baseline`, `full_history_preservation:toolCall`, `full_history_preservation:thought` | Moonshot Kimi K3: preserves both historical tool calls and reasoning traces across turns. | | `minimax-m2` | `openai_shape_baseline`, `full_history_preservation:toolCall`, `full_history_preservation:thought` | MiniMax M2 / M2.1 / M2.7: tool-call and reasoning trace preservation across multi-turn dispatch. | | `minimax-m3` | `openai_shape_baseline`, `full_history_preservation:toolCall`, `full_history_preservation:thought` | MiniMax M3: tool-call and reasoning trace preservation across multi-turn dispatch. | | `mistral` | `openai_shape_baseline` | Mistral / Devstral: standard tool-result adjacency baseline. | | `llama-3` | `openai_shape_baseline`, `single_tool_call_per_turn` | Meta Llama 3.x: maximum 1 tool call per assistant turn (no parallel tool execution). | | `llama-4` | `openai_shape_baseline` | Meta Llama 4: standard tool-result adjacency baseline (parallel tool execution allowed). | | `nemotron` | `openai_shape_baseline` | Nvidia Nemotron: standard tool-result adjacency baseline. | | `gemma-3` | `strict_alternation` | Google Gemma 3: strict two-role (`user`/`model`) alternation. | | `gemma-4` | `strict_alternation`, `stale_thinking_advisory` | Google Gemma 4: strict alternation + non-blocking advisory against resending stale prior-turn thinking. | | `gpt-oss` | `harmony_commentary_channel` | OpenAI GPT-OSS: every function tool call must carry a Harmony commentary-channel tag. | | `codex-responses` | `payload_field_preservation:encrypted_content` | OpenAI Codex / Responses API: reasoning encrypted content must remain stable across turns. | | `cohere-command-r` | `openai_shape_baseline` | Cohere Command R / R+: standard tool-result adjacency baseline. | | `phi` | `openai_shape_baseline` | Microsoft Phi: ChatML format, standard tool-result adjacency baseline. | | `mai` | `openai_shape_baseline` | Microsoft Foundry MAI-Thinking / MAI-Code: standard tool-result adjacency baseline. | | `jamba` | `openai_shape_baseline` | AI21 Jamba: standard tool-result adjacency baseline. | | `falcon` | `openai_shape_baseline` | TII Falcon: standard tool-result adjacency baseline. | | `palmyra` | `openai_shape_baseline` | Writer Palmyra: standard tool-result adjacency baseline. | | `ernie` | `openai_shape_baseline` | Baidu ERNIE: standard tool-result adjacency baseline. | | `gpt-4-legacy` | `openai_shape_baseline` | OpenAI legacy GPT-4 (end-of-life): standard tool-result adjacency baseline. | | `bytedance-seed` | `openai_shape_baseline` | ByteDance Seed / Doubao (**UNCONFIRMED baseline guess**): verify before relying on in `enforce` mode. | | `muse-spark` | `openai_shape_baseline` | Meta Muse Spark (**UNCONFIRMED baseline guess**): verify before relying on in `enforce` mode. | | `muse-glimmer` | `openai_shape_baseline` | Meta Muse Glimmer (**UNCONFIRMED baseline guess**): verify before relying on in `enforce` mode. | | `granite-3-x` | `role_remap_split_tool_roles` | IBM Granite 3.x: producer must set a role-remap marker confirming its split tool-call/tool-response wire roles. | | `granite-4-x` | `role_remap_inline_tool_call` | IBM Granite 4.x: producer must set a role-remap marker confirming its inline tool-call, remapped-response wire roles. | *'grok' is a recognized profile key that resolves directly to 'permissive'. It is the single vendor in this entire catalog that just has no opinion on message ordering, which, after reading the rest of this table, should feel almost suspicious.* ## Composing Recipes in Middleware You can specify family recipes directly in `OrderingGuardOptions.profiles`. Composing multiple recipes lets you capture layered constraints — for example, pairing a model family recipe with a hosting-layer recipe when deploying through Bedrock Converse. This two-layer conflict (where the model requires one structure and the hosting wrapper bolts on a second, conflicting constraint) is precisely why testing models in isolation is never enough: you must validate the actual deployment shape. ```ts import { orderingGuardDispatchMiddleware } from '@nhtio/adk/batteries/validation' // Single family recipe const middleware = orderingGuardDispatchMiddleware({ profiles: ['gemini-3'], action: 'enforce', }) // Combining a family recipe with a hosting-layer recipe const bedrockClaudeMiddleware = orderingGuardDispatchMiddleware({ profiles: ['anthropic-manual-thinking', 'bedrock-converse'], action: 'mutate', }) ``` ## See Also * **[Validation Hub](./index)** — Overview and model selector table. * **[Atomic Behaviors](./behaviors)** — Breakdown of each composed atomic profile. * **[Operating Modes](./modes)** — Configuring `enforce` vs `mutate` execution. * **[Advisories & Placeholders](./advisories)** — Guidance on unconfirmed recipes (`bytedance-seed`, `muse-spark`, `muse-glimmer`).