Cross-application arbitration usually belongs to the system layer
Aliases: system layer · cross-app · platform policy
What it is
Cross-application arbitration usually belongs to the system layer. Only the system can see the whole picture when several apps produce feedback at once; an individual app knows only its own events and cannot judge whether they are more urgent than others'. App-level arbitration is a workaround for when the system offers no mechanism.
Why it happens
System-level arbitration is necessary because arbitration requires comparing relative urgency, and apps cannot see each other—only the system can aggregate. If each app decides on its own whether to output, they compete for the channel at the same moment, and the practical winner is whoever fires first regardless of consequence. System-level arbitration also keeps cross-app behavior consistent, so users face the same treatment for the same event level across apps. The cost is that apps must pass event-level information up, which requires agreed interfaces and grading standards.
Studying it
Measure behavior under cross-app concurrency: have several apps on one device fire events of differing levels simultaneously, compare system-level arbitration with app-level output on critical-event latency and loss. Variables include the number of concurrent apps, the level distribution, and OS version. Include users' ability to identify the event source, since chaotic concurrent output leaves them unable to confirm what happened.
Where it stops holding
If apps use separate channels—their own audio sessions—the system can allocate resources per app, lowering the urgency of cross-app arbitration, though attentional conflict remains. When the system provides no arbitration interface, apps can only protect themselves in a limited way, such as lowering output frequency. If all apps share one grading standard, system-level arbitration works best; when standards diverge, results still need mapping onto a unified user response layer.
Applying it
- Prefer the platform's arbitration mechanism and map in-app event levels onto the shared response layer.
- Where no mechanism exists, at least limit the app's own concurrent output to avoid competing for the channel.
- Keep level semantics consistent across apps so the same level gets the same treatment.
- Verification: under multi-app concurrency, measure critical-event latency and loss against a single-app condition, confirming concurrency does not mask critical events.
Related
- Within the group: D5.06.1 Simultaneous multichannel output needs arbitration rules · D5.06.7 Users should be able to override the default arbitration for a situation
- Adjacent: D2.03.7 Level definitions need consistency across products · D5.06.3 Priority follows consequence level, not channel capability
- Search terms:
system-level arbitration·cross-application·platform policy
Cards in the same group
- D5.06.1Simultaneous multichannel output needs arbitration rules
- D5.06.2The same event should not be fully repeated on every channel
- D5.06.3Priority follows consequence level, not channel capability
- D5.06.4Arbitration must handle queueing and dropping among simultaneous events
- D5.06.5Interruptive arbitration cuts off feedback; queued arbitration lets it finish first
- D5.06.7Users should be able to override the default arbitration for a situation