Conformance suite
How FounderHQ proves every SDK behaves the same way.
Five SDKs capture the same events. If one of them counted sessions differently, your numbers would change when you added a platform. The conformance suite exists to stop that.
What it is
One file, packages/events-core/fixtures/conformance-v2.json, holds 29
golden fixtures. Each fixture lists a sequence of actions and the exact
bytes an SDK must produce. The web, React Native, Swift, Kotlin, and Node
runners replay those actions and compare their output to the fixture,
byte for byte.
Clock, UUID, storage, transport, and device facts are all injected, so the comparison is deterministic. A run either matches or fails.
The fixtures cover the behaviour that breaks quietly when SDKs drift:
- Session rollover on idle time and on maximum age
- Identify, reset, and set-once ordering
- Retry after a partial acknowledgement
- Identity rotation directives
- Oversize payloads
- Persistence across a restart, and offline recovery
- Remote-config re-arm on web and on mobile
- Opt-out and opt-in, and the cookieless consent transition
- Single-page-app and hard-unload page views
- Mobile screens, pixel dimensions, and app lifecycle
- Checkout metadata and account lifecycle
- Mobile purchase claims from the App Store, Google Play, and RevenueCat
What it buys you
Your dashboard reads one number for "sessions" whether the visit came from a browser or an iPhone. You can add Android in month six and trust that it did not move month five's chart. When you report a bug, the fix lands as a fixture, so it cannot come back.
Capability matrix
Some behaviour does not exist on some platforms. A browser has no app lifecycle. A phone has no window. Rather than skip those fixtures quietly, the suite declares which capability each platform has, and records a written reason for every gap.
| Capability | Web | Node | React Native | iOS | Android |
|---|---|---|---|---|---|
| capture | yes | yes | yes | yes | yes |
| identify | yes | — | yes | yes | yes |
| person properties | yes | — | yes | yes | yes |
| super properties | yes | — | yes | yes | yes |
| screen | yes | — | yes | yes | yes |
| screen ids | — | — | yes | yes | yes |
| sessions | yes | — | yes | yes | yes |
| persistence | yes | — | yes | yes | yes |
| offline queue | yes | — | yes | yes | yes |
| partial ack | yes | — | yes | yes | yes |
| identity rotation | yes | — | yes | yes | yes |
| remote config | yes | — | yes | yes | yes |
| consent | yes | — | yes | yes | yes |
| page views | yes | — | — | — | — |
| pageleave resilience | yes | — | — | — | — |
| window ids | yes | — | — | — | — |
| DOM autocapture | yes | — | — | — | — |
| scroll | yes | — | — | — | — |
| cookieless consent | yes | — | — | — | — |
| checkout metadata | yes | yes | — | — | — |
| accounts | yes | yes | yes | yes | yes |
| mobile session restore | — | — | yes | yes | yes |
| pixel dimensions | — | — | yes | yes | yes |
| app lifecycle | — | — | yes | yes | yes |
| mobile purchase claims | — | yes | yes | yes | yes |
| secret key | — | yes | — | — | — |
A dash means the platform declares the capability out of scope, with a reason in the fixture file. For example, iOS records named screens instead of browser page views, and never inspects native view trees.
Building your own client?
Run your client against the same fixture file. If it matches, your numbers line up with every official SDK. Start from Wire protocol.