The public Notation API lets a caller put all 4 voices on ONE instrument/stave with no auto-split and no warning — the exact 'three or four voices on one stave' fault this chapter says is almost always wrong

Gradus's own JSX renderer never lets this happen: `resolveVoices()` structurally caps any 3-4-voice block at 2 voices per stave via `staveIdxOf(i) = i < 2 ? 0 : 1`. The public Notation API's `InstrumentInput.voices: VoiceLine[]` has no equivalent — an agent (or Sean, hand-authoring a request) can supply `voices: [{voice:1,...},{voice:2,...},{voice:3,...},{voice:4,...}]` under ONE `instruments[]` entry, which is one staff, and jsonToScore.ts will happily parse, distribute, and merge all four voice lines onto that single staff with no split, no warning, and no error.

A 4-voice chorale request sent to /api/v1/notation/render as a single `instruments[0].voices` array with voice numbers 1-4 renders as one staff carrying all four voices — MusicXML's `<voice>` element alone does not create separate staves, and nothing in Gradus's pipeline promotes this into the SATB two-stave short score the JSX renderer would have produced for equivalent content.

Gould, Behind Bars, ch. on multiple voices — 2-per-stave is the practical ceiling (see three-or-four-voices-one-stave-almost-always-wrong).

This rule can be decided from pitches, durations and voices — no layout required. A validator can check it before anything is drawn.