Interface: AlternationRule
Defined in: src/batteries/validation/types.ts:142
Requires a strict sequence of conversation roles.
Properties
| Property | Type | Description | Defined in |
|---|---|---|---|
id | string | Stable identifier used in violations. | src/batteries/validation/types.ts:146 |
maxPerGroup? | number | Optional cap on ToolCall entries within one same-role group. Llama 3's parallel-tool-call limitation is represented as 1; Llama 4 lifts that limitation by omitting this field. | src/batteries/validation/types.ts:155 |
mode | "strict" | The only supported mode in this version: every successive turn must alternate. | src/batteries/validation/types.ts:150 |
roles | readonly ("user" | "assistant")[] | Allowed role cycle, normally ['user', 'assistant']. | src/batteries/validation/types.ts:148 |
severity? | "blocking" | "advisory" | Whether a violation blocks dispatch. Omitted means advisory. Remarks Advisory is the default because this catalog's rules were derived from vendor DOCUMENTATION, and a live audit against each rule's own native API found that most of them block turn state the vendor accepts (16 of 17 rules measured; only thought-signature-required was confirmed enforced). Documentation describes what a vendor says it requires; only observation shows what it does. Defaulting to advisory keeps the catalog's knowledge — you still learn which primitive broke which vendor's stated contract — without rejecting dispatches the model would have served. Opt into blocking per rule when you have verified the constraint on the surface you dispatch through. See docs/batteries/validation/api-surface-scope.md. | src/batteries/validation/types.ts:169 |
type | "alternation" | Discriminator selecting the role-alternation evaluator. | src/batteries/validation/types.ts:144 |