Evidence Ledger

Read the evidence ledger

An evidence ledger connects a claim to the artifact that supports it. EdgeORE needs this because source reviews, automated tests, hosted screenshots and blockchain results describe different things. A passing parser test does not prove a wallet accepted an authorization request. An app-signed receipt does not prove an RPC accepted a transaction. A transaction signature alone does not prove the chain confirmed a successful transfer. The ledger prevents those shortcuts.

Record facts at the right level

For a source gate, preserve the commit, command, exit status, test XML and build logs. For an APK, preserve the filename, package, versionName, versionCode, source stamp, full SHA-256 and signing-certificate fingerprint. For a runtime session, preserve the environment, Android version, time, screenshots, operator attribution and action sequence. For a chain observation, preserve the cluster, signature, RPC request, RPC response and observation time. A useful ledger row points to those records rather than repeating a confident sentence.

The tested source commit and the repository's later evidence-only merge can differ. That does not invalidate the build if the distinction is explicit. The APK About stamp identifies the source used for that binary; a docs-only merge identifies where the results were stored. Do not overwrite the original build stamp with a newer branch hash. Do not assume that an APK rebuilt with a different debug key will have the same file hash, even if the source is unchanged.

Interpret the historical gates

The recorded Android qualification result is 164 tests, 163 passed, zero failed and one skipped. The checker result is seven passed in a separate Gradle project. Keep those totals separate in the README, deck and website. A skipped integration test needs its own explanation and, where available, a separate live-agent result. Adding the suites together obscures their environments and makes comparisons with future runs harder.

The published byte-mutation experiment is not part of the preserved evidence described in the session. Its numbers should therefore not appear as a measured result in this website. A narrower preserved demonstration does exist: an original fixture verifies, and changing a signed body's lamports causes a digest mismatch. That establishes a fixture-level integrity check. The real-transfer receipt gate still needs an export associated with an actually confirmed devnet operation.

Create a useful ledger entry

Use one entry per run, with a stable identifier and links to its files. Include what was not run beside what passed. A launch session might say: hosted Android emulator, Pixel 7 profile, Android 13, launch and navigation recorded; physical-device behavior not measured; wallet completion not qualified. This is more useful than a generic green badge because another person can understand the boundary without reading the whole conversation.

Do not treat a Git author name as the runtime operator. If browser automation captured the session, name that operator in SESSION.md. The repository owner can commit the files without becoming the person who ran the device. Likewise, a timestamp in a screenshot is supporting context, not a cryptographic proof of who captured it. Provenance comes from the collection as a whole, with limitations stated plainly.

Review an entry before promoting it

Check the full hash, not an abbreviated prefix. Open the screenshots and ensure they show the claimed environment. Read the test XML rather than trusting a summary alone. Verify that a receipt's signature and digest are not merely printed as decorative strings. Confirm that a devnet explorer URL contains the operation's actual signature. If a required artifact is absent, leave the row incomplete and explain the missing observation.

A good final review asks two questions: what would make this claim false, and can a reader inspect the evidence that rules that out? For launch, a blank or crashed screen would make the claim false. For successful transfer, an RPC error or non-null transaction error would matter. For receipt integrity, a changed signed body that still verifies would matter. Designing the ledger around those questions keeps evidence practical rather than ceremonial.

---

Wiki home · Qualification updates · Sources and credits