Back to the field report

AWS

Technical study of AWS's Cloudscape design system

AWS's Cloudscape design system was reviewed to answer two questions: How well does Cloudscape stay aligned from design through production? Can an AI coding agent meet the recorded benchmark requirements?

Cloudscape shows useful public design-system readiness, while a separate purposive agent benchmark found uneven contract compliance.

Cloudscape provides a mature public component library and substantial guidance. In this purposively selected benchmark, the profile using only the evidence supplied with each task met every blocking requirement in 24 of 60 runs, and the optional official-resource profile did so in 22 of 60. Across matched task-run pairs, the optional profile helped 9 times, hurt 11 times, and made no difference 40 times.

The resource tool was actually used in 12 of 60 optional-profile runs. Because the tasks were not sampled from production work and the profiles differed in more than documentation access, these results do not estimate production reliability or the causal effect of documentation.

What Cloudscape already does well

  • A broad, production-oriented component library with detailed usage guidance
  • Strong application-layout, validation, loading, and creation-pattern documentation
  • Published accessibility and responsive test definitions for core components
  • Clear public contribution, release, and ownership practices
  • Public material that supported perfect controlled results for responsive spacing and public-change review across three repeated runs

What is still unclear

Most saved responses missed at least one blocking requirement in both operational profiles. The result combines four different measurements: executable software, exact contract transcription, semantic selection, and governance procedure. Only the executable-software group was exercised as an implementation.

Evidence compliance is reported separately so a missing citation is not described as broken software. AWS may already maintain stronger internal examples and validation; those materials can be supplied for a future, explicitly scoped evaluation.

Readers need to know what each task measured before acting on a pass rate. Teams can use the failed executable checks to improve typed examples and complete workflows, and use the evidence results to improve stable source anchors, without treating the combined score as a Cloudscape quality rating.

How well does Cloudscape stay aligned from design through production?

The study reviewed 20 criteria across foundations, design-to-code bindings, components, product structure, and governance. The evidence included available design files, documentation, source code, tests, and operating guidance.

Result68.75 / 100
Scores across the five areas
Foundations75 Bindings56.25 Components75 Structure75 Governance62.5

Benchmark-contract compliance under two recorded Cloudscape profiles

The offline v2 review re-evaluated all 120 saved responses without making new actor calls. It preserves the v1 files, corrects known evaluator and harness defects, and separates different measurement constructs.

Evidence supplied with each task40%

24 of 60 runs (40%)

Optional official Cloudscape resources36.7%

22 of 60 runs (36.7%)

Most runs missed at least one blocking benchmark requirement

The profile using only the evidence supplied with each task passed 24 of 60 runs (40%). The optional official-resource profile passed 22 of 60 runs (36.7%). Across matched task-run pairs, optional access helped 9 times, hurt 11 times, and made no difference 40 times.

Interpretation: Most runs in each profile missed at least one requirement in this purposive benchmark. The result does not identify a single cause and is not a Cloudscape product-quality score.

Results by measurement kind

MeasurementEvidence supplied with each taskOptional official Cloudscape resources
Executable software11 of 368 of 36
Contract transcription10 of 1810 of 18
Semantic selection0 of 31 of 3
Governance procedure3 of 33 of 3

Only the executable-software rows represent implementations exercised by TypeScript and browser harnesses. The other rows measure exact-answer transcription, semantic selection, or public governance reasoning.

Evidence compliance

ProfileAll evidence requirementsValid locatorsRequired regionsRequired sources
Evidence supplied with each task41 of 6099.7%81.7%100%
Optional official Cloudscape resources36 of 6092.9%71.7%92.5%

Evidence compliance is reported separately from executable behavior. The optional-resource tool was used in 12 of 60 runs and made 21 requests.

Evidence supplied with each task: task-by-task results

Benchmark-contract outcomes across repeated runs

FoundationsChoose the AppLayout background token for light and dark mode0%
BindingsConnect single-row Table selection to React state100%
ComponentsBuild a keyboard-operable automatic-updates toggle33.3%
StructureBuild empty, populated, and filtered inventory states0%
StructureBuild create, configure, save, success, and retry states0%
GovernancePlan the public evidence needed to release a change0%
FoundationsChoose the token for a visible keyboard focus ring100%
FoundationsUse Cloudscape’s responsive spacing system100%
FoundationsStyle a custom surface without hard-coded colors0%
BindingsConnect a controlled Modal to its open and close actions66.7%
ComponentsBuild a retryable and dismissible error message0%
GovernancePlan an accessibility regression fix from report to release66.7%
BindingsUpdate SideNavigation after an internal link is followed0%
BindingsConnect a required name field to validation state66.7%
ComponentsMake both Cancel and Escape close a Modal33.3%
StructureFilter a resource table and recover from no matches0%
GovernancePlan the review path for an accessibility fix66.7%
ComponentsShow loading, disable Save, then show Saved66.7%
StructurePreserve rows, show a Spinner, and append loaded results0%
GovernanceUse public repository evidence to plan a reviewed component change100%

Passed Failed

Optional official Cloudscape resources: task-by-task results

Benchmark-contract outcomes across repeated runs

FoundationsChoose the AppLayout background token for light and dark mode33.3%
BindingsConnect single-row Table selection to React state66.7%
ComponentsBuild a keyboard-operable automatic-updates toggle33.3%
StructureBuild empty, populated, and filtered inventory states33.3%
StructureBuild create, configure, save, success, and retry states0%
GovernancePlan the public evidence needed to release a change0%
FoundationsChoose the token for a visible keyboard focus ring66.7%
FoundationsUse Cloudscape’s responsive spacing system100%
FoundationsStyle a custom surface without hard-coded colors0%
BindingsConnect a controlled Modal to its open and close actions0%
ComponentsBuild a retryable and dismissible error message33.3%
GovernancePlan an accessibility regression fix from report to release66.7%
BindingsUpdate SideNavigation after an internal link is followed33.3%
BindingsConnect a required name field to validation state0%
ComponentsMake both Cancel and Escape close a Modal0%
StructureFilter a resource table and recover from no matches33.3%
GovernancePlan the review path for an accessibility fix100%
ComponentsShow loading, disable Save, then show Saved0%
StructurePreserve rows, show a Spinner, and append loaded results33.3%
GovernanceUse public repository evidence to plan a reviewed component change100%

Passed Failed

Claim boundary: The selected tasks are not a probability sample of production work. The profiles also differed in tool availability, output mode, parser, command flags, and preamble. This comparison does not estimate representative implementation reliability or the causal effect of documentation access.

Why each criterion received its score

Open any item to see the evidence, the scoring rule, and what kept it from receiving a higher score.

Foundations

Every score in this area completed review.

75
out of 100, continue, 100% reviewed
Token taxonomy and semanticscritical
Assessor scores: 3, 3, 3; human review: approve3 / 4

The Figma 2.0.3 file (full-file variable coverage, 703 resolved variables, 447 alias references) and the pinned style-dictionary source both show a layered raw -> alias/reference -> semantic/component token architecture. palette-values.ts holds raw hex primitives (colorGrey50 etc.); token-names.ts defines a ReferenceTokenName alias layer (colorPrimary/colorNeutral/colorError/etc. scales); one-theme/colors.ts and core token categories build semantic/component tokens that reference those aliases (e.g. colorBackgroundButtonPrimaryDefault: '{colorPrimary600}'); core/index.ts and one-theme/index.ts operationally assemble all ten token categories (color-palette, color-charts, color-severity, colors, typography, borders, motion, sizes, spacing, shadows) plus eight component-scoped contexts into an exported, built theme.

The design-tokens documentation confirms the same CTI (Category>Type>Item>State) taxonomy is normatively documented with a themeable/light/dark matrix for 407 color tokens. A snapshot test (design-tokens.test.ts) operationally validates that the generated classic and visual-refresh token JSON (and its generated JSON schema) matches expectation, confirming the graph is actually built and shape-checked, not just described.

Completeness
Complete
Sources
10 of 10
Verification
Test defined
Test definition
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: Score 4 requires the token graph to be validated, measured, and maintained across consumers; the only automated check observed is a same-repo snapshot test comparing two internal themes (classic, visual-refresh) to a stored snapshot: there is no evidence of cross-consumer measurement, drift detection, or maintained ownership metrics for the token graph itself.

Scope: foundation; system-wide.

Subjects: style-dictionary token pipeline (core, one-theme), Figma 2.0.3 color-palette/color-variable/typography/borders/spacing/sizes/color-charts-palette collections, design tokens documentation.

Limitation: Evidence covers the foundation/token-generation layer and a full-file Figma variable export; it does not verify how individual component source files consume these tokens, nor does it cover internal test results referenced in governance.

What broke
No confirmed break.
Impact
Teams can rely on a stable, documented CTI naming/alias structure for building and theming products, but cannot yet cite an automated cross-consumer measurement of token graph health (e.g. drift or unused-alias detection across downstream packages).
Why
Evidence shows the layered token architecture is built and shape-tested within this repository, but no evidence packet source demonstrates measurement or maintenance of the graph across multiple external consumers.
What to change
Publish or surface evidence of cross-consumer token validation (e.g. a token-graph linter run against downstream theming-build/theming-runtime consumers, or adoption telemetry) to support a score of 4.
Supporting evidence, 8 citation(s)
Primitive completeness
Assessor scores: 3, 3, 3; human review: approve3 / 4

Core low-level primitives: spacing (4px base unit, 10 Figma variables plus a documented scale), borders/radius (40 Figma variables spanning alert, badge, button, focus-ring, code-editor), shadows (14 variables), sizes (11 variables), icon sizing (5 variables), motion, and responsive breakpoints (breakpoints.scss defines an 8-step scale with up/down mixins): are documented in normative docs and implemented as discrete, reusable style-dictionary modules (borders.ts, sizes.ts, spacing.ts, shadows.ts, motion.ts) that are consumed through a single shared builder loop (core/index.ts tokenCategories) rather than duplicated per component.

The spacing documentation directly cites consistent reuse of the same primitive scale across many unrelated component types (button, form field, container, tabs, grid, select, app layout, split panel, popover, cards, tutorial panel), and the sampled deep components (Toggle, Cards, Flashbar, Form field, Modal, Table) each bind to primitive variables from the same borders/sizes/spacing collections in Figma. This is direct, non-prose evidence of both comprehensiveness and consistent consumption via a cited shared mechanism, meeting anchor 3.

Completeness
Complete
Sources
10 of 10
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: Anchor 4 requires measured and governed primitive coverage/adoption (for example, lint rules enforcing token-only styling, or a published adoption metric). No such measurement or governance artifact is present in the evidence packet.

Scope: foundation; system-wide.

Subjects: Spacing, border/radius, shadow, size, motion, and breakpoint primitives in the pinned Figma 2.0.3 file and @cloudscape-design/components style-dictionary.

Limitation: Cross-component consumption is directly observed only for the 10 resolved deep-component samples and the components explicitly named in normative spacing/breakpoint documentation; consumption by the remainder of the ~150+ catalog components is not individually verified in this packet.

What broke
No confirmed break
Impact
Product and component authors have a documented, reusable primitive layer rather than ad hoc values, reducing visual drift risk across surfaces, but there is no public signal of whether adoption is enforced or measured.
Why
Evidence shows the primitive set is centrally defined and imported once for the whole token build, and normative docs plus bound-variable data confirm reuse across varied component types.
What to change
Surface public evidence of primitive-adoption enforcement (for example, stylelint rules against raw px/hex values, or a published usage audit) to support anchor 4.
Supporting evidence, 6 citation(s)
Modes and adaptationcritical
Assessor scores: 3, 3, 3; human review: approve3 / 4

Color mode (light/dark), density mode (comfortable/compact), and motion mode (default/disabled) are implemented as first-class, systematic dimensions in the style-dictionary architecture: utils/modes.ts defines createColorMode/createDensityMode/createMotionMode, and core/index.ts and one-theme/index.ts apply this shared `modes` array uniformly to every token category (color-palette, colors, typography, borders, motion, sizes, spacing, shadows) and to every visual context (compact-table, top-navigation, header, flashbar, alert, app-layout-toolbar) via addTokens/addContext calls in a single loop, not per-component special-casing.

The Figma file independently confirms a Light/Dark mode dimension on the color-variable and color-charts-palette collections. Density is concretely evidenced in code (one-theme/spacing.ts: spaceFieldVertical comfortable/compact values). Responsive adaptation is documented as a systematic element-query mechanism tied to a defined breakpoint scale (breakpoints.scss), and theming/visual-context overrides are documented with a working code example (theming-docs).

Accessibility guidance is extensive and cites concrete per-component practices (Table row-header semantics, Form field labeling, App layout heading order, Tabs focus styling). This constitutes direct, non-prose evidence that modes are systematically threaded through the token architecture and components, meeting anchor 3.

Completeness
Complete
Sources
10 of 10
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: Anchor 4 requires mode compatibility to be continuously validated across supported consumers. The only automated artifact observed is a two-theme snapshot test for token JSON output (design-tokens.test.ts); there is no evidence of automated cross-mode (for example, dark+compact+RTL) regression testing or validation across multiple downstream consumer packages.

Scope: mixed; system-wide.

Subjects: Color (light/dark) mode, density mode, motion mode, responsive breakpoints, theming/visual contexts, and accessibility guidance across the pinned Figma file, components repository, and normative documentation.

Limitation: Platform/bidirectionality (RTL) mode is referenced only as a documentation title in the llms.txt index and is not evidenced in this packet, so its systematic status is unknown; per-component automated accessibility test execution (vs. documented guidance) is likewise not directly observed.

What broke
No confirmed break
Impact
Applications get systematic, low-effort support for dark mode, density, reduced motion, responsive layout, and accessible interaction patterns because these are wired into the shared token build rather than reimplemented per component.
Why
The mode dimensions are implemented once in utils/modes.ts and consumed uniformly by both open-source theme builders, and are corroborated by the Figma file's own Light/Dark variable modes.
What to change
Publish evidence of automated, continuous validation of mode combinations (for example, visual regression across dark/compact/RTL permutations) across the packages that consume these tokens to support anchor 4.
Supporting evidence, 8 citation(s)
Consumable delivery and versioning
Assessor scores: 3, 3, 3; human review: approve3 / 4

Cloudscape ships foundations as versioned, machine-consumable artifacts to more than one consumer type: the npm package @cloudscape-design/components (peerDependency react >=16.8.0, with an explicit build:react18 script and react18-aliased devDependencies for a second React major-version consumer), companion published packages consumed as dependencies (@cloudscape-design/theming-runtime, @cloudscape-design/component-toolkit, and theming-build used by the style-dictionary pipeline), a generated JSON design-tokens artifact plus its JSON schema (validated by a snapshot test), and a separately versioned Figma Community design library (2.0.3) explicitly documented as independent from the daily-published React package.

Build-time theming additionally generates a themed component + design-token package via buildThemedComponents, showing artifact generation is a real, invokable mechanism, not just a description.

Completeness
Complete
Sources
10 of 10
Verification
Test defined
Test definition
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: Score 4 requires delivery contracts to be validated and migration impact measured; no changelog/semver-diff tooling, consumer-impact measurement, or breaking-change gate was evidenced: only shape-level snapshot validation of generated token JSON.

Scope: foundation; system-wide.

Subjects: @cloudscape-design/components npm package, companion theming-runtime/theming-build packages, generated design-tokens JSON + schema artifact, Figma Community design library (2.0.3).

Limitation: Evidence confirms the delivery mechanism and versioning scheme structurally, but does not include registry-level confirmation of the exact evaluated npm version's contents, nor any migration-impact measurement across consumer upgrades.

What broke
The pinned repository snapshot's package.json declares version 3.0.0, while the assignment's evaluated npm version is 3.0.1348; the evidence packet does not contain the corresponding published package.json to directly confirm artifact contents at that exact published version.
Impact
This is a traceability gap rather than a capability failure: it does not undermine the observed delivery mechanism (versioned multi-consumer artifacts), but it means the exact published-version artifact contents were not independently confirmed against the pinned repository source in this evidence set.
Why
Cloudscape's own governance evidence states additional internal testing occurs before npm publication, consistent with the main-branch package.json (3.0.0) differing from a later auto-incremented published patch version (3.0.1348); the repository and npm registry are versioned independently by design.
What to change
Include the published npm package.json (or registry metadata) for the exact evaluated version alongside repository source, and add migration-impact evidence (e.g. semver-diff or changelog-linked breaking-change reports) to support a score of 4.
Supporting evidence, 6 citation(s)

Bindings

Every score in this area completed review.

56.25
out of 100, partial, 100% reviewed
Naming parity
Assessor scores: 3, 2, 3; human review: approve3 / 4

Every sampled Figma component-set name maps through a consistent, predictable transform onto its code component identifier (Title Case with optional '(Atom)' suffix for atomic components ↔ PascalCase TypeScript component name), and the one structural divergence (Button) decomposes into four Figma sets whose names match the code's Variant enum values one-for-one, with an explicit system-authored 'compound' disposition and rationale in the coverage profile. Spinner's absence from the Figma file is likewise explicitly recorded as a design-evidence boundary, not left as an unexplained naming gap.

No automated naming-parity checking or drift measurement was found, which excludes the top anchor.

Completeness
Complete
Sources
24 of 24
Verification
Implemented
Test definition
Not observed
Automation wiring
Not observed
Current result
Not observed
Generalizability
Sample only

Scoring rule used: Names are systematically aligned across surfaces

What a higher score requires: Parity is automatically checked and drift is measured

What is still needed: No evidence of an automated naming-parity check (for example, a lint rule, Code Connect script, or CI job) that measures or reports naming drift between the Figma library and the npm package: required for the automated-validation anchor.

Scope: deep-component; sample-only.

Subjects: button, toggle, modal, flashbar, form-field, input, cards, side-navigation, app-layout, table, spinner.

Limitation: Only the declared deep-component sample was checked against name transforms; the remaining component sets in the 154-set Figma catalog were not individually verified, so this finding cannot be generalized to the full catalog without further sampling.

What broke
No confirmed break: sampled component names in Figma follow a consistent, predictable transform (Title Case plus an '(Atom)' suffix for atomic components) that maps cleanly onto each component's PascalCase code identifier and, for Button, onto its variant enum values.
Impact
Practitioners can reliably locate the Figma asset for a given code component (or vice versa) using a predictable naming convention, without needing a manual lookup table.
Why
Cross-referencing figma-sample-details.json component-set names (for example, 'Toggle (Atom)', 'Modal', 'Primary button (Atom)') against the corresponding TypeScript component/prop names in cloudscape-component-implementation (for example, ToggleProps, ModalProps, ButtonProps.Variant='primary') shows a one-to-one, predictable name transform for every sampled component, and the figma-sample-resolution.json disposition fields explicitly document the two structural exceptions (Button compound, Spinner not-observable).
What to change
None required for the sampled set; extend the same explicit disposition/rationale metadata already used for Button and Spinner to the remaining catalog components so naming decisions are documented system-wide rather than inferred by a reviewer.
Supporting evidence, 5 citation(s)
Design-to-code contract correspondencecritical
Assessor scores: 1, 2, 2; human review: approve2 / 4

Core consumer-controlled choices correspond well across the sample: Toggle's Selected variant maps to the checked state, Flashbar's Content/Type combination maps to the loading prop, Button's compound atom structure maps to the variant enum, and hover/hidden runtime concerns are justifiably excluded via derived_mapping and runtime_only classifications.

However, two concrete surface-specific controls in the sample are neither supported on the counterpart surface nor explicitly classified as design-only or runtime-only in the evidence: Figma's Button Type variant includes 'Dropdown'/'Dropdown+Main' options absent from ButtonProps.Variant, and Figma's Modal Size variant (Small/Medium/Large/Max) omits the x-large/xx-large values ModalProps.Size supports. Because these gaps are unexplained rather than justified exclusions, the sample does not meet anchor 3's requirement that 'surface-specific controls are explicitly classified.'

Completeness
Complete
Sources
24 of 24
Verification
Implemented
Test definition
Not observed
Automation wiring
Not observed
Current result
Not observed
Generalizability
Sample only

Scoring rule used: Core consumer choices correspond through documented APIs or runtime mechanisms, with justified surface-specific controls excluded

What a higher score requires: Supported choices, derived states, slots, and composition map coherently, and surface-specific controls are explicitly classified

What is still needed: Reaching anchor 3 requires that every surface-specific control in the sample be explicitly classified; the Button Dropdown/Dropdown+Main Type options and the Modal x-large/xx-large size values are unexplained gaps with no documented disposition in the evidence packet, so they remain genuine_gap rather than justified exclusions.

Scope: deep-component; sample-only.

Subjects: button, modal, toggle, flashbar, table.

Limitation: Property-by-property correspondence was directly checked for button, modal, toggle, flashbar, and table; app-layout, cards, form-field, input, side-navigation, and spinner were not individually mapped property-by-property in this analysis and may exhibit different correspondence quality.

What broke
Figma's Button atoms (Normal/Primary/Icon) expose Type options 'Dropdown' and 'Dropdown+Main' with no corresponding ButtonProps.variant value, and Figma's Modal Size variant set (Small/Medium/Large/Max) omits the x-large and xx-large values present in ModalProps.Size, with neither gap explained by a documented disposition in the evidence packet.
Impact
A designer selecting a Dropdown-type Button atom in Figma cannot produce that exact configuration with the shipped Button component (dropdown-trigger behavior lives on a different component), and a designer authoring an x-large or xx-large modal spec has no matching Figma size option to reference, creating unexplained handoff friction for those specific configurations.
Why
figma-sample-details.json lists 'Dropdown' and 'Dropdown+Main' among the five Type variant options for the Normal button (Atom) set (node 12669:4938), while ButtonProps.Variant in button/interfaces.ts enumerates only normal/primary/link/icon/inline-icon/inline-link; similarly the Modal (Atom) Size variant (node 12669:37215) lists only four options while ModalProps.Size in modal/interfaces.ts adds 'x-large' and 'xx-large'.
What to change
Classify the Dropdown/Dropdown+Main Button Type options as design_only (representing the trigger portion of the separate ButtonDropdown component) or add matching code support; extend the Modal Figma component set's Size variant to include x-large/xx-large, or publish a rationale for their exclusion from the design library.
Binding mappings
  • Button variant (Primary/Normal/Link/Icon): shared_contract; design: Four separate Figma component sets: Primary button (Atom), Normal button (Atom), Link button (Atom), Icon button (Atom); code: ButtonProps.variant: 'normal' | 'primary' | 'link' | 'icon' | 'inline-icon' | 'inline-link'. The evaluation's declared design disposition classifies this as compound: the four independently-confirmed Figma sets collectively represent the single code variant enum, so the consumer-controlled 'variant' choice is honored across surfaces even though it is not modeled as one Figma component set.
  • Button Type='Dropdown'/'Dropdown+Main' (Normal/Primary/Icon button atoms): genuine_gap; design: Type variant option list includes 'Dropdown' and 'Dropdown+Main' alongside 'Text only', 'Text + icon', 'External link'; code: ButtonProps.Variant has no 'dropdown' value; dropdown-trigger behavior is not exposed on the Button component in the supplied interfaces.ts. No design disposition or rationale in the evidence packet explains why the Button Figma atoms include dropdown-trigger Type options with no counterpart in ButtonProps.Variant; this is an unclassified, unexplained gap rather than a justified authoring-only or runtime-only control.
  • Toggle checked/Selected state: shared_contract; design: Toggle (Atom) 'Selected' variant: Off/On; code: ToggleProps.ChangeDetail.checked: boolean (event payload for the controlled checked state). Figma's binary Selected variant corresponds directly to the boolean checked state that Toggle's onChange event and controlled usage pattern manage in code.
  • Flashbar loading indicator: derived_mapping; design: Flashbar component set: Content variant ('Progress'/'Text') combined with Type='Info in loading state'; code: FlashbarProps.MessageDefinition.loading?: boolean, which replaces the status icon with a spinner and forces the type to info. The design models loading as a combination of two variant dimensions while code exposes it as a single loading boolean that forces type; the same meaning (a loading flashbar) is expressed through different but equivalent mechanisms.
  • Modal size options: genuine_gap; design: Modal component set 'Size' variant: Small (320px), Medium (600px), Large (820px), Max; code: ModalProps.Size: 'small' | 'medium' | 'large' | 'x-large' | 'xx-large' | 'max'. Code supports two additional fixed sizes (x-large, xx-large) with no corresponding Figma variant option, and the evidence packet contains no rationale explaining the omission.
  • Button hover state: derived_mapping; design: Normal/Primary/Icon/Link button atoms' 'State' variant includes 'Hover' alongside 'Default'/'Disabled'; code: No hover prop on ButtonProps; hover is implemented via a CSS pseudo-state driven by design tokens such as colorBackgroundButtonNormalHover. Figma models hover as an explicit static variant frame for design review, while code achieves the same visual state through a :hover-driven token rather than a settable prop; this is a legitimate derived mapping between a design-time state variant and a runtime pseudo-state.
  • Table responsive content preview (Content (D)/Content (S)): design_only; design: Table component set exposes 'Content (D)#683:0' and 'Content (S)#683:3' INSTANCE_SWAP properties to preview desktop vs. small-viewport table content in Figma; code: Not applicable -- TableProps has no desktop/small content-swap property; responsive rendering is handled automatically by the component at runtime. This is an authoring-time preview mechanism letting designers swap in different mock content per breakpoint frame; it has no necessary code prop counterpart because the shipped Table component determines its responsive layout automatically rather than through an author-supplied breakpoint variant.
  • Modal onDismiss: runtime_only; design: Not applicable -- the Modal component set's property definitions (Content, Size) do not model a dismiss event; code: ModalProps.onDismiss: NonCancelableEventHandler<ModalProps.DismissDetail>, fired on close-button click, overlay click, or Escape key. onDismiss is an event handler wired to application routing/state and has no necessary static Figma property; this is a justified runtime-only control excluded from parity comparison.
Supporting evidence, 10 citation(s)
Token paritycritical
Assessor scores: 2, 2, 2; human review: approve2 / 4

Foundation variable coverage is full-file (not sampled), giving broad visibility into the Figma token model. Color tokens show strong identity and mode parity: the Figma color-variable collection (283 variables, Light/Dark modes) matches code's paired light/dark token objects (for example, colorGreyOpaque70) and the normative token docs' CTI-style semantic naming (for example, $color-background-button-normal-hover).

However, the Figma spacing collection exposes only a single mode ('Value', 10 variables) while the implementation applies a distinct comfortable/compact density mode to spacing tokens (confirmed by createDensityMode() and one-theme spacing overrides with different comfortable/compact values, and documented on the public tokens page with separate Comfortable/Compact columns). Additionally, the raw Figma variable count for colors (615) is not reconciled against the 407 colors documented on the public design-tokens page.

These are documented, evidence-based gaps rather than a full identity-and-mode match, placing the sample at anchor 2 rather than anchor 3.

Completeness
Complete
Sources
24 of 24
Verification
Implemented
Test definition
Not observed
Automation wiring
Not observed
Current result
Not observed
Generalizability
System wide

Scoring rule used: Core semantic tokens align with documented gaps

What a higher score requires: Token identity and modes align across design and code

What is still needed: Reaching anchor 3 would require the Figma spacing collection to model a comfortable/compact density mode matching the code's createDensityMode dimension, and a reconciliation of the raw Figma variable count (703 total / 615 color) against the number of tokens documented on the public design-tokens page (407 colors), since this gap is currently unexplained in the evidence.

Scope: foundation; system-wide.

Subjects: color tokens, spacing tokens, typography tokens, border tokens.

Limitation: Foundation variable coverage is stated as full-file rather than a sample, supporting a system-wide claim about the token model; however, the unexplained 615-vs-407 color-count discrepancy between the raw Figma variable export and the publicly documented token table was not reconciled within the evidence packet, and data-visualization-specific colors are covered on a separate documentation page not included here.

What broke
The Figma 'spacing' variable collection models only a single mode ('Value', 10 variables), while implementation spacing tokens branch into comfortable/compact density modes (confirmed by createDensityMode() and by one-theme/spacing.ts overriding several spacing tokens with distinct comfortable/compact values, and documented publicly with separate Comfortable/Compact columns for spacing tokens such as $space-alert-vertical: 8px/4px).
Impact
Designers working from the Figma spacing variables cannot see or select the compact-density spacing values the shipped component library applies in compact mode, so density-mode layouts may drift from the design source unless manually cross-referenced against the separate token documentation table.
Why
figma-variable-summary.json lists the spacing collection with a single mode object named 'Value' covering all 10 spacing variables, while style-dictionary/utils/modes.ts defines a 'density' mode with comfortable/compact states, and one-theme/spacing.ts sets spaceFieldVertical to { comfortable: '4px', compact: '2px' } -- a distinction the design-tokens documentation also surfaces via separate Comfortable/Compact mode columns.
What to change
Extend the Figma spacing variable collection with a density mode dimension mirroring the code's comfortable/compact modes, or explicitly document that spacing density is intentionally an implementation-only concern not modeled in the design source.
Supporting evidence, 8 citation(s)
Traceability and deprecation
Assessor scores: 2, 2, 3; human review: revise2 / 4

Each sampled component documentation page provides maintained, component-scoped links to the design library, source code, and API properties. The collected component API and implementation interfaces document supported properties and events while marking superseded APIs as deprecated, including Table’s visibleColumns, AppLayout’s contentHeader and disableContentHeaderOverlap, and Flashbar’s buttonText and onButtonClick. This supports the anchor that core assets have maintained references.

However, no public evidence shows a maintained cross-surface mapping from specific Figma components and properties to corresponding code components and properties, or an automated mechanism detecting drift between them.

Completeness
Complete
Sources
24 of 24
Verification
Implemented
Test definition
Not observed
Automation wiring
Not observed
Current result
Not observed
Generalizability
Sample only

Scoring rule used: Core assets have maintained references

What a higher score requires: Versioned mappings expose supported and deprecated APIs

What is still needed: A publisher-maintained, versioned Figma-to-code mapping, such as Code Connect or an equivalent manifest, covering current and deprecated design-side assets is needed to establish cross-surface traceability.

Scope: mixed; sample-only.

Subjects: button, flashbar, table, app-layout, form-field, toggle, modal, cards, side-navigation, input, component-api manifest, release/governance workflows.

Limitation: Only the sampled components' interface files and doc pages, plus the public release workflows, were inspected; internal design-review or governance processes that might strengthen traceability are outside this public evaluation's declared governance scope, per the governance known_limitations.

What broke
No unexplained failure was found in the maintained per-component references, but no versioned design-to-code identifier mapping (for example, Code Connect) exists to expose deprecated design assets alongside deprecated code props the same way the component-api manifest does for code alone.
Impact
Consumers can find the right doc/code/design entry point per component via maintained links, and can discover deprecated code props from the manifest, but nothing currently flags a Figma asset as stale relative to a specific code API change, so drift between design and code deprecations would go undetected until manually reviewed.
Why
Every sampled component's documentation page (Button, Table, App layout, Flashbar, Form field, Modal, Toggle, Side navigation, Cards, Input) carries dated, component-scoped 'Browse code' and 'Get design library' links, and the versioned component-api.json documents deprecated props such as Table's visibleColumns and AppLayout's contentHeader/disableContentHeaderOverlap; no Code Connect dependency, workflow step, or Figma-node-to-code-identifier manifest appears in the release-governance workflows or package.json dependencies.
What to change
Publish a versioned Figma-to-code identifier mapping (or adopt Code Connect) so deprecated or renamed design assets can be traced to their code equivalents the same way deprecated code props already are traced within the component-api manifest.
Supporting evidence, 6 citation(s)

Components

Every score in this area completed review.

75
out of 100, continue, 100% reviewed
Core component coverage
Assessor scores: 3, 3, 3; human review: approve3 / 4

The public catalog (cloudscape-llms-index, cloudscape-component-api) documents over 100 components spanning layout, navigation, forms, data display, feedback, and charts: comprehensive breadth for a general enterprise console product scope. The Figma library independently maps matching component sets for the declared deep-component sample (Toggle, Cards, Flashbar, Form field, Modal, Button variants, Table, App layout, Side navigation), corroborating that catalog breadth extends into the design surface, not just code. This satisfies the anchor's single clause (comprehensive coverage for stated scope) without reaching the measurement anchor.

Completeness
Complete
Sources
23 of 23
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: No public evidence of measured adoption, gap tracking, or component health metrics (required for score 4); cloudscape-governance known_limitations explicitly states adoption dashboards and internal test results are outside this public evaluation.

Scope: catalog; system-wide.

Subjects: cloudscape-llms-index component catalog, cloudscape-component-api, cloudscape-figma component library.

Limitation: Catalog presence proves breadth and inventory only; it does not by itself prove deep state, accessibility, or responsive quality for every listed component: only the declared deep-component sample was inspected in depth for this evaluation.

What broke
No confirmed break
Impact
Teams building common enterprise-console product surfaces (forms, tables, cards, navigation, feedback, charts) can rely on a documented, first-party component for most needs rather than building custom one-offs
Why
cloudscape-llms-index and cloudscape-component-api jointly enumerate over 100 documented components with full API declarations, and cloudscape-figma independently confirms matching component sets for the sampled deep components
What to change
Publish a public catalog gap-analysis, adoption, or component-health dashboard to support a higher (4) score in future evaluations
Supporting evidence, 3 citation(s)
Normal, recovery, and permission statescritical
Assessor scores: 3, 3, 3; human review: approve3 / 4

Within the declared sample, several components have both a rich state model in code and direct test evidence: Button's disabled/loading/disabledReason behavior is exhaustively tested (tooltip open/close on focus, blur, hover, and Esc; aria-disabled vs disabled; tab-order skip); FormField's error/warning text and debounced live-region character count are tested; Flashbar's type/loading states and alert-vs-status focus behavior on add/dismiss are tested; Table's interfaces define a four-state loader (pending/loading/finished/error) plus skeleton and empty slots.

System-authored pattern docs (validation, loading-and-refreshing, empty-states) give explicit, component-referenced guidance tying these states together across the declared flow and patterns. This satisfies 'comprehensive ownership and guidance' for the well-evidenced subset, but permission-specific behavior is not directly evidenced (only disabledReason as an analog), and input/toggle/side-navigation/cards/spinner state transitions are only supported by interface declarations rather than visible test excerpts in this packet, so the anchor is met unevenly across the full declared sample.

Completeness
Complete
Sources
23 of 23
Verification
Implemented
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: No execution/measurement evidence (CI pass/fail results, coverage dashboards) ties these state contracts to continuous testing; permission-specific state behavior and state-transition tests for input, toggle, side-navigation, cards, and spinner are not directly shown in this packet, so a score of 4 is unsupported.

Scope: mixed; sample-only.

Subjects: button, form-field, flashbar, table, modal, app-layout, create-configure-save flow, loading-recovery pattern, empty-state-recovery pattern.

Limitation: Findings apply to the declared deep-component and composition sample and do not establish state behavior for catalog components outside this sample.

What broke
No confirmed break at the comprehensive-guidance level, but permission-state evidence and cross-sample automated-test evidence are thin
Impact
Consumers can rely on documented/tested state contracts for button, form-field, flashbar, and table's loader model, but should independently verify state behavior for input, toggle, side-navigation, cards, and spinner, and should not assume permission-denied handling matches disabledReason's tested pattern without checking
Why
Evidence favors deep coverage on a subset of the declared sample (button, form-field, flashbar, table interfaces) while other declared components/compositions show only design-level or documentation-level support in this packet
What to change
Provide direct unit/integration test evidence for input, toggle, side-navigation, cards, and spinner state transitions, and for permission-denied scenarios, to substantiate a higher score
Supporting evidence, 5 citation(s)
Responsive behavior
Assessor scores: 3, 3, 3; human review: revise3 / 4

Cloudscape’s responsive-development guidance defines a system-wide mechanism in which components adapt to the width of their containing element using predefined breakpoints rather than relying only on viewport width. Collected test source encodes specific expected adaptations across the declared sample: Cards defines exact column counts at multiple container widths and after preference changes; AppLayout defines mobile behavior across supported visual themes; and Table defines different focus and horizontal-scroll behavior at narrow and wide viewports.

Together, the normative mechanism and executable test definitions support consistent adaptation across the sampled conditions. Score 4 is not supported because no current CI or visual-regression execution results were observed across the complete supported condition matrix.

Completeness
Complete
Sources
23 of 23
Verification
Test defined
Test definition
Observed
Automation wiring
Not observed
Current result
Not observed
Generalizability
System wide

Scoring rule used: Components adapt consistently across supported conditions

What a higher score requires: Responsive behavior is continuously tested across the matrix

What is still needed: Current automated execution results covering the supported viewport, container, theme, density, and content matrix, along with tracked responsive regressions, are needed to establish continuous validation.

Scope: mixed; system-wide.

Subjects: element-query responsive mechanism, cards, app-layout, table, create-configure-save flow viewports (small/medium/large).

Limitation: The element-query mechanism is cited as applying system-wide, but only cards, app-layout, and table have direct executed test evidence in this packet; other catalog/deep components' responsive behavior is not independently confirmed here.

What broke
No confirmed break: responsive adaptation is documented via a system-wide element-query mechanism and directly exercised by tests across several sampled components and viewports.
Impact
Consumers assembling the create-configure-save flow (small/medium/large viewports) and loading/empty-state patterns can rely on tested, viewport-appropriate behavior for app-layout, cards, and table, reducing risk of layout breakage on resize.
Why
Executed tests assert concrete pixel-based behavior (breakpoint thresholds, mobile-forced states, scroll behavior) rather than only describing intent in prose.
What to change
Surface visual-regression/CI run results (for example, from the referenced visual-regression workflow) so responsive behavior can be confirmed as continuously validated rather than validated only at the point these test files were authored.
Supporting evidence, 5 citation(s)
Accessibility behaviorcritical
Assessor scores: 3, 3, 3; human review: approve3 / 4

Within the declared sample, accessible behavior is comprehensively implemented and tested for several components: Button tests aria-disabled vs disabled, aria-describedby/hidden-text for disabledReason with focus/blur/hover/Esc-driven tooltip visibility, aria-expanded/aria-haspopup/aria-controls, and keyboard tab-order skipping of disabled buttons. Modal tests initial focus delegation, focus restoration, avoidance of stray focus capture, and keeping focused elements visible above a sticky footer. Flashbar tests ARIA role (alert vs status) selection and focus movement on add/dismiss, including debounced multi-item announcements.

App layout tests aria-label/aria-expanded/aria-controls/role semantics for drawer, tools, and navigation triggers across themes and mobile. FormField associates a semantic <label> element and tests accessible error/warning icon text and debounced live-region character-count announcements. This is backed by a normative WCAG-aligned foundation doc citing specific Cloudscape components as accessibility exemplars.

The gap to the top anchor is that dedicated a11y-regression test files (a11y-refresh-dark/light, table a11y.test.tsx) exist per the file listing but their content, results, or CI gating are not shown in this packet.

Completeness
Complete
Sources
23 of 23
Verification
Documented
Test definition
Not observed
Automation wiring
Not 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: Dedicated automated accessibility-regression test files (a11y-refresh-dark.test.ts, a11y-refresh-light.test.ts, table/__tests__/a11y.test.tsx) exist per the file listing, but their content, pass/fail results, or CI gating were not included in this evidence packet, so continuous AT-coverage measurement cannot be confirmed for a score of 4.

Scope: mixed; sample-only.

Subjects: button, modal, flashbar, app-layout, form-field, cloudscape-accessibility-docs foundation guidance.

Limitation: Findings are strongest for button, modal, flashbar, app-layout, and form-field; side-navigation and toggle show only minor accessibility test coverage, and input, cards, table, and spinner accessibility depth is not shown in this packet, so this should not be generalized to those components without further evidence.

What broke
No confirmed critical accessibility failure; the gap is limited to proof of continuous/measured AT-regression coverage
Impact
Consumers can rely on tested keyboard/focus/ARIA behavior for button, modal, flashbar, app-layout, and form-field; broader system-wide continuous AT monitoring is unconfirmed from this packet, and side-navigation, toggle, input, cards, table, and spinner accessibility depth is only lightly or not evidenced here
Why
Referenced a11y-specific test suite files (a11y-refresh-dark/light, table a11y.test.tsx) were listed as valid evidence paths in the packet's source repository but not excerpted with content
What to change
Include content/results from the a11y-refresh-dark/light test suites and table a11y.test.tsx, or CI gating configuration, to substantiate continuously-measured AT coverage
Supporting evidence, 1 citation(s)

Structure

Every score in this area completed review.

75
out of 100, continue, 100% reviewed
Layout primitives
Assessor scores: 3, 3, 3; human review: approve3 / 4

Foundation documentation defines a 4px-based spacing scale with concrete usage mappings (e.g. 4px between form-field label and control, 40px app-layout content padding on large screens) and an application-layout anatomy (five named regions) plus a responsive mechanism (element queries against predefined breakpoints, not viewport).

This is not merely prose: the app-layout code (interfaces.ts, index.tsx) implements the same contract observed in docs: contentType values ('default'|'form'|'table'|'cards'|'wizard'|'dashboard') drive default navigation/content-width behavior, and useAppLayoutPlacement computes responsive placement from header/footer selectors. The Figma sample for app-layout is fully resolved with 18 bound variable IDs on a single node, consistent with the declared full-file variable coverage.

Together this covers the stated product scope (the app-layout-anchored flow and pattern samples) with primitives that are both documented and implemented, but no automated measurement of layout exceptions or breakpoint conformance was present in evidence, so anchor 4 is not reached.

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: Layout primitives cover the stated product scope

What a higher score requires: Layout use and exceptions are validated and measured

What is still needed: No observed automated validation or measurement of layout use/exceptions (e.g. breakpoint or visual-regression execution results) was present in the supplied evidence text, only test file paths without visible content, so 'validated and measured' cannot be scored.

Scope: mixed; system-wide.

Subjects: app-layout foundation layout guidance, spacing foundation scale, responsive development foundation guidance, app-layout component implementation, app-layout Figma variable-binding sample.

Limitation: Foundation guidance and full-file variable coverage support system-wide layout primitives, but direct code/Figma cross-verification was only performed for the app-layout sample; per-component conformance to spacing tokens outside the sample was not independently checked.

What broke
No confirmed break
Impact
Teams can rely on a documented, code-consistent set of layout primitives (grid, spacing, app-layout regions, responsive element queries) for the declared product scope, but cannot point to measured evidence that exceptions or breakpoint drift are caught automatically.
Why
Foundation docs and app-layout code agree on the same contentType-driven layout contract, and Figma variable binding is full-file, but no automated breakpoint/visual-regression results were included in the evidence packet.
What to change
Surface CI visual-regression or breakpoint-conformance results (e.g. from the referenced app-layout-responsive visual tests) as directly cited evidence to support a higher anchor.
Supporting evidence, 5 citation(s)
Composition guidance
Assessor scores: 3, 3, 3; human review: approve3 / 4

Composition rules are documented at the slot level for every component required by the declared flow/patterns: app-layout's notifications, navigation, tools, content, and splitPanel regions each have explicit placement rules (e.g. flashbar 'in the notification region of app layout'); cards and table docs both state that full-page variants 'must be the first component in the content slot'; modal specifies using space-between for multiple footer buttons.

These rules are corroborated by the observed AppLayoutProps slot API (content, tools, notifications, navigation, splitPanel, drawers) in interfaces.ts, so the guidance is not merely prose disconnected from implementation. This covers the supported assemblies named in create-configure-save, loading-recovery, and empty-state-recovery, but no evidence shows these composition rules are enforced automatically (e.g. lint rule failing when cards aren't first in content), so anchor 4 is not reached.

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: 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 enforcement of composition rules (e.g. a lint/test failing if a full-page cards instance is not first in the content slot) was present in the evidence, so 'executable or automatically validated' cannot be scored.

Scope: composition; sample-only.

Subjects: app-layout slot contract, cards full-page placement rule, table full-page placement rule, modal footer composition, flashbar app-layout placement.

Limitation: Evidence establishes composition contracts only for the components named in the declared create-configure-save, loading-recovery, and empty-state-recovery samples; it does not establish a system-wide composition-validation mechanism applicable to components outside this sample.

What broke
No confirmed break
Impact
Developers assembling the declared create/loading/empty-state flows have concrete, component-linked slot rules to follow, reducing ambiguity about where each component belongs, but there is no automated guardrail evidenced to catch violations of those rules.
Why
Composition guidance is normative documentation cross-checked against the actual AppLayoutProps slot surface, but no lint, type-level, or test enforcement of ordering/placement rules (e.g. cards-first-in-content) was present in the supplied evidence.
What to change
Cite or add automated checks (lint rule, structural test) that fail when a documented composition rule (e.g. full-page cards not first in content) is violated, to support a higher anchor.
Supporting evidence, 5 citation(s)
Patterns and templates
Assessor scores: 3, 3, 3; human review: approve3 / 4

All three declared patterns are documented as reusable task patterns with explicit, lettered building blocks (single-page create: breadcrumbs, form page header, container, primary fields, expandable section, form actions, info link, help panel, side navigation) or state-by-state guidance (loading-and-refreshing: manual/automatic refresh, refreshing issues, skeleton vs. spinner loading; empty-states: empty state vs. zero-results state, each with heading/description/action-button building blocks), and each links directly to the components named in the coverage profile (table, cards, button, flashbar, spinner, form).

This matches anchor 3's requirement that patterns cover important tasks and remain linked to components. The known limitation that no matching end-to-end Figma screen was claimed is consistent with these patterns being declared code+documentation surfaces only, not a design-surface gap. No adoption, outcome, or lifecycle measurement of pattern usage was present, so anchor 4 is not reached.

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: 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 pattern usage, outcome, or lifecycle measurement (e.g. adoption analytics, deprecation tracking) was present in the supplied evidence, so 'pattern use, outcomes, and lifecycle are measured' cannot be scored.

Scope: composition; sample-only.

Subjects: single-page create pattern, loading-and-refreshing pattern, empty-states pattern.

Limitation: Evidence covers only the three declared patterns and their linked components; it does not establish that all Cloudscape patterns (only three of which are in scope here) meet the same bar, nor does it confirm a matching Figma end-to-end screen exists for these patterns.

What broke
No confirmed break
Impact
Teams implementing create, loading/refresh, or empty-state flows have canonical, component-linked reference patterns to follow rather than having to invent structure per feature, but there is no evidence these patterns' real-world usage or outcomes are tracked.
Why
The three declared patterns are documented with explicit building blocks and direct component links across the required code and documentation surfaces (design was correctly excluded per the flow's known_limitations), but usage/lifecycle telemetry is outside public evidence.
What to change
If pattern adoption or outcome data exists internally, surface it publicly (or cite it) to support measurement-based scoring; otherwise this remains a documentation-level ceiling.
Supporting evidence, 4 citation(s)
Navigation, focus, and state ownershipcritical
Assessor scores: 3, 3, 3; human review: revise3 / 4

AppLayout’s documentation and implementation interfaces define controlled-state ownership for navigation, tools, drawers, and split panels, plus imperative focus contracts for responsive transitions. Routing guidance explains when state should be reset or when an AppLayout instance should be scoped to a route. Collected integration-test source encodes focus transitions across split panels, tools, drawers, navigation, and information links on mobile and desktop across supported visual themes.

Modal guidance additionally defines dialog-nesting and focus-on-open ownership. This supports comprehensive navigation, focus, and state contracts for the AppLayout-centered create-configure-save flow. Loading-recovery and empty-state-recovery ownership remain supported primarily by prose guidance in the reviewed evidence, and no current CI execution results were observed.

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: Navigation, focus, and state contracts are comprehensive

What a higher score requires: Cross-composition contracts are executable and continuously verified

What is still needed: Current continuous-execution results for the AppLayout focus contracts, plus equivalent implementation or test coverage for loading-recovery and empty-state-recovery transitions, are needed to establish executable and continuously verified cross-composition ownership.

Scope: mixed; sample-only.

Subjects: app-layout drawer/tools/navigation/split-panel focus ownership (integ tests), create-configure-save flow controlled-state contract, modal dialog-nesting and focus-on-open rules.

Limitation: Ownership evidence is strong and code-verified for app-layout compositions but is documentation-only for the loading-recovery and empty-state-recovery patterns; findings should not be generalized to table/cards async ownership without further code-level evidence.

What broke
No confirmed broken ownership behavior in the sampled tests; the gap is uneven evidence depth across the declared compositions.
Impact
The app-layout shell used by the create-configure-save flow has a strong, test-backed ownership contract for drawers, tools, navigation, and split panel, reducing risk of focus loss or state desync during responsive transitions. But loading-recovery and empty-state-recovery (table/cards refresh, error, and recovery transitions) rely on prose guidance only here, so ownership risk during async table/cards state changes (e.g. focus during a failed refresh) is less independently verified.
Why
The component-quality snapshot supplied deep integ-test coverage specifically for app-layout, while the loading-and-refreshing and empty-states pattern sources in this packet are documentation pages without accompanying table/cards ownership test files.
What to change
Extend automated focus/state-ownership testing analogous to app-layout-focus-delegation.test.ts to table and cards loading/error/recovery transitions, and surface CI run evidence (e.g. workflow results) for the existing app-layout tests to support scoring toward anchor 4.
Supporting evidence, 4 citation(s)

Governance

Every score in this area completed review.

62.5
out of 100, partial, 100% reviewed
Named ownership
Assessor scores: 3, 2, 3; human review: approve3 / 4

CODEOWNERS assigns a single named team as the mandatory reviewer/merger for the entire repository, and this is a technically enforced GitHub mechanism, not merely a policy statement. CONTRIBUTING.md operationalizes support boundaries: contribution scope is limited to bug fixes, general support runs through issues/discussions, and security issues are routed to a dedicated non-public vulnerability-reporting channel rather than public issues. Together these show decision rights and support boundaries functioning, but no public ownership-health or service-expectation metrics exist, so the evidence stops short of anchor 4.

Completeness
Complete
Sources
7 of 7
Verification
Documented
Test definition
Not observed
Automation wiring
Not 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: No public ownership health or service-expectation metrics (for example, response-time SLAs, staffing/coverage data) are evidenced, which anchor 4 requires.

Scope: governance; system-wide.

Subjects: CODEOWNERS repo-wide ownership rule, CONTRIBUTING.md support and security-reporting boundaries.

Limitation: Applies to the entire public components repository as declared, but cannot reveal internal AWS ownership records, per-component ownership detail, or ownership health metrics, which the governance evidence scope marks as outside public evaluation.

What broke
Ownership evidence is limited to one flat, repo-wide CODEOWNERS entry with no per-component ownership breakdown, and no ownership health or responsiveness metrics are published.
Impact
Consumers can see who has merge authority and what the support boundaries are, but cannot tell which team owns a specific component or how healthy/responsive that ownership is.
Why
CODEOWNERS is a single wildcard rule naming one team for the whole repository, and CONTRIBUTING.md's support-boundary language is a static policy statement with no accompanying metrics.
What to change
Publish component/area-level ownership detail and ownership health indicators (for example, response-time data, staffing coverage) to move toward measured ownership maturity.
Supporting evidence, 3 citation(s)
Contribution and review
Assessor scores: 3, 3, 3; human review: approve3 / 4

CONTRIBUTING.md documents a fork-PR-review-merge path, and this is made operational by two independent mechanisms observed directly: an automated CI gate (build-lint-test.yml) that runs on every pull_request and merge_group event across a React 16/18 matrix, and a PR template checklist that requires authors/reviewers to evaluate correctness (docs, backward compatibility, browser support, manual accessibility testing), security (checkSafeUrl validation), and testing (unit/integration coverage) on every submission.

This is cross-discipline and operational, but the packet contains no measurement of review outcomes or throughput, which anchor 4 requires.

Completeness
Complete
Sources
7 of 7
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: No evidence of measured review quality, throughput, or outcomes (for example, review latency, defect escape rate, rejection rate) is present, which anchor 4 requires.

Scope: governance; system-wide.

Subjects: pull request review process, build-lint-test.yml CI gate, PULL_REQUEST_TEMPLATE.md checklist.

Limitation: Confirms CI triggers and template content apply repo-wide, but does not confirm branch-protection enforcement of code-owner review or actual historical review behavior/outcomes, which are outside the observable public evidence.

What broke
No confirmed break: the review path is documented and operational across correctness/security/testing dimensions, but review outcomes are not measured.
Impact
Contributors face a consistently enforced review gate (CI plus a cross-discipline checklist) before merge, giving reasonable confidence in per-PR review rigor, but the project cannot demonstrate consistency or effectiveness of that review over time.
Why
build-lint-test.yml triggers automatically on pull_request, merge_group, and push-to-main events; PULL_REQUEST_TEMPLATE.md requires evaluation of correctness, security, and testing on every PR, per the evidenced files.
What to change
Track and publish review/CI outcome metrics (for example, pass rates, review latency, post-merge defect rate) to support a higher score, and confirm whether code-owner review is enforced via branch protection.
Supporting evidence, 3 citation(s)
Releases, migration, and deprecationcritical
Assessor scores: 2, 2, 2; human review: approve2 / 4

GENERAL_GUIDE.md documents a clear versioning policy (daily patch releases, patch versions never containing breaking changes) and explicitly scopes the public API surface (component APIs, test utilities, design tokens; internal HTML/class names excluded from breaking-change consideration). API_DOCS.md documents a `@deprecated` tag convention requiring a replacement recommendation, and the llms.txt index references a dedicated charts migration guide.

This satisfies anchor 2's documentation requirement, but the packet does not evidence an explicit, general operational contract for deprecation notice periods, support windows, or systematic migration tooling: only a tagging convention and one component-family migration guide: so anchor 3 is not fully supported.

Completeness
Complete
Sources
7 of 7
Verification
Release documented
Test definition
Not observed
Automation wiring
Not observed
Current result
Not observed
Generalizability
Sample only

Scoring rule used: Versions and important changes are documented

What a higher score requires: Deprecation and migration have explicit operational contracts

What is still needed: Anchor 3 requires deprecation and migration to have explicit operational contracts (for example, stated notice periods, support overlap windows, or systematic migration tooling/codemods). The packet only evidences a tagging convention plus one named migration guide (charts), not a general, enforced deprecation/migration policy, so this anchor is not fully met.

Scope: mixed; sample-only.

Subjects: GENERAL_GUIDE.md versioning/public-API section, API_DOCS.md @deprecated tag, charts migration guide reference.

Limitation: Migration tooling evidence is limited to the charts component family; a general deprecation-timeline contract is absent from the public packet, and internal pre-publish testing outcomes referenced in CONTRIBUTING.md are explicitly out of scope for this public evaluation.

What broke
Deprecation and migration lack an explicit, generalized operational contract despite documented versioning and a deprecation-tag convention.
Impact
Consumers know the release cadence and that patch versions are non-breaking, but have no published guarantee of deprecation notice periods or systematic migration support beyond the charts component family.
Why
GENERAL_GUIDE.md documents versioning and public API scope, and API_DOCS.md documents the @deprecated tag, but no evidenced source states deprecation timelines, advance notice requirements, or migration tooling coverage beyond the named charts migration guide.
What to change
Publish an explicit deprecation/migration policy (notice period, supported overlap window, migration tooling scope) and extend migration guidance beyond charts to other breaking transitions.
Supporting evidence, 3 citation(s)
Quality enforcement and feedbackcritical
Assessor scores: 3, 2, 3; human review: revise2 / 4

Cloudscape has substantial automated quality gates across pull requests, merge queues, supported React versions, accessibility, visual regression, testing, and bundle size.

However, the score-3 anchor requires quality gates to cover both the supported lifecycle and exceptions. The public evidence contains snapshot-update instructions but no governed waiver, bypass, approval, or exception-tracking process, so the directly supported anchor is 2: core automated checks or review gates exist.

Completeness
Complete
Sources
7 of 7
Verification
Automation wired
Test definition
Not observed
Automation wiring
Observed
Current result
Not observed
Generalizability
System wide

Scoring rule used: Core automated checks or review gates exist

What a higher score requires: Quality gates cover the supported lifecycle and exceptions

What is still needed: Additional evidence must satisfy the next anchor: Quality gates cover the supported lifecycle and exceptions

Scope: governance; system-wide.

Subjects: build-lint-test.yml, visual-regression.yml, src/__a11y__ accessibility suite, bundle-size.yml/bundle-size-report.yml, PULL_REQUEST_TEMPLATE.md checklist.

Limitation: These CI/test artifacts are repository-wide mechanisms, not per-component samples, but internal post-merge testing, waiver/exception governance, and adoption or regression metrics are outside the declared public governance evidence scope.

What broke
No confirmed break: a substantial, observably-triggered set of automated quality gates exists, but public evidence of exception/waiver governance and measured outcomes is absent.
Impact
Contributions are protected by real automated build, visual-regression, accessibility, and bundle-size checks, but there is no visibility into how exceptions to these gates are governed or whether gate outcomes (pass rates, flake rates, waivers granted) are tracked and acted on.
Why
The sampled CI configuration and test suites demonstrate gate existence and triggering conditions, but none of the evidenced files describe an exception process or expose aggregate gate-outcome metrics.
What to change
Document how exceptions to automated gates (for example, an accepted visual diff or a11y waiver) are recorded and tracked, and publish gate-outcome metrics (pass rates, flake rates) to support measurement-based scoring.
Supporting evidence, 3 citation(s)

How Cloudscape can get better

Start with the known problem. Then keep design and code aligned, test complete product experiences, and track whether the system improves. Open an item to see what to do, who should own it, and how to show it worked.

Score today68.75 / 100
Points this plan could add+31.25
4 stages to a score of 100Each stage builds on the one before it. The number shown is the score Cloudscape could reach after a new evaluation confirms the work.
0TodayCurrent score
68.75Starting point
1Stage 1Fix known issues
68.75Possible score, +0 points
2Stage 2Align Figma and code
82.5Possible score, +13.75 points
3Stage 3Test the whole system
92.5Possible score, +10 points
4Stage 4Measure and improve
100Possible score, +7.5 points

How the score could change: Cloudscape can only earn these points after the work is complete and the evaluation is run again. Some of the evidence may already exist inside AWS.

Before starting new work, ask what already exists inside AWS

Before funding new work, check whether AWS teams already run the tests, mappings, dashboards, and reviews requested by this study. If they do, AWS can share current results for a re-run instead of rebuilding an existing capability.

Ask for:

  • Current canonical implementations and end-to-end results for supported creation, validation, loading, recovery, and AppLayout flows
  • Current checks that compare Figma variables and properties, released token outputs, typed component APIs, and approved exceptions
  • Current reports showing state, responsive, interaction, accessibility, and assistive-technology coverage across the component library
  • Current reports showing adoption, exceptions, migration completion, review times, and quality trends
Stage 1

Fix the known problem and check what the team already does internally.

Project 1

Make typed composition and complete workflows executable

Problem
The profile using only the evidence supplied with each task passed 24 of 60 benchmark runs. Executable failures included typed API and workflow-state problems; other failures involved exact semantic, governance, or evidence requirements.
Action
  • Publish exact TypeScript references for nested SideNavigation items, Modal dismissal, immutable Flashbar messages, filtered lists, load-more announcements, and create-resource composition.
  • Show supported imports and properties beside common invalid alternatives such as Modal.closeLabel and mutable readonly message arrays.
  • Give each decision-relevant guidance passage a stable machine-readable source identifier and granular anchor.
  • Cover validation, focus, loading, success, failure, retry, live announcements, and 320-pixel behavior in executable tests.
  • Preregister the task universe, evaluator, measurement-kind analysis, and decision rule before repeating the two recorded operational profiles.
Owner
  • Cloudscape AppLayout and form component owners
  • Cloudscape accessibility and pattern owners
  • Cloudscape documentation and developer-experience owners
Finish line

Designers, engineers, and agents can start from versioned Cloudscape references that use exact typed APIs, preserve required workflow state, cite the governing evidence, and pass the same checks used for acceptance.

  • Every published reference type-checks against the documented Cloudscape package version.
  • The references pass their required accessibility, interaction, responsive, semantic, and evidence checks.
  • A preregistered rerun reports executable, transcription, semantic, governance, and evidence outcomes separately.
  • The rerun does not describe benchmark compliance as representative production reliability or documentation causality.
Save for the next evaluation
  • Published TypeScript references, API schemas, negative examples, and agent-facing guidance
  • Runtime tests for type, accessibility, interaction, responsive behavior, semantic selection, and provenance
  • Repeated actor streams, run outputs, hashes, costs, exposure logs, and the preregistered analysis plan
Decision enabled
Which public examples and acceptance checks reduce failures in this benchmark, without treating the result as production reliability.
Stage 2

Keep Figma and code aligned.

Project 2

Keep Figma and code aligned before release

Problem
Cloudscape has mature foundations and useful design and code assets. The evaluated public evidence did not reconcile Button dropdown variants, Modal sizes, density modes, token inventories, and a maintained Figma-to-code mapping in one release check. AWS may already run parts of this check internally.
Action
  • Generate a versioned manifest listing Figma variables and properties, released token names and modes, typed component APIs, mappings, and approved exceptions.
  • Resolve or explicitly classify the sampled Button dropdown and Modal size differences.
  • Reconcile Figma spacing density and color inventories with released outputs.
  • Run a release check that fails on unexplained differences and records owned, expiring exceptions.
  • Publish compatibility, mapping coverage, drift, and approved-exception results.
Owner
  • Cloudscape foundations and token-build owners
  • Cloudscape Figma library and component API owners
  • Cloudscape documentation and build-infrastructure owners
Finish line

A change to a token, Figma control, mapping, or typed component API cannot ship with an unexplained difference.

  • Every supported design and code output appears in a dated compatibility report.
  • A seeded token or property mismatch fails the check and identifies the exact surfaces involved.
  • Every surface-specific difference has a rationale, owner, and review date.
  • The report shows current mapping coverage, compatibility, drift, and approved exceptions.
Save for the next evaluation
  • Cross-surface manifest and comparison implementation
  • Passing and intentionally failing CI results
  • Compatibility, mapping-coverage, drift, and exception reports
  • Approved exception and mapping-decision register
Decision enabled
Whether a token, Figma, mapping, or component API change is safe to release.
Do this first
Make typed composition and complete workflows executable
Stage 3

Test complete product experiences, not only individual parts.

Project 3

Test complete product experiences across the whole system

Problem
Cloudscape documents component behavior, accessibility, responsive behavior, layout, and application patterns. This study did not find one current published quality matrix covering required states, screen sizes, accessibility checks, layout rules, and complete product flows. AWS may maintain broader internal results.
Action
  • Define required normal, loading, empty, error, disabled, recovery, and permission states for each component type.
  • Test required states across supported screen sizes, keyboard paths, and assistive technology.
  • Turn important layout, composition, and interaction rules into executable checks.
  • Build repeatable tests for validation, create-and-save, loading recovery, empty states, modal focus, AppLayout controls, and responsive layout.
  • Publish a per-release report with current results, owners, exception expiration dates, and completed fixes.
Owner
  • Cloudscape component and pattern maintainers
  • Cloudscape accessibility and quality owners
  • Product teams representing supported flows
Finish line

For every supported component and pattern, teams can see which conditions apply, which tests passed, what is exempt, and who owns any remaining problem.

  • Every supported component and pattern shows which states and environments apply.
  • Current results cover viewports, interaction, keyboard, and accessibility requirements.
  • A broken layout, focus path, validation relationship, AppLayout control, or recovery flow fails an automated check.
  • Every failure and approved exception has an owner, review date, and recorded resolution.
Save for the next evaluation
  • Versioned component and pattern quality matrix
  • CI results for states, viewports, interaction, and accessibility
  • End-to-end flow and layout-conformance results
  • Failure and exception register
Decision enabled
Whether a supported component or product flow is ready across required states, accessibility conditions, and screen sizes.
Do this first
Keep Figma and code aligned before release
Stage 4

Use real results to decide what to improve next.

Project 4

Use operating results to decide where Cloudscape needs investment

Problem
Cloudscape has documented ownership, contribution, and release practices. This study did not find public trend data for ownership health, review throughput, deprecation support, migrations, approved exceptions, or quality outcomes. AWS may track these internally.
Action
  • Define support windows and migration help for general component deprecations and breaking changes.
  • Track review time, contribution completion, migration progress, adoption, exceptions, regressions, and ownership health.
  • Require each exception to have an owner, reason, expiration date, and follow-up result.
  • Publish the target, current result, trend, accountable owner, and next action for each operating measure.
  • Record the staffing or process decision made when a target is missed.
Owner
  • Cloudscape governance and release owners
  • Cloudscape program and design-infrastructure leadership
  • Cloudscape component maintainers
Finish line

Cloudscape leadership can see whether the system is being adopted safely, where teams are stuck, and which staffing or process change will improve the result.

  • General deprecation guidance states notice, support window, migration help, and enforcement points.
  • Current operating results show baselines, targets, trends, and accountable owners.
  • Every approved exception has a reason, owner, expiration date, and recorded outcome.
  • The team can point to a staffing, release, migration, or process decision changed by the data.
Save for the next evaluation
  • Deprecation and migration support policy
  • Review, migration, adoption, exception, quality, and ownership trends
  • Exception register with expirations and outcomes
  • Quarterly decisions and follow-up results
Decision enabled
Where leadership should invest, delay a migration, or change staffing, ownership, release policy, or process.
Do this first
Test complete product experiences across the whole system
What Cloudscape would need to show for a score of 100 (20 criteria)

This table lists every place where the system lost points. Scores only change after the work is complete and the evaluation is run again.

CriterionScore nowGoalPoints availableWhat is missing
Foundations: Token taxonomy and semantics
Why the system lost points

Score 4 requires the token graph to be validated, measured, and maintained across consumers; the only automated check observed is a same-repo snapshot test comparing two internal themes (classic, visual-refresh) to a stored snapshot: there is no evidence of cross-consumer measurement, drift detection, or maintained ownership metrics for the token graph itself.

What the system needs to show: The token graph is validated, measured, and maintained across consumers

34+1.25Proof needed
Foundations: Primitive completeness
Why the system lost points

Anchor 4 requires measured and governed primitive coverage/adoption (for example, lint rules enforcing token-only styling, or a published adoption metric). No such measurement or governance artifact is present in the evidence packet.

What the system needs to show: Primitive coverage and adoption are measured and governed

34+1.25Proof needed
Foundations: Modes and adaptation
Why the system lost points

Anchor 4 requires mode compatibility to be continuously validated across supported consumers. The only automated artifact observed is a two-theme snapshot test for token JSON output (design-tokens.test.ts); there is no evidence of automated cross-mode (for example, dark+compact+RTL) regression testing or validation across multiple downstream consumer packages.

What the system needs to show: Mode compatibility is continuously validated across supported consumers

34+1.25Proof needed
Foundations: Consumable delivery and versioning
Why the system lost points

Score 4 requires delivery contracts to be validated and migration impact measured; no changelog/semver-diff tooling, consumer-impact measurement, or breaking-change gate was evidenced: only shape-level snapshot validation of generated token JSON.

What the system needs to show: Delivery contracts are validated and migration impact is measured

34+1.25Proof needed
Bindings: Naming parity
Why the system lost points

No evidence of an automated naming-parity check (for example, a lint rule, Code Connect script, or CI job) that measures or reports naming drift between the Figma library and the npm package: required for the automated-validation anchor.

What the system needs to show: Parity is automatically checked and drift is measured

34+1.25Proof needed
Bindings: Design-to-code contract correspondence
Why the system lost points

Reaching anchor 3 requires that every surface-specific control in the sample be explicitly classified; the Button Dropdown/Dropdown+Main Type options and the Modal x-large/xx-large size values are unexplained gaps with no documented disposition in the evidence packet, so they remain genuine_gap rather than justified exclusions.

What the system needs to show: Machine-readable mappings continuously validate shared contracts and explicitly classify surface-specific controls

24+2.5Proof needed
Bindings: Token parity
Why the system lost points

Reaching anchor 3 would require the Figma spacing collection to model a comfortable/compact density mode matching the code's createDensityMode dimension, and a reconciliation of the raw Figma variable count (703 total / 615 color) against the number of tokens documented on the public design-tokens page (407 colors), since this gap is currently unexplained in the evidence.

What the system needs to show: Cross-surface token parity is automatically validated

24+2.5Proof needed
Bindings: Traceability and deprecation
Why the system lost points

A publisher-maintained, versioned Figma-to-code mapping, such as Code Connect or an equivalent manifest, covering current and deprecated design-side assets is needed to establish cross-surface traceability.

What the system needs to show: Traceability and deprecation drift are automatically enforced

24+2.5Proof needed
Components: Core component coverage
Why the system lost points

No public evidence of measured adoption, gap tracking, or component health metrics (required for score 4); cloudscape-governance known_limitations explicitly states adoption dashboards and internal test results are outside this public evaluation.

What the system needs to show: Gaps, adoption, and component health are measured

34+1.25Proof needed
Components: Normal, recovery, and permission states
Why the system lost points

No execution/measurement evidence (CI pass/fail results, coverage dashboards) ties these state contracts to continuous testing; permission-specific state behavior and state-transition tests for input, toggle, side-navigation, cards, and spinner are not directly shown in this packet, so a score of 4 is unsupported.

What the system needs to show: State contracts are executable, tested, and measured

34+1.25Proof needed
Components: Responsive behavior
Why the system lost points

Current automated execution results covering the supported viewport, container, theme, density, and content matrix, along with tracked responsive regressions, are needed to establish continuous validation.

What the system needs to show: Responsive behavior is continuously tested across the matrix

34+1.25Proof needed
Components: Accessibility behavior
Why the system lost points

Dedicated automated accessibility-regression test files (a11y-refresh-dark.test.ts, a11y-refresh-light.test.ts, table/__tests__/a11y.test.tsx) exist per the file listing, but their content, pass/fail results, or CI gating were not included in this evidence packet, so continuous AT-coverage measurement cannot be confirmed for a score of 4.

What the system needs to show: Assistive-technology coverage and regressions are continuously measured

34+1.25Proof needed
Structure: Layout primitives
Why the system lost points

No observed automated validation or measurement of layout use/exceptions (e.g. breakpoint or visual-regression execution results) was present in the supplied evidence text, only test file paths without visible content, so 'validated and measured' cannot be scored.

What the system needs to show: Layout use and exceptions are validated and measured

34+1.25Proof needed
Structure: Composition guidance
Why the system lost points

No automated or executable enforcement of composition rules (e.g. a lint/test failing if a full-page cards instance is not first in the content slot) was present in the evidence, so 'executable or automatically validated' cannot be scored.

What the system needs to show: Composition rules are executable or automatically validated

34+1.25Proof needed
Structure: Patterns and templates
Why the system lost points

No evidence of pattern usage, outcome, or lifecycle measurement (e.g. adoption analytics, deprecation tracking) was present in the supplied evidence, so 'pattern use, outcomes, and lifecycle are measured' cannot be scored.

What the system needs to show: Pattern use, outcomes, and lifecycle are measured

34+1.25Proof needed
Structure: Navigation, focus, and state ownership
Why the system lost points

Current continuous-execution results for the AppLayout focus contracts, plus equivalent implementation or test coverage for loading-recovery and empty-state-recovery transitions, are needed to establish executable and continuously verified cross-composition ownership.

What the system needs to show: Cross-composition contracts are executable and continuously verified

34+1.25Proof needed
Governance: Named ownership
Why the system lost points

No public ownership health or service-expectation metrics (for example, response-time SLAs, staffing/coverage data) are evidenced, which anchor 4 requires.

What the system needs to show: Ownership health and service expectations are measured

34+1.25Proof needed
Governance: Contribution and review
Why the system lost points

No evidence of measured review quality, throughput, or outcomes (for example, review latency, defect escape rate, rejection rate) is present, which anchor 4 requires.

What the system needs to show: Review quality, throughput, and outcomes are measured

34+1.25Proof needed
Governance: Releases, migration, and deprecation
Why the system lost points

Anchor 3 requires deprecation and migration to have explicit operational contracts (for example, stated notice periods, support overlap windows, or systematic migration tooling/codemods). The packet only evidences a tagging convention plus one named migration guide (charts), not a general, enforced deprecation/migration policy, so this anchor is not fully met.

What the system needs to show: Compatibility and migration success are validated and measured

24+2.5Proof needed
Governance: Quality enforcement and feedback
Why the system lost points

Additional evidence must satisfy the next anchor: Quality gates cover the supported lifecycle and exceptions

What the system needs to show: Quality, adoption, exceptions, and regressions are measured and acted on

24+2.5Proof needed

Study footnotes

Use these notes and files to check how the study was run, how the results were scored, and which evidence was included.

How the study worked

Results and data

Agent-test files

Bundle records

Study notes

Cloudscape study details
Publication status
Approved
Human review coverage
100%
Assessor agreement
75%
Warnings resolved
2
Warnings unresolved
0
Evidence completeness
100%
Evidence cutoff
2026-08-22
Assessor profile
claude-code/claude-sonnet-5/claude-json/contract-2
Passes
3
Disposition
pilot
Deep sample
11 components
Compositions
1 flow(s), 2 pattern(s)
Governance
public

How to read this score: Scores are normalized rubric results, not school grades, popularity rankings, or industry percentiles. A criterion score of 3 maps to 75 and means the configured anchor is comprehensive, operational, or tested as defined by that criterion.

Evidence boundary: “Not observed” means the study did not find that result in the captured public evidence. It does not prove that the company lacks the capability internally. The team can share current internal results for a re-run.

Composition evidence: create-configure-save: system-authored, empty-state-recovery: system-authored, loading-recovery: system-authored.

Component sample choices: app-layout: analyst-declared, button: analyst-declared, cards: analyst-declared, flashbar: analyst-declared, form-field: analyst-declared, input: analyst-declared, modal: analyst-declared, side-navigation: analyst-declared, spinner: analyst-declared, table: analyst-declared, toggle: analyst-declared. These choices set what the study covers. Any mappings written by the publisher are labeled separately.

Scope and limitations (9)
  • This scorecard describes capability supported by the configured evidence snapshot.
  • Missing public evidence is reported as unknown and is not evidence that an internal capability is absent.
  • Repeated outputs from one assessor model measure agreement, not statistical independence.
  • The overall score is not a school grade, popularity ranking, or industry percentile.
  • Deep component findings are scoped to 11 declared component samples across 10 archetypes unless system-wide evidence is cited.
  • Structure findings use 1 declared flow sample(s) and 2 declared pattern sample(s).
  • Governance findings describe public evidence only.
  • Cloudscape states that additional testing occurs internally before npm publication; internal test results, AWS ownership records, adoption dashboards, and governance outcome metrics are outside this public evaluation.
  • The public repository does not expose the complete internal decision process behind Cloudscape design changes.