# 07 — Adoption and compliance

What it actually costs to align a product UI with the HPE Design System, and
how to check whether one is aligned.

## Three adoption paths

### 1. React plus Grommet plus `grommet-theme-hpe`

The path the design system is built for. Install the theme and you inherit
colors, fonts, component defaults, keyboard navigation, ARIA support, focus
handling, and responsive behavior.

Cost: highest if the product is not already React. Lowest ongoing cost after
that, because brand refreshes arrive as a version bump.

This is the only path where the accessibility table in `05-accessibility.md`
reads "handled" down most of the column.

### 2. `hpe-design-tokens` only

For any other stack. Tokens are tech-agnostic and published to npm. You get the
correct colors, type, and spacing. You do not get component behavior.

Cost: moderate to adopt, permanent to maintain. Every accessible behavior
(keyboard, ARIA, focus, semantic structure, responsiveness) is yours to build
and re-verify.

The docs recommend mapping to **v0.9.0 tokens first** to reach parity with the
product's current look, verify against familiar styling, then upgrade forward.
That turns one risky change into two with a checkpoint between them.

### 3. Reference only

Read the guidance, match by eye, use the templates as design references. Fine
for a prototype or an internal tool. Not defensible for a customer-facing HPE
product, because the values drift the moment the brand moves and nothing
signals that they have.

## Review checklist

Usable as a gate in a design or code review. Every item traces to a rule in the
docs, cited to its doc here.

**Brand marks** (`02`)
- [ ] HPE Element is present at top-left of the product experience
- [ ] Element is accompanied by the company name and the product or service name
- [ ] Lockup spacing and layout are unmodified
- [ ] No HPE GreenLake badge on new material (the existing badge is retired)
- [ ] Correct positive or reversed logo variant for the background

**Color** (`02`)
- [ ] No raw hex values in the UI. Semantic or component tokens only
- [ ] Primitive tokens are not referenced directly
- [ ] Status colors used only where they carry meaning, never decoratively
- [ ] Strong backgrounds pair with `onStrong` text and icon tokens
- [ ] Nothing is conveyed by color alone. Every case has a label, icon, pattern,
      or underline as well
- [ ] Data visualization series start at the first token and proceed in order

**Typography** (`02`)
- [ ] HPE Graphik loaded from the HPE CDN, not bundled or substituted
- [ ] Heading levels chosen for semantics; size set by token, never by demoting
      a heading level
- [ ] Heading hierarchy has no skipped levels
- [ ] Paragraphs carry the `maxWidth` for their t-shirt size
- [ ] Sizes in `rem` so browser font settings scale the UI

**Layout** (`02`)
- [ ] Spacing comes from the scale, not arbitrary pixel values
- [ ] Spacing tokens used for layout; component or element tokens for elements
- [ ] Gap and padding, not margin
- [ ] Borders only where spacing and background contrast are insufficient

**Copy** (`04`)
- [ ] Sentence case throughout, including labels, columns, tabs, menus, dialogs
- [ ] Buttons ending in a short preposition capitalize it ("Sign Up")
- [ ] No all caps anywhere
- [ ] No string begins with a lowercase letter
- [ ] Acronyms defined on first use, and only used if repeated
- [ ] Long product names shortened after first reference
- [ ] Error messages do not blame the user, do not say "try", do not say
      "retry after some time"
- [ ] No references to "your administrator"
- [ ] Term list observed: application not app, ID, OK, I/O, "log in" vs "login"

**Accessibility** (`05`)
- [ ] Keyboard navigation reaches and operates every control
- [ ] Focus is visible on every focusable element
- [ ] All images and media have descriptive alt text
- [ ] All form fields, buttons, and errors have meaningful labels
- [ ] Decorative icons carry `aria-hidden`; meaningful icons carry a label
- [ ] Automated scan clean (axe or Lighthouse)
- [ ] **Manual test performed.** Automated tools catch 30 to 50% of violations,
      so a clean scan is a floor and not a pass

**Version hygiene** (`03`)
- [ ] Token major version recorded, and known to match sibling products. Two
      HPE products on different majors will not look like the same company
- [ ] No references into the `deprecated.*` token namespace

## What compliance is worth arguing about

Not every item above carries the same weight. Ranked by consequence:

1. **Accessibility failures.** These can be procurement blockers, and in some
   jurisdictions legal exposure. Everything else on the list is cosmetic by
   comparison.
2. **Element and logo misuse.** Governed by the HPE Terms of Use, and the one
   category where a brand team is likely to intervene directly.
3. **Hardcoded hex values.** Not visible to a customer today, but this is what
   makes the next brand refresh expensive rather than free. The cost lands
   later, which is why it gets waved through.
4. **Copy rules.** Cheap to fix, visible to customers, and the thing that most
   often makes an acquired product feel un-HPE.
5. **Spacing and type scale drift.** Real but low-stakes individually. It
   accumulates into a UI that looks off without anyone being able to say why.

## Where an acquired product typically stands

Worth setting expectations before scoping any alignment work. A product that
joined HPE through acquisition usually has: its own component library, its own
color constants in code, its own typeface, its own copy conventions, and no
token layer at all. The realistic sequence is tokens first (path 2), copy
second (cheap, high visibility), component migration last if ever.

The full React migration is rarely justified on brand grounds alone. It is
justified when the accessibility column in `05-accessibility.md` becomes a
requirement, because that is where the "handled" entries are worth real
engineering months.

## Open questions

- Is there an HPE-internal alignment audit or scorecard that products are
  measured against? Nothing public suggests one. The design system repo does
  carry an `alignment-audit` entry in its `knowledge/` directory, but it is a
  planned stub scoped to auditing the design system's own docs, tokens, and
  components, not product teams. Do not cite it as evidence of a product gate.
- What is the expected timeline for products to reach v2-Landmark, and is there
  a deadline attached?
- For an embedded or OEM UI, whose brand governs, and does the Element rule
  still apply?
- Does any HPE release process actually check the items above, or is this a
  self-assessment?