Symptom
An input JSON array maps to multiple document requests. Composition produces every expected page, but all of them land in one PDF instead of one file per document. The application and the data mapping demonstrably work, which is why iterating on the document layout gets you nowhere: the pages were never the problem.
Cause
Page creation and file creation are separate decisions in the engine. Several documents can be composed into one output stream when the output queue has no break at the document boundary.
The controlling setting lives on the output queue in the Communication Set, not in the input mapping and not in the PDF page design. Searching in the wrong layer is what makes this issue cost hours instead of minutes.
Fix
Open the output queue used by the Communication Set and configure its output breaks at the document or communication boundary the job requires. Leave the input event mapped to the repeated request structure; it was correct all along.
Then verify with a two-request test: the queue should create two PDF files, each containing only the pages for its own request.
If the output is still one file, check two things: the run actually uses the edited Communication Set (stale deployments are common here), and the output connector is not configured in a mode that deliberately aggregates the job.
If one multi-page PDF is what you actually want, leave the queue unbroken and validate the page sequence instead.
Keep document selection and file grouping separate
Output breaks control delivery grouping. Input patterns select requests, and document logic decides what each document contains. Keep those decisions separate so a delivery change does not alter document selection.