Product

What parity means

Parity is the word this product rests on, so it should not be left to the reader. Below is every difference the Pack measures, every one that needs a person, and every one it does not check at all. The third list is the longest, and publishing it is cheaper for you than finding it out on your own app.

Checked by the Pack

Visual appearance: Matched screenshot pairs from both builds, captured in the same run on the same device, compared pixel by pixel after masks. A second comparator reports structure, position and content separately, so a shifted row reads differently from a wrong colour.
Element structure and order: The comparator matches the content bands of the two screenshots before comparing them, so it reports an element that is missing, extra or out of order rather than only a pixel count.
Analytics events: One JSON object per event from each build while the same flow runs, matched on name and props. Order-independent by default. With --ordered it aligns the logs by longest common subsequence first, so one missing event near the start cannot manufacture differences in every event after it.
Loading and error states: Only where you write a capture flow for them. They are screens like any other: the Bluesky showcase captures an empty state and an error state because its flows ask for them. Nothing discovers a state you did not script.

Needs a person

Drift between 1% and 2%: The tools report it; they cannot accept it. Every drift needs written sign-off from someone who did not write the port, and the porting agent may never sign off its own work. Above 2% is a fail and no sign-off is permitted.
Platform-conventions ports: When a checkpoint chooses each platform's own conventions over your existing design, the pixel diff is informational only. A person reviews the screenshots against the approved design. Events and test ids must still match exactly.
Native code quality: A reviewer agent reads the native architecture and a second checks parity, both instructed to look for problems rather than approval. Their findings are input to a human decision, not a guarantee. State ownership, recomposition and threading are engineering review, not a measured number.

Not checked

Navigation and back behaviour: Not checked automatically. This is not a theoretical gap: the open defect in the Bluesky showcase is a swipe-back gesture that does not pop the thread on iOS, and it was found by running a check the report had written down as outstanding, not by the pipeline.
Authentication and session persistence: The playbook covers carrying stored data across so users stay signed in, and the assessment inventories the modules involved. Neither is a check that runs and passes. Test sign-in, token refresh, logout and session restore yourself.
Deep links and push tokens: Covered as cutover planning, not as a parity check. Nothing in the pipeline opens a link or registers a token and compares the result.
Offline and background behaviour: Not checked. A capture flow drives a foreground app against a seeded server.
Accessibility: Not checked. Screenshots cannot see focus order, labels or dynamic type, and no script in the Pack inspects the accessibility tree.
Performance: Not checked. No frame timing, startup or memory measurement is part of the parity gate.

The bands a screen falls into

One number decides a screen: the share of pixels that differ after masks. Drift is not a pass.

Pass: at or below 1%; Accepted by the tools. No human step.
Drift: above 1%, at or below 2%; Not a pass. Needs written sign-off from someone who did not write the port.
Fail: above 2%; The checkpoint stops. No sign-off is permitted and no threshold may be raised to clear it.

Rules the gate cannot be argued down with

Never compare screenshots from different devices, scales, orientations or appearance modes.
Never raise the threshold or add a mask to turn a fail into a pass.
Never mask the element the checkpoint ports.
Never sign off a fail.
Never let the porting agent sign off its own drift.
Never write a capture flow that changes server data.

What this method cannot tell you

Parity is measured on the states you script. A flow that does not visit a screen says nothing about it, and the number of screens measured is never the number of screens in the app.
A screen is not a screen state. One screen with a loaded, empty and error state is three measurements, and the Bluesky showcase counts them that way: 35 measurements across 20 iOS and 15 Android states.
Passing the gate means the tested states match within the threshold. It does not mean the app is ready to release. Those are different milestones.
Masks hide known-volatile regions such as a system status bar. Every mask needs a recorded reason, and a mask over the element being ported is forbidden, but a mask is still a region nobody is comparing.
Agent output is not deterministic. The same checkpoint run twice can produce different native code. What reproduces is the measurement: a full re-run on a later day returned the same differing-pixel count for all fifteen Android screens.

Every number on this site was produced by the checks above. The Bluesky migration is the one measured in full, including the drift that needed a written acceptance and the one defect still open. The method covers where this gate sits in a checkpoint.