# Phone delivery evidence board

Use this board to choose how someone will reach one essential phone task. It does not score platforms, detect installation support, install an app or prove offline behavior.

The four worked examples below are fictional planning decisions. **Every actual app-task result is Not tested.** No phone model, operating-system version, browser version, installation, store submission or completed app journey was observed for these examples.

## Keep two kinds of evidence separate

**Route assessment** compares a requirement with the chosen entry method and current documented platform availability. Write Candidate to test, Unresolved, Route mismatch or Currently unavailable. A candidate is the next experiment; it is not a passed task.

**App-task result** is Pass, Fail or Not tested. Use Pass only after the stated expected result occurs on the recorded app version and target device. A failed mandatory check blocks that tested route. An untested mandatory check keeps task readiness unresolved. Do not count optional preferences as compensation.

On October 11, 2026, [Overskill’s store FAQ](https://www.overskill.com/help/articles/app-store-publishing-faq) says branded App Store and Google Play publishing are unavailable on any plan. The current-availability cells below use that documented fact, not a failed store-submission experiment. Recheck it before making a new decision or setting a launch date.

## M1 — Visitors need a result before installation

Audience: craft-fair visitors. Essential task: scan the event sign and find stall C7. Mandatory condition: no installation before first use. Online connection: acceptable. Optional preference: a reusable home-screen icon. Target device/OS/browser: **Not recorded**. Actual app URL/version: **Not recorded**.

| Route | Requirement assessment | App-task result | Decision / next evidence |
| --- | --- | --- | --- |
| Browser link | Candidate to test: direct entry matches the no-install condition | Not tested | Test scanning the final QR destination and finding C7 on each target; record whether the map is readable and usable |
| Browser installation | Route mismatch if installation is required before the first task | Not tested | Do not make installation the entry gate; the same site may still be tested through its browser-link route |
| App-store distribution through Overskill | Currently unavailable; mandatory store installation would also contradict first-use access | Not tested | Do not make it the launch path for this requirement |

Next test owner: event organizer. Task readiness: **Unresolved**. Selected experiment: browser link. No test date or passed result has been invented.

## M2 — Returning members require a home-screen launch

Audience: returning studio members. Essential task: launch from a home-screen icon and find the current week’s timetable. Mandatory condition: home-screen launch on the named target devices. Online connection: acceptable. Optional preference: store discoverability. Target device/OS/browser: **Not recorded**. Actual app URL/version: **Not recorded**. Whether sign-in is required: **Not decided; resolve before testing**.

| Route | Requirement assessment | App-task result | Decision / next evidence |
| --- | --- | --- | --- |
| Browser link alone | Route mismatch: a link alone does not supply the required icon launch | Not tested | Useful as an initial URL, but insufficient for the chosen requirement |
| Browser installation | Candidate to test on each named target | Not tested | Use current device instructions; record the offered action, icon, launch destination/mode, close/reopen result and correct timetable |
| App-store distribution through Overskill | Currently unavailable | Not tested | Optional store discoverability does not need to block an installation pilot; it cannot be promised |

Next test owner: studio operator. Task readiness: **Unresolved**. Selected experiment: browser installation. An icon by itself passes neither the timetable task nor any required sign-in check.

## M3 — A saved offline change is mandatory

Audience: event supply coordinators. Essential task: record a supply count without connectivity and recover the intended record after closing and reconnecting. Mandatory conditions: offline write, persistence across closure, and reconciliation without lost or duplicate records. Optional preference: an icon. Target device/OS/browser and app version: **Not recorded**.

| Route | Requirement assessment | App-task result | Decision / next evidence |
| --- | --- | --- | --- |
| Browser link | Unresolved: opening a URL says nothing about this offline-write contract | Not tested | Obtain an authorized prototype and test the sequence below with sample data |
| Browser installation | Unresolved: installation supplies no proof of persistence or reconciliation | Not tested | Test the same contract in the installed launch mode if that mode remains a candidate |
| App-store distribution through Overskill | Currently unavailable; a store listing would not prove the data contract anyway | Not tested | Keep the availability blocker separate from the untested data behavior |

Do not switch M3 to Candidate merely because an icon appears or the last page opens offline.

| Required checkpoint | Expected observation to define before the test | Actual result | Evidence / owner |
| --- | --- | --- | --- |
| Create or edit while disconnected | The exact sample record and field value are visible as pending work; no false saved-to-server message | Not tested | None / prototype owner |
| Close and reopen before reconnecting | The intended pending record/value remains recoverable | Not tested | None / prototype owner |
| Reconnect | The agreed server record/value exists and the UI reports its actual state | Not tested | None / prototype owner |
| Retry or encounter a competing edit | Follow the explicit retry/conflict rule; do not lose the intended change or silently create a duplicate | Not tested | None / prototype owner |

Next owner: prototype owner. Task readiness: **Unresolved**. No delivery route is selected for launch. Define the record identity and retry/conflict rule before attempting this test. Use only sample data. The [interruption guide](https://www.overskill.com/learn/test-ai-app-interruptions) can help plan recovery; this sheet is not a synchronization implementation.

## M4 — A store listing is a contractual requirement

Audience: a partner’s customers. Essential task: find the branded app in the required store and open the customer service screen before launch. Mandatory condition: the store listing is part of acceptance, not optional convenience. Target store: **Partner must name it**; the current Overskill limit covers both App Store and Google Play. Device/browser/app version: **Not recorded**.

| Route | Requirement assessment | App-task result | Decision / next evidence |
| --- | --- | --- | --- |
| Browser link | Route mismatch: it is not the required store listing | Not tested | Does not satisfy the frozen requirement |
| Browser installation | Route mismatch: a home-screen icon is not a store listing | Not tested | Does not satisfy the frozen requirement |
| App-store distribution through Overskill | Currently unavailable, per the dated FAQ above | Not tested | Current platform no-fit; stop/defer or independently verify another approach |

Next owner: launch decision owner. Task readiness: **Blocked by documented availability and route mismatch**. Decision: **Stop/defer this Overskill launch path**. Do not substitute a plan upgrade, a waitlist, an unverified wrapper or a future approval promise.

If the partner changes the requirement to accept a browser link, create a new board version with that decision and its date. Keep this version. The new requirement removes one mismatch; it does not turn any app-task result into Pass.

## Blank board — one task, three routes

Copy this section for your project. Keep the worked examples separate.

- Board ID / version / decision date:
- Decision owner / next review date:
- Audience:
- One essential task and visible completion result:
- Mandatory delivery requirement:
- Other mandatory conditions (access, data, connection, device capability):
- Optional preferences:
- Target device model / OS version / browser version (one row per target):
- App URL / app version or published revision:
- Intended account role and sign-in starting state:
- Current product-availability source / observed date / precise scope:

| Route | Meets the frozen route requirement? Why? | Current platform availability and source | App-task result | Next evidence / owner |
| --- | --- | --- | --- | --- |
| Browser link | Unresolved | Not checked | Not tested | |
| Browser installation | Unresolved | Not checked | Not tested | |
| App-store distribution | Unresolved | Not checked | Not tested | |

Do not copy a worked scenario’s availability date as today’s observation. A source establishes only what it says; it does not supply your app’s result.

### Task evidence row — repeat for each mandatory checkpoint and target

| Field | Your entry |
| --- | --- |
| Route, target and app version | |
| Mandatory or optional | |
| Exact starting state, including connection/account | |
| Action | |
| Expected visible and saved result | |
| Result: Pass / Fail / Not tested | Not tested |
| Observation time and evidence reference | |
| Failure or unknown, with next owner | |
| Retest reference; keep the original row | |

Decision: Candidate to test / Unresolved proof / Current platform no-fit / Stop or defer / Tested pilot on the listed targets.

Reason: ________. Unmet mandatory conditions: ________. Next action, owner and date: ________.

Use Tested pilot only when every mandatory check has evidence of Pass on the listed targets and the route requirement/availability is satisfied. It is not a claim about every device or a complete launch review. Use the [launch checklist](https://www.overskill.com/learn/ai-app-launch-checklist) next.

### Keep a decision change visible

| Old board/version and requirement | New requirement and who changed it | New decision | Evidence still missing |
| --- | --- | --- | --- |
| | | | |

## Carry a suitable pilot into Overskill

Open the [brief builder](https://www.overskill.com/learn#brief-builder). Enter your audience and outcome; describe the selected route, data, roles and mandatory test in the records field. Edit the input fields to revise the generated brief, then choose **Start build**. **Copy brief** is secondary. The link imports no board and does not install, synchronize or submit an app to a store. Normal account access and credit requirements apply.

For M1, a portable starting brief is:

> Build a mobile web stall finder for craft-fair visitors. A visitor must scan our QR sign and find stall C7 without signing in or installing anything. Show only the public stall name, location and opening information. Authorized event staff may edit listings; visitors cannot change them or read private organizer records. Use fictional sample stalls first. Online access is acceptable; do not promise offline data, browser installation or store distribution. Test the final QR destination and the lookup on our named phone, OS and browser versions before sharing it.

If a mandatory condition makes the route a no-fit, preserve that decision instead of starting a build. If it is unknown, decide whether a bounded prototype test is worth doing before promising delivery.

## Installation references

- [Overskill installation help](https://www.overskill.com/help/articles/installing-your-app-on-iphone-and-android) owns the product’s installation instructions; it is not this board’s task evidence.
- [MDN installability guidance](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Making_PWAs_installable) distinguishes installation support and offline experience.
- [Apple’s iPhone web-app guide](https://support.apple.com/guide/iphone/open-as-web-app-iphea86e5236/ios) describes its current Safari path. Match instructions to the device/version you are testing.