A parks-and-recreation facility booking form has a variable number of attendees per reservation, each with a name and an age bracket. Which schema design best represents this in the structured extraction output?

Schema design should follow the shape of the data rather than a guess about its typical size. A reservation's attendee list is a variable-length collection of like entities, each carrying its own fields, and an array of objects is exactly the construct that expresses that shape.

An attendees array whose items are objects with name and ageBracket properties handles one attendee or twenty with no schema change, and it keeps each person's fields individually addressable downstream. Nothing has to be invented, neither a slot count nor an encoding convention, so the parks-and-recreation booking output stays queryable for age-bracket reporting, headcounts, and individual reservations alike.

Fixed numbered fields hard-code a guess about cardinality and misrepresent data the moment a booking exceeds or falls short of it, leaving empty slots and truncated lists as normal states; a single free-text field discards structure entirely and pushes the parsing problem downstream onto a brittle regex, defeating the purpose of structured extraction; and per-bracket booleans lose identity and count together, telling you only that a bracket was present rather than how many people were in it or who they were.

Exam caveat: an array models the shape correctly but does not enforce completeness, since an extraction that misses an attendee produces a shorter array that is still perfectly valid against the schema. Operational check: compare the extracted array's length against the reservation's stated party size and flag any mismatch for human review, rather than trusting a well-formed array to be a complete one.