01 / 15
P Parity

Cross-platform experience assurance

One journey.
Every surface.

Verify that selected platforms deliver the same intended customer experience—with synchronized evidence developers can act on.

Working slice: Ask Sia after onboardingValidated: Android · mWeb · WebScreenshot proofHuman approval
02 / 15

Before Parity

The journey is shared.
The tests are not.

A
Android testEspresso / Appium implementation
maintain
i
iOS testXCTest / Appium implementation
rewrite
m
mWeb testResponsive Playwright journey
duplicate
W
Web testDesktop Playwright journey
drift

Four capable test stacks can all pass independently—and still deliver four subtly different experiences.

THE GAP

No shared product-state contract

Execution tools know how to operate a platform. They do not automatically prove that every platform reached an equivalent business state with equivalent controls, content, and accessibility.

03 / 15

A precise comparison

Useful tools.
Different responsibility.

Appium, Espresso, XCTest, Playwright

Excellent execution engines, but the same journey is often rewritten and maintained for each platform.

Screenshot-diff tools

Detect visual change, but may not know whether platforms reached equivalent product states or intentionally different layouts.

Manual QA

Essential for exploratory judgment, but expensive and difficult to repeat consistently across every build and surface.

AI test generators

Accelerate authoring, but commonly produce tests for one platform or repository without a durable cross-platform experience contract.

Parity

Models one product journey, delegates execution to platform adapters, and verifies equivalent implementation with synchronized evidence.

Parity complements existing automation and human QA; it adds the cross-platform assurance layer between product intent and platform execution.

04 / 15

Working prototype: one registered contract

Describe what the customer should experience.

Today’s vertical slice stores one reviewed Intent journey as logical intent—not duplicated selectors or coordinates.

INTENT

Open application

A platform adapter decides how.

CHECKPOINT

Application ready

Workers synchronize on business state.

ASSERTION

Ask Sia is visible

Controls and accessibility are required.

VARIANCE

Reasoned exceptions

Platform differences are explicit, governed, and expirable.

intent.verify-floating-actionValid contract
1
Launch the applicationintent: open_application
98%
2
Wait for application readycheckpoint: app_ready
96%
3
Verify Ask Sia is visiblecompare: outcome · controls · accessibility
94%
05 / 15

Prerequisite: make the application testable

Artifact-first does not mean zero-integration.

Parity reduces duplicated journey work. It does not remove testability requirements.

Source access is optional. Runtime replay is mandatory before a discovered mapping is trusted.

1
Runnable surfacesAPK or installed Android app, simulator .app or signed iOS build, and reachable mWeb/Web URLs.
2
Stable semanticsResource IDs, accessibility identifiers, test IDs, roles, names, and labels—not coordinates.
3
Reproducible stateControlled fixtures, environment, feature flags, locale, and safe credential profiles.
4
Compatible workersAndroid device/emulator, Playwright browser, and macOS/Xcode infrastructure for iOS.

First-run onboarding: configure launch details → discover targets incrementally → review ambiguity → replay → save verified mappings with build provenance.

06 / 15

The assurance pipeline

From human intent to evidence-backed finding.

1AuthorText, voice, import
2ValidateSchema, assumptions, safety
3ExecuteOnly selected workers
4NormalizeDOM + native UI → canonical model
5CompareEquivalent checkpoint state
6DecideFix, accept, rerun
ONE PLATFORM

Functional test

Assertions run and evidence is saved for later.

TWO OR MORE

Consistency test

Compatible states unlock cross-platform findings.

ADD LATER

Historical comparison

Reuse compatible prior evidence with visible provenance.

Prototype boundary: the localhost demo executes a named-control presence check with screenshots. Rich canonical-tree alignment and historical comparison are implemented as core packages but are not the live customer-issue demo shown today.

07 / 15

Same checkpoint, four surfaces

Parity verifies meaning before pixels.

Androidready
Ask
UiAutomator semantics · screenshot
iOSplanned
Ask
Architecture defined · not locally validated
mWebready
Ask
390×844 DOM/a11y · screenshot
Webready
Ask
1440×900 DOM/a11y · screenshot

Live demo: Android, mWeb, and Web. Target architecture: native trees and browser accessibility trees become a canonical model; iOS requires a compatible macOS/Xcode worker and remains unvalidated in this local demo.

08 / 15

Extensible contract roadmap

Test the experience—not just the element.

OUTCOME + CONTENT

Coupon and checkout

Was the coupon applied? Do discount, total, currency, and success copy agree?

JOURNEY + STRUCTURE

Login and onboarding

Did every platform reach the intended destination with the same required choices and next actions?

STATE + CONTROL

Form validation

Are required errors equivalent? Is Submit enabled only when the form becomes valid?

NAVIGATION + ACTIONS

Search and navigation

Do equivalent queries, filters, tabs, and back actions lead to the same product state?

CONTENT + RECOVERY

Loading, empty, and error states

Are status messages, retry actions, and fallback paths present and meaningfully equivalent?

ACCESSIBILITY

Inclusive interaction

Compare roles, labels, focusability, order, target size, and success or error announcements.

Implemented live flow: one registered customer issue—after onboarding, verify whether Ask Sia is present. The examples above are planned contract types enabled incrementally; they are not all available in the current localhost UI.

09 / 15

Platform-native does not mean inconsistent

Same outcome.
Approved native expression.

INTENT · share_item

Customer can share the selected item

The contract requires the outcome and an accessible action—not one identical component everywhere.

AndroidNative system share sheet
iOSActivity view controller
WebWeb Share API or approved Copy link fallback
Conformant variant
Different UI, approved equivalent outcome.
Accepted variance
Restriction has reason, owner, alternative, and expiry.
Finding
No outcome, no approved alternative, or inaccessible fallback.

No majority vote: Android, iOS, or Web is never automatically “truth.” The experience contract and recorded product decision define what is acceptable.

10 / 15

Target comparison model

Compare like with like—or say “incomparable.”

Checkpoint
Android
iOS
mWeb
Web
app_ready
✓ ready
✓ ready
✓ ready
✓ ready
control_verified
✓ Ask Sia
✓ Ask Sia
✓ Ask Sia
✕ missing
COMPARABLE

Equivalent fixture, environment, build policy, and business state

A missing Web control becomes a confirmed implementation difference.

INCOMPARABLE

Login failed, stale fixture, wrong experiment, or incompatible build

Parity reports an evidence problem—not a product inconsistency.

11 / 15

Target report shape

Every finding carries its proof.

Illustrative finding UI-CONTROL-001

Ask Sia is missing on Web

HIGH

Android, iOS, and mWeb expose the required floating action at control_verified. Web reached the same product state but has no equivalent accessible control.

4 screenshots4 semantic trees12 action eventsstate compatible
Suggested fix: restore the Web floating action or document an accessible platform alternative with a reason and expiry.

Difference table

Outcome

All platforms reached application ready.

Control

Missing on Web; present elsewhere.

Accessibility

No equivalent Web role or label found.

Layout

Advisory only; native and responsive layouts may differ.

Confidence

High—semantic and screenshot evidence agree.

12 / 15

Working today + Sunday integration

English speech works today.
Local-language translation lands Sunday.

1Speak — workingChrome speech recognition creates an editable English transcript.
2Translate — SundaySarvam Saaras v3 will detect supported language and translate speech to English.
3Review — requiredConfirm the transcript or translation and correct product terms such as “Ask Sia.”
4Generate — working sliceThe registered customer-issue journey produces deterministic, cited steps.
5Approve & runSpeech never executes directly. Human approval remains mandatory.

Hackathon-day target: Hindi demo: “एप्लिकेशन खोलें। जाँच करें कि आस्क सिया दिखाई दे रहा है।” → detected language → reviewed English. Sarvam credentials stay server-side; provider failure returns safely to the working English/typed path.

13 / 15

Not just a report

A governed feedback loop.

DetectEvidence-backed difference
ExplainMeasured vs inferred
DecideFix, accept, defer
ApplyTarget workflow · not automatic today
ReplayBefore/after proof

Today Parity reports; it does not silently rewrite product code.

The current prototype produces evidence and suggested remediation. Repository-aware proposals, human-bound approval, replay, and governed accepted differences are the target feedback loop.

14 / 15

Sunday demo script · one supported journey

Show the complete trust boundary.

Speak in Hindi when Sarvam is connected

एप्लिकेशन खोलें।
जाँच करें कि आस्क सिया दिखाई दे रहा है।

Expected English: Open the application. Verify that Ask Sia is visible.

ಕನ್ನಡ · kn-INதமிழ் · ta-INతెలుగు · te-INമലയാളം · ml-IN
1
Record and stopShow permission, timer, provider disclosure, and temporary audio.
2
Review detection + translationShow language and probability; correct a product term to demonstrate human control.
3
Generate stepsShow source phrase, action, intent, target, and confidence.
4
Approve and runExecute the registered Ask Sia presence flow on Android, mWeb, and Web.
5
Show proofScreenshots, exact actions, difference table, and suggested alternative.
6
Use the fallback if neededRun the working English speech path or play the hosted screen-only not-reproduced/reproduced demos.

Disclosure: the current prototype supports this one registered customer-issue journey. The hosted WebM recordings show a voice-driven UI flow but intentionally contain no microphone audio.

15 / 15

Parity

Stop asking whether every test passed.
Ask whether every customer received the intended experience.

One journey · selected platforms · synchronized proof · conscious decisions

← → navigate · O overview · F fullscreen · Home restart