Technical study of IBM's Carbon Core design system

The DTCG theme files (g10.json, g100.json) implement hundreds of role-based semantic tokens (background, layer, field, border, text, link, icon, support, focus, skeleton, ai, chat, syntax, toggle, overlay, shadow) each carrying an alias reference to a raw color primitive (e.g. background -> {gray.10}) and an inline $description of its role, repeated consistently across four theme files representing four modes. This is corroborated by the Figma file's confirmed full-file variable coverage: 1205 variables, 1907 alias references, and a dedicated Theme collection of 548 variables across the same four modes (White/Gray10/Gray90/Gray100), resolving the packet's stated known_limitation that full-file coverage needed confirmation via the Variables endpoint or a checked-in export. The independent color-guidance documentation states an operational Theme/Token/Role/Value model and gives systematic, non-arbitrary derivation rules for interaction-state tokens (hover = half-step, active = two full steps, selected = one full step), showing the alias/semantic layer is not just named but rule-governed. This satisfies anchor 3 (comprehensive, operational semantic layers and aliases). It does not reach anchor 4 because no evidence shows an automated process that validates or reconciles the token graph across consumers (for example, a CI check diffing Figma-exported variables against the DTCG/npm package output) or measures token adoption/usage over time.

Completeness

Complete

Sources

5 of 5

Verification

Implemented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Semantic layers and aliases are comprehensive and operational

What a higher score requires: The token graph is validated, measured, and maintained across consumers
What is still needed: No evidence of an automated mechanism that validates or reconciles the token graph across consumers (for example, CI parity checks between the Figma export and the published npm packages) or that measures token adoption/maintenance across consuming teams, which anchor 4 requires.

Scope: mixed; system-wide. Subjects: @carbon/themes DTCG token files (white, g10, g90, g100), carbon-v11-figma Theme variable collection, carbon-color-guidance token/theme/role documentation. Limitation: Full-file variable coverage is confirmed for the current Figma library snapshot and the shipped DTCG theme sources reviewed (g10/g100; g90/white were referenced but not fully re-verified line-by-line due to excerpt truncation), and no automated cross-consumer validation pipeline is evidenced.

What broke

No confirmed break in the semantic/alias layer itself; the unmet piece is validation, not structure

Impact

Consumers can trust the documented semantic taxonomy and alias structure for current design and code artifacts, but cannot assume the token graph is actively guarded against future design/code drift since no automated reconciliation is evidenced.

Why

The DTCG theme files and Figma variable export both show a comprehensive, alias-based token graph with documented operational rules, but the packet contains no CI/build artifact or governance record showing the graph is continuously checked across the code and design channels.

What to change

Publish or surface evidence of an automated check (for example, a CI job or release gate) that reconciles the Figma variable export against the published DTCG/npm token output, and track/report on token consumption across dependent packages.

Reusable low-level primitives are documented and packaged separately from semantic tokens: @carbon/colors exposes a full raw color scale (10-100 grades plus hover variants) as JS/Sass constants; @carbon/layout exposes a spacing scale (spacing01-13), fluid spacing, container sizes, and icon sizes; @carbon/motion exposes DTCG duration and cubic-bezier easing primitives with usage descriptions. These primitives are not merely declared but are shown being consumed: @carbon/motion's surfaces.json composes named motion 'recipes' (disclosure, contextual, stretch, expand, invoke) entirely from alias references to the duration/easing primitives (e.g. {duration.moderate.01}, {easing.entrance.productive}), and the theme DTCG files alias raw color primitives (e.g. {gray.10}, {blue.60}) throughout. The Figma variable summary independently confirms parallel primitive collections (Spacing: 28 variables, Radius: 2 variables, Breakpoint: 215 variables across 5 modes), meaning the same primitive scales are available to both code and design consumers. This meets anchor 3 (comprehensive and consistently consumed). It falls short of anchor 4 because there is no evidence of measured adoption or governance over primitive usage (for example, linting that enforces primitive-only values, or reported consumption metrics), only the IBM Telemetry package-install notice, which does not measure primitive-level usage.

Completeness

Complete

Sources

5 of 5

Verification

Implemented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Primitives are comprehensive and consistently consumed

What a higher score requires: Primitive coverage and adoption are measured and governed
What is still needed: No evidence of measured or governed primitive adoption (for example, enforcement tooling, consumption telemetry, or a reported adoption rate across consuming teams/products), which anchor 4 requires.

Scope: mixed; system-wide. Subjects: @carbon/colors raw palette, @carbon/layout spacing/container/icon-size scale, @carbon/motion duration/easing primitives and surface recipes, carbon-v11-figma Spacing/Radius/Breakpoint variable collections. Limitation: Confirms the primitive packages themselves and their alias-based consumption within the themes/motion packages; does not verify that every cataloged component (beyond the sampled deep components) consistently draws on these primitives rather than hard-coded values.

What broke

No confirmed break; the gap is adoption measurement, not primitive completeness

Impact

Component and product authors have a usable, comprehensive primitive set in both code and design tooling, but there is no visibility into how consistently the broader component catalog actually draws on these primitives versus hard-coded values.

Why

Evidence shows the primitives exist, are documented, and are consumed by at least the motion and color semantic layers via aliasing, but no telemetry, lint enforcement, or audit data on primitive usage across the full component catalog is present in the packet.

What to change

Add or surface enforcement (lint rules disallowing raw values in component styles) or usage telemetry so primitive adoption can be measured and governed across the catalog.

Carbon documents and implements four theme modes (White, Gray 10, Gray 90, Gray 100) as complete DTCG token sets, each tagged with a color-scheme extension and producing distinct values for the same semantic token names; this is mirrored exactly in the Figma Theme variable collection (548 variables x 4 modes). Responsive/layout modes are likewise systematic: a Breakpoint collection (215 variables across 5 modes: SM/MD/LG/XL/Max) and a Grid mode collection (25 variables across Wide/Narrow/Condensed/Nested) exist alongside documented 2x Grid breakpoint and margin specifications. Accessibility-oriented modes are embedded directly in the token model: the color-guidance documentation describes systematic light/dark layering, explicit high-contrast 'inverse' tokens for deliberate high-contrast moments, a dedicated $focus token family, and WCAG contrast-ratio tables driving token value selection. Sampled component nodes (e.g. Button) show bound_variable_ids drawing directly from the Theme, Breakpoint, and other mode-bearing collections, confirming these modes are wired into at least the sampled components rather than existing only as unused design tokens. This satisfies anchor 3 (systematic across tokens and components, for the modes Carbon claims: theming, responsive, and accessibility). It does not reach anchor 4 because there is no evidence of continuous/automated validation of mode compatibility across supported consumers (for example, automated visual regression or variable-parity checks per mode).

Completeness

Complete

Sources

5 of 5

Verification

Implemented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Modes are systematic across tokens and components

What a higher score requires: Mode compatibility is continuously validated across supported consumers
What is still needed: No evidence of continuous/automated validation of mode compatibility across consumers (for example, automated cross-mode visual regression, or parity checks confirming every mode renders correctly in shipped code across releases), which anchor 4 requires.

Scope: mixed; system-wide. Subjects: Theme collection (4 modes), Breakpoint collection (5 modes), Grid mode collection (4 modes), carbon-color-guidance accessibility/high-contrast documentation, Button component bound-variable sample. Limitation: Mode infrastructure (variable collections, DTCG theme files) is confirmed full-file/system-wide; component-level wiring is directly confirmed only for the sampled deep components (e.g. Button), not verified across the entire catalog.

What broke

No confirmed break; the gap is continuous validation across consumers, not mode coverage

Impact

Designers and developers can rely on documented, token-driven theme/responsive/accessibility modes that are demonstrably wired into at least the sampled components, but there is no assurance that every mode continues to render correctly across all consumers after each release.

Why

Theme, breakpoint, and accessibility-related modes are represented consistently in both the DTCG source and the Figma variable export, and sampled components bind to these mode-bearing variables, but no automated per-mode regression or validation evidence is present in the packet.

What to change

Introduce and publish evidence of automated per-mode validation (for example, visual regression across all four themes and breakpoints in CI) to move from systematic support to continuously validated mode compatibility.

Carbon delivers installable foundation packagesNot availableincluding colors, layout, motion, and themesNot availablewith documented Sass and JavaScript consumption paths. Carbon’s Figma guidance separately documents its named v11 libraries and how designers enable them through Figma’s Libraries mechanism, while the collected full-file export confirms that the evaluated design library contains the corresponding variable foundation. Together, this establishes distinct delivery channels for code and design consumers. Score 4 is not supported because public evidence does not demonstrate an automated release-over-release check reconciling the Figma variables with published package output or measured migration impact when foundations change.

Completeness

Complete

Sources

5 of 5

Verification

Implemented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Multiple consumers receive consistent versioned artifacts

What a higher score requires: Delivery contracts are validated and migration impact is measured
What is still needed: Automated release-over-release validation between Figma variables and published package output, plus measured consumer migration impact for foundation changes, is needed to establish validated and measured delivery contracts.

Scope: mixed; system-wide. Subjects: @carbon/colors, @carbon/layout, @carbon/motion, @carbon/themes npm packages, (v11) Carbon Design System Figma community library. Limitation: Confirms the existence and consistency of two versioned delivery channels at this snapshot; does not confirm automated reconciliation between them over time or measurement of migration impact on downstream consumers.

What broke

No confirmed break; the gap is contract validation and migration measurement, not the existence of versioned delivery

Impact

Both design and engineering consumers can reliably install and reference a versioned foundations artifact today, but there is no evidence that drift between the Figma library and the npm packages would be automatically caught, or that the impact of a foundations change on downstream consumers is tracked.

Why

READMEs confirm independent npm package versioning and Sass/JS consumption paths, and the Figma guidance/summary confirm a parallel versioned design-library channel with full-file coverage, but no CI/contract-test artifact or migration-impact report appears in the packet.

What to change

Add an automated check that reconciles the published Figma variable export against the released npm package token output on each version bump, and publish migration-impact data (for example, which consumers were affected) for foundations token changes.

Code Connect files (packages/react/code-connect/**) provide a documented, per-component naming translation table between Figma property/variant names and React props for all 11 deep-component samples (e.g. Button 'Style'→kind, 'Size'→size, 'State: Disabled'→disabled; Grid's Figma asset is explicitly named 'Screen' while the code component is 'Grid'). This is systematic documentation, not tribal knowledge, ruling out anchor 1. However, material known gaps are explicit in the evidence itself: Tile's Code Connect mapping has most Figma properties (titleText, descriptionText, disabled, selected, slot, title, description) commented out with an inline comment citing an open, unresolved GitHub issue (#20089) for a 'Code Connect CLI validation bug'; Toggle's Figma 'State text' single property is mapped to two distinct code props (labelA/labelB); and 'Show label' is a negated boolean vs. code's hideLabel. These are documented but real naming-alignment gaps for at least one full sampled component, which prevents claiming systematic alignment across the whole sample.

Completeness

Complete

Sources

18 of 18

Verification

Implemented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

Sample only

Scoring rule used: Common names are documented with known gaps

What a higher score requires: Names are systematically aligned across surfaces
What is still needed: To reach 'systematically aligned across surfaces', the Tile sample's naming mapping would need to be fully restored (not commented out) and Data table's TableRow would need its remaining commented-out Figma properties (selectable, select type, selection, state, zebra style) mapped, so that no deep-component sample has an unresolved naming gap.

Scope: deep-component; sample-only. Subjects: Button, Form, Text input, Toggle, Modal, Notification, Tile, Loading, Grid, Data table, UI shell. Limitation: Evidence covers only the 11 declared deep-component samples via Code Connect; catalog-wide naming parity for the remaining ~330 composition candidates in the Figma library is not evidenced and cannot be inferred from this sample.

What broke

Tile's published Code Connect naming map has most Figma properties (title/description/disabled/selected/slot) disabled due to a known, unresolved tooling bug, and Data table's TableRow has multiple Figma properties (selectable, select type, selection, state, zebra style) left commented out.

Impact

Consumers using Figma Dev Mode for these two sampled components will not see accurate prop-name guidance for a meaningful subset of their design properties, increasing the chance of manual, ad hoc translation for exactly the components where it is most needed.

Why

packages/react/code-connect/Tile/Tile.figma.tsx and TableRow.figma.tsx show large blocks of commented-out figma.connect props, with Tile's comment explicitly citing carbon-design-system/carbon#20089 as the blocking cause.

What to change

Resolve the referenced Code Connect CLI validation bug (or work around it) to restore full Tile prop mapping, and complete the TableRow property mapping so naming parity is uniformly documented, not partially disabled, across the full deep-component sample.

Across the declared sample, consumer-controlled choices correspond through React APIs, CSS/runtime behavior, or composition. Tile types map to specialized Tile components and content maps through children; DataTable row selection and expansion map through specialized row subcomponents; Figma interaction states map to CSS or runtime state; Grid breakpoint is an authoring preview control; and modal callbacks are runtime-only. The unresolved Tile Code Connect validation defect reduces active traceability but does not remove the supported cross-surface contract. No evidence shows continuous machine validation and drift measurement across the complete contract.

Completeness

Complete

Sources

18 of 18

Verification

Implemented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

Sample only

Scoring rule used: Supported choices, derived states, slots, and composition map coherently, and surface-specific controls are explicitly classified

What a higher score requires: Machine-readable mappings continuously validate shared contracts and explicitly classify surface-specific controls
What is still needed: Additional evidence must satisfy the next anchor: Machine-readable mappings continuously validate shared contracts and explicitly classify surface-specific controls

Scope: deep-component; sample-only. Subjects: Button, TextInput, Toggle, Notification, Modal, Form, Grid, Tile, Data table (TableRow). Limitation: Only the 11 declared deep-component samples were evidenced; contract correspondence for catalog-only components is unknown, and the Tile/TableRow gaps should not be generalized to the rest of the sample, which shows coherent mappings.

What broke

Tile's Code Connect mapping has its core content props (titleText, descriptionText, slot, title, description) commented out and non-functional, citing an unresolved upstream Code Connect CLI validation bug (carbon-design-system/carbon#20089); only the swapSlot instance-swap prop remains live.

Impact

Consumers reading Tile's Figma-to-code mapping in Dev Mode will not see how Figma's title/description/content properties correspond to React Tile usage, forcing manual translation for this component.

Why

The Tile.figma.tsx source itself documents the gap: 'TODO: Re-enable these props when Code Connect validation bug is fixed... Properties exist in Figma but fail validation despite correct names.'

What to change

Track and resolve the linked Code Connect CLI validation bug, or ship an interim manual example demonstrating the titleText/descriptionText/slot mapping until the tooling bug is fixed; also clarify whether TableRow's commented base props are dead code or an active gap.

The checked-in full-file Figma export makes variable names observable. Reviewer comparison found direct semantic matches for 101 of 104 standard core code-token paths (97.1%) and the design and code artifacts share four theme modes. Product/design-only Figma extensions and syntax/implementation-only code tokens are treated as scoped differences, not parity failures. Three standard paths remain unmatched (layer/background/03, shadow, support/caution/undefined), and no automated parity or drift check was evidenced, so score 4 is not supported.

Completeness

Complete

Sources

18 of 18

Verification

Implemented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Token identity and modes align across design and code

What a higher score requires: Cross-surface token parity is automatically validated
What is still needed: Additional evidence must satisfy the next anchor: Cross-surface token parity is automatically validated

Scope: foundation; system-wide. Subjects: Color tokens (@carbon/colors), Theme tokens (@carbon/themes DTCG: white/g10/g90/g100), Figma Variables (full-file coverage, 1205 resolved variables). Limitation: This assessment covers the color/theme token layer, where full-file Figma variable coverage was explicitly confirmed; motion and layout/spacing token parity (e.g. deprecated layout01-07 tokens in @carbon/layout) were not independently cross-checked against Figma variable bindings in this packet and are not included in this generalization.

What broke

No confirmed break in identity/mode alignment for the evidenced foundation token layer; the remaining gap is the absence of automated cross-surface validation.

Impact

Without automated parity checks, token drift between a future Figma Variables update and the DTCG token export would not be caught until manually noticed, risking silent divergence between design and code color/theme tokens over time.

Why

The evidence shows full-file variable resolution and matching DTCG token group structure/modes, but no CI job comparing the two surfaces was found among the reviewed GitHub workflows.

What to change

Add an automated CI check (e.g. via the Figma Variables REST API) that diffs published Figma Variable names/values against the generated DTCG token files on each release and fails on unexplained divergence.

Carbon maintains component-to-Figma references through per-component Code Connect files and republishes them through CI when changes reach main. Deprecated APIs are identified in implementation code, while the versioned v11 migration guide documents removed, renamed, and deprecated APIs; the versioning policy and public API snapshot testing further support code API traceability. This meets the versioned maintained-reference anchor. Score 4 is not supported because Code Connect is explicitly exploratory, some sampled mappings contain disabled or incomplete properties, and no automated design-to-code drift check was evidenced.

Completeness

Complete

Sources

18 of 18

Verification

Automation wired

Test definition

Not observed

Automation wiring

Observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Versioned mappings expose supported and deprecated APIs

What a higher score requires: Traceability and deprecation drift are automatically enforced
What is still needed: Additional evidence must satisfy the next anchor: Traceability and deprecation drift are automatically enforced

Scope: mixed; system-wide. Subjects: Code Connect mechanism (11 sampled deep components), @carbon/react semver/deprecation documentation, deprecate() PropTypes wrapper pattern. Limitation: The versioning/migration documentation explicitly covers the entire @carbon/react public API, supporting a system-wide claim for deprecation tracking; however, the Code Connect design-linking portion of traceability was only verified for the 11-item deep-component sample and should not be assumed complete for catalog items outside that sample.

What broke

No confirmed break in the versioned-mapping mechanism itself, but Code Connect is self-described as being in an 'exploratory phase' and at least one sampled file (TableRow.figma.tsx) contains commented-out properties without an inline explanation comparable to the documented Tile issue.

Impact

Consumers of Code Connect for DataTable's TableRow may not realize several Figma properties (AI spacer, zebra style, state, selectable, select type, selection) are intentionally left unmapped, since no comment or issue link is provided there, reducing traceability confidence for that specific mapping.

Why

TableRow.figma.tsx comments out multiple properties without citing a reason, whereas Tile's equivalent gap is explicitly documented with a linked GitHub issue, showing inconsistent rigor in how gaps are traced.

What to change

Add inline rationale or issue links for all commented-out Code Connect properties (starting with TableRow) so every excluded or deferred property is traceable, consistent with the practice already used for Tile.

Carbon's documented catalog spans roughly 40 components across action, input, selection, navigation, overlay, feedback, content, status, layout, and data-display archetypes, and all 11 declared representative deep components resolved in the Figma library. This supports comprehensive coverage for Carbon Core's stated foundational scope. Score 4 is not supported because no public systematic measurement of catalog gaps, adoption, or component health was evidenced; catalog presence is not treated as proof of state, responsive, accessibility, or binding quality.

Completeness

Complete

Sources

21 of 21

Verification

Implemented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Coverage is comprehensive for the stated scope

What a higher score requires: Gaps, adoption, and component health are measured
What is still needed: Additional evidence must satisfy the next anchor: Gaps, adoption, and component health are measured

Scope: catalog; system-wide. Subjects: carbon-preview-components catalog listing, carbon-v11-figma component-set inventory, carbon-production-home library ecosystem overview. Limitation: Catalog evidence establishes breadth and inventory only; it does not prove per-component state, accessibility, binding, or responsive quality. The preview-site catalog is release-authority supplemental material, not normative production documentation.

What broke

No confirmed break

Impact

Teams building common enterprise UI needs (forms, tables, navigation, feedback, overlays) have a reusable component available in both design and code for nearly every documented use case.

Why

Catalog and Figma inventory evidence corroborate each other across two independent public sources (preview catalog and Figma library) plus the code package.

What to change

Publish a public gap/adoption metric (for example, component maturity or usage dashboard) to support a higher anchor; current governance scope explicitly withholds this as private.

Across the declared sample, Carbon documents and implements form validation, server-side correction, disabled and duplicate-submission prevention, loading and progress, success, warning, read-only, empty and no-results recovery, and error-management states for permission, system, and configuration failures. The empty-state pattern explicitly requires explaining permission restrictions and providing steps to request access. This supports comprehensive state ownership and guidance across the declared components and compositions. Score 4 is not supported because public evidence does not show continuous, comprehensive measurement of the state matrix, and partial-success behavior is not established as a system-wide contract.

Completeness

Complete

Sources

21 of 21

Verification

Documented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

Sample only

Scoring rule used: Normal and recovery states have comprehensive ownership and guidance

What a higher score requires: State contracts are executable, tested, and measured
What is still needed: Current system-wide state-coverage resultsNot availableincluding permission, partial-success, and recovery scenarios across the catalogNot availableplus tracked gaps or regressions are needed to establish measured state coverage.

Scope: deep-component; sample-only. Subjects: Button, Text input, Toggle, Notification, Modal, Loading, Data table (catalog corroboration). Limitation: State-matrix conclusions apply to the sampled deep components and cited compositions; not confirmed for the full ~40-component public catalog.

What broke

Permission-state guidance and evidence (for example, access-denied / insufficient-permission handling) are absent from all sampled deep components and compositions.

Impact

Teams building permission-gated flows have no documented or tested Carbon pattern to rely on, risking inconsistent ad hoc handling of denied-access states.

Why

None of the sampled deep-component Figma state dimensions, docs, or e2e specs reference a permission/authorization state; only loading, error, disabled, warning, and validation states are covered.

What to change

Publish explicit permission/access-denied state guidance with corresponding automated test coverage, or clarify that permission handling is intentionally delegated outside Carbon Core (for example, to Carbon for Products).

Carbon defines a detailed breakpoint system, matching Figma variants, responsive Grid implementation that generates breakpoint-specific classes, and component guidance such as UI-shell collapse at smaller sizes. This meets documented behavior and constraints. Score 3 is not supported because runtime adaptation is evidenced strongly for Grid but not consistently across the broader declared component and composition sample, and collected tests do not exercise the small, medium, and large viewport matrix. The finding is evidence-bounded and does not claim Carbon is unresponsive.

Completeness

Complete

Sources

21 of 21

Verification

Test defined

Test definition

Observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

Sample only

Scoring rule used: Basic behavior and constraints are documented

What a higher score requires: Components adapt consistently across supported conditions
What is still needed: Additional evidence must satisfy the next anchor: Components adapt consistently across supported conditions

Scope: mixed; sample-only. Subjects: 2x Grid foundation, grid/Screen component, ui-shell Header, data-table, modal sizing. Limitation: Evidence demonstrates breakpoint/variant definitions and prose guidance for a subset of components; it does not cover container-query behavior, density modes, or content-driven responsive conditions system-wide, and does not confirm runtime adaptation for components outside this citation set.

What broke

No confirmed break, but no direct operational or test evidence of runtime responsive adaptation was found in the packet beyond breakpoint/variant definitions and prose guidance.

Impact

Consumers can rely on documented breakpoint constraints and layout guidance for planning, but cannot confirm from this evidence alone that Grid, Modal, UI shell, or Data table actually re-flow correctly at each breakpoint without separate manual or visual verification.

Why

The evidence packet supplies breakpoint/variant enumerations (Figma Screen, Grid code-connect) and normative prose describing intended responsive behavior, but no CSS/media-query source, no viewport-resize e2e test, and no visual-regression citation tied specifically to breakpoint behavior.

What to change

Surface (or cite) the responsive/media-query implementation in the Grid, Modal, and UI shell Header source, or add breakpoint-driven e2e/visual-regression checks, to move from documented constraints to demonstrated adaptive behavior.

Carbon implements ARIA semantics, accessible names, keyboard behavior, focus routing and trapping, and Escape handling, and runs Playwright accessibility tests covering all 11 sampled component families. CI executes automated violation checks plus keyboard, focus-order, disabled-state, activation, and modal focus-trap assertions across four shards on pushes and pull requests, corroborated by published component testing statuses. This meets comprehensive and tested accessible behavior. Score 4 is not supported because screen-reader testing remains primarily manual, Form, Loading, and Modal disclose advanced-state or keyboard-testing gaps, and no continuously measured assistive-technology coverage or regression metric was evidenced.

Completeness

Complete

Sources

21 of 21

Verification

Automation wired

Test definition

Observed

Automation wiring

Observed

Current result

Not observed

Generalizability

Sample only

Scoring rule used: Accessible behavior is comprehensive and tested

What a higher score requires: Assistive-technology coverage and regressions are continuously measured
What is still needed: Additional evidence must satisfy the next anchor: Assistive-technology coverage and regressions are continuously measured

Scope: deep-component; sample-only. Subjects: button, form, text-input, toggle, ui-shell, modal, notification, tile, loading, grid, data-table. Limitation: AVT CI evidence is confirmed only for components with e2e test files present in this packet (the 11 declared deep components); it does not confirm equivalent automated AT/keyboard testing exists or passes for catalog components outside the declared deep sample.

What broke

No confirmed critical accessibility failure; the residual gap is that AT/screen-reader regression checking is manual and a subset of the sample (Loading, Form, Modal) has incomplete advanced-state/keyboard test coverage per Carbon's own disclosure.

Impact

Teams can trust that automated axe-style violation checks and keyboard-focus behavior are continuously verified in CI for the sampled components, but cannot assume the same continuous assurance for screen-reader interaction or for Loading/Form/Modal advanced states, which rely on manual, point-in-time verification.

Why

Direct CI configuration and e2e test-code evidence show executed, gating automated checks; Carbon's own normative testing-status tables directly disclose which states and interaction modes remain manually verified or partially tested.

What to change

Automate AT/screen-reader regression checks where feasible (or document a recurring manual AVT3 cadence with public results), and close the disclosed advanced-state/keyboard-testing gaps for Loading and Form.

Carbon provides an operational layout system covering mini units, spacing, columns, rows, margins, padding, gutters, fluid/fixed/hybrid grids, breakpoint conditions, panel types, and screen regions. Grid, Row, and Column implementation is present with breakpoint-specific span and offset contracts, a matching Figma Screen asset is captured, and component documentation applies the layout rules to Forms, Data tables, Tiles, and other sampled surfaces. This supports coverage of Carbon Core’s stated product scope. Score 4 is not supported because public evidence does not measure layout adoption or exceptions, and no automated layout-usage validation was found.

Completeness

Complete

Sources

18 of 18

Verification

Implemented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Layout primitives cover the stated product scope

What a higher score requires: Layout use and exceptions are validated and measured
What is still needed: Automated layout-conformance results, governed exception tracking, and adoption measurement across supported consumer surfaces are needed to establish validated and measured layout use.

Scope: mixed; system-wide. Subjects: 2x Grid foundation, Form layout guidance, Data table placement guidance, Tile layout guidance, Button alignment guidance. Limitation: No Grid/Row/Column code artifact was included to verify implementation fidelity to the documented rules; no measurement of layout compliance or exceptions across the product is evidenced.

What broke

No confirmed break; however, no Grid/Row/Column implementation source was included in the evidence packet to verify the documented grid rules are enforced by the runtime components.

Impact

Teams can trust the documented grid/spacing/shell contract as comprehensive design guidance, but this packet cannot confirm the Grid/Row/Column code enforces those rules or that layout exceptions are caught before shipping.

Why

The 2x Grid foundation page and its cross-references from form, data-table, tile, and button docs establish a comprehensive, applied layout contract, but no Grid.tsx/Row.tsx/Column.tsx source or automated conformance check appears in the evidence.

What to change

Include Grid/Row/Column implementation source and any lint or test coverage of grid usage to substantiate a move toward anchor 4 (validated, measured layout use).

Composition rules are documented extensively and consistently across the declared create-configure-save flow and loading-recovery pattern: Modal anatomy explicitly allows Data table/Form/Progress-indicator content to occupy the body; Button docs define allowed/disallowed button-group combinations; the Forms pattern defines button alignment, bleed, and emphasis rules inside dialogs/side panels; Notification docs define placement composition relative to forms (above submit/cancel) and callouts. Crucially, this is not prose-only: ModalFooter.tsx contains real operational composition code: SecondaryButtonSet composes Button and ButtonSet, and the file imports InlineLoading for use inside the modal footer, directly evidencing a coded composition contract for Button+Loading+Modal matching two of the three declared compositions. This combination of consistent documented rules plus one directly observed code composition supports 'composition contracts cover supported product assemblies.' No evidence of automated/executable validation of these composition rules (for example, lint rules or Code Connect enforcement) was present, so anchor 4 is not met.

Completeness

Complete

Sources

18 of 18

Verification

Implemented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

Sample only

Scoring rule used: Composition contracts cover supported product assemblies

What a higher score requires: Composition rules are executable or automatically validated
What is still needed: No automated or executable validation (lint rule, Code Connect enforcement, or test) of these composition contracts is present, which anchor 4 requires.

Scope: composition; sample-only. Subjects: create-configure-save flow (Button, Modal, Notification, Loading), loading-recovery pattern. Limitation: Directly observed code composition is limited to the Modal footer (Button, ButtonSet, InlineLoading); Grid, Form, TextInput, and Toggle composition is evidenced only through documentation, not source.

What broke

No confirmed break: documented composition rules are corroborated by real ModalFooter code composing Button, ButtonSet, and InlineLoading.

Impact

Teams assembling the declared flow and loading-recovery pattern have both a documented contract and a working code reference for button/loading composition inside a modal footer, reducing ambiguity for that sub-assembly.

Why

ModalFooter.tsx imports and composes Button, ButtonSet, and InlineLoading with explicit secondary/primary button role logic, matching the documented button-group and modal-footer guidance.

What to change

Extend observed code composition evidence to Form+TextInput+Toggle and Notification+Grid assemblies to remove reliance on documentation alone for the remaining flow components.

The four declared patterns (Forms, Loading, Empty states, Notifications) are each documented as detailed, reusable task patterns with anatomy, variants, best practices, and explicit 'Related' links back to their constituent components (for example, Forms pattern links Button, Checkbox, Text input, Toggle; Loading pattern links Data table, Loading, Pagination and cross-links Empty states/Forms/Notifications patterns; Notification pattern links Modal, Notification, UI shell). This directly matches 'patterns cover important tasks and remain linked to components' for the declared sample. The composition packet's own known_limitations disclose that Carbon does not publish a composed Figma flow/pattern artifact for these: an honest scope boundary rather than a design failure, and design is not a required surface for these patterns. No evidence of pattern usage, outcome, or lifecycle measurement was found, so anchor 4 is not met.

Completeness

Complete

Sources

18 of 18

Verification

Documented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

Sample only

Scoring rule used: Patterns cover important tasks and remain linked to components

What a higher score requires: Pattern use, outcomes, and lifecycle are measured
What is still needed: No evidence of measured pattern use, outcomes, or lifecycle tracking (adoption metrics, deprecation cadence) is present, which anchor 4 requires.

Scope: composition; sample-only. Subjects: Forms pattern, Loading pattern, Empty states pattern, Notifications pattern. Limitation: Evidence covers only the four declared patterns; it does not establish coverage of Carbon's full pattern catalog (for example, Dialogs, Filtering, Search) beyond the preview-site index, which is supplemental only.

What broke

No confirmed break: the declared patterns are documented and component-linked, but Carbon's own known_limitations disclose no composed Figma flow artifact exists for them.

Impact

Designers and engineers have clear task-pattern guidance and component linkage to implement the declared flow and patterns, but cannot cross-check a canonical composed design artifact: only code/documentation surfaces are required and available.

Why

carbon-forms-pattern, carbon-loading-pattern, carbon-empty-state-pattern, and carbon-notification-pattern each provide anatomy, when-to-use guidance, and explicit 'Related' component/pattern links matching the declared composition scope.

What to change

No change required for the required (code, documentation) surfaces; if design-surface parity becomes required in future, Carbon would need to publish composed pattern artifacts.

ComposedModal.tsx provides direct, operational (not merely prose) evidence of focus and dismissal ownership: a Tab-wrap focus trap (wrapFocus/wrapFocusWithoutSentinels), Escape-key handling gated by isTopmostVisibleModal to correctly own only the topmost of nested/stacked modals, outside-click ownership that differs by passive vs. transactional modal state (with a runtime warning() guarding against misconfiguration), initial-focus assignment logic (danger button vs. selectorPrimaryFocus vs. close button), and launcher-focus return on close. This is corroborated by normative Modal usage docs describing trigger/focus/loading/validation ownership, Notification docs describing dismissal and keyboard-focus ownership (Tab between action and close-x, Esc), and Loading docs describing interaction-blocking ownership (overlay blocks all interaction; small loading disables related buttons). Together these comprehensively cover dialog, async-state (loading/validation), and nested-composition ownership for the declared flow and patterns. Drawer/side-panel and route-level ownership are not part of the declared flow's component set (grid, form, text-input, toggle, button, notification, modal, loading) and remain unevidenced/unknown rather than a confirmed gap. No evidence of continuous automated verification (for example, focus-trap tests running in CI) was found, so anchor 4 is not met.

Completeness

Complete

Sources

18 of 18

Verification

Implemented

Test definition

Not observed

Automation wiring

Not observed

Current result

Not observed

Generalizability

Sample only

Scoring rule used: Navigation, focus, and state contracts are comprehensive

What a higher score requires: Cross-composition contracts are executable and continuously verified
What is still needed: No CI test, automated focus-trap assertion, or other continuous-verification evidence was found for these ownership contracts, which anchor 4 requires; drawer/route-level ownership also remains unevidenced since those constructs are outside the declared flow's component set.

Scope: mixed; sample-only. Subjects: Modal (ComposedModal), Notification dismissal/keyboard ownership, Loading interaction-blocking ownership. Limitation: Ownership evidence is strongest for Modal (direct code) and documentation-level for Notification/Loading; drawer/side-panel and route-transition ownership fall outside the declared flow and pattern component set and are therefore unknown, not confirmed absent.

What broke

No confirmed break within the declared dialog/async-state sample: ownership is comprehensively evidenced. Drawer/route-level ownership is unevidenced but is also outside the declared flow's component set.

Impact

For the create-configure-save flow and loading-recovery pattern, engineers have a coherent, code-backed contract for who owns focus, escape handling, outside-click dismissal, and loading/validation state during a dialog task, reducing risk of conflicting implementations across teams.

Why

ComposedModal.tsx implements isTopmostVisibleModal-gated escape handling, isPassive-based outside-click rules with a runtime warning, and initial-focus/launcher-focus-return logic; Modal, Notification, and Loading usage docs independently corroborate the same ownership behaviors in prose.

What to change

To reach anchor 4, add automated tests or CI-verified assertions for the modal focus trap, nested-modal escape targeting, and loading/validation state transitions so the contract is continuously verified rather than only implemented and documented.

Carbon's ownership model is operational: CODEOWNERS assigns default and path-specific reviewers, pull-request guidance defines developer and design approval rights, issue-triage automation assigns severity, labels, and project metadata, support documentation establishes rotations and named escalation paths, and security reporting includes a published response expectation. This meets operational decision rights and support boundaries. Score 4 is not supported because the available merge-rate metric does not comprehensively measure ownership health, response-time compliance, reviewer load, escalation resolution, or support-service performance.

Completeness

Complete

Sources

8 of 8

Verification

Automation wired

Test definition

Not observed

Automation wiring

Observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Decision rights and support boundaries are operational

What a higher score requires: Ownership health and service expectations are measured
What is still needed: Additional evidence must satisfy the next anchor: Ownership health and service expectations are measured

Scope: governance; system-wide. Subjects: CODEOWNERS reviewer assignment, issue-triage automation, SECURITY.md response commitment, support.md escalation paths. Limitation: Evidence is public-repository governance material only; private IBM decision records, internal Slack activity, and adoption/ownership-health dashboards referenced in the governance known_limitations are unknown, not scored as absent.

What broke

No confirmed break in documented ownership, but no public measurement of ownership health or service-expectation adherence exists beyond a single weekly merge-rate metric.

Impact

Consumers can see who owns what and how escalation is supposed to work, but cannot verify from public evidence whether commitments like the 7-business-day security response target are actually being met over time.

Why

metrics-merge-rate.yml is the only recurring, automated measurement present in the evidence packet; it tracks PR throughput, not response-time or escalation-SLA compliance.

What to change

Publish a periodic, automated measurement of core ownership-health signals (issue/PR response time versus committed targets, escalation resolution time) using the same weekly-report pattern already established for merge rate.

Carbon operates a cross-discipline contribution and review process with a defined four-stage pull-request review, criteria spanning implementation, testing, Storybook, styling, CI, and other change types, two developer approvals, an additional design approval for qualifying visual or interaction changes, author self-review checklists, CODEOWNERS assignment, and automated quality gates. This meets operational cross-discipline review criteria and decisions. Score 4 is not supported because public measurement covers some merge throughput but not review quality and outcomes such as defect escape, post-merge reverts, or review effectiveness.

Completeness

Complete

Sources

8 of 8

Verification

Automation wired

Test definition

Not observed

Automation wiring

Observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Cross-discipline review criteria and decisions are operational

What a higher score requires: Review quality, throughput, and outcomes are measured
What is still needed: Additional evidence must satisfy the next anchor: Review quality, throughput, and outcomes are measured

Scope: governance; system-wide. Subjects: PR review process and checklist, issue-triage automation, PR merge-rate metric, preview-site contribution overview (supplemental). Limitation: Evidence covers the public GitHub contribution/review process and one supplemental preview-site overview page; internal design-crit and CAG meeting outcomes, and non-public review discussions, are unknown.

What broke

No confirmed break in the documented cross-discipline review process, but no public evidence measures review quality or outcomes beyond weekly merge throughput.

Impact

Stakeholders can confirm an operational, criteria-driven review path exists, but cannot independently verify from public evidence that it is producing measurably better outcomes (fewer defects, fewer reverts) over time.

Why

metrics-merge-rate.yml measures only merge throughput; no review-quality or downstream-outcome metric is present in the evidence packet.

What to change

Extend the existing automated metrics reporting beyond merge rate to include review-quality/outcome signals (for example, post-merge revert rate, accessibility-regression rate tied to reviewed PRs) and publish them on the same recurring cadence.

Carbon operates explicit release-safety contracts through semantic-versioning rules, preview/prerelease/active/maintenance/LTS phases, committed future-major feature flags, versioned migration guides, tested @carbon/upgrade codemods, Public API snapshot checks, automated release workflows with CI and accessibility gates, and supported-version and security-response policies. This meets operational deprecation and migration contracts. Score 4 is not supported because consumer migration outcomes are not publicly measured: no migration completion rates, post-release breakage rates, compatibility incident metrics, or adoption-health evidence was found.

Completeness

Complete

Sources

8 of 8

Verification

Automation wired

Test definition

Observed

Automation wiring

Observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Deprecation and migration have explicit operational contracts

What a higher score requires: Compatibility and migration success are validated and measured
What is still needed: Additional evidence must satisfy the next anchor: Compatibility and migration success are validated and measured

Scope: governance; system-wide. Subjects: semver versioning policy, v11/v12 migration guides, release/version/promote CI workflows, release-schedule phase and feature-flag commitments. Limitation: Evidence covers public versioning/migration documentation and release automation for the current v11 line and the v12 preview; private migration outcome data and consumer adoption telemetry are outside public evidence per the governance known_limitations.

What broke

No confirmed break in the documented deprecation/migration contract, but migration success itself is not measured in public evidence: only API compatibility is checked via the PublicAPI snapshot test.

Impact

Consumers can rely on a concrete, documented semver/migration contract and an automated compatibility check, but cannot independently verify that migrations succeed in practice (for example, how many consumers adopt committed v12 flags cleanly before the major bump).

Why

versioning.md documents the PublicAPI snapshot mechanism enforced in CI, and release-schedule.md documents the committed-flag preview contract, but no adoption or migration-success telemetry is present in public evidence; the governance known_limitations explicitly exclude adoption dashboards.

What to change

Publish aggregate, privacy-safe migration/adoption telemetry (for example, pre-release adoption rate of committed enable-v12-* flags, or post-migration defect reports) to close the gap between the documented migration contract and measured migration success.

Carbon operates quality gates across its delivery lifecycle through formatting and lint checks, unit tests with coverage, build and generated-style checks, end-to-end tests, sharded Playwright accessibility tests, Chromatic visual regression, change-triggered and weekly CodeQL scanning, release-time accessibility checks, and published severity and exception-handling rules. These are active workflows with direct assertions and meet automated lifecycle-and-exception enforcement. Score 4 is not supported because no public quality-trend reporting, waiver and exception frequency, regression rates, recurring accessibility trends, or follow-through outcome measurement was evidenced; merge-rate reporting measures throughput rather than quality.

Completeness

Complete

Sources

8 of 8

Verification

Automation wired

Test definition

Observed

Automation wiring

Observed

Current result

Not observed

Generalizability

System wide

Scoring rule used: Quality gates cover the supported lifecycle and exceptions

What a higher score requires: Quality, adoption, exceptions, and regressions are measured and acted on
What is still needed: Additional evidence must satisfy the next anchor: Quality, adoption, exceptions, and regressions are measured and acted on

Scope: governance; system-wide. Subjects: CI pipeline (lint/test/build/security), sharded Playwright AVT accessibility gate, CodeQL scheduled security scan, PR checklist exception handling. Limitation: Evidence covers CI/CD workflow definitions and a sample of AVT e2e test files across 11 components; it does not establish that every component or pattern in the full catalog has equivalent AVT coverage, and it does not include private DAP audit records referenced by accessibility.md.

What broke

No confirmed break in gate coverage, but no public evidence measures quality trends, exception/waiver frequency, or regressions over time beyond a weekly merge-rate figure.

Impact

The public evidence shows real, currently-enforced automated gates (a blocking AVT accessibility job, CodeQL scanning, unit tests) plus documented exception handling, but leaves it unclear how often exceptions are invoked or whether gate effectiveness is monitored and acted on over time.

Why

accessibility.md's false-positive dismissal and the PR template's strikethrough mechanism show exception handling exists, but no dashboard or periodic report of exception frequency or gate-failure/regression trend is present in the evidence packet, unlike the weekly merge-rate metric.

What to change

Track and periodically report exception/waiver frequency (accessibility false-positive dismissals, PR-checklist strikethroughs) and gate-failure/regression trends, extending the reporting pattern already established for the weekly merge-rate metric.