Packvow privacy policy
Draft — pending solicitor review.
Effective date: 14 October 2026
This policy explains what personal data Packvow handles, why, who helps us handle it, how long we keep it and what rights you have. It covers the Packvow app for Android and iOS and the online service behind it.
Packvow is used by takeaway kitchens. A venue's staff photograph each order as it is packed. If a customer later claims an item was missing, the venue can use the photos to contest the refund with Uber Eats, Just Eat or Deliveroo.
1. Who we are
Packvow is run by Pilbe, 82, Suite A James Carter Road, Mildenhall, IP28 7DE, United Kingdom ("Packvow", "we", "us").
Contact: packvow@gmail.com
OWNER TO CONFIRM: our ICO data protection fee registration number, if registered, to be added here.
2. Our role: controller or processor
This depends on the data.
- The venue is the controller of the data its staff capture with Packvow: photos and videos of orders, ticket photos and their text, customer first names, packer names and order records. Packvow processes that data for the venue, on the venue's instructions, as its processor. If you are a customer or a member of a venue's staff, the venue decides how this data is used. Please contact the venue first. We will help the venue answer you.
- Packvow is the controller for the account data we need to run the service and keep it secure: the owner's email address and sign-in details. OWNER TO CONFIRM: SECURITY_PRIVACY.md states only that "the venue is the data controller; Packvow is a processor" and names one controller use (below). It does not say who controls account data. This draft treats Packvow as controller for account data. A solicitor should confirm.
- Packvow is also the controller when it uses facts about phones (maker, model, Android version and app version) across all venues to decide which phones and Android versions to support. We rely on our legitimate interest for this.
- Usage statistics: whether Packvow acts as processor or controller for usage statistics is not yet settled. A solicitor will confirm it (ADR-049). OWNER TO CONFIRM: Packvow's role for usage statistics.
A written processor agreement between Packvow and each venue sets out the processor terms. OWNER TO CONFIRM: the DPA (docs/legal/DPA.md) is drafted, pending solicitor review. It must be agreed before the first live venue.
3. Who may use Packvow
Packvow is for businesses. Only people aged 18 or over may use Packvow. The venue owner agrees to this, and confirms it for each packer they add. We do not collect anyone's age or date of birth.
Packvow is not for children and we do not knowingly collect children's data.
4. What we collect
4.1 Account and venue
- The owner's email address, used to sign in.
- The owner's password. We never see or store it. Our sign-in provider (Supabase Auth) keeps only a one-way hash of it.
- Sign-in codes we email when the owner chooses "Email me a code instead".
- The venue's name, the delivery platforms it uses, its time zone and its settings (for example how long to keep photos, and whether video mode is on).
- A record of which account belongs to which venue.
4.2 Staff (packers)
- Each packer's display name. No surname is needed.
- A hash of the packer's 4-digit PIN, if one is set. The PIN itself is not stored.
- Which packer packed each order, and which packer confirmed or corrected an item.
Packers do not have their own accounts. They choose their name on the venue's shared phone.
4.3 Orders and tickets
- A photo of the printed order ticket.
- The text read from the ticket. We remove phone number and postcode patterns from that text before storing it. The ticket photo is cropped to leave out the address block where the app can find it.
- What the ticket says: the platform, the order reference, the customer's first name, the items, quantities, modifiers, notes, allergen flags and the time the order was placed.
- Any corrections staff make to the ticket, with who made them and when.
We never ask for or try to capture a customer's address or phone number.
OWNER TO CONFIRM: tickets carry allergen flags (for example "contains nuts") next to a customer's first name. A solicitor should say whether this is health data (special category data under UK GDPR Article 9) and, if so, what condition applies. SECURITY_PRIVACY.md is silent on this.
4.4 Packing photos and videos
- Photos of each item as it is packed, of the open bag with the ticket, and of the sealed bag.
- In video mode, a video of the packing area. Video mode is off unless the venue owner turns it on. No sound is recorded.
- For each photo or video: when it was taken, which phone took it, a fingerprint of the file (SHA-256) and when our server received it.
- The original file is kept exactly as the camera wrote it. Its embedded data (EXIF) usually includes the phone's maker and model and the time. The app never records location. It asks for no location permission, and the camera's location tagging is off.
The app guides staff to frame the packing area and keep faces out of shot. Hands, arms or clothing may still appear.
4.5 AI checks
- The result of each AI check: which items were seen, how confident the check was, and short notes such as "lid not sealed".
- Which AI model and prompt version produced the result, how long it took and what it cost.
4.6 Refund claims and dispute packs
- Claims the owner records: the order, the platform, the type of claim, the items claimed, the amount, the dates, the outcome, the amount recovered and any notes the owner types.
- Dispute packs (a PDF and a ZIP of the original files) built from an order's evidence.
- Share links to a pack's PDF. We store only a fingerprint of each link, when it expires, whether it was stopped, and how many times and when it was opened.
A share link lets anyone who holds it open that pack's PDF, which shows the customer's first name, the order reference and the packing photos, for up to 30 days after it is made or renewed, unless the owner stops it sooner. Opening a link records only a count and the times in our tables. Our hosting provider's function logs keep each request's address, which includes the link's token, and the browser type, for the hosting plan's log retention period. Links are deleted with their pack.
4.7 Phones
For each phone the venue uses:
- a random installation id created by the app (not a hardware identifier, serial number, IMEI or Android ID);
- the phone's maker and model, Android version and app version;
- the date it was last seen.
The app records which of the venue's phones packed each order, and that phone's make, model, Android version and app version, so we can fix faults and the owner can recognise the venue's phones. Nothing records where the phone is. On an iPhone it records the iOS version instead of the Android version. A phone's record does not show whether the phone is still signed in.
We use these only to keep the service working and secure: to find faults tied to a phone model or app version, to record which phone packed each order, and to help the owner recognise the venue's phones. We never use them for analytics or marketing, to measure packers, or to link venues.
4.8 Usage statistics
If "Send usage statistics" is on for a phone, the app sends short records of what happened, for example "ticket scanned", "order sealed" or "pack built", with numbers such as how long a step took. Each record is linked to the venue and the order. It contains no names, photos, ticket text or installation id. The full list is fixed in advance (UX_FLOWS.md, "Analytics events").
The switch is in Settings on each phone. It starts on. Anyone using that phone can turn it off. When it is off, nothing is recorded or sent and any records waiting on the phone are deleted.
We do not use any third-party analytics or advertising tools.
4.9 Crash and fault reports
The app sends no crash reports.
4.10 Technical logs
Our hosting provider keeps request logs for a short period, as all web services do. These logs may include IP addresses and the type of browser or app. When someone opens a dispute pack share link, the log includes the link's address and the browser type.
OWNER TO CONFIRM: SECURITY_PRIVACY.md does not yet list Supabase Auth's session records (IP address and user agent) or the IP addresses in Supabase's request logs (ADR-042 open item), nor their retention period on the plan in use. Add the period here.
4.11 What we keep on the phone
The app stores its sign-in, its queue of unsent work, photos and videos waiting to upload, and its installation id in the app's private storage on the phone. These are needed for the service to work offline and securely, so the app does not ask for consent for them (PECR Schedule A1 paragraph 4).
5. Why we use it, and our lawful basis
| What | Why | Lawful basis |
|---|---|---|
| Owner email and password hash | To create the account and let the owner sign in | Contract |
| Venue details and settings | To provide the service the venue signed up for | Contract (with the venue) |
| Packer names and PIN hashes | To record who packed each order | Legitimate interest (the venue's): attribution of who packed |
| Ticket photos, ticket text, customer first names, items | To build a checklist for the order and to defend against disputed refunds | Legitimate interest (the venue's): defending against false or mistaken refund claims |
| Packing photos and videos | Evidence of what was packed | Legitimate interest (the venue's): defending against false or mistaken refund claims |
| AI check results | To tell staff, while packing, if an item looks missing | Legitimate interest (the venue's), as above |
| Claims and dispute packs | To help the owner contest a refund | Legitimate interest (the venue's), as above |
| Phone details and installation id | To keep the service working and secure | Legitimate interest: finding faults, security, recording which phone packed an order |
| Phone details across venues | To decide which phones and Android versions to support | Packvow's legitimate interest (Packvow as controller) |
| Usage statistics | To run and improve the service | Legitimate interest; PECR statistical-purposes exception (to be confirmed by a solicitor) |
| Crash and fault reports | To find and fix faults | Legitimate interest; PECR Schedule A1 paragraph 4 |
Where a row says "the venue's" legitimate interest, the venue is the controller and decides the basis. The table shows the basis Packvow's design assumes.
We do not sell personal data. We do not use it for advertising. We do not use it to train AI models, and our AI provider does not either (section 6).
The AI checks do not make decisions about people. They only flag items that may be missing. Staff can always override them, and they never stop an order being sealed.
6. Who we share it with (our processors)
We use these service providers. Each acts on our instructions under a contract.
| Provider | What it does | Where data is processed |
|---|---|---|
| Supabase | Database, sign-in, file storage and server functions | Ireland, EU (AWS eu-west-1) |
| Google Cloud (Vertex AI, Gemini models) | Reads ticket photos and checks packing photos | EU member states only (Vertex AI eu multi-region) |
| Expo (EAS Update) | Delivers fixes to the app between store releases | United States |
| Resend | Sends sign-in codes and account emails | United States |
About Google Cloud:
- Ticket and packing photos are sent to Google only for the AI check, through Google Cloud's EU endpoint, under Google Cloud's terms and its Cloud Data Processing Addendum.
- Google stores and processes these requests only in EU member states, and does not use them to train its models.
- Google holds inputs and outputs in memory for up to 24 hours inside the EU.
- If Google's automated abuse checks flag a request, Google may keep a log of it in the EU for up to 90 days. We will ask Google for an exemption from this logging before the first live venue.
- Google may access data from outside the EU for support, and through its own sub-processors, under its addendum.
About Anthropic: Anthropic (Claude) is an alternative AI provider we use only to test our checks on sample images. It receives no data from the live service. If we ever switch, we will tell venues first.
About Google ML Kit: the app reads ticket text on the phone with Google's ML Kit, which does not send the photo or its text anywhere. ML Kit sends Google usage metrics about the library itself (for example how long recognition took), as its terms require us to tell you.
About Expo: we use Expo's build service (EAS) to build the app, and its update service (EAS Update) to deliver fixes between store releases. When the app checks for an update (only after sign-in, while it is open), it sends Expo the runtime version, the update channel, the phone's platform, the ids of the update it is running and of any update that recently failed, and a random identifier the update library makes on the phone; after a launch that crashed, the next check also sends up to 1,024 characters of the error that stopped it. Expo sees the phone's IP address. No account, venue, order or photo data goes to Expo.
Apple and Google run their app stores as separate controllers. Their privacy policies cover what they collect when you download the app.
Sharing by the venue. The venue may download dispute packs, share a pack link or send photos to a delivery platform to contest a refund. That is the venue's choice, as controller. Copies the venue shares or downloads are outside our control.
Other disclosures. We may disclose data if the law requires it, or to protect our rights or the safety of others. If Packvow's business is sold or transferred, data may pass to the new owner under the same commitments.
7. International transfers
Our database and files are stored in Ireland, in the EU, which the UK recognises as giving adequate protection.
Photos sent for AI checks are processed by Google in EU member states. The UK recognises the EEA as adequate, so this transfer needs no extra safeguards. Google's possible support access from outside the EU is covered by its Cloud Data Processing Addendum.
OWNER TO CONFIRM: a solicitor should confirm the wording of the two paragraphs above (SECURITY_PRIVACY.md, ADR-037).
OWNER TO CONFIRM: Expo and Resend process data in the United States; name the safeguard here (for example the UK Extension to the EU-US Data Privacy Framework, or the UK International Data Transfer Addendum).
8. How long we keep it
Orders and their evidence. The venue owner chooses how long to keep orders: between 30 and 365 days. The default is 90 days. Each night we delete whole orders older than that, counted from when our server received the order: the photos, videos, ticket, checklist, AI results, claims and dispute packs together, with their share links. When a venue shortens its retention period, the shorter period takes effect 7 days after it is saved; a longer period takes effect at once; retention is counted from when the order reached our server.
- The 7-day delay on a shorter period means a mistake can be undone before anything extra is deleted.
- Dispute hold. An order with a refund claim is kept past the period while the claim is open (until 90 days after its last activity; the owner is warned 14 days and 1 day before), for 30 days after its outcome is recorded, and while a share link to its pack still works (at most 30 days after it was issued or last renewed).
- The owner can delete an order sooner. A deletion by the owner is not held.
Usage statistics. Kept for the venue's retention period or 90 days, whichever is shorter. After that we keep only monthly totals per venue, with no order, phone or staff ids, for at most 13 months. At a venue run by one person, those totals may still describe that person.
Phone records. Deleted 90 days after a phone was last heard from, or when the venue is deleted.
Packer names and PIN hashes. A packer's PIN hash is deleted when the owner deactivates the packer. The packer's name is deleted once two things hold: no kept order, ticket edit or checklist line names them, and their record has not changed for the longer of the venue's retention period and 90 days. An active packer's name is kept until the owner deactivates them or the venue is deleted.
The account. Kept until the owner deletes it (section 10).
After deletion. We keep the random ids of deleted orders, with the venue id and date, for 400 days, so we can refuse late uploads from a phone that was offline. They hold nothing else.
Backups. Deleted database rows stay in our database backups until those expire: 7 days of daily backups, or up to 28 days if point-in-time recovery is used. Backups are used only to restore the service. If we ever restore one, we run the deletions again. Photos and videos are not in backups, so deleted evidence cannot be restored.
OWNER TO CONFIRM: SECURITY_PRIVACY.md assumes the Supabase Pro plan's backups. The hosted project is on the free tier today (BLOCKERS B19, B20). State the backup period of the plan actually in use when the policy is published.
On the phone. Each photo stays on the phone until the server has confirmed it received it intact. After that it is removed when the phone's Packvow storage passes 2 GB, oldest first.
9. Security
- All data travels over encrypted connections (TLS). Data is encrypted at rest by our hosting provider.
- Each venue can reach only its own data. This is enforced in the database itself.
- File storage is private. Files are reached only through links that last minutes, or through a pack share link the owner can stop at any time.
- Original photos cannot be changed or overwritten after upload. Each has a fingerprint, so any change would show.
- AI provider keys are never in the app.
- On the phone, data is kept in the app's private storage, and sensitive settings are encrypted with a key held by the phone.
Kitchen phones stay signed in so staff can work without passwords. Anyone who picks up an unlocked kitchen phone can see the venue's orders, ticket photos, packing photos and packers' names. Someone who copies the phone's sign-in could also build dispute packs for claims, download them and issue share links, until the owner signs that phone out. We advise venues to use a screen lock, keep the owner's password private, and keep the owner's email off the kitchen phone. If a phone is lost, the owner can sign it out from another phone.
No system is perfectly secure. If a breach affects your data, we will tell the venue without delay so it can meet its own duties, and we will tell you and the ICO where the law requires.
10. Deleting your account
The owner can delete the Packvow account and all of the venue's data:
- In the app: Settings → Delete account. You confirm with your password or an emailed code. Before deleting, the app names any open claims and live share links, so you can download what you need first. The phone then signs out and deletes everything Packvow kept on it.
- On the web, without the app: sign in on our account deletion page with your email address and password, read what would be deleted, and confirm with your password again.
- By email: write to packvow@gmail.com from the account's email address and ask us to delete your Packvow account.
We delete the account, the venue, all orders, photos, videos, packs, claims, staff, phone records and usage statistics within 24 hours. Open claims do not hold back an account deletion. What stays afterwards is described in section 8 ("After deletion" and "Backups"). A public page explains the steps: https://packvow.aiisup.com/delete-account-info.
Exporting the venue's data. The owner can download a copy of the venue's data and its original photos and clips first: Settings → Export the venue's data, confirmed with your password or an emailed code. The data (orders, tickets, checklists, AI results, claims, staff names, phones, usage statistics and settings, as JSON files) comes in one ZIP file, and the original photos and clips in further ZIP files of up to 500 MB each, downloaded one at a time to the phone and then shared or saved where you choose. The export leaves out credentials (PIN hashes, share-link secrets and owner-check records), the service's own bookkeeping, and files that can be made again from the originals (overlay photos and dispute packs). An original that never fully reached our server, or failed its fingerprint check, is listed in the export with the reason instead. The export's files are kept on our servers for 7 days, then deleted. A venue can have up to 3 exports in those 7 days.
Signing a phone out. The owner can also sign one kitchen phone out and empty it, without deleting the account: Settings → Sign out and clear this phone. It refuses while orders on that phone have not reached the server, and names anything that would be lost first. The phone then counts as a new device.
11. Your rights
Under UK data protection law you have the right to:
- ask for a copy of your data (access);
- ask us to correct it;
- ask us to delete it;
- ask us to restrict how we use it;
- object to our use of it where we rely on legitimate interests;
- ask for your data in a portable format (the owner can export the venue's data in Settings → Export the venue's data: the data as JSON files in a ZIP, and the original photos and clips in further ZIPs; section 10);
- complain to the Information Commissioner's Office (ico.org.uk, 0303 123 1113).
If you are a customer or a member of a venue's staff, the venue controls your data in Packvow. Contact the venue first. If you contact us, we will pass your request to the venue and help it answer.
If you are a venue owner, contact us at packvow@gmail.com. We will reply within one month. We may ask you to confirm your identity, usually by writing from the account's email address.
12. Changes to this policy
We will update this policy when the service or the law changes. We will change the effective date at the top. If a change matters, for example a new AI provider or a new place where data is processed, we will tell venue owners in the app or by email before it takes effect.
13. Contact
Pilbe 82, Suite A James Carter Road, Mildenhall, IP28 7DE, United Kingdom packvow@gmail.com