Evidence standard

Results come after
reproduction.

We are publishing the standard before any product score. Product numbers will appear only after the relevant core passes a locked, repeated, multi-app review.

No current product score is published here. Historical engineering results are treated as inputs to verification, not as proof that the present core can handle every app.
The gate

What must be true before numbers go public.

The standard covers detection, restraint, repeatability, and the production path. Passing one app or one run is not enough.

Gate 01

Freeze what is being tested

Record the core build, configuration, app binaries, device profile, and scoring rules before results are opened. A later code or configuration change starts a new candidate.

Gate 02

Use more than one kind of app

Exercise the supported Android scope across multiple apps and UI frameworks, including workflows that require navigation, saved state, and test data.

Gate 03

Score catches and clean controls

Grade end-to-end outcomes against a locked answer key. Include clean builds and hard negatives so a high catch count cannot hide noisy findings.

Gate 04

Repeat the runs on devices

Run the same candidate repeatedly, disclose incomplete runs, and measure whether it reaches the intended workflows as well as whether it records a finding.

Gate 05

Prove the operating path

Verify review completion, bounded cost and time, evidence retention, monitoring, and rollback using the same configuration intended for production.

Gate 06

Publish the misses with the score

Release the cohort, denominator, exclusions, per-app outcomes, and known gaps beside any summary number. Inconclusive runs remain in the record.

Current status

What we are not claiming yet.

The public site should not make the verification decision before the test record does. These limits remain explicit until a result meets the standard.

  • No current-core, multi-app certification score is published on this page.
  • We do not publish catch-rate, false-alarm, speed, or reliability scores until the underlying work is independently reproduced.
  • Earlier internal campaigns inform engineering work; they are not presented here as certification of the current product.
  • Production readiness is assessed separately and includes operating and rollback checks.
Publication record

What each result must carry.

  • Candidate and configuration identifier
  • App cohort, framework mix, and build hashes
  • Pre-declared scoring rules and exclusions
  • Per-app and repeated-run outcomes
  • Clean-control and incomplete-run results
  • Review time, cost, and operating limits
  • Known misses and unresolved risks

Help make the evidence representative.

We are working with a small number of Android teams whose real release workflows can strengthen the multi-app validation set. Participation is scoped before any review.