“Supported” has at least three different meanings. Keep them separate when reading a Showcase or reviewing an app:
| Claim | Evidence needed |
|---|---|
| ARC can load the source | The source is selected by the loader and passes its relevant validation |
| A target can render the tree | That renderer has a presentation path for the relevant node/capability combination |
| An interaction works | A real session/target acceptance test observed the expected change |
The first does not establish the second, and neither establishes the third.
Interactive AUP uses a session
For an interactive AUP app, ARC starts from a rendered tree and can send versioned patch updates to a target renderer. The server-side store validates a patch batch before applying it atomically: one failed operation does not intentionally leave a partially applied batch. This is session synchronization, not a promise of distributed persistence or cross-device transaction semantics.
The target reports its actual DeviceCaps during handshake. The renderer then chooses its own presentation and may apply a defined degradation path. An event shape alone does not guarantee that every device or renderer supports the same interaction.
Static Web Device is a separate path
Web Device can render a supported AUP tree directly into static HTML. It can also use page layouts that compose Web components. Neither path automatically makes every native primitive valid as a Web layout section, and static HTML rendering does not open an interactive AUP session.
When a document needs a specific device claim, name the primitive, target, ARC version, and observed acceptance. “It rendered once in a Showcase file” is not enough.
For shared primitive boundaries, see Primitive taxonomy and evidence. For patches and degradation, see Patches, scenes, and capabilities.