Conformance

What it means

A renderer is Exponential UI conformant when its runner replays every suite of the manifest and the report passes: every suite present, every case run, nothing failed or skipped. Then a surface means the same thing on it as on ours. The same tree comes out of the reducer, every macro expands the same way, a theme resolves to the same colours, a control measures to the same box, and the host makes the same policy decisions.

The fixtures in fixtures/ are the contract. The TypeScript reference generated their expected values, and the Rust core replays them byte for byte. A renderer built on the Rust core gets the pure suites through its bindings, one built on the TypeScript package gets them from @exponential-at/ui, and anything else implements the reducer and host.json itself.

The suites

Generated from the fixtures into conformance/manifest.json (version 2), which drift-gates the case counts. A suite's unit says what one case is.

Total: 1,660 cases in 24 suites.

Run it on your renderer

A third-party renderer (Flutter, Qt, a terminal UI) becomes conformant in four steps:

1. Read the manifest. It lists each suite's fixture files, the unit and the case count. It ships in the npm package as @exponential-at/ui/conformance/manifest.json, next to the fixtures.
2. Replay every case the way the suite's check says: reduce, expand, resolve, measure, lay out, place, paint, decode or decide, and compare with the fixture's expected value. Geometry suites take your painter's own measurements (controls within 0.5, a CSS layout within 1 px).
3. Write the report (below), one entry per suite, naming every failed case.
4. Check it. The checker compares the report with the manifest and prints the verdict:

bun run --filter @exponential-at/ui conformance:check path/to/report.json
# CONFORMANT  my-renderer (flutter 0.3.0): 1660 cases passed in 24 suites

Outside the monorepo, checkReport() from @exponential-at/ui gives the same verdict in code. A report with a missing suite, a short case count or a skipped case is not conformant.

The report

One JSON object per run, validated by report.schema.json:

{
  "renderer": "my-renderer",
  "platform": "web",
  "version": "0.3.0",
  "conformanceVersion": 2,
  "suites": {
    "catalog": { "cases": 466, "passed": 466, "failed": [] },
    "macros":  { "cases": 200, "passed": 200, "failed": [] },
    …
  }
}

• renderer, platform, version: who ran it, where.
• conformanceVersion: the manifest's version the runner was written against.
• suites.<id>: cases run, passed, failed (the failed cases' names with a short reason) and, optionally, skipped.

Our runners write it to $EXPONENTIAL_UI_CONFORMANCE_REPORT (default .conformance/<name>.json at the repo root).

Our runners and CI

The core and all four first-party renderers run the full suite:

CI (exponential-ui.yml) runs all of them on every SDK pull request and fails unless every report is conformant. A release tag is only cut from a commit where that workflow is green.

The real-font harness

The suites lock the contract with a fixed fake measure. The real-font harness locks what real text does to it: the kitchen sink and the responsive cases, rendered by React (headless Chromium) and gpui with the same committed fonts (Inter, Geist, JetBrains Mono, Nunito, Fira Code), compared frame by frame against a committed web baseline.

bun run --filter @exponential-at/ui conformance -- --only kitchen-sink/playful/dark/390/ltr

Next: the comparison becomes suite real-font in the manifest, so conformance:check stays the one verdict.

A2UI listing

Once two platforms pass, Exponential UI gets an entry on the A2UI ecosystem's renderers page, as a pull request to google/A2UI:

Exponential UI (React, SwiftUI, Jetpack Compose, gpui): native renderers of the A2UI v0.9 basic catalog plus a core catalog, runtime themes, extension catalogs and a host API (transports, functions, bindings, policy). Apache-2.0. https://ui.exponential.at