Evaluate release evidence by asking one question of any build in users’ hands: can we show what protection it carries, who approved that, and how it was tested? Otukan answers it with an evidence record for every protected release, for Android and iOS apps built natively or with Flutter or React Native. Each owner adds an entry at their handoff, entries are added rather than rewritten, and the record stays in your environment. This page covers who may write evidence, what each handoff contributes and how the record handles failures and rollbacks. Judging a release against a regulation remains your auditors’ task.
Authority
Who writes which entry
Evidence is only as strong as the rules about who can add it. Otukan’s record separates the writers, so the identity that produces a build is not the one that approves or releases it.
| Writer | Entry it adds | Rights it needs |
|---|---|---|
| Protection step identity | Input and output digests, Otukan version, profile version, step log | Add entries for the run it performed |
| Profile approvers | Approval of a named profile version | Add approvals; no access to build outputs |
| Release owner | Signing certificate fingerprint, rollout decision | Add signing and release entries |
| QA team | Protected-build test results | Add test entries |
| Auditors and reviewers | None | Read the record |
Artefact inputs and secret handling
The record describes artefacts without containing sensitive material. It stores digests rather than binaries, and the fingerprint of the signing certificate rather than any key. On Android with Play App Signing, the record can hold both your upload certificate fingerprint and the app signing certificate fingerprint that Google uses for the copies users install, so reviewers see which certificate actually reached devices. On iOS, it holds the fingerprint of the distribution certificate your team signed the upload with; App Store processing then re-signs the copies users download.
Retention
Keep each record for at least as long as the build it describes can still be installed on users’ devices, then for whatever period your own policy sets. Older app versions stay in use long after a new one ships, and a question about one of them is only answerable if its record survives.
Sequence
Each handoff leaves evidence before the next stage starts. A record with a missing entry is visible as incomplete.
| Handoff | What the next owner receives | Evidence left behind |
|---|---|---|
| Approval to protection | An approved profile version | Approver, time and profile version |
| Protection to signing | A protected artefact | Input and output digests, Otukan version, log |
| Signing to testing | A signed, protected build | Certificate fingerprint, digest of the protected input, build number |
| Testing to release | Pass or fail per flow | Results for install, update, sign-in and sensitive flows |
| Release to production | A rollout decision | Stage, date and link to the previous release |
Signing changes the artefact, so its digest changes too. The signing entry therefore names the protected artefact digest it started from, and a reviewer can trace the signed build back to the protection run rather than to an unprotected copy of the same version.
The order of these stages and their entry conditions are set out on protection lifecycle.
Operations
Failures and retries
A failed protection run is evidence too. Otukan keeps it in the record with its log and the inputs it was given. A retry is added as a new entry linked to the failed one, so a reviewer sees that the build went through two attempts and why, rather than a clean history that hides the problem.
Versioning
Two identifiers anchor every record: the profile version your owners approved and the Otukan version your pipeline pinned. When either changes, the next record shows the change and the approval that allowed it, which answers the reviewer’s usual question of what differs between this release and the last one.
Rollback
A store cannot restore an earlier binary, so recovery means halting the rollout and shipping a higher version number. The halted release keeps its record, marked with the decision. The replacement build gets a new record linked to the faulty release and to the last known good one. Anyone reading the history later sees the whole sequence in order, with each decision attributed.
What a reviewer can answer from the record
- Which protection profile did the build installed on a given date carry?
- Who approved that profile, and when?
- Was the signed build the one that left the protection step?
- Which flows were tested on the protected build before it shipped?
- Which release came before it, and why was it replaced?
For how evidence fits the product as a whole, return to mobile app security. Setting release criteria from expected signals is covered on security validation.