Research traceability for the candidate contracts
Type: Comparative view
Status: Active proposal traceability
Canonical for: Mapping candidate contract concerns to upstream evidence classes
Depends on: Current research synthesis, system profiles and semantic-naming evidence; it inherits the global interpretation rule
This table explains why information appears in the contracts. It does not claim every requirement has direct LLM evidence.
| Contract concern | Mature-system evidence | AI/standards evidence | Classification |
|---|---|---|---|
| Canonical identity and implementation source | Carbon component IDs/imports; Storybook IDs/paths; Figma Code Connect mappings | Tool names are causal signals; SKOS separates concept and label | Industry/standards supported; adjacent AI evidence |
| Purpose and selection boundary | Carbon selection rules; Storybook Button-versus-Link JSDoc; Atlassian/SAP intent claims | Tool documentation and relevance work support descriptions/boundaries in adjacent tasks | Adjacent empirical + industry supported |
| Property name and dimension | Typed APIs across systems; cross-system variant/appearance/kind divergence | Parameter names and schema-key wording are causal in adjacent experiments | Empirical adjacent; DS property comparison unestablished |
| Enum-value meaning | Usage docs, stories and prop definitions; semantic collision matrix | No direct isolated enum-value naming experiment | Industry supported; direct AI evidence gap |
| Type, required/default and legal values | TypeScript/OpenUI5/Storybook manifests | Structured constraints improve validity | Empirically supported for validity |
| State separate from intent | Component APIs and stories; Shopify/GitLab factorization | WAI-ARIA role/state/property precedent | Standards/industry supported |
| Composition and relationships | Figma nested mappings; Storybook subcomponents; Carbon pairing rules; Atlassian slots; SAP relationship logic | JSON Schema/SHACL/feature models can express rules | Industry/standards supported; selection benefit unestablished |
| Accessibility contract | Carbon, Fluent, ADS and OpenUI5 guidance/code/tests | WAI-ARIA and native semantics | Standards/industry supported; DS-agent effect sparse |
| Content requirements | Microsoft content engineering; Carbon/Atlassian content guidance | Description and instruction wording affects related model tasks | Adjacent empirical + industry supported |
| Semantic token binding | Carbon/ADS/Fluent tokens; Figma variables | DTCG explicit type/reference; do not infer from groups/value | Standards/industry supported |
| Examples and non-examples | Storybook stories, Figma snippets, Carbon examples | EASYTOOL/example evidence is adjacent; counterexample effect not isolated | Adjacent + industry supported |
| Deterministic constraints and validation | Types/tests/parsers across systems; Storybook test loop | Constraint Tax: validity can improve while correctness falls | Empirical adjacent; optimal timing unestablished |
| Version, status and deprecation | Package history, aliases, Storybook preview status, Code Connect source version | No direct agent ablation | Industry supported; plausible AI relevance |
| Targeted retrieval and curation | Carbon Discover–Canonicalize–Target; Storybook manifest tags; Figma selected context | Tool/schema retrieval studies summarized in the research | Adjacent empirical + industry supported |
| AI-optimisation record | Atlassian reports aggregate eval gains; no public system-wide benchmark | Multiple tool/schema benchmarks demonstrate model/task dependence | Required by working definition; DS method unestablished |
Important non-equivalences preserved
- A component name does not define its purpose.
- A property type does not define when to select it.
- An enum prevents invention only when enforced; it does not ensure the correct legal choice.
- A Figma/code mapping establishes correspondence, not appropriateness.
- A story demonstrates a known state, not all valid states.
- An accessibility test proves only its stated coverage.
- MCP provides delivery, not semantic quality.
- A standards vocabulary demonstrates representability, not improved LLM performance.
- Reliable access to current design or implementation artifacts can make a component AI-exposed while selection and composition meaning remains implicit.
- A contract that appears complete is AI-ready only for the capabilities it actually supports.
- A contract is not AI-optimised until its exact version has been evaluated with agents.