MEASURED
Directly extracted from a named artifact or captured in a documented test.
METHOD / VERSION 0.1
Show the path from artifact to claim.
Every finding should identify the artifact, source, date, method, and boundary of what the evidence can support.
THE WORKFLOW
Five layers, kept deliberately separate
- 01
Define the question
State the decision or uncertainty the page addresses before collecting evidence.
- 02
Identify the artifact
Record package ID, version, file digest, size, acquisition path, and retrieval date.
- 03
Measure the build
Extract signer, signing schemes, APK Signature Scheme v3-family key-rotation lineage, SDK range, ABIs, permissions, components, and relevant static indicators. Record first-party key-replacement notices and distribution-channel signer changes separately from verified lineage.
- 04
Reconcile primary sources
Compare the artifact with developer documentation, source repositories, release records, and distribution metadata.
- 05
Publish limits with results
Separate direct observations, sourced facts, inferences, and unanswered questions; date every conclusion.
SOURCE ORDER
Primary evidence comes first
A study starts with the exact APK or related artifact being discussed. It then checks the developer-controlled repository and release record, official project documentation, reproducible repository metadata, and source code where relevant. Third-party summaries may identify a lead, but they do not replace the primary record.
A release page alone does not establish the identity of a downloaded file. The page must connect claims to an artifact digest, package identity, signer record, or another reproducible identifier where the question requires it.
CLAIM LABELS
Readers should see what kind of statement they are reading
SOURCE-BACKED
Stated by a primary source and linked to the exact release, document, or repository.
INFERRED
A reasoned interpretation that is kept distinct from a direct observation.
NOT TESTED
A material question the available evidence does not answer.
BEHAVIOR
Permissions, code, and network activity are different evidence
A manifest permission describes a capability requested by the build. An embedded library or endpoint is static evidence that code or configuration exists. Neither proves that a transmission happened. A behavioral claim requires a documented runtime observation, including device or emulator context, version, test conditions, and known blind spots.
CORRECTIONS
Versioning and corrections
Material findings carry an evidence date and version scope. When new evidence changes a conclusion, the page should preserve a visible correction note describing what changed and why. Silent edits are reserved for spelling or formatting changes that do not alter meaning.
Send evidence corrections to corrections@apporiginlab.com with the page, disputed field, and a primary-source URL. A public correction channel and page-level revision history are launch requirements. The site remains excluded from search until those facilities and the first research bundle have passed review.