Composition analysis
Type: Finding
Status: Active
Canonical for: Composition-specific evidence, distinctions, maturity and remaining representation questions
Depends on: Atlassian, Carbon, Figma, SAP and Storybook system profiles
Central distinction
Knowing what components exist is an inventory/API problem.
Knowing how to compose a good product experience is a semantic, contextual and governance problem.
The corpus strongly supports this distinction.
Evidence spectrum
Component-local composition — implemented
- TypeScript props and slots define allowable local structure.
- Figma Code Connect maps variants, nested props, children and slots.
- Storybook exposes subcomponents, args and multi-component stories.
- Carbon Builder encodes explicit Modal composition, tab-family pairing and Tag-versus-status-indicator selection rules in an agent skill.
- Carbon embeds AI Label into existing controls with placement/state constraints.
These mechanisms answer questions such as “what child can render here?” or “how does this variant map to code?” They do not answer “is this the right workflow?”
Reusable product composition — documented and partly implemented
- Atlassian’s Panel defines a constrained responsive shell, contextual subheaders and purposeful content regions. Core/platform/app tiers locate ownership and reuse.
- Storybook stories/templates preserve known working combinations that can be tested.
- Microsoft Adaptive Cards constrain output to a JSON-defined host-adaptive structure.
- Carbon AI Chat exposes slots and custom panels within a stable chat framework.
These are recipes/scaffolds rather than universal grammars.
Intent-driven composition — emerging
SAP says composition requires explicit relationships, functional roles, supported intent, contextual fit and generation-time guardrails. Its Joule Work claim is the strongest evidence of intent-driven generative UI, but the schema is not public.
Atlassian’s context engine similarly aims to encode constraints, flexibility and intent so an agent can traverse decision trees. Public evidence describes the architecture more than the data model.
What composition metadata would need to communicate
Evidence across SAP, Atlassian, Storybook and Figma implies at least:
- functional role and supported task;
- allowed/required parent and child relationships;
- slots and region purposes;
- hierarchy and information priority;
- responsive and density behavior;
- content requirements;
- accessibility constraints;
- valid states and transitions;
- prohibited combinations and anti-patterns;
- domain/context conditions;
- validation hooks.
This is an inference, not a published common schema.
Governance tension
Examples and templates are safe but incomplete. A strict grammar is enforceable but may suppress legitimate product variation. Atlassian’s core/platform/app model acknowledges this by locating freedom at the app layer. SAP’s experience-model framing places design work in defining scaffolds and signals rather than fixed screens.
Maturity judgment
- Local slots, props, templates and stories: established.
- Agent retrieval of examples and component relationships: emerging.
- Machine-readable selection intent across a whole DS: experimental.
- Generation-time enforcement of coherent, accessible product experiences: experimental, with one strong official production claim and little public implementation detail.