When a list is too long for a card, the widget decides — not the model
Past four results, Kav's widget turns a card list into a swipeable rail on its own, with no auto-advance, so it can't fail the rule a carousel usually breaks.
A capability author doesn't design for how many results a question happens to return. They declare a shape once — "one card per thing" — and the number of cards on any given day is whatever the underlying system returns.
The scenario
A resident asks a retail chain's assistant where they can pick up an item. Six branches carry it. The capability that answers is declared CardList — the identical render hint used elsewhere on this platform for a single result, like a property-tax balance. Six is a lot of cards to stack in a chat window, so the widget, on its own, turns them into a swipeable rail instead of a long vertical scroll.
What makes this safe rather than risky
Carousels have a well-known accessibility problem: auto-advancing content that changes while someone is still reading it, or reading it with a screen reader, is one of the most common WCAG failures on the web. Kav's rail has no auto-advance and no timer. It only moves when the resident swipes it. The decision to become a rail at all is made by the widget, based on a fixed threshold (past four results), not by the model guessing that "a rail would look nice here."
Who decided what
The capability author decided the data was a list of discrete things. The widget decided how a list of six discrete things should be laid out on a small screen. The model wrote the sentence introducing the results. At no point did anyone have to specially design a "six-branch" experience — the same CardList hint that renders one card renders six, because the number of items was never part of the contract.
Why this is the actual point
A hand-built integration has to anticipate every count a query might return and design for each one. A capability contract that only says "these are individual things" doesn't need to anticipate anything — one render hint, one rule for when it becomes a rail, and every organization on the platform gets the same correct behavior whether their query returns one branch or six.