Overview

Last updated 3 Oct 2026

ProvenBatch — Research & Market Notes

A living document. Add findings as we learn them, with a date and a source. When something turns out to be wrong, correct it in place and say so — a struck-through wrong belief is more useful than a silently deleted one, because it stops us rediscovering it.

Last updated: 3 Oct 2026

Published as the Research library: outputs/admin-site/research-library.html (generated — run bash outputs/build-research-library.sh after editing). Served on the admin origin only, never the customer app. Future research belongs in this file or in outputs/docs/*-research.md, then rebuild; do not leave it scattered. Competitor research is maintained in Google Drive (see §3).

Overview

Last updated not dated

1. What the product is, and where it actually wins

The product: ingredient/supplier management, recipe costing, and derived PPDS allergen labels for small UK baking businesses.

Table stakes (everyone has these — they don't win anything): PPDS labels with bolded allergens · allergen matrix · recipe costing · audit trail · sub-recipes.

Our actual moat — two things, neither of which competitors advertise:

1. Per-bake supplier selection. The label proves which pack actually went in the mixer, not which pack the recipe assumes. Swap to an alternate supplier on the day and the label — and its allergens — change with it. Everyone else derives labels from the recipe; we derive from the batch. This is the defensible idea.
2. Second-opinion allergen scanner + freshness tracking (v0.11.0, v0.13.0). Nobody in the comparisons below sells "we check our own allergen detection and tell you when it's stale".

Strategic read (17 Jul 2026): deepen the moat, don't chase the feature list. Stock control and order management are where competitors are strong and we'd be late; correctness and trust is where we're already ahead and where a labelling product lives or dies.

Market

Last updated 31 Jul 2026

2. Market

Who: UK small food businesses — not bakers specifically. PPDS is not a bakery rule: the FSA publishes sector guidance for butchers as well as bakers, and meal-prep caterers, farm shops, delis and cafes packing sandwiches, market stalls and street food, chocolatiers, and jam, preserve and sauce makers are all in scope on identical terms. Home bakers and cottage bakeries are one vertical among several, not the market. Solo or family-run; a laptop and a phone; no IT support. Price-sensitive.

(Corrected 29 Jul 2026. This paragraph led with "UK home bakers" and read as a baker-first market, which understated the addressable set and contradicted §11 and stella-apps-business-research.md §1a — both of which establish that widening beyond bakers is copy and positioning, not build. Now logged as D-24.)

The buying trigger is almost certainly compliance fear (Natasha's Law), not efficiency. That suggests the pitch is "prove you did it right", not "save time".

Biggest adoption barrier — evidenced, not assumed: entering ~70 ingredient declarations by hand. Our own instance has 70 sourcings; nobody will type that to trial an app. This is why supplier product capture and parsing is so important.

⚠️ The arithmetic here is stale, and the update strengthens the conclusion — see §17 (24 Aug 2026). The instance now has 181 sourcings, of which 91 still carry the (enter declaration) placeholder and 157 have never been confirmed against a pack — a month after #249 shipped a working one-tap pack reader. The barrier is not just the first 70; per-item capture does not clear a backlog at all.

Open question: market size unknown. Not yet researched. Sized 31 Jul 2026 — see §12 and gtm-channels-research.md §1. UK register ≈ 540k rated / 605k total; TAM ≈ 150–240k PPDS-obligated businesses (£27–43m ARR); realistic 3-year SOM 1,000–5,000 subscribers (£180k–£900k ARR). Two load-bearing numbers remain modelled rather than known: the PPDS fraction and the active home-based stock (~60–120k, modelled).

Market

Last updated 27 Jul 2026

11. Commercialisation: markets, competitors, pricing, and Stella Apps (researched 27 Jul 2026)

Full report: outputs/docs/stella-apps-business-research.md (six sections: market expansion, must-have UK SaaS features, competitive landscape, suggested pricing, HMRC/business setup, banking and accounting). It carries its own source list. Headlines worth having here:

• Competitive anchor confirmed and sharpened. FoodCore is still £19 Essentials / £55 Core, no per-label fee, no per-user fee for small teams, 7-day trial with no card. (⚠️ Superseded 10 Aug 2026: FoodCore repriced to three tiers, £25/£40/£65 inc. VAT — the anchor is now £25–65/mo and our under-price opening widened. See §3 and the master competitor sheet.) Nutritics is reported at roughly £80-200/mo and is not aimed at our buyer. US home-baker tools sit at $20-49 (Bakesy $20/$40 with a free tier, BakeOnyx $29, CakeBoss $49/$99/$179); Craftybase runs $49-349. (Corrected 20 Aug 2026, live vendor pages, during the website comparison re-verification: Bakesy dropped its free tier — now Standard $9.99 / Premium $17.99 with a 30-day trial; and Craftybase rebranded to Stocksmith (stocksmith.io) — same team, software and $49–349 prices, craftybase.com redirects there. FoodCore re-verified unchanged at £25/£40/£65 inc. VAT: matrix and food safety still Core-only, costing/orders/stock still Growth, AI checks still metered 20/50/100, 7-day trial no card.)
• The sub-£10 slot is empty. Bake Diary closed in May 2025. It was Ireland-based, served mostly UK and Irish bakers at about EUR 6.95/mo, and was the cheapest credible option. That is both our clearest opening and a warning: the market has just watched a cheap single-founder tool disappear, so credibility signals (status page, export promise, backup policy) are commercial features, not hygiene.
• Recommended pricing: £9 Starter / £19 Standard / £39 Pro, annual at 10x monthly, 30-day full-feature trial with no card, and a read-only Archive state rather than locking data at the end. The label engine stays complete in every tier; the paywall runs along orders, accounts, receipts, stock and users. Fixed cost base is roughly £50-70/mo, so break-even is about 8 Starter or 4 Standard customers. Stripe's £0.20 fixed fee is 2.2% of a £9 charge, so annual billing nearly halves fee drag at the low tiers.
• Expansion is cheapest sideways, not abroad. PPDS is not a bakery rule: meal-prep caterers, farm shops, delis, market stalls, butchers and preserve makers are in scope on identical terms, so that expansion is copy and positioning, not build. Then Ireland (same FIC base, but PPDS food is treated as non-prepacked under S.I. 489/2014 — the FSAI cites this "as updated by S.I. 656/2024"; §29a records that 656 changed enforcement, not the declaration — so a different label template), then AU/NZ PEAL (21 allergens, plain-English, prescribed format, mandatory since 25 Feb 2024), then Canada (11 priority allergens; the real cost is bilingual labels), then the US last (9 allergens, simplest label, hardest market). Candle/wax-melt CLP labelling is the strongest non-food adjacency: same shape exactly, a mandatory label derived from supplier documentation, with the same insurance-invalidation fear as the buying trigger. (⚠️ Order corrected in place 6 Sep 2026, #825 — outputs/docs/decisions/825-choose-markets-and-order.md, register entry D-29, DECIDED — Dave confirmed on #825: the UK's own jurisdiction gap comes first. The food-safety module seeds SFBB, an FSA England-and-Wales pack, and ProvenBot is hard-wired to food.gov.uk — a Scottish (Food Standards Scotland / CookSafe) or Northern Irish (Safe Catering) business is misdefaulted today, and D-01 says "UK", not "England and Wales". Filed as #1349. The corrected order: UK adjacent verticals (now, copy only) → Scotland and NI (#1349) → Ireland (first non-UK, #826 → #827, post-GA only) → AU/NZ → Canada → USA last, re-tested and confirmed on market grounds. Candles/CLP is removed from the market order — a product line on the same engine, not a market, decided on its own issue. Two things the table above does not show: Ireland's regime for PPDS food is lighter than Natasha's Law, so the compliance buying trigger is weaker there and Ireland is first for the abstraction and the Bake Diary story, not for revenue (~8% of the UK by population); and B2C digital sales into Ireland carry Irish VAT from the first euro, so "ready for Ireland" includes choosing non-Union OSS or a merchant of record before #827 starts — see the VAT bullet two entries below.)
• To make any of that cheap, three things must become data not code: the declarable allergen set, the label template, and the locale layer. (Corrected 27 Jul: the original version of this bullet said #48 single tenancy gated everything. It does not. #48 shipped in v0.14.0 - see the correction in §6. The real launch gates are billing, staging (#137), the legal stack and support tooling.)
• Market size is still not closed. Closed to a defensible range on 31 Jul 2026 — see §12. Two corrections to this bullet's figures: the register is ~540k rated / ~605k total (the 430,000+ was the older rated-only count), and the 37%-domestic figure is confirmed and dated (37% of 92,540 registrations Mar 2020–Mar 2022, FSA campaign). The FSA still publishes no home-based stock total; §12 models it at 60–120k active.
• UK SaaS obligations that actually apply to us: ICO Tier 1 fee £52/yr (£47 by DD); UK GDPR plus the DUAA (in force 5 Feb 2026, complaint-handling duties from 19 Jun 2026) means a DPA, a sub-processor list and a published complaints route; VAT threshold £90,000, frozen for 2026-27, but no threshold at all for B2C digital sales outside the UK, so stay UK-only or use a merchant of record; the DMCC subscription regime is consumer-facing and delayed to spring 2027, but build to it anyway. And say plainly in the Terms that the food business operator owns their label.
• Stella Apps setup: sole trader is right for now; register for Self Assessment by 5 October after the first trading tax year; Class 2 is gone, Class 4 is 6% / 2%; cash basis is HMRC's default from 2024/25; MTD for Income Tax reaches £20,000 qualifying income in April 2028, assessed on 2026-27, so keep digital records from day one.
• ✅ Banking: Mettle — ACCOUNT OPENED 29 Jul 2026, along with sole trader registration at HMRC. Chosen over Tide on one specific ground - it includes the full FreeAgent platform free, which is HMRC-recognised for MTD and removes the accounting line item entirely. Tide is perfectly workable (its 20p transfer fee barely bites a business with a handful of movements a month) and Starling is the strongest full-bank alternative; hold a second account somewhere else as insurance against a frozen one.

Full write-up

From outputs/docs/stella-apps-business-research.md

Stella Apps / ProvenBatch - Commercial Research Report

Prepared 27 Jul 2026. Companion to outputs/RESEARCH.md (which stays the living record); this is the standing commercial reference for launching ProvenBatch as a paid product under Stella Apps.

Scope. Six questions: where the toolset travels with least rework, what any UK SaaS must have, who we are competing with, what to charge, how to set Stella Apps up with HMRC, and how to bank and book-keep it.

How to read the evidence. Every factual claim below is sourced in the Sources list. Where a figure could not be verified it is marked [unverified] and is not used to support a recommendation. Prices and thresholds move: re-check anything commercial before acting on it.

Not advice. This is research, not regulated tax, legal or financial advice. Confirm tax and compliance points with HMRC guidance or an accountant before filing anything.

1. Market Expansion Opportunities

The product is not really "bakery software". It is a chain: supplier declaration → ingredient → recipe → derived, provenance-backed label. Anything that shares that chain is a candidate market. Two axes: adjacent verticals (same law, so almost no rebuild) and geographies (different law, so the rebuild cost is the allergen taxonomy and label format).

1a. Adjacent UK verticals - effectively zero regulatory rebuild

Natasha's Law / PPDS is not a bakery rule. The FSA scope covers any business packing food on the premises it is sold from, and the FSA publishes sector-specific PPDS guidance for butchers as well as bakers. Businesses in scope include bakeries and cake businesses, market stalls, cafes and delis packing sandwiches, salads and ready meals, meal-prep and catering businesses packing for collection or delivery, home bakers selling online or at markets, and farm shops and food halls packing their own produce.

Read: this is the cheapest expansion available and it does not need a single regulatory change. It is a positioning and copy exercise, not a build. The one caveat is that FoodCore already names "bakeries, meal prep businesses, home producers, caterers and market traders", so this ground is contested rather than empty.

Market size, honestly. The Food Hygiene Rating Scheme covers more than 430,000 businesses across England, Wales and Northern Ireland. The FSA reports that 37% of new registrations since March 2020 are run from domestic kitchens at private addresses, and separately warns that many home-based sellers have never registered at all. That supports "tens of thousands of home-based food businesses" as a plausible order of magnitude, but the FSA does not publish a home-based total, so the precise addressable number remains unverified (this is RESEARCH.md §7 open question 1, still open). Note the double edge: unregistered sellers enlarge the latent market but are, by definition, the least compliance-motivated buyers.

1b. Geographic expansion, ranked by rebuild cost

1c. Adjacent non-food markets (same engine, different rulebook)

• Candle and wax melt makers (CLP labelling). Structurally the closest analogue to what we already do: a mandatory hazard label derived from supplier documentation (a Safety Data Sheet and a CLP sheet for the exact fragrance percentage used), required on anything containing fragrance or essential oil, at any scale, including market stalls and Etsy. Crucially the buying trigger is identical to ours: product liability insurance commonly requires correct labelling, so a wrong label can invalidate cover. Rebuild: swap the allergen engine for a pictogram / hazard-statement engine; keep supplier declarations, derivation and provenance untouched. This is the strongest non-food candidate.
• Soap and cosmetics (UK Cosmetic Products Regulation). Requires a UK Responsible Person, a Cosmetic Product Safety Report signed by a qualified assessor, and an INCI ingredient list on the packaging. We could generate the INCI list and RP block, but the gating artefact (the CPSR) is a human assessment we cannot supply, so the software is a smaller part of the customer's problem. Weaker fit than candles.

1d. What to build once, to make all of the above cheap

None of this is affordable while jurisdiction rules are baked into code. Before any expansion:

1. Fix single tenancy first. Corrected 27 Jul 2026, same day as first issue. The original version of this report repeated a stale RESEARCH.md §6 claim that the app is single-tenant and unsellable until #48 lands. #48 shipped in v0.14.0: tenant tables, flat RLS policies, self-serve sign-up, and isolation proven against a real throwaway tenant. There is no architectural gate on selling. The actual launch gates are billing, a separate staging environment (#137), the legal stack and support tooling. Nothing else in this report depended on the wrong claim, but §3b and §5 have been corrected to match.
2. Allergen list as data, not code - a jurisdiction profile carrying the declarable set (14 UK / 21 AU-NZ / 11 CA / 9 US), the emphasis rule, and the naming rule (for example PEAL's "name each tree nut individually").
3. Label template as data - flat ingredient list vs "Contains" statement vs written allergen notice, driven by the same profile.
4. Locale layer - currency, units, date format, and language strings extracted from the single HTML file.
5. A jurisdiction is then a config row plus a template, which is the difference between a two-week market entry and a three-month one.

Recommended order: UK adjacent verticals (now, no build) → Ireland (small build, vacated by Bake Diary) → AU/NZ → candles as a separate product → Canada → USA.

2. Must-Have SaaS Features and UK Considerations

2a. Product and platform must-haves

Grouped by whether they gate launch.

Gating (cannot sell without):

• Multi-tenant data isolation with per-tenant RLS, proven by tests. Done in v0.14.0 (#48).
• Self-serve signup (done, create_my_business()), email verification, password reset, and account deletion.
• Subscription billing with plan gating, trials, card updates and dunning (failed-payment retries).
• Data export in an open format, both for UK GDPR portability and because "you can leave with your data" is a trust argument in a compliance product.
• Backups with a tested restore, not just backups.
• A support route with a stated response expectation.

Near-gating (needed within weeks of the first paying customer):

• Onboarding import. Our own evidence is that entering roughly 70 ingredient declarations by hand is the single biggest adoption barrier. Barcode capture (#27) and receipt scanning are therefore not features, they are the funnel.
• Users and roles. If a baker's staff verify allergens, roles (#38) become a compliance question, not a convenience.
• A label archive: an immutable record of exactly what was printed, when, and from which supplier batch. This is our differentiator turned into an artefact the customer can hand to an EHO.
• Vendor support access that is time-boxed and logged (RESEARCH.md §6a). Decide before customer #1 asks, not during their first problem.

Operational:

• Error monitoring, uptime monitoring and a public status page.
• Transactional email with SPF, DKIM and DMARC configured (compliance email that lands in spam is worse than no email).
• Cookieless product analytics, so no cookie banner is needed (see PECR below).
• A documented incident and breach process (72-hour clock).

2b. UK regulatory and operational notes

2c. Recommended service providers

Estimated fixed cost base at launch: roughly £50 to £70 per month (Supabase Pro plus insurance, ICO fee amortised, domain, with hosting and email on free tiers). That number drives §4.

3. Competitive Landscape

(⚠️ FoodCore's entry here is superseded — they repriced to £25/£40/£65 inc. VAT; the current analysis is the master competitor sheet.)

All pricing verified July 2026. Currency is as the vendor lists it; USD prices are not converted, because the exchange rate is not the point, the price perception is.

3a. Who is actually in the market

UK, direct:

• FoodCore - the closest comparison and the price anchor. Two plans: Essentials from £19/month (recipes, allergens, Natasha's Law labels) and Core from £55/month (adds costing, shopping lists, orders, food safety logs, business insights, team management). No per-label charges, no per-user fees for small teams, no setup fee, no minimum contract, 7-day full-feature trial with no card. Explicitly targets bakeries, meal prep, home producers, caterers and market traders. They also run a substantial content and SEO operation, which is a competitive fact in its own right.
• Planglow (LabelLogic Live) - established UK label supplier with software attached. Different business model: the software pulls through label and consumable sales. Pricing not published in a form we could verify [unverified].
• Nutritics - nutrition analysis and compliance for dietitians, manufacturers, hospitals and larger caterers. Reported at roughly £80-200/month, tiered by users and products, with complex onboarding and no PPDS label printing aimed at small producers. Not a competitor for our buyer; it is who our buyer is told they should use and cannot afford.

Home-baker tools, mostly US-priced:

• CakeBoss - $49/month up to 50 orders, $99/month up to 200, $179/month unlimited.
• Bakesy - free up to 5 orders/month, $20/month Starter, $40/month Growth (unlimited orders).
• BakeOnyx - $29/month, positioned at 10 to 40 custom orders a month, mobile-first.
• Baking It - cake-business tooling (tin and serving charts, portions, 3D design, orders, quotes), reported at over 40,000 users.
• Craftybase - the maker-economy COGS and inventory tool: $49 Studio, $99 Indie, $199 Business, $349 Growth per month, with about two months free on annual billing, and a 14-day trial. Priced by order lines, not by recipes.

The vacancy: Bake Diary closed in May 2025. It was an Ireland-based recipe-costing app serving mostly UK and Irish bakers at about EUR 6.95 a month, and it was by some distance the cheapest credible option. Its closure did two things: it emptied the sub-£10 tier, and it gave the whole market a reason to distrust cheap single-founder tools. Both matter to us.

3b. Feature comparison

Rows in bold are where we currently differ. "Ours" reflects what is live at v0.68.0.

3c. Pricing analysis

• The UK anchor is £19 to £55 a month (FoodCore). Nutritics sets a ceiling reference at £80-200.
• The US home-baker tools cluster at $20 to $49, with CakeBoss going to $179 for volume.
• Nothing credible now sits under £10 a month in the UK. Bake Diary occupied that slot at about EUR 6.95 and it is gone.
• Our buyer is a cake-shed or home baker whose business may generate "several hundred pounds per week". £55 a month is roughly a whole day's takings for some of them; £19 is arguable; under £10 is an easy yes. Price sensitivity here is real, not assumed.
• Charging per label is a live model in this market (Planglow's model depends on consumables). FoodCore explicitly does not charge per label, so "no per-label fee" is table stakes, not a differentiator.

3d. Where we can actually differentiate

1. Batch-level provenance. Everyone else derives the label from the recipe. We derive it from the batch that was made. That is the only claim in this document that no competitor advertises, and it is the one to build the brand on. Turn it into an artefact: a printable, timestamped record of what went in.
2. We check our own work. The second-opinion allergen scan plus freshness and verification tracking is unique in the comparison set, and it directly answers the failure mode our own data proved is the dangerous one: silent under-declaration.
3. We remove the data entry. Barcode capture and photo receipt scanning attack the evidenced adoption barrier (roughly 70 declarations to type). No competitor in the set advertises either. This is a funnel advantage, which is worth more than a feature advantage.
4. On-device by default. Receipt photos are never uploaded... "your photos never leave the phone" is a sales line. > WRONG. Corrected 27 Jul 2026, before this document was ever used to sell anything. This > claim was carried over from RESEARCH.md §8, which was written on 19 Jul and describes an > architecture the app has since moved past. Receipt photos are uploaded. index.html sends > image_base64 to the parse-receipt edge function, which reads the photo with Claude > vision (#168, Mobile M2); on-device Tesseract is now only the fallback path. Receipt images > are also stored, in a private Supabase bucket with a 6-year default retention (#120). > > Marketing "your photos never leave the phone" would have been a false privacy claim on a > compliance product, which is the worst possible place to make one. The real, defensible version > is "your data is held in the UK": the Supabase project is in eu-west-2 (London), verified > 27 Jul 2026. The Anthropic call is a US transfer and needs a documented transfer mechanism, so > it is a compliance obligation rather than a selling point. See > outputs/docs/go-to-market-decisions.md §D1.
5. Price. We can profitably sit under the anchor (see §4).
6. Accounts built for how HMRC actually works. Cash basis is HMRC's default for sole traders from 2024/25, which is exactly the model planned. Competitors either ignore accounting or bolt on COGS-heavy inventory tooling built for US Etsy sellers.

Honest weaknesses. Stock control (#33) and food safety logs (#36) are where FoodCore's £55 tier is strong and we are not. We have no brand, no reviews, no customers and no SEO surface (one 520 KB HTML file with no server rendering), while FoodCore is publishing comparison content weekly. And the market has just watched a cheap single-founder tool close, so credibility signals matter disproportionately: a status page, a data export promise, a published backup policy and a real company identity are commercial features here, not hygiene.

4. Suggested Pricing Structure

4a. The model

Trial first, not freemium. Benchmarks put SMB-targeted free-trial conversion at roughly 6 to 10%, against 2 to 5% for freemium, and trials reach monetisation in 12 to 18 days rather than 90 to

1. Requiring a card raises conversion sharply but suppresses signups, and in a nervous,

price-sensitive market a card wall will cost more than it gains.

Recommendation: a 30-day full-feature trial with no card required, backed by import tooling so a baker can actually get their 70 declarations in during the trial. The trial is only as good as the onboarding, which is why barcode capture is the commercial priority, not a nice-to-have.

When a trial or subscription ends, never lock the data. Drop to a read-only Archive state: everything stays visible and exportable, but label printing and new batches stop. Holding a food business's allergen records hostage is both a bad look and a compliance hazard, and the paid action (printing a label this week) is the one worth gating.

4b. Tiers

All prices in GBP, per business per month, VAT not applicable while under the £90,000 threshold. Annual billing at 10x the monthly price (two months free).

Deliberate choices worth flagging:

• The label engine is in every tier, uncrippled. Never sell a partial allergen label. If someone is paying us anything, the compliance output must be complete, or we own a safety problem.
• The paywall runs along "running a business", not "being safe". Orders, accounts, receipts, stock and extra users are the upgrade levers.
• Products, not labels, are the Starter limit. Per-label metering punishes exactly the behaviour we want (label everything).
• £19 buys at Standard what FoodCore charges £19 for at Essentials, and includes much of their £55 Core tier. That is the positioning: their entry price, most of their top tier, plus the batch provenance nobody else has.

4c. Why these numbers

Cost basis. Fixed costs are roughly £50 to £70 a month (§2c). Per-tenant marginal cost is close to zero: the app is a static file and Supabase Pro's included capacity covers many small tenants.

Payment fee drag (Stripe 1.5% + £0.20, plus Billing 0.7%):

The £0.20 fixed component is 2.2% of a £9 charge. Push annual billing hard at the low tiers: it nearly halves fee drag, and it removes eleven chances a year for a card to fail. Offer a founder annual rate rather than a monthly discount.

Break-even. Against a £65/month cost base: about 8 Starter customers, or 4 Standard, or 2 Pro. A realistic mixed book of 20 customers weighted to Standard clears roughly £250 to £300 net a month, which is a real side income and, more importantly, funds the compliance and insurance overhead without subsidy.

Launch tactics.

• Grandfather early customers on their signup price permanently and say so. In a market that just lost Bake Diary, "the price you join at is the price you keep" is a trust signal as much as a discount.
• Publish the price on the site. FoodCore does; opacity reads as expensive.
• No setup fees, no per-label fees, no per-user fees below the tier cap, monthly cancellation. Match FoodCore on all four so none of them becomes an objection.
• Revisit pricing only after 20 paying customers. Before that, the data is anecdote.

5. Business Setup and HMRC Guidance

5a. Is sole trader the right structure?

Yes, for now, on the stated facts: single owner, revenue well under the £90,000 VAT threshold, minimal capital, and a preference for the least administrative overhead. Registration is a single online step, there are no filing fees, and accounts stay private.

The one real caveat. A sole trader has unlimited personal liability, and this is compliance software: the failure mode is a customer's mislabelled product, not a lost invoice. That is a genuine rather than theoretical exposure. Mitigate with (a) Terms that state plainly that the food business operator is responsible for their labels, (b) professional indemnity insurance from day one, and (c) a trigger to incorporate. Sensible triggers: the first business customer who asks for a signed DPA with an uncapped indemnity, revenue passing roughly £30,000, or the first employee or contractor.

5b. Setting up "Stella Apps"

1. Check the name is usable. A sole trader may trade under a business name without registering it, but it must not include "limited", "Ltd", "plc" or similar, must not be misleading, must avoid sensitive words (for example "Royal", "British", "Bank", "Insurance", "Institute", "Chartered"), and must not be confusingly similar to an existing brand. Search the UK IPO trade mark register and Companies House before committing, and check domain and social handles. There is no register of sole trader names, so the protection you get is what you create: consider a UKIPO trade mark in class 9 (software) and class 42 (SaaS) once revenue justifies it. Current IPO fees should be taken from the IPO site at the time of filing [unverified here].
2. ✅ DONE 29 Jul 2026 — registered as a sole trader with HMRC. (Recorded under the home address, deliberately: HMRC holds it on the personal record regardless, publishes no register of sole traders, and its post is deadline-bearing — so routing it through a forwarding service would add risk for no privacy gain. See D-07 and #267.) Original guidance retained below. Register for Self Assessment with HMRC. The deadline is 5 October following the end of the tax year in which trading started (so trading begun in 2026/27 must be registered by 5 October 2027). Register early rather than at the deadline: you need the UTR and Government Gateway account before you can do anything else. Registration is required once self-employment income exceeds, or is expected to exceed, £1,000 in a tax year.
3. Note the trading allowance. If gross trading income in a tax year is £1,000 or less, there is generally no need to register or report. Above it, you can deduct the £1,000 allowance instead of actual expenses, which is only worth doing if your costs are lower than that.
4. Pay the ICO data protection fee (Tier 1, £52, or £47 by Direct Debit) before processing live customer data.
5. Take out professional indemnity insurance (from roughly £8-10 a month) before the first paying customer.
6. ✅ DONE 29 Jul 2026 — Mettle business account opened, which is §6b's primary recommendation. This also settles accounting (§6c): FreeAgent now comes free with the account, so the £0 accounting line in §3 holds and no separate decision is needed. Remaining habit worth adopting: a separate savings pot taking 25-30% of every payout on the day it lands. (Original: open a separate business bank account — see §6. Not legally required for a sole trader, but it is the difference between an hour and a weekend at tax time.)
7. Publish the legal stack before launch: Terms, Privacy Policy, DPA, sub-processor list, and contact and complaints details.
8. Keep Stella Apps separate from the bakery. If Whisk & Whimsy is a tenant of the product, document it as such. Mixing the two sets of books, or the two sets of customer data, creates both a tax and a data-protection problem that is trivial to avoid now and awkward to unwind later.

5c. Tax and compliance checklist

6. Banking and Accounting Recommendations

6a. Tide, assessed against this specific business

What it costs and gives you (verified July 2026): free plan with no monthly fee and no minimum balance, a Mastercard debit card, and invoicing built into the app. Reported FSCS protection to £120,000 on new accounts [verify at application; FSCS protection normally depends on the underlying deposit-taking bank]. Accounts commonly open within hours. Direct Sage bank feed, plus Xero, QuickBooks and FreeAgent integrations on the free plan.

Charges: 5 free transfers a month then 20p per transfer in or out; £1 per ATM withdrawal; 3% on cash deposits at PayPoint; 90p per cheque deposited by app; 2.75% FX on overseas card use on the free plan. No overdraft.

Verdict for Stella Apps: perfectly workable, and the transfer fee barely bites. A SaaS business has a handful of movements a month (a Stripe payout, a few supplier Direct Debits, a transfer to a tax pot), so 20p per transfer is pennies. The 3% cash and 90p cheque fees are irrelevant to a business that will never handle either. The weak points are the absence of an overdraft and the FX rate, and FX only matters if you buy in USD (Supabase and several of the tools above bill in dollars, so a card with better FX is worth something).

6b. Alternatives worth taking seriously

Recommendation.

1. ✅ Primary: Mettle — CHOSEN AND OPENED 29 Jul 2026. Precisely because it makes the accounting software free. FreeAgent is a £150-300 a year product being given away with a free bank account, it is HMRC-recognised for MTD, and it removes an entire line item and an entire decision.
2. Secondary: Starling or Tide. Starling if you value being with an actual bank with an overdraft option; Tide if the built-in invoicing genuinely suits how you bill. Holding a second account at a different institution is cheap insurance against a frozen account, which is a real and well-documented risk with app-based providers. ⏸ Deferred 5 Aug 2026 (#270): revisit when Stripe goes live (#206), not now. Little point insuring an account with nothing in it, and a dormant business account risks being closed anyway. ⚠️ The accepted trade-off: opening one takes days-to-weeks, so this may end up done under time pressure — start the application in parallel with #206 rather than after it. Mettle stays primary regardless, since FreeAgent is free only while it sees at least one transaction a month.
3. Set up a separate savings pot and move 25-30% of every payout into it for tax on the day it lands. This is the single highest-value habit for a new sole trader.

6c. Accounting: simple and cheap

Practical bookkeeping notes for this business:

• Book gross revenue and record Stripe fees as an expense. Booking net understates turnover, which matters for the £90,000 VAT test.
• Categorise recurring tool spend (Supabase, Netlify, email, insurance, ICO) as a single "software and subscriptions" category so the monthly cost base is visible at a glance. ⚠️ Superseded 5 Aug 2026 (#270), twice — and the second attempt was also wrong, so both are recorded here. The original list was stale (Netlify has been gone since 3 Aug) and one lumped line destroys the fixed-vs-usage split #216 exists to measure. The second attempt proposed creating three custom categories, possibly split across FreeAgent's Cost of Sales and Admin Expenses tabs. Looking at the actual category list killed that too: FreeAgent already ships everything needed — create nothing. Two things the real UI settles:
• The dropdown is labelled "Tax Return Box", offers thirteen fixed options, and cannot be added to. A category selects a box; it never defines one.
• None of the thirteen is "cost of goods bought for resale" — that box belongs to the Cost of Sales tab, whose categories are all locked to a single "Cost of Goods" box. For a software business with no physical goods, use Admin Expenses only and skip Cost of Sales. ⚠️ Amended once the Cost of Sales tab was actually read: it holds 101 Cost of Sales, 102 Commission Paid, 103 Materials, 104 Equipment Hire, 150 Subcontractor Costs. Three are goods-oriented and useless to us, but 101 and 102 are exactly the two lines a SaaS business needs, so Cost of Sales is in use after all — for those two rows only.

The mapping, existing categories only (also kept as a one-page reference at outputs/docs/freeagent-category-mapping.pdf):

• Cost of Sales — the per-sale costs: 🎯 Anthropic API → 101 Cost of Sales; Stripe fees → 102 Commission Paid.
• Admin Expenses — fixed overhead: Supabase (both projects), Cloudflare and the domains → 268 Web Hosting; Google Workspace and Resend → 269 Computer Software; insurance → 364; ICO fee → 361 Subscriptions; trading address (#267) → 250 Office Costs (a service, not property, so not 251 Rent); accountant → 292; home working → 366 Use Of Home.

🎯 The point of putting those two in Cost of Sales is that FreeAgent then computes Income less Cost of Sales = gross profit by itself — which is exactly #216's output. Anthropic is the only genuinely per-customer cost in the estate, so it is the numerator; leave it merged into hosting and that number has to be reconstructed by hand from records that no longer distinguish it.

Supabase deliberately stays on 268, not Cost of Sales. Textbook SaaS accounting puts hosting in COGS, but ours is a flat per-project fee regardless of customer count — fixed overhead, not cost of sale. Move it to 101 if Supabase billing ever becomes usage-based.

⚠️ For a service business with no goods, "Cost of Goods" is a slightly odd SA103 box. Immaterial below £90k (single total figure) — on the list for the year-one accountant, not a blocker.

• USD charges should be recorded at the rate actually paid, not a notional rate. Keep the card statement.
• Under cash basis, most equipment is simply expensed in the month it is paid for, so a flat "expense it when it leaves the account" model is correct.
• Where the accounting basis is actually "set" (added 5 Aug 2026, #270). There are three places it could plausibly live and only one of them is an action:

1. HMRC — nothing to do. There is no form, notification or online setting for the basis. Since 2024/25 cash basis is the default, so it applies by operation of law from the first day of trading unless you actively opt out. Registering as a sole trader did not ask, and should not have.
2. The Self Assessment return — a non-action to protect. Cash basis = leave SA103S box 8 ("If you used traditional accounting rather than cash basis, put 'X' in the box") blank. The only way to get this wrong is to tick it. First relevant filing is the 2026-27 return, due 31 Jan 2028.
3. FreeAgent — the one real action. FreeAgent asks for the accounting basis alongside the accounting dates during account setup, and it drives every report and its Self Assessment area. If it was left on accruals, the books disagree with the return. Switching needs level-8 (full) access, is unavailable to a user holding the 'Accountant' role, and becomes unavailable once a return has been filed through FreeAgent on the other basis — which is why this is cheap now and expensive later.

• Cash basis losses are no longer trapped: the pre-2024/25 restriction to carry-forward-only was removed at the same time as the turnover thresholds, so a first-year loss can go sideways against general income or be carried back. Worth raising with the year-one accountant rather than self-serving, since it interacts with the Stella Apps / bakery separation.
• ⚠️ Do not confuse the accounting basis with the VAT cash accounting scheme — different regime, different election, and irrelevant here while D-16 holds (deliberately not VAT-registered).
• Keep digital records from day one. Even if MTD for Income Tax does not apply yet, the £20,000 threshold arrives in April 2028 and is assessed on 2026-27 income.

Estimated year-one running cost for Stella Apps:

Against the tiers in §4, that is covered by roughly four Standard customers. That customer count rests on the total above and is stale with it — recompute both together, once, from real invoices. Recorded as the first concrete input to #216.

Open questions this report does not close

1. Would a baker actually pay? Still unvalidated. Two home bakers who are not us remain the cheapest falsification of everything above (carried over from RESEARCH.md §7).
2. Precise UK market size. The FSA does not publish a home-based food business total. Still open.
3. Planglow's pricing could not be verified.
4. Whether "Stella Apps" is free to use as a name and mark. Needs an IPO and Companies House search before any spend on branding.
5. The single-tenancy blocker (#48) gates all of it. Wrong, corrected 27 Jul 2026: #48 shipped in v0.14.0. The real gates are billing, a separate staging environment (#137), the legal stack and support tooling. See outputs/docs/launch-plan.md for how they are sequenced.

Sources

Regulation and food law

• FSA - Allergen labelling changes for prepacked for direct sale (PPDS) food
• FSA - PPDS allergen labelling changes for butchers
• FSA - Starting a food business from your home
• FSA - 15 years of food hygiene ratings (430,000+ rated businesses)
• FSA - campaign encouraging new food businesses to register (37% home-based since March 2020)
• FoodDocs - What is Natasha's Law (scope by business type)
• FSAI - Allergen information for non-prepacked food (S.I. 489/2014, S.I. 656/2024)
• FSAI - Food Information to Consumers (FIC)
• FSANZ - Plain English Allergen Labelling: one year on
• FSANZ - Allergen labelling for food businesses
• Nutritics - What is PEAL legislation
• FDA - Food allergies and FALCPA
• FDA - Guidance for Industry: food allergen labeling Q&A (Edition 5)
• CFIA - List of ingredients and allergens on food labels
• Health Canada - Food allergen labelling
• Home Fragrance Academy - CLP labelling for candles and wax melts
• Craftiful - CLP label requirements UK makers must meet
• Business Companion - Cosmetic products
• Russell Regulatory Consultants - Cosmetic safety assessments in the UK
• The Vanilla Valley - Food hygiene requirements for UK home bakers, 2026

UK SaaS compliance

• GOV.UK - VAT rules if you supply digital services to private consumers
• AVASK - UK VAT threshold 2026
• ICO - Guide to the data protection fee
• ICO - Data protection fee: what you need to do
• Naq - GDPR small business 2026 UK compliance guide (DUAA dates)
• Go Legal AI - What is a data processor: UK GDPR duties and checklist
• Reed Smith - DMCC subscription rules delayed to spring 2027
• White & Case - Click to cancel: the UK's new subscription contract regime
• Taylor Wessing - Subscription contracts: new regime under DMCCA delayed
• Hiscox - How much does professional indemnity insurance cost
• UK Business Software - Best business insurance for sole traders UK 2026

Providers and platform costs

• Stripe Billing pricing
• We Are Founders - Stripe fees UK 2026
• Finexer - 2026 Stripe pricing analysis for UK businesses
• SaaS Software Tools - Stripe vs Paddle 2026 (merchant of record)
• UI Bakery - Supabase pricing in 2026
• CostBench - Netlify pricing 2026
• BuildMVPFast - Email API pricing comparison, July 2026
• Nuntly - Resend pricing 2026

Competitors

• FoodCore - recipe management pricing
• FoodCore - bakery management software
• FoodCore - allergen management software for UK food businesses, compared 2026
• Planglow - allergen labelling
• BakeOnyx - 9 best bakery software for home bakers, 2026
• BakeOnyx - best software for home bakers, 2026
• BakeMargin - Bake Diary shut down: alternatives in 2026
• Janelle Copeland - Best Bake Diary alternatives for bakers in 2026
• Craftybase - pricing
• Capterra UK - Baking It
• London Business Insider - UK cake sheds business trend

Pricing and conversion benchmarks

• ChartMogul - The SaaS conversion report
• Userpilot - SaaS average free trial conversion rate benchmarks
• Appcues - Free trial conversion rate benchmarks and strategies

Business setup, tax, banking and accounting

• Xero - Sole trader self assessment: how to register and file
• ByteStart - The October 5th Self Assessment deadline
• ByteStart - How to choose a name for your UK sole trader business
• LegalVision UK - Choosing a business name as a sole trader
• LITRG - Trading allowance
• LITRG - Accounts: cash basis
• LITRG - National Insurance for the self-employed
• FreeAgent - Class 4 National Insurance rates 2026/27
• GOV.UK - Extension of Making Tax Digital for Income Tax to sole traders and landlords
• GoCardless - The sole traders' guide to Making Tax Digital 2026
• Forbes Advisor UK - Tide business account review 2026
• Business Expert - Tide business account 2026: fees, eligibility, verdict
• Business Expert - Best sole trader bank accounts in the UK 2026
• Business Expert - Mettle review 2026
• FreeAgent - Free accounting software with NatWest, RBS and Mettle
• Mettle - FreeAgent included with a Mettle business account
• MTD Compare - Crunch pricing 2026
• Best accounting software for UK sole traders 2026, MTD-ready comparison

Market

Last updated 31 Jul 2026

12. Go-to-market channels & market sizing (researched 31 Jul 2026)

Full report: outputs/docs/gtm-channels-research.md (ten sections: TAM/SAM/SOM, online communities, social & creator channels, SEO & content, paid acquisition, email + the PECR/DUAA legal rails, events calendar, partnerships, a phased channel plan mapped to the launch timeline, and follow-ups). Six parallel research passes; almost all evidence is search-extract (the proxy 403'd nearly every direct fetch — caveat stated once at the top of the report). Headlines worth having here:

• Market size, finally bounded (answers old open question 1). UK register ≈ 540k rated / 605k total food businesses (the 430k figure elsewhere was the older rated-only count — corrected in place). TAM = 605k × an assumed 25–40% doing PPDS ⇒ 150–240k businesses, £27–43m ARR at our blended £15/mo. Reachable SAM ≈ 110–190k (home-based businesses modelled at 60–120k active — the FSA publishes no stock total). Realistic 3-year SOM: 1,000–5,000 subscribers = £180k–£900k ARR. Honest read: a lifestyle-to-small-business outcome, not a venture market, and Bake Diary dying at €6.95/mo means the £9 tier alone can't carry the business — the 30%+ on £19+ mix assumption is load-bearing for viability.
• 🔴 Cold email to most of our audience is illegal. Sole traders are individual subscribers under PECR — consent or soft opt-in only; the DUAA (in force 5 Feb 2026) left that unchanged and raised maximum PECR fines from £500k to £17.5m/4%. ICO cases are lost on missing consent records → consent log (timestamp, source, wording) in Supabase from day one. DUAA's one gift: first-party analytics cookies are now banner-free (lost if data feeds advertising) — so Plausible-class analytics, no ad pixels, which also suits the brand: a compliance product must not open with a tracking banner.
• Paid acquisition is not a primary channel at £9–39/mo. SMB SaaS CAC norms are 2–7× our £30–100 allowable CAC. The one paid bet: exact-match Google Search on "allergen label software"/"natasha's law software" at £5–10/day — SERPs show SEO investment but no evident ads (verify in Ads Transparency Center — dashboard-only from a cloud session).
• Every high-value UK baker Facebook group is a coach's funnel (Annie Bennett's Home Baking Business Community UK ~7k, A Bigger Slice, The Cake Business Club, CakeFlix's gated groups). The route in is an admin partnership — guest allergen-labelling masterclass, affiliate cut — not posting. Confirms and extends D-17. Non-baker verticals route through associations: NCASS (⚠️ channel-conflict risk — it bundles its own compliance offering), NMTF (clean, lead here), FRA, craft-butcher bodies. Compliance questions get asked on Mumsnet, r/AskUK, and in the groups.
• SEO flank is open where it matters: FoodCore double-dips the commercial SERPs but ignores the home-baker vertical, farm shops (that SERP is literally Wikipedia), and batch-level traceability — our differentiator story, unclaimed except one blog. "Bake Diary alternative" is the fastest win: orphaned UK/Irish users, every current ranker US/inventory-first, none mention PPDS. Directory listings (Capterra/GetApp/G2/Serchen/SourceForge) are free, rank by themselves, and carry a ~3× AI-citation multiplier; Reddit is the #1 source AI search engines cite. Expect near-zero Google traffic before month 4 of the site. ⚠️ Correction of consequence, 9 Aug 2026: the Reddit finding still stands as research, but Dave dropped Reddit as a channel — so the AI-citation upside it describes is one we have decided not to collect. The directory listings, which carry the ~3× multiplier and cost nothing, are now the whole of this lane. ✅ REVERSED 10 Aug 2026 — the correction above lasted one day. Dave reinstated Reddit and the account exists (u/ProvenBatch, secured; see gtm/social-accounts.md). The AI-citation upside is back on the table, so this lane is directory listings and Reddit again, not directories alone. UK Business Forums stays dropped. Kept rather than rewritten because the sequence is the point: a finding survived two reversals of the decision built on it, which is the argument for recording research separately from the choices made about it. 🔻 FINAL, 15 Aug 2026 — the chain ends here: Reddit is dropped PERMANENTLY (Dave; the account is being deleted, Inoreader with it — both generated work he doesn't have time for). The Reddit finding above still stands as research; the upside is deliberately not collected, and directory listings are the whole of this lane — the 9 Aug correction turned out to be the durable one. Related finding, verified same day against Reddit's own help centre: Reddit closed self-serve API app creation in Nov 2025 ("Responsible Builder Policy" — manual approval, personal-use requests effectively never granted), so automation on the channel was already impossible without an approval Reddit rarely gives. Do not re-add the channel; this supersedes both reversals.
• Creators are nano-scale and already commercial: UK cake-business coaches at 1–10k followers, £20–150/post, with affiliate precedent (CakeFlix 30%, Craftybase 12-month rev-share) → a recurring-commission ambassador scheme fits our price point. YouTube's "Natasha's Law" inventory is stale 2021 institutional video — a current maker-voiced series has no incumbent. The Jun 2025 TikTok Shop allergen scandal is a standing content hook.
• Events: visit, never exhibit (£3–5k/stand vs ~£300 LTV; ROI literature says self-serve low-price products don't pencil). Cake International, NEC, 6–8 Nov 2026 — beta month, an hour away — walk it with beta invite cards. Pre-beta: Speciality & Fine Food Fair (8–9 Sep, ⚠️ date conflicts in listings) and Street Food Business Expo (29–30 Sep, NCASS runs the keynote theatre).
• Partnership rails already exist: High Speed Training runs a public affiliate programme; councils host third-party home-baker guidance (West Norfolk's cake-makers PDF is the precedent for an EHO-signposting ask, start with Buckinghamshire); insurers' cover assumes compliance (CMTIA reachable founder-to-founder); a wholesaler (Pilgrim Foodservice) already markets a Natasha's Law solution to its customers.

Full write-up

From outputs/docs/gtm-channels-research.md

ProvenBatch — Go-to-Market Channels & Market Sizing Research

Researched 31 Jul 2026, six parallel research passes (market sizing · online communities · social & creator channels · SEO & content · paid + email/automation · events & partnerships). Companion to stella-apps-business-research.md (what the market looks like), go-to-market-decisions.md (what we have decided) and launch-plan.md (when things happen). This document says where the customers are and how to reach them. It builds on decisions already made — D-24 (small food businesses generally, never bakery-first), D-17/#218 (beta via Facebook groups + local intros), D-23 (Astro site for SEO), D-02 (£9/£19/£39), D-01 (UK only) — and nothing here contradicts them.

⚠️ Evidence caveat, stated once for the whole document. The agent proxy 403'd essentially every direct page fetch during this research (food.gov.uk, legislation.gov.uk, facebook.com, foodcore.io, ICO guidance pages, YouTube watch pages, ukbusinessforums.co.uk, farmretail.co.uk and dozens more). Nearly every claim below is search-extract evidence — consistent across sources where possible, flagged individually where thin. Good enough to plan against; anything that gates a spend or a legal position should be confirmed by eye first. Individual "[extract-only]" flags are kept where the claim is load-bearing or contested.

0. Headlines — what this research changes

1. Market size is finally bounded (§1). The UK register is ~540k rated / ~605k total food businesses (larger than the 430k in earlier docs — that was the older rated-only count). TAM for PPDS-obligated businesses ≈ 150k–240k businesses (£27m–£43m ARR); reachable SAM ≈ 110k–190k; a realistic 3-year SOM is 1,000–5,000 subscribers = £180k–£900k ARR. Honest framing: a lifestyle-to-small-business outcome, not a venture-scale market — and two load-bearing numbers (the PPDS fraction, the active home-business stock) are still modelled, not known.
2. Cold email to most of our audience is illegal (§6). Sole traders are individual subscribers under PECR, so "B2B cold email is fine" is false for home bakers and market traders. The DUAA (in force 5 Feb 2026) raised PECR fines to UK-GDPR level (£17.5m/4%). Consent-logged, opt-in email only.
3. Paid ads are not a primary channel at £9–39/mo (§5). SMB SaaS CAC norms (£150–550) sit 2–7× above our allowable CAC. The one paid bet with a real chance: exact-match Google Search on "allergen label software / natasha's law software" at £5–10/day.
4. Every high-value baker Facebook group is a coach's funnel (§2). The route in is a partnership with the admin (guest masterclass, affiliate cut), not posting. D-17's "participate first" rule is confirmed and extended.
5. The SEO flank is more open than FoodCore's presence suggests (§4). FoodCore double-dips the commercial SERPs, but the home-baker vertical, farm shops (that SERP is literally Wikipedia), batch-level traceability (our differentiator), and "Bake Diary alternative" (orphaned UK/Irish users, no ranker mentions PPDS) are all winnable now.
6. The creator market is nano-scale and already monetised (§3). UK cake-business coaches run 1k–10k followings and already do affiliate deals (CakeFlix 30%, Craftybase 12-month rev-share as templates). YouTube "Natasha's Law" content is stale 2021 institutional video — a current, maker-voiced series has no incumbent.
7. Visit events, don't exhibit (§7). Exhibiting doesn't pencil at our price point (£3–5k/show vs ~£300 LTV). Cake International, NEC, 6–8 Nov 2026 — the densest gathering of home cake makers in the UK, in our beta month, an hour from Aylesbury — is the one to walk with beta invites.
8. Partnership rails already exist (§8). High Speed Training runs a public affiliate programme; councils demonstrably host third-party guidance for home bakers; insurers sell policies whose cover assumes compliance; a wholesaler (Pilgrim Foodservice) already markets a "Natasha's Law solution" to its customers. These are conversations, not builds.

1. Market sizing — TAM / SAM / SOM

1a. The register (2026 baseline)

⚠️ Correction to earlier docs: RESEARCH.md §2/§11 and the decision register's §E carry "430,000+ FHRS businesses" — that appears to be an older rated-only count. Use ~540k/~605k from here on (corrected in RESEARCH.md §12).

Registration flow: 90,613 new registrations 2023/24 (vs 83,594 in 2022/23), with 20% growth in home-caterer and restaurant/takeaway sectors; H1 2024/25 ran at the same ~90k/yr pace; >39,500 new registrations were still awaiting first inspection as of Feb 2025 (FSA board papers via gov.uk mirror + Food Safety News, extract-only). ~85–90k gross new registrations a year against a slow-growing register implies very high closure churn among new food businesses — which feeds the SOM churn assumptions below.

1b. Segment counts (IBISWorld enterprise counts unless noted, all extract-only)

Bread & bakery production 3,002 (2025) · bakery cafes 1,793 · bakery product retailing 4,310 (2026) · butchers 5,588 (avg 5.5 employees) · delicatessens 1,509 (2026) · cafes & coffee shops 8,403 (plus ~12,400 independent coffee outlets, Lumina 2024) · farm retailers ~1,580 (Harper Adams 2022; FRA cites 1,581) · food & drink manufacturers 12,195, 99% SME (FDF 2025) · new takeaway companies 2023–25 67,293 (Companies House via h2products, soft). No chocolatier or preserve-maker counts were obtained (gap).

1c. Home-based food businesses — modelled, not published

• 37% of 92,540 new registrations since Mar 2020 were from domestic kitchens (FSA campaign via Food Safety News, Mar 2022) — confirms and dates the figure already in RESEARCH.md §2.
• The FSA still publishes no stock total of home-based businesses — re-confirmed this pass.
• Modelled estimate: ~440–460k gross registrations Mar 2020→mid-2026 × ~35–37% domestic ≈ 155–170k gross home-based registrations; applying 40–60% cessation within two years (assumption, justified by the register's slow net growth) ⇒ active stock ≈ 60,000–120,000, central ~90,000. A modelled range, not a fact — the two follow-ups that would replace it with a fact are in §9.

1d. What fraction does PPDS — the load-bearing unknown

The 2019 PPDS Impact Assessment (legislation.gov.uk/ukia/2019/144) would state the official in-scope count; it 403'd on every route and extracts didn't surface the number. Honest gap. What the July 2023 FSA evaluation of Natasha's Law does say (via FSA blog / British Baker extracts): 91% of PPDS businesses aware of the law, 68% say they have the information they need, 26% changed what they sell — 17% moved food out of PPDS entirely, 16% shifted to buying in prepacked; trading standards testing found large minorities in breach (one headline: "half of businesses tested"; FSA 2023–24 testing 17 of 47 items with unlabelled allergens — weakest provenance, verify before quoting). Working assumption: 25–40% of registered food businesses regularly produce PPDS. Everything downstream is sensitivity-tested, not known.

1e. The arithmetic (blended £15/mo = £180/yr assumed: 60% × £9 + 30% × £19 + 10% × £39)

SAM ≈ TAM deliberately: our target list is the whole PPDS-doing micro population — the excluded segments (chains, institutions, mid-size manufacturers) were never counted in.

SOM constraints: (1) only ~48% of micro businesses adopt technology at all (gov.uk/OECD, definition unverified); (2) category precedent — Craftybase "10,000+ makers" lifetime, global; Bakesy "74K+ users" global, free-inflated; Bake Diary "thousands" of UK/Irish bakers at €6.95/mo and it still closed (May 2025); (3) churn arithmetic — at 4%/mo (mid-range SMB benchmark, 3–7%/mo across venasolutions/kalungi/churnkey), steady state = 25 × monthly gross adds, so 40–120 organic adds/month ⇒ 1,000–3,000 subscribers. Anything claiming ≥10% of SAM should be rejected as overclaiming.

Sensitivity: the PPDS fraction halves TAM if halved; the home-based stock dominates SAM; churn at 7%/mo cuts the subscriber base to ~57% of the 4%/mo case. Bake Diary's death at €6.95/mo suggests the £9 tier alone cannot carry the business — the 30%+ on £19+ mix assumption is load-bearing for viability, not just sizing.

2. Online communities — where the owners actually are

2a. The structural finding

Every high-value UK home-baking group is somebody's funnel. The "community" is 4–6 free Facebook groups, each run by a coach selling courses to exactly our ICP:

Implication: don't fight the funnel — join it. Offer admins a free allergen-labelling masterclass (their members' #1 anxiety, our exact ground), an affiliate cut, or free accounts for their paid tiers. One admin partnership beats a thousand promo posts, and it is the only reliable way past their gates. This is how D-17's "participate first" plays out in practice.

2b. Other verticals route through associations, not groups

• Street food / caterers: NCASS (5,000+ members, 11,000+ outlets, ~90% street food/mobile/events [extract-only]) — no public forum; the channel is supplier membership (newsletter inclusion, "approved supplier" badge, discounted ads). Trader groups exist on Facebook (Street food/Food Trucks/Traders/Equipment U.K; Street Food Traders – Mobile Caterers) but peer intel moves through WhatsApp groups run by market organisers — the way in is via the organiser, not the group.
• Market traders: NMTF (~25,000 traders represented, £150/yr sole-trader membership) + a cluster of FB groups (Events Organisers and Market Traders; Markets & Events UK; Connecting Stall Holders & Event Organisers UK).
• Farm shops: no large peer FB group exists; the vertical is the Farm Retail Association (~325 members; the wider population is 1,000+ farm shops/markets).
• Butchers: Craft Butcher International (1,400+ members as of Dec 2020, likely larger), Butchers Collective (supplier-run), National Craft Butchers / Scottish Craft Butchers.
• Chocolatiers/preserves/cafes: UK Chocolatiers FB group; Guild of Jam and Preserve Makers; Coffee Shop Owners UK + Coffee Forums UK's Business Owner subforum.
• No owner-side food-hygiene discussion group exists — compliance talk happens inside the trade groups above, which is exactly where our answers belong.

2c. Forums, Reddit, and where the compliance questions get asked

🔻 FINAL, 15 Aug 2026 (Dave): Reddit is DROPPED PERMANENTLY — do not re-add. The 10 Aug reinstatement is reversed for good; u/ProvenBatch is being deleted. Dave's reasoning: the channel generates work he doesn't have time for. A contributing fact found the same day: Reddit closed self-serve API app creation in Nov 2025, so tooling could not have carried the load either. The §2c answer lane and the §4e AI-citation upside are deliberately not collected via Reddit — Mumsnet, the Facebook groups and the directory listings carry those lanes instead. The research below is kept per this file's rule: it is the priced record of what the decision gives up, not a recommendation. The 9 Aug decision it re-confirms:

🔻 DECISION, 9 Aug 2026 (Dave): Reddit and UK Business Forums are dropped as channels — neither account is being opened. The research below is deliberately kept, not deleted. It is not wrong; it is the evidence for what the decision costs, and without it the next reader re-derives "we should be on Reddit" from scratch. ⚠️ The cost is concentrated in one line: Reddit is the #1 source AI search engines cite (§4e), so the AI-citation compounding is what is being given up. Mumsnet and the Facebook groups are unaffected and carry the answer-content lane instead.

• UK Business Forums (250,000+ members claimed) — the best-codified promo rules found anywhere: self-promo only in the Marketplace section, only for paid Business Members; unprompted DMs explicitly banned. A legitimate paid promo lane + evergreen SEO-indexed answer threads.
• Reddit is a Q&A/SEO channel, not a promo channel: r/AskUK (2.4M) is where "can I sell food from my kitchen?" gets asked as life-admin; r/smallbusinessuk exists; all strictly no-promo. Notably, Reddit is the #1 source AI search engines cite (§4e) — honest answers there compound.
• Mumsnet Talk is the richest open Q&A venue found: "How do you start selling cakes from home?", "Is it possible to make a living as a home baker?", threads already citing the 28-day registration rule and allergen training. Exactly ProvenBatch's answer territory.
• The "do I need allergen labels for my cakes" SERP is currently won by council PDFs (East Suffolk, Reading, West Norfolk, Torbay) and one competitor-adjacent site (Allergen Checker) — a direct content gap (§4).
• Write off: Discord (nothing there), LinkedIn groups (wrong audience — B2B/supplier flavoured), giant global cake-decorating groups (hobbyist reach, no targeting), The Staff Canteen (employed chefs, not owner-operators).

2d. Ranked shortlist (10)

1. The Home Baking Business Community UK — admin partnership (Annie Bennett)
2. A Bigger Slice – The Cake Collective — admin partnership
3. UK Business Forums — paid Marketplace lane + answer threads 🔻 dropped 9 Aug 2026 (and still dropped after Reddit's 10 Aug reinstatement — the paid-membership reason is unaffected)
4. NCASS — supplier membership (street food vertical)
5. Mumsnet Talk — answer content
6. The Cake Business Club + Business of Cake — low-cost admin partnerships
7. Market-trader FB cluster (three groups above)
8. Coffee Shop Owners UK + Coffee Forums business subforum
9. Craft Butcher International + Butchers Collective — small but zero competition for attention
10. r/AskUK + r/smallbusinessuk — no-promo answer content, long-tail credibility

Open item: actual member counts for every FB group need a logged-in Facebook session (~30 min of Dave-side verification).

3. Social & creator channels

3a. The creator landscape is nano-scale and already commercial

UK cake-business coaches (Kate Tynan/The Cake Business Club ~7.4k IG, Karen MacFadyen ~1.2k, Lauren Smy ~0.9k, Emma Stewart, @cakeandbusiness — all [extract-only]) run small but 100%-ICP audiences, and the tier already does software collabs (Castiron, a US baker-software firm, has used Tynan). CakeFlix (52k YouTube subs, 210k members claimed) runs an affiliate programme at up to 30% commission; Craftybase pays a recurring commission for the referred customer's first 12 months. Finch Bakery (157.7k TikTok) — not a coach, but the UK's loudest "bakery small business" voice — has already posted an allergen-labels video citing Natasha's Law: direct proof the topic plays on baker TikTok.

Rates: UK nano (1–10k) £20–150/post; micro (10–100k) £80–1,500/post; video +25–50% (Whito UK 2026 benchmark [extract-only]). At our price point, flat fees only make sense at nano rates — the fit is a recurring-commission ambassador scheme for coaches and podcast hosts, topped with £50-tier podcast sponsorships.

3b. Platform findings

• TikTok/Instagram: the audience self-identifies via #cakebusiness, #uksmallbusiness, #ukcakemaker and day-in-the-life discover pages per trade; TikTok claims 1.5M UK businesses on platform; Swansea Council's market-trader TikTok drew 1.1M views in a year. "Bakesy app review" is an established TikTok search genre — home bakers search app names + "review/how to use", which is how Bakesy (US) grew: organic, non-sponsored recommendation videos from real bakers. The June 2025 TikTok Shop allergen scandal (BBC investigation: sellers listing "spices" as allergen info) is a standing stitch/duet hook — and nobody owns the food-safety-educator seat on UK TikTok.
• YouTube: the "Natasha's Law explained" inventory is almost entirely 2021–22 launch-window content by institutions and vendors (FSA, councils, Brother), not creators bakers follow. View counts were unobtainable (watch pages 403), so the gap is real but unquantified — validate with the first two videos before scaling.
• Street food / farm shop: no creator equivalent exists; the SERP is owned by SaaS/insurer content marketing (Square, Toast, Simply Business, High Speed Training) and the institutional voices are NCASS and Speciality Food Magazine (ABC-certified 8,498 circulation, farm shop/deli readership).
• Podcasts: The Business of Cake Making Podcast (156+ episodes, UK cake makers); My Baking Journey (OLBAA) sells sponsorship "from as little as £50" [extract-only] — the cheapest possible test of podcast spend; NCASS newsletter/podcast via supplier membership; Froghop Food Founders / Food Talk Show for artisan producers. Skip broad UK-entrepreneur podcasts (wrong precision per pound).

3c. Where a solo founder's effort goes first

1. TikTok + IG Reels, one asset set (daily-ish, £0) — the 75-second label-derivation demo is the native genre; post the same vertical video to both.
2. Nano-creator collabs + recurring-commission ambassador scheme (£50–500/experiment).
3. YouTube search-intent long-tail (1–2 videos/month, compounds) — own "allergen labels for cakes UK" the way FoodCore is trying to own the written SERP.
4. Niche trade media & bodies (a few emails, £50–low hundreds) — covers the non-baker verticals TikTok reaches less well.

4. SEO & content

4a. Keyword universe (SERP-density evidence; no volume tool was reachable — do a free Keyword Planner pull before writing)

• (a) Compliance questions — "natasha's law" (FSA unwinnable at #1; commercial-adjacent variants winnable), "PPDS labelling" (council pages are thin PDFs — beatable below the FSA), "14 allergens list" (people pay £2–4 on Etsy for posters the FSA gives away — demand + weak supply), "do I need allergen labels" home-baker phrasing (rankers are cake-supply shops and hobby blogs, no software vendor, FoodCore absent).
• (b) Task keywords — "allergen matrix template" (crowded but all static downloads; rival Paddl already runs the template-magnet playbook; nobody offers a generated, always-current matrix), "recipe cost calculator" (very high demand, US-heavy, nobody ties costing to labelling), "ingredients list generator" (rankers are US/FDA-first with a UK skin — a UK-native generator with bolded allergens is a gap).
• (c) Commercial — "food labelling software UK" / "allergen label software UK": FoodCore holds both a money page AND the comparison listicle (classic double-dip, self-ranking #1 in its own comparisons); other rankers (Nutritics, Kafoodle, IndiCater, InstaLabel) sell to hospitality chains, not micro-producers — positioning gap at the £9–39 end. "Bakery software UK" is directory-dominated (win by being listed, not by blogging). "PPDS label printer": every ranker sells hardware; the software-first "your £30 thermal or inkjet is fine" answer is absent.
• (d) Vertical long-tail — the open flank — cake makers (no vendor owns it), street food (NCASS member-walled; FoodCore has a thin LP), farm shop (the SERP is literally Wikipedia — zero vendor content), butchers, preserves (SERP is all Canva/Avery templates), wedding cakes (only a law firm and a YouTube video rank). Batch-level traceability — our differentiator story — is unclaimed except for one blog (CraftBatch); FoodCore's allergen tracking is recipe-level.

4b. Competitor content operations

FoodCore runs a real two-layer operation: programmatic vertical landing pages (/food-labelling-software, /natashas-law-labelling-software, /market-stall-food-labelling-software, /recipe-costing-software-for-bakeries…) plus self-serving blog listicles ("Allergen Label Software UK", "Best Kitchen Management Software UK 2026"), and is listed on Capterra/GetApp/G2/Software Advice/SaaSworthy. What they don't cover (observed absences): home-baker compliance questions, wedding cakes, farm shops, butchers, preserves, batch-level traceability, enforcement stories, free interactive tools. Their content is comparison-shaped, not fear/answer-shaped. Planglow targets cafés/food-to-go (labels+software bundle; Erudus data partnership); Nutritics is enterprise/hospitality; smaller players to watch: Paddl (template magnets), LabelFood (city programmatic pages), CraftBatch (batch tracking), InstaLabel, Allergen Checker — and, added 24 Aug 2026, AllergenKit (twelve SEO guides on exactly our buyer's keyword set — natashas-law, selling-food-from-home, 5-star-hygiene-rating — plus live free tools; Dave found them organically, so the funnel demonstrably works; full analysis the master competitor sheet).

Content gaps no vendor answers well: "is this specific thing PPDS?" edge cases (cake in a box, wrapped brownies on a stall, pre-orders); "may contain" for micro-producers (councils note blanket disclaimers are non-compliant, nobody explains the right way); compound/hidden ingredients ("what's in your sprinkles"); enforcement reality (a running fines/prosecutions tracker); batch-vs-recipe labelling.

4c. Lead magnets / free tools — exists vs missing

Exists: FSA's dry PPDS decision tool; static allergen-matrix templates everywhere; BakeProfit's no-signup calculators (their whole funnel); US nutrition-first label generators. Missing and winnable: an interactive scenario-based "Is my food PPDS?" checker; a live allergen matrix generator (type ingredients → matrix + hidden-allergen flags); a UK-native label preview generator (bolded allergens, first label free, no signup); a compound-ingredient decoder; a Bake Diary rescue page.

⚠️ Amended 24 Aug 2026 (AllergenKit deep dive): the free-tools gap is closing — AllergenKit now ships a live in-browser allergen matrix builder (click-to-tick, review-dated PDF, saves in-browser, no signup), a one-label-draft label maker and printable charts/posters, aimed at exactly our buyer; FoodCore's four free tools sit at the other end of the market. The pattern is now twice-validated AND first-mover on "live matrix, no signup" is partially taken — which raises the urgency of shortlist items 2 and 4 below and sharpens their spec: ours must generate the matrix from typed ingredients with hidden-allergen flags (the product demo in disguise), not just format hand-ticked boxes, which is all theirs does.

4d. Directories and the Bake Diary vacancy

• Capterra/GetApp/Software Advice basic listings are free (paid PPC from ~$2/click with ~$500/mo floors — skip); G2 reportedly acquired Capterra from Gartner in early 2026 [extract-only — verify], so one profile strategy may now cover both. Serchen UK and SourceForge are cheap incremental listings whose category pages themselves rank for "bakery software UK". FoodCore is on all the majors; ProvenBatch is currently invisible. Week-one job at site launch.
• Bake Diary (closed 31 May 2025, €6.95/mo, mostly UK/Irish bakers, no migration path): the "Bake Diary alternative" SERP is still being freshly contested with 2026-dated posts, and every recommended replacement is US/inventory-first — nobody mentions Natasha's Law/PPDS, which is exactly what the orphaned UK/Irish users need. A /compare/bake-diary page + "Bake Diary alternative UK" post is the fastest revenue per word written.

4e. AI-search visibility (all extract-only, directional)

Reddit is the most-cited source across ChatGPT/Gemini/Perplexity/AI Overviews (🔻 noted, not actionable: Reddit is dropped permanently, 15 Aug 2026); review platforms (G2/Capterra/Trustpilot) carry a ~3× citation multiplier in recommendation answers; third-party-style comparison content is cited ~3× more than us-vs-them pages; original statistics lift citation rates 30–40%. AI referrals are ~1% of traffic but the fastest-growing and convert ~6× better than organic. AI Overviews are squeezing informational CTR (top-1 CTR down ~58% where they appear), so compliance-question posts must be built to be cited (schema, direct answers, original data) while commercial/tool pages carry the revenue.

4f. Realities for a new provenbatch.co.uk + prioritised shortlist

New domains: 3–6 months of suppression; only 1.74% of new pages reach top-10 within a year (Ahrefs via seo.ai); realistic meaningful rankings 6–12 months. This niche is moderately contested — FoodCore is real but young. Expect near-zero Google traffic before month 4; directories and the Bake Diary tail are the realistic signup sources in months 1–3 (Reddit answers — channel dropped permanently 15 Aug 2026).

Top content in priority order (full 15-item table in the research transcript; the load-bearing top eight):

1. "Bake Diary has closed — the UK alternative that does your PPDS labels too" + /compare/bake-diary
2. Interactive "Is my food PPDS?" checker (scenario-based, free, no signup — earns council/blog links)
3. Allergen labels for home bakers & cake makers: the complete UK guide (pillar; no software vendor ranks)
4. Free allergen matrix generator + supporting template post (the product demo in disguise)
5. ProvenBatch vs FoodCore, honest comparison (undercuts £19/£55 with £9; comparison pages get ~3× AI citations)
6. Why your label should come from the batch, not the recipe (differentiator manifesto — nearly empty space)
7. Best food labelling software UK 2026, including our competitors (contest FoodCore's double-dip)
8. "May contain": precautionary allergen labelling for small food businesses (identified gap; also our own open PAL question, RESEARCH.md §4)

Then: market stall/street food PPDS edge cases · farm shop guide (zero competition) · 14 allergens

• hidden-ingredient decoder · "PPDS labels without a £300 printer" · wedding cakes · a Natasha's Law

fines tracker (verify SERP first) · a UK recipe cost calculator tying cost to label. Parallel week-one actions: free listings on Capterra UK, GetApp, G2, Serchen, SourceForge + genuine forum participation (Mumsnet, the Facebook groups — Reddit dropped permanently 15 Aug 2026).

5. Paid acquisition — the verdict is mostly no

5a. Why cold paid fails at £9–39/mo

At £14–15 blended ARPU and 4–5%/mo churn, gross LTV ≈ £175–280, so allowable CAC is £30–100 (3:1). Industry SMB-segment CAC benchmarks run $200–700 — 2–7× our ceiling; sub-$5k-ACV survivors do it with high-volume low-touch PLG, and "outbound economics rarely work" at this ACV. Funnel check: Meta's ~£22 blended cost-per-lead needs ≥22% lead→paid conversion to clear £100 CAC — not plausible from cold traffic. This is the standard "why paid fails at low ACV" result, confirmed across sources.

5b. Channel notes

• Meta: the "small business owner" interest-targeting era is over (interests consolidated Jun 2025, discontinued Jan 2026; detailed targeting now treated as suggestions) — for a niche B2B offer the creative itself must filter ("If you sell cakes at markets…"). Lookalikes from customer lists survive and are the tool indie reports say works. New: Meta charges a 2% UK "location fee" on ads since 1 Jul 2026, billed outside Ads Manager metrics. Benchmarks: CPC ~£0.80–1.60, CPL £20–40 for niche B2B. Realistic test: £300–600/mo for 6–8 weeks minimum — defer until organic proves messages.
• Google Search: UK all-industry CPC ~£1.95; B2B SaaS £3–9. No published CPC exists for "allergen label software"/"natasha's law" — almost certainly low-volume, low-competition long tail (their SERPs are SEO content, not ads). The one cold paid bet worth making: exact-match Search at £5–10/day. Manual check for Dave first (dashboards, no CLI): Google Keyword Planner volumes + adstransparency.google.com and the Meta Ad Library for nutritics.com, kafoodle.com, foodcore.io, planglow.com, brother.co.uk — both 403'd from this session.
• Performance Max: avoid (needs ~30 conversions/mo to learn, treats spam form-fills as wins, cannibalises Search). LinkedIn: no (economics built for $25k deals; audience barely there). TikTok ads: plausible later, organic first (B2B CPL $25–60 reported, 30–50% below LinkedIn — agency-sourced). Pinterest: cheap clicks (~$0.30–0.83), wrong mode (recipe-browsing, not compliance) — at most a £5/day promoted-template test.
• Where paid does fit: (1) exact-match Search as above; (2) retargeting + boosting proven organic posts (£20–50/boost) once the site has traffic; (3) customer-list lookalikes after ~100 customers. Never: LinkedIn, PMax, broad cold Meta prospecting.

6. Email, automation, and the legal rails

ProvenBatch is a compliance product; its own marketing must be visibly compliant. This section separates LAW from TACTICS. (Direct ICO pages 403'd; every legal point below is corroborated across ≥2 independent legal/ICO-derived extracts. The ICO's updated direct-marketing guidance was due Spring 2026 — re-check before the first campaign.)

6a. LAW — marketing email (PECR + UK GDPR + DUAA)

• Consent is the default for marketing email to individual subscribers. No small-business or "it's B2B" exemption.
• 🔴 Sole traders and non-LLP partnerships (E/W/NI) are INDIVIDUAL subscribers under PECR. Most of our audience are sole traders, so cold email to them without consent/soft opt-in is a PECR breach — "B2B cold email is fine" is false for this market. Cold email to limited companies is lawful (identify yourself, honour opt-outs, LIA under GDPR) — which makes cold outreach a manual, Companies-House-checked, low-volume tactic for delis/farm shops at most, not a channel.
• Soft opt-in, exactly (all three, cumulatively): details obtained in the course of a sale or negotiations for a sale; marketing only our own similar products; free opt-out offered at collection and in every message. A trial signup plausibly qualifies as "negotiations for a sale" (practitioner interpretation, not an ICO ruling); a lead-magnet download alone does NOT — put an unticked "send me PPDS tips" checkbox on every magnet form and log it.
• DUAA changes (in force 5 Feb 2026): soft opt-in extended to charities (irrelevant to us); the commercial rules and sole-trader status are unchanged; maximum PECR fines rose from £500k to £17.5m / 4% of turnover. Enforcement lands on ordinary-sized firms (HelloFresh £140k; Allay £120k + ZMLUK £105k in Jan 2026; average PECR fine ~£95k across 49 actions since Mar 2022), and the near-universal root cause is inability to prove consent existed at send time → keep a consent log (timestamp, source, wording) — a trivial Supabase table.

6b. LAW — cookies and tracking

• DUAA created new consent exceptions to PECR reg 6 (5 Feb 2026): first-party statistical/analytics cookies used solely to improve your own service are now banner-free — but the exception is lost if data feeds advertising or profiling (so GA4 is doubtful), even exempt cookies need clear information + a simple opt-out, and Meta/Google ad pixels still require prior opt-in consent. Cookie breaches now carry the £17.5m/4% maximum.
• TACTICS — ship banner-free: Plausible or Fathom (cookieless, ~£7–9/mo, no banner by design); Cloudflare Web Analytics has conflicting evidence on whether it sets cookies [unresolved — test what it actually sets, since we're on Cloudflare anyway]. No ad pixels initially — a compliance product whose site opens with a grudging tracking banner undermines the pitch. Attribute via UTMs + a "how did you hear about us?" signup field + per-channel promo codes.

6c. TACTICS — capture, nurture, lifecycle

• Lead magnets matched to compliance fear: PPDS checklist, 14-allergens poster, label template pack, "Does PPDS apply to me?" quiz, EHO-visit prep checklist. Benchmarks (directional): checklists/templates 20–40% on dedicated pages; quizzes ~40%; one form field beats two (4.4% vs 2.9%); single-CTA pages 13.5% vs 2.5% with 5+.
• Tooling at near-zero cost: keep Resend for transactional (already the stack, D-09); MailerLite free tier (~1,000 contacts, automations + landing pages) or Loops free tier (1,000 contacts, event-driven) for marketing/lifecycle; £0/month to start. Double opt-in ON — not legally required, but it is the consent proof the ICO fines people for lacking.
• Trial lifecycle (5 emails, one behavioural trigger): day-0 welcome with a single activation goal ("print your first compliant label"); day-2/3 nudge only if no label created (targets the documented 72-hour activation cliff — 68% of trials not activated in 72h never convert); day-7 proof/objection (an EHO-inspection story); trial-end-minus-2 with clear pricing; day+3 win-back. Wire off a label_created event. Promotional sends during trial ride the soft opt-in — state it at signup and carry the unsubscribe everywhere.
• Pre-GA list building: value-first content + waitlist 3–6 months ahead (i.e. now — GA is 19 Jan 2027), fed by the community/content work in §2–4, not by paid spend.

Addendum, 30 Aug 2026 (RESEARCH.md §19d has the full pass). The list-building half is now decided: near-term the list lives on our own rails — /beta's updates_opt_in consent into beta_requests, updates-only capture + unsubscribe + campaign sending filed as issues from the content-upgrade session — because a pre-launch list does not qualify for PECR's soft opt-in and our unticked checkbox already collects the explicit consent correctly. When the list outgrows the rails (~250+ subscribers or GA), MailerLite is the pick over Loops: EU data residency + a DPA on every account by default, built-in double opt-in and GDPR forms, free to 250 subscribers/2,500 emails a month, then from $12/mo (its free tier is smaller than the ~1,000 contacts stated above — that figure has aged). Buttondown (API-first, 100 free, ~$9/mo) is the runner-up; Kit cliffs to $39/mo; Mailchimp's free tier is no longer competitive. Adopting any of them is a new sub-processor → a D-12 disclosure change, priced into the decision.

7. Events — visit, don't exhibit

7a. The exhibiting arithmetic

UK shell scheme runs £220–625/sqm; realistic all-in £3,000–5,000 per national show. Trade-show ROI literature is blunt: shows pay off where deal size absorbs the cost, and are explicitly "not worth it for low-value, self-serve products". At ~£300 LTV a £4k stand must convert 13+ paying customers from the stand alone — implausible for v1. 2026–27 answer: visit everything (trade tickets are free-to-cheap), exhibit nowhere national. The only exhibit experiments worth modelling later: a regional show (The Source, £/sqm at the bottom of the range) or FRA conference sponsorship.

7b. Calendar (dates re-verified where flagged; all extract-only)

8. Partnerships & referral channels

Ranked, with the evidence:

1. Food hygiene training providers — High Speed Training first. The market leader in Level 2 e-learning runs a public affiliate programme on Paid On Results (rate not visible), and its Food Hygiene Hub ranks for exactly the searches new food businesses make. Pitch a tools mention/co-content now, affiliate mechanics later. Virtual College publishes a "starting a food business from home" guide — same play. The rails already exist; this is the lowest-effort route.
2. Local authority / EHO signposting, starting with Buckinghamshire. Every customer legally passes through a council page 28 days before trading. Councils overwhelmingly link the FSA, but demonstrably host audience-specific guidance when it exists (West Norfolk's "cakemakers guidance" PDF). The ask is signposting alongside FSA links, and a free tier materially helps. Expect "we can't endorse commercial products" by default; start with one friendly EHO conversation. [KNOWLEDGE-ONLY, verify: the FSA's Safer Food Better Business packs have no software companion — a "digital sidecar to your SFBB pack" positioning is untested but unclaimed.]
3. NMTF before NCASS. Both own their verticals (25k traders; 5k+ caterer members). NCASS has channel-conflict risk (bundles its own compliance offering into membership) — approach as "complements membership", and lead with NMTF, where no competing product surfaced. A member-benefit listing or Young Traders Market sponsorship is the cheapest stallholder route.
4. Non-software label printers & food wholesalers. Planglow proves labels+software bundles sell (they are a competitor, not a partner — and their compliance-fear content marketing validates ours). Pilgrim Foodservice already markets a "one-stop Natasha's Law compliance solution" to its wholesale customers — the proof that wholesalers will carry this message; BFP/Bako-type bakery wholesalers are the analogous targets [unverified]. Plain label printers (e.g. Reflex Labels — PPDS content, print only) are the clean non-competing bundle: "we generate the label, they print the stock".
5. Insurers (CMTIA first). The compliance-condition link is real and sourced: Protectivity's home-bakery liability pays out "provided you have followed safety and hygiene standards" — "your cover assumes you're compliant; here's the tool" is a strong story. CMTIA (market-trader policies £65–110/yr, small Bristol broker) is reachable founder-to-founder for a discount-code swap; Simply Business's content hub is the SEO prize. No precedent of an insurer co-marketing a compliance SaaS was found — treat as experiment, not plan.

Open gaps (search budget): accountants/bookkeepers for food micro-businesses, kitchen-share operators, SFBB distribution detail, affiliate commission rates.

9. The channel plan that falls out, mapped to the launch timeline

Phasing against launch-plan.md (beta invites 23 Nov 2026 · first revenue 11 Dec 2026 · GA 19 Jan 2027):

The one-line strategy: organic and partnerships carry acquisition (communities via admin partnerships, SEO into the vertical gaps FoodCore ignores, nano-creators on commission, councils and trainers as referrers); paid is a £5–10/day exact-match Search experiment and nothing else until ~100 customers exist; and every email practice is consent-logged because our marketing is part of the product's compliance story.

10. Follow-ups that would harden this most

1. Read the 2019 PPDS Impact Assessment (legislation.gov.uk/ukia/2019/144) from a browser — the official in-scope business count is the single highest-value missing number (drives TAM).
2. Query the FHRS open-data API (api.ratings.food.gov.uk, business-type field) from an unproxied machine — real segment counts including mobile caterers and home caterers; or FOI the FSA for domestic-premises totals (drives SAM).
3. 30 minutes logged into Facebook: verify member counts and promo rules for the §2 shortlist.
4. Google Keyword Planner + Ads Transparency Center + Meta Ad Library (all dashboard-only from here): volumes for the §4 keyword set; whether FoodCore/Nutritics/Kafoodle/Planglow run ads.
5. Chase FRA 2027 conference dates and Bakers' Fair 2026 dates; re-verify SFFF (8–9 vs 15–16 Sep) before booking travel.
6. Re-check the ICO's updated direct-marketing guidance (was due Spring 2026) before the first email campaign.

Market

Last updated 20 Sep 2026

31. Where the customers are and how to reach them — acquisition research for the 1 Oct public trial (researched 20 Sep 2026)

Dave's brief: two questions — where are PPDS-obligated small food businesses, and how do we find them lawfully at near-zero cost; and how do we reach them so they start a trial and pay. Nine parallel passes, every claim graded verified / reported / inference, dated and linked. Full write-up: outputs/docs/gtm-acquisition-research-2026-09.md (§C11 is the one-page 90-day plan; §C12 the twenty named leads). Builds on §12 / gtm-channels-research.md and challenges it only where this pass found better evidence:

• The home-based stock has a primary-data anchor. FHRS open data marks a private-address business by a blank address and an outward-only postcode (GOV.UK, 30 Jun 2026). A 14-authority sample (28,163 records, pulled 20 Sep) puts that pattern at 16% of all records and 62–63% of "Other catering premises" / "Mobile caterer"; scaled to the 612,609-record register that is ~95–100k establishments at a private address (±20%) — inside §12's 60k–120k model. The AwaitingInspection rating is in practice the public new-registration feed (9% of records, 18–23% in home-type categories). FHRS holds no email or phone, so it is a targeting and measurement source, not an outreach list.
• FSA Sept 2026 Board: 104,000 new registrations in 2025/26 (+8.7%), ~590k establishments, 36,000 awaiting first inspection. §12 used ~90k/yr.
• Three corrections to what §12 assumed. AllergenKit is live at £9/mo for "cake sheds · home bakeries · market bakers" — the sub-£10 slot is not empty (the 24 Aug deep dive already knew). Pilgrim Foodservice's "Natasha's Law solution" is Planglow's LabelLogic Live via Erudus — an occupied wholesaler rail; the realistic wholesaler ask is an Erudus data integration. High Speed Training's affiliate programme pays outward (20–30% to sites that send HST customers); it is not HST referring to us. Councils and the FSA link no third-party tools (ten pages, zero links).
• The per-trial CAC ceiling does not close. "£6–20 per started trial" only reconciles with the £30–100 allowable CAC at ~20% trial-to-paid; the best opt-in no-card benchmark (ChartMogul with Kyle Poyar, Jan 2026, 200 products, US/global) is 4–6% good, 10–15% great, median 8%. Either activation earns the "great" band or the paid ceiling per trial is ~£1.50–£8.
• ICO direct-marketing guidance is current for the DUAA (updated 28 Apr 2026) and says in its own words that "signing up to a free trial" is "negotiations for the sale" — the soft opt-in covers trial signups if an opt-out is offered at signup and in every message. PECR fines rose to £17.5m/4% on 5 Feb 2026 (SI 2026/82). Recognised legitimate interests do not include direct marketing. Lawful first contact without consent: sole trader — TPS-screened call, letter, in person; Ltd/LLP — the same plus email with identity and opt-out.
• Message. "Fear > time > cost" is half right: fear triggers first-timers; established hand-labellers' live pain is keeping labels correct when packs and recipes change; cost is a barrier to software, not a motive. The missing angle is customer trust — FSS 2023: allergic consumers avoid small outlets ("I would like to buy more locally, but I don't trust them"); FSA Our Food 2023: 17 of 47 PPDS samples had an undeclared allergen, failures "restricted to smaller food businesses" and mostly no label or no ingredients list rather than a wrong list. Never claim hand-written labels are illegal (GOV.UK says they are permitted if legible).
• Referral: ship "give a month, get a month" first (FreeAgent's pattern — vests on the referee's first payment, never during a trial, stacks to a free year), shown on the read-only banner; no cash, no affiliate software (all ≥$39–49/mo). Coach affiliates post-GA at the 20–30%-for-12-months norm (Stocksmith, Xero, CakeFlix).
• Bake Diary's closure is the loudest objection in the buyer's own groups (two weeks' notice, users lost data). Recommendation: publish a wind-down commitment (notice period, export format) on the pricing page.
• Dead leads: Guild of Jam and Preserve Makers (domain redirects elsewhere), Karma Kitchen (domain for sale). Contested SEO gap: BakerInbox (UK) took "Bake Diary alternative UK" on 15 Jun 2026.

Market

Last updated 20 Sep 2026

Where the customers are and how to reach them — evidence-graded acquisition research for the 1 October 2026 public trial

Researched 20 Sep 2026, nine parallel research passes (where businesses are visible · trigger moments · referrers · analogues · message evidence · lawful outreach · trial-to-paid · referral and objections · named leads), synthesised into one document. Companion to gtm-channels-research.md (31 Jul 2026 — the channel map this builds on and does not repeat), metricool-growth-research.md (15 Sep 2026 — the paid-and-social loop) and go-to-market-decisions.md (what is decided). This document answers two questions: where are our customers and how do we find them lawfully at near-zero cost; and how do we reach them so they start a trial and then pay. Everything already known from the July pass is taken as read and only challenged where this pass found better evidence — each challenge is flagged in §0.

How to read the grades. Every material claim carries one of three grades, next to the claim: [verified] = the primary page was fetched and read (or the API/data file was pulled and parsed) on 20 Sep 2026; [reported] = a secondary source or a search extract that was not opened; [inference] = our reasoning from the evidence. [repo] marks a fact taken from a ProvenBatch repository document or the production database — primary for us, but internal. Where something could not be checked it says "not verified" rather than guessing. Dates are the date on the page where one exists, otherwise "undated".

Two limits on this pass, stated once. (1) The session's shared web-search budget ran out part-way through every pass; the second half of each was done by fetching known primary URLs directly, so coverage is deep on official sources and thinner on forum and social quotes. (2) The outbound proxy returned 403/405 on a set of sites (Pilgrim Foodservice, Avery, Brother's blog, British Baker, Etsy's policy pages, the FSA's own alerts site, TPS Online, Meta's Ad Library, several council PDFs); each is named where it matters and listed at the end.

0. Headlines — what this pass changes, and where it contradicts §3 of the brief

1. The home-based stock now has a primary-data anchor. The FHRS open data marks a business trading from a private address by publishing a blank address and an outward-only postcode (GOV.UK guidance updated 30 Jun 2026 [verified]). Applying that test to 14 random authorities (28,163 records, pulled 20 Sep 2026) gives 16% of all records and 62–63% of "Other catering premises" and "Mobile caterer" records [verified, own analysis]; scaled to the 612,609-record register that is roughly 95,000–100,000 UK establishments at a private address [inference, ±20%]. It sits inside the brief's 60k–120k model and should be recorded as its first primary-source check. §A1.
2. New-registration volume is higher than the July figure. The FSA's September 2026 Board paper reports 104,000 new registrations in 2025/26 (+8.7%), ~590,000 establishments and 36,000 premises still awaiting a first inspection [verified]. The July pass used ~90k/yr. §A2.
3. 🔴 Contradiction: the sub-£10 slot is not empty. AllergenKit (allergenkit.co.uk) is live at £9/month, 7-day no-card trial, founding-member price lock, aimed at "cake sheds · home bakeries · market bakers", with free no-signup tools and a concierge "tell Finn one recurring bake" offer [verified]. The repo's own 24 Aug deep dive already records this; the brief's line is stale and should be corrected. §A4.
4. 🔴 Contradiction: Pilgrim Foodservice's "Natasha's Law solution" is Planglow's LabelLogic Live fed by Erudus (Planglow, 7 Dec 2021 [verified]; price £120/yr [reported]). It is an occupied wholesaler rail, not an open one. Booker (Apr 2024) and Bidfood (DayMark plus its own MyRecipes) have likewise chosen. The realistic wholesaler ask is an Erudus data integration, not a co-marketing deal. §A3, §A4.
5. **🔴 Contradiction: High Speed Training's affiliate programme pays *outward*** — 20–30% of order value to sites that send HST customers (Paid On Results [verified]). It is a way for us to earn a few pounds per Level 2 referral, not a way for HST to refer to us. Virtual College (Awin, 10%/5%) is the same shape. §A3.
6. Councils and the FSA do not link third-party tools. Ten FSA, council, growth-hub and CIEH pages read; zero third-party links [verified]. The July pass's "councils host third-party guidance" rail rests on one West Norfolk PDF; treat EHO teams as an audience to make the product legible to, not a referrer. §A3.
7. The trial-to-paid arithmetic in the brief does not close. Allowable CAC £30–100 and "£6–20 per started trial" reconcile only at ~20% trial-to-paid. The best primary benchmark for an opt-in, no-card trial (ChartMogul with Kyle Poyar, Jan 2026, 200 self-serve products) is 4–6% "good", 10–15% "great", median 8% [verified; US/global]. At 4–8%, £6–20 per trial is £75–500 per customer. Either the activation work in §B8 earns the "great" band or the paid ceiling per trial must fall to about £1.50–£8. §B8.
8. The ICO's direct-marketing guidance is now current for the DUAA (updated 28 Apr 2026 [verified]) and its own wording says "signing up to a free trial of your product or service" is "negotiations for the sale" — the soft opt-in is available to us for trial signups, provided an opt-out is offered at signup and in every message [verified]. The Guide to PECR pages are still marked "under review" and the "PECR advice for small organisations" update was listed as Drafting/Summer 2026 with no page found — pending. §B7.
9. "Bake Diary alternative UK" is contested, not open. BakerInbox (UK, £19/mo) published the UK page on 15 Jun 2026; four non-UK sites hold it too; none of them does Natasha's Law labels [verified]. Still worth writing, but it is a differentiated page now, not a vacant one. §A4.
10. Nothing found supports contacting an individual business at a trigger moment. Every trigger with real evidence (registration, calendar, enforcement stories, recalls, marketplace gates) is reachable through a public page, a search result or an admin-approved group post, never a list. The lawful first-contact matrix (§B7) is the same for every source of leads: post, in person, TPS/CTPS-screened calls, corporate email to Ltd companies only, and public replies where the business asked in public.
11. Two named leads in the brief are dead. The Guild of Jam and Preserve Makers domain now redirects to an unrelated site; Karma Kitchen's domain serves a for-sale page [verified]. Both are excluded from §C12.

A. Finding customers

A1. Where PPDS-obligated small food businesses become visible

Bottom line. The one lawful, free, national, daily-refreshed place every vertical becomes visible is the FSA's FHRS open data (612,609 establishments, OGL v3, no API key), and it carries two usable signals: a business type, and the private-address pattern that marks a home business, plus an "AwaitingInspection" rating that is in practice the public new-registration feed [verified]. It holds no email or phone, so what it lawfully enables is targeting and measurement, letters to shop addresses, and in-person visits — not electronic outreach; every other source (council registers, market directories, association finders, platforms) is small, patchy or blocked.

A1.1 Council registration and the FHRS open data

What it is. The FSA publishes hygiene ratings for every local authority as per-LA XML/JSON files and a REST API; "updated daily"; the full dataset held 612,609 businesses on 17 Sep 2026 [verified, https://ratings.food.gov.uk/open-data]. "No sign-up process, API keys, or login details are required" [verified, https://api.ratings.food.gov.uk/help, undated]. Licence: Open Government Licence v3, update frequency "near real-time" [verified, https://data.food.gov.uk/catalog/datasets/38dd8d6a-5ab1-4f50-b753-ab33288e3200]. OGL lets you copy, adapt and "exploit the Information commercially" with attribution, and excludes personal data [verified, nationalarchives.gov.uk/doc/open-government-licence/version/3/]. Cost: free.

Fields per record (parsed from FHRS417en-GB.xml, North Tyneside, extract 16 Sep 2026) [verified]: FHRSID, LocalAuthorityBusinessID, BusinessName, BusinessType, BusinessTypeID, AddressLine1–4, PostCode, RatingValue, RatingKey, RatingDate, LocalAuthorityCode/Name/WebSite/EmailAddress, Scores (Hygiene, Structural, ConfidenceInManagement), SchemeType, NewRatingPending, Geocode. The API adds Phone (empty in every record inspected), RightToReply, Distance [verified, live call 20 Sep 2026]. There is no business email field; the only email is the council's environmental-health inbox. RatingValue includes AwaitingInspection, AwaitingPublication, Exempt and (FHIS) Pass / Improvement Required [verified].

Business types (live from /BusinessTypes/basic, 20 Sep 2026) and how our verticals land [verified counts; mapping is inference from names seen in the files]:

Caveat: type is assigned by the LA and is inconsistent — the same kind of home cake business is 7841 in one authority and 4613 in another [inference from samples]. Any pipeline filters on all of 7841, 7846, 4613 and 7839 (plus 1 and 7844 for cafes) and then classifies by name.

The home-based signal exists and is strong. GOV.UK: "If your business is registered at a private address (for example you are a home caterer), only the first part of the postcode is published… You may give permission for the full address to be published" (guidance updated 30 Jun 2026) [verified, gov.uk/government/publications/food-hygiene-rating-scheme-fhrs-guidance-for-businesses]. So the machine-readable test is address lines empty and postcode outward-only. Applied to 14 random FHRS authorities (Maldon, Darlington, North Yorkshire, Blaenau Gwent, Bristol, Swansea, Cambridge, Newham, Walsall, Bracknell Forest, Spelthorne, Folkestone & Hythe, Bexley, Burnley; 28,163 records; files pulled 20 Sep 2026) [verified, own analysis]:

Per-LA private share ran from ~11% (Newham, Burnley) to ~25% (Maldon, Bracknell Forest). [inference] Scaling 16% to 612,609 gives ~95,000–100,000 establishments trading from a private address, of which ~45,000–50,000 are "Other catering premises" or "Mobile caterer". The pattern also catches some non-PPDS records (childminders, distributors, allotment egg sellers) and misses home businesses that consented to full-address publication — treat as ±20%. This is the first primary-data anchor for the brief's 60k–120k modelled range; report it as such, not as a replacement.

New registrations. The FSA publishes no new-registration list; the register.food.gov.uk privacy notice says the FSA passes details to the LA and "the list of registered food business establishments is published by the relevant local authority", citing Article 113 of retained Regulation (EU) 2017/625 [verified, https://register.food.gov.uk/privacy-notice, undated]. In practice the FHRS AwaitingInspection record is the public new-registration signal: 9.0% of all sampled records, 18–23% in the home-type categories, with a blank RatingDate [verified]. In Charnwood (87 awaiting, 20 Sep 2026) the list read like our customer list — "Elsie's Cakery", "Jessica Blossom Bakes", "Cookie For Thought", "Nom Granola", "shredosmealprep", "Hot Fresh Donuts" — all private-address [verified]. Two API findings: the ratingKey filter on /Establishments did not filter in tests (every variant returned the full count) and there is no sort-by-date-added; to detect new registrations you diff the daily per-LA files on FHRSID (~360 files, a cheap nightly job) [verified].

Can we use it lawfully for outreach? OGL does not licence the personal data inside the dataset, and a sole trader's business name is usually personal data — "If you can identify an individual either directly or indirectly it will constitute personal data even if they are acting in their business capacity" [verified, ICO B2B marketing page]. So processing rests on our own lawful basis (legitimate interests for postal B2B marketing, with the right to object honoured) [inference from the ICO page]. Under PECR, sole traders and ordinary partnerships are individual subscribers: no email, no SMS, and — because the ICO's definition of electronic mail covers "direct messaging on social media" — no social DMs without consent or soft opt-in [verified, ICO electronic-mail guidance]. Corporate subscribers (Ltd, LLP, Scottish partnership) may be emailed with identity disclosed and an opt-out [verified]. Live calls must be screened against both TPS and CTPS [verified]. Post is outside PECR [verified]. Therefore the lawful first contacts an FHRS lead enables are: (a) a letter to a published trading address (shops and units, not home businesses, whose address is withheld); (b) in person at the market or shop; (c) a TPS/CTPS-screened call — but FHRS holds no number; (d) corporate email only after a Companies House match, which most home bakers fail; (e) a public reply where the business asked in public. Full matrix in §B7.

What FHRS is best for [inference]: not outreach but targeting and measurement — choosing LAs and postcode districts for the £150/mo paid plan, counting the home-based stock, seeding per-town SEO pages, and knowing which councils hold the most awaiting-inspection home businesses (the EHO audience). TPS/CTPS costs are reported only (direct licences "from £300" TPS / "from £150" CTPS; third-party checks from £4.25+VAT per 325; Selectabase, Aug 2026 [reported — the TPS site itself did not render]).

A1.2 Council public registers

GOV.UK (updated 25 Jun 2026): anyone who sells, cooks, stores, handles, prepares or distributes food must register with their LA at least 28 days before trading; home-based, mobile and online sellers included [verified, gov.uk/food-business-registration]. Council pages still describe a public register open to inspection — Salford: "A register of addresses and the type of business carried on at each will be open to inspection by the general public" [verified]; Ealing lists name, address, telephone and type "available for inspection by the public" [verified] — but inspection is at council offices and there is no national machine-readable version. A few publish online: North Norfolk (PDF) [verified page; PDF not opened]; Cornwall's "Food Register" dataset on data.gov.uk, OGL, last updated 29 Sep 2020 [verified]. FOI precedents exist (Enfield 2012, B&NES, Westminster on WhatDoTheyKnow) [reported — 403]; councils routinely withhold home addresses under s.40 [inference]. No council publishing a "new registrations this month" list was found. Cost: free. Lawful use: same as FHRS — a shop address at best.

A1.3 Market operators, farmers'-market and food-hall directories

Butcher and fine-food bodies: National Craft Butchers' "Find a Craft Butcher" URL returned 404; Q Guild's member page 403; Guild of Fine Food 403 throughout — not verified.

A1.4 Local-authority "home baker" guidance pages

These are where a new home business reads about PPDS, so they matter for message and for placement, not as lists. North Yorkshire's Food safety pack for home bakers covers registration, SFBB, traceability and PPDS labelling with the 14 allergens in bold [verified, northyorks.gov.uk]; Scottish Borders' pack (25 Jun 2021) links the FSA's PPDS guidance [verified]; Reigate & Banstead and Wigan publish printable packs [verified exist]; King's Lynn & West Norfolk hosts four cake-maker PDFs (allergen guide, checklist, packaging and labelling, cakemaker's guidance) [verified]. None publishes who registered, and — see §A3 — none links a third-party tool.

A1.5 Training providers, insurers, wholesalers

• Training. High Speed Training runs a named case-study series ("The Savvy Baker", 21 Aug 2026; GOAT; Sufra; Waterstones Café W; Taylors of Harrogate) [verified] — a handful of already scaling businesses, not a cohort list. Virtual College: no case-study page (404). NCASS sells Level 1–3 and allergen courses to members; cohorts not public [verified]. Coach graduate showcases: not checked (budget).
• Insurers. Protectivity (knowledge centre, refer-a-friend £25/£25, no community) [verified]; CMTIA (newsletter and blog, no directory) [verified]; Superscript (newsletter; blog Jul–Sep 2026) [verified]; Simply Business (knowledge centre; a 2021 bakery feature now 404) [verified]; PolicyBee (no cake-maker page; food trades absent from its list) [verified]. No insurer publishes customer lists or a community; their blogs are a content-partnership surface (§A3).
• Wholesalers. Bako launched an allergen-checker portal by product code before Natasha's Law (British Baker 2021) [reported — 405]; Pilgrim markets Planglow's LabelLogic Live [reported — 403; confirmed from Planglow's side, verified]; Booker is an NCASS partner deal [verified]; Brakes is an FRA partner [verified]; BFP rendered empty; Bidfood and Costco not checked. None publishes customers; the only visibility a wholesaler offers is physical — trade counters and cash-and-carry car parks, where in-person contact is lawful [inference].

A1.6 Cottage-food marketplaces and ordering platforms (UK reality check)

A1.7 Summary — how findable, how many, how fresh

[inference] Where the effort goes: a nightly FHRS diff (new FHRSIDs in 7841/7846/7839/4613 with the private-address pattern) is the only source that is national, fresh, free and lawful to hold; use it to size, to target the paid search and the launch social, and to feed post-to-shops and in-person market work — not electronic outreach. The market directories choose which markets to walk, not whom to write to.

A2. Which moments make the need acute

Bottom line. The two triggers that are both findable and timely are first council registration (104,000 registrations in 2025/26, roughly a third from home kitchens, every one told by GOV.UK to provide allergen information and expect an unannounced inspection [verified]) and the calendar (the Christmas run, Mother's Day and Easter, Allergy Awareness Week, and 1 October itself — the fifth anniversary of Natasha's Law commencing), because both are predictable and reachable through search and public pages rather than through any list of people. Enforcement stories, ingredient-level recalls and marketplace rule changes are sharper but arrive at random and identify no individual we may lawfully contact, so they are content moments to post on the day, not targeting signals.

Scoring: Findable = can we reach the business at that moment without a list, cold email or DM (1–5); Timely = how close to the moment of need a lawful touch can land (1–5).

A2.1 First council registration — Findable 4 / Timely 3

GOV.UK Starting a food business (updated 19 Aug 2026): register "at least 28 days before you start trading"; "an inspection will be arranged if required", higher-risk first, "some may wait several months", typically unannounced; you must "provide allergen information to your customers", for distance sales "before the purchase of the food is completed" and "when the food is delivered"; keep HACCP-based procedures and supplier traceability records for inspection [verified]. The page does not say PPDS or Natasha's Law in the parts returned [verified, absence]. FSA September 2026 Board, Local Authority Performance Update: ~590,000 establishments (April 2026); 104,000 new registrations in 2025/26, up 8.7%; 36,000 premises awaiting first inspection (6.1%), down from 77,000 in April 2021 but "5,000 premises above pre-Covid levels" [verified]. FSA press release 24 Feb 2022: 37% of new ventures since March 2020 operate from domestic kitchens [verified]. None of four council registration pages read (Oldham, Worcestershire, Brighton & Hove, North East Lincolnshire) mentions PPDS [verified, absence]; Brighton & Hove warns an incomplete SFBB diary "could affect your score" [verified]. What inspectors are told to check: the FSA's Feb 2026 audit of Rhondda Cynon Taf sets out the Code of Practice expectation to "verify incoming traceability and supplier allergen information" and assess labelling, and found the LA's allergen assessments "poor quality" with unsafe samples handled by "low level verbal advice" — "a serious failure" [verified]. So the expectation is that the inspector asks for supplier allergen information and labels; practice is uneven [inference]. Lawful reach: Google at the moment they type "register food business" / "what happens after registering"; council pages; content on "after you register: the four things the inspector will ask to see". FHRS AwaitingInspection in aggregate only.

A2.2 Seasonal peaks — Findable 4 / Timely 3

Dated compliance-calendar events: Allergy Awareness Week 20–26 Apr 2026 (Allergy UK) [verified]; the UK's first National Allergy Strategy launched in Parliament 20 Apr 2026 with recommendations aimed at catering and retail bodies [verified launch; content reported]; Anaphylaxis UK's bake-sale guidance (7 Aug 2025) tells home bakers to label every bake [verified]; 1 October is Natasha's Law's anniversary — the fifth on 1 Oct 2026 [verified]. Sales seasonality: British Baker reports a three-week Christmas period at nearly 10% of annual sales for one bakery and the Oct–Dec "golden quarter" as a "huge slice" [reported — 405]; Google Trends extracts put "birthday cake" at its 2025/26 high in Jan 2026 and "wedding cake" peaking Feb 2026 [reported, weak]. [inference] A hamper is the archetypal multi-item PPDS product (several home-made items in one pack, one label) — the Christmas-run message writes itself.

A2.3 Marketplace onboarding and policy changes — Findable 3 / Timely 3 (4 on the day)

TikTok Shop UK Food and Beverage Listing Guidelines (updated 25 Aug 2026): food is "Invite Only"; sellers must provide Food Business Operator registration (or FHRS rating) and a HACCP plan for manufacturers; "ingredients known to cause allergic reactions must be clearly indicated" on the product page and physical labels, with the 14 allergens highlighted [verified]. The June 2025 BBC investigation (sellers listing allergens as "not applicable" or ingredients as "spices") produced no announced TikTok policy change per CIEH (6 Jun and 3 Jul 2025) [verified]; whether the invite-only gate pre-dates it could not be established [reported]. The FSA's Future of Food Regulation (Sept 2026 Board) puts online platforms under "a dedicated discovery and scoping exercise" with recommendations in 2027 [verified]. eBay UK: register with the LA before selling food; labels must carry name, ingredients, allergens, storage, nutrition, place of manufacture [verified]. Etsy's policy pages: 403 (a search extract says accurate ingredient and allergen listings are required [reported]). Amazon UK: login shell only. Lawful reach: content on "what TikTok Shop's food onboarding asks for and how to produce the label it wants"; our own TikTok channel timed to policy updates; never DMs.

A2.4 Council enforcement stories — Findable 3 / Timely 4, roughly quarterly

Named cases read on the council's own site [all verified]:

Only Oldham is a PPDS-cake case our buyer would recognise as "me"; small-operator fines run hundreds to low thousands; the £36,000 case was a supermarket. The fact that lands is Rasika's: a customer hospitalised because a supplier ingredient was not what the label said — a supplier-declaration failure, which is ProvenBatch's exact ground [inference]. No national enforcement statistics for PPDS since Oct 2021 exist; the FSA's Sept 2026 update says England/NI food standards data is "currently unavailable" [verified]. Non-compliance rates that can be quoted: FSA Surveillance Sampling 2022-23 — 17 of 47 PPDS samples (36%) had undeclared allergens, a fifth of bread products, all PPDS [verified]; Retail Surveillance 2024/25 — bread 26% satisfactory, small FBOs 71% compliant vs 82% for large retailers [verified]; FSA PPDS evaluation (Apr 2023) — 24% not fully compliant, 17% moved foods out of PPDS to avoid labelling, 51% reported higher costs [reported — FSA pages now 410/404; via Roythornes, Oct 2023]. Inquests: Celia Marsh PFD report (7 Dec 2022) called for "a robust system to confirm the absence of the relevant allergen in all ingredients and during production" [verified]; Owen's Law remains voluntary guidance (5 Mar 2025), evaluation due spring 2026, law not before 2027–28 [reported]. Lawful reach: a same-week post via group admins in that borough and on our own channels — "what the Oldham case actually required" — reaches every business there while the story is live; no individual is targeted.

A2.5 The rest, ranked

One forward signal: the FSA's Future of Food Regulation (Sept 2026) names "enhanced registration for all" as a core outcome, with Wales asking to explore "prior approval rather than a right of registration"; consultation June 2027, piloting from Jan 2028 [verified]. If registration becomes a gate, trigger 1 strengthens [inference].

A3. Who already has our customers' trust and could refer

Bottom line. The referrers with real trust and a working "recommend things" habit are (1) cake and food-business coaches and podcasts, who already run 30% affiliate schemes and take guest pitches, (2) insurers' knowledge centres, whose own FAQ wording ("labelled products accurately") is the buying trigger in the insurer's voice, and (3) shared kitchens and council food-enterprise centres, which already publish partner-perk lists and hand tenants to advisers. Councils and the FSA never link third-party tools, the national wholesalers have already chosen a caterer-facing labelling partner, and the trainers' affiliate programmes pay outward — so those three are audiences or data sources, not referrer rails.

Ranking for a solo founder (trust × reach × ease): 1 coaches and podcasts; 2 insurers' knowledge centres; 3 shared kitchens and enterprise centres; 4 NMTF/NABMA (no published partner process — needs a phone call); 5 BIPC. Councils, national wholesalers, trainers and printer brands score low as referrers because each would be asked to change policy rather than add a line [inference]. No UK insurer was found publishing "policy conditions require Natasha's Law compliance" as a formal condition; Protectivity's FAQ is the nearest [verified absence].

A4. What the closest analogues do

Bottom line. The self-serve UK analogues (FoodCore, AllergenKit, Stocksmith) grow on three near-zero-cost levers — free no-signup tools, a large programmatic content and landing-page estate, and a visible solo founder who answers personally — while the enterprise players (Nutritics, Kafoodle, Planglow) grow through wholesaler catalogues, demo-led sales and contract-caterer logos that we cannot and should not copy. Bake Diary's closure (email ~10 May 2025, last day 31 May 2025, no migration tool, domain now dead) is documented in two UK cake-business podcasts and several "alternative" pages, and the two things every replacement rushed to say — "your data is exportable" and "we are still here" — are the objection ProvenBatch must answer in its own copy.

Cross-cutting patterns [verified unless marked]. Every self-serve product with traction runs no-signup tools, and the allergen-matrix builder appears three times (FoodCore, AllergenKit, Paddl) — crowded; a free PPDS label checker ("paste or photograph your label, we tell you what's missing") is offered by none [verified absence; inference that it is open]. Review counts are tiny everywhere (0–25); volume lives in app stores for consumer-style apps. Only Stocksmith publishes an affiliate programme. Paid-ad activity could not be verified for any analogue (Google Ads Transparency is a JS shell; Meta Ad Library 403). No founder interview surfaced for FoodCore, AllergenKit, Bakesy or Bake Diary.

Copyable at near-zero cost [inference on verified facts]: (1) a free no-signup PPDS label checker; (2) Stocksmith's end-of-trial wording plus a "what happens if ProvenBatch closes" page; (3) a UK "Bake Diary alternative" page stating pounds, UK-held data, Natasha's Law labels; (4) concierge first-product onboarding as a public offer (AllergenKit's "tell Finn" made ours); (5) five to seven vertical landing pages including farm shop and butcher, which FoodCore lacks; (6) a factual "vs FoodCore" page — nobody writes one; (7) Erudus purchase-history import for caterers, delis and farm shops; (8) podcast guesting — two UK cake podcasts devoted episodes to a software closure, so software is on-topic; (9) affiliate terms modelled on Stocksmith; (10) directory listings for the badges, expecting no reviews.

Off the table under §4, which the analogues do: bakery-only branding (AllergenKit, Bakesy, BakerInbox); LinkedIn and X (Nutritics, Kafoodle, CompliChef, Planglow); own Facebook groups and group posting (Bake Boost); testimonials before real ones exist (FoodCore, BakeProfit); demo-led funnels with account managers (Planglow, Nutritics); hardware and label lock-in (CompliChef, Planglow).

B. Reaching them for conversion

B5. Message — testing "compliance fear beats time saved beats cost control"

Bottom line. The hypothesis is half right: fear is the trigger for a first-timer and for anyone who has never labelled, but for a business already labelling by hand the evidence (the FSA's own 2019 consultation, competitor users' review language, the 2023 evaluation) says the live pain is keeping labels correct when recipes and supplier packs change — an error-and-time problem, not a fear problem — and cost is a barrier to software rather than a motive to buy it. The angle the hypothesis misses is customer trust: allergic consumers say in the FSS's own research that they avoid small outlets because they do not expect or trust a full ingredients label, and the FSA's sampling shows that when small businesses fail it is mostly because there is no label or no ingredients list at all, not because the list is wrong.

B5.1 What businesses and consumers actually say (verbatim where a primary page allowed it)

Verbatim Facebook, Mumsnet, TikTok and YouTube comments could not be captured this pass (those sites returned 403/404/CAPTCHA and the search budget ran out); the closest primary substitutes are below and the gap is listed at the end.

The numbers that can be quoted [all verified]. FSA Our Food 2023 (8 Oct 2024): 47 PPDS foods sampled, 17 (36%) had an undeclared allergen — "either there was no label present or the allergen was not listed"; "Compliance failures in the sampled products were restricted to smaller food businesses. A high percentage were due to the absence of labelling, or some labelling being present without an ingredients list rather than the ingredients list being incorrect." Allergy alerts: 77 (2020), 83, 83, 64 (2023), 101 (2024); milk the most common undeclared allergen most years; 2024's peanut-in-mustard incident produced 34 alerts across 59 brands (Our Food 2024). Food and You 2 Wave 11 (31 Mar 2026): 23% of adults report a food hypersensitivity; 59% had a bad reaction (up from 42% in 2021). Confidence in allergen information by channel (Wave 2, 2021): cafés/sandwich shops 79%, takeaway direct 63%, delivery apps 50%, Facebook Marketplace 21%. FSA out-of-home research (7 Oct 2025): 87% trust written information vs 75% verbal; 25% "couldn't see allergen information" at their last purchase. FSA SME research (3 Oct 2024): updating written allergen information "may carry costs… meaning they are unable and/or unwilling to do this as regularly as needed". 2019 Impact Assessment: a typical outlet spends "approximately £100.00 annually on labels".

The law, stated so it can be quoted safely [verified from legislation.gov.uk and GOV.UK]. PPDS = "food that is packaged at the same place it is offered or sold to consumers and is in this packaging before it is ordered or selected", including "some food sold at mobile or temporary outlets" (GOV.UK, updated 17 Jul 2026). Failing to comply with reg 10 of the Food Information Regulations 2014 "constitutes a criminal offence" with "a potentially unlimited fine" (FSA technical guidance; level 5 uncapped in England and Wales by LASPO 2012 s85 since 12 Mar 2015; Scotland/NI scales not checked). "May contain" only after a risk assessment finds "an unavoidable risk… that cannot be sufficiently controlled" and "could be considered misleading if it doesn't reflect genuine risk". Labels "can be handwritten" if legible (GOV.UK caterers guide, 17 Jul 2026) — so "hand-written is illegal" is a claim we must never make. No prosecution of a home baker or market stall for PPDS labelling was found; do not imply one.

B5.2 Which framing converts whom [inference on the verified evidence]

Nervous first-timer (home baker, new stall, first market season). They ask "does it apply to me?", "are cupcakes in a box PPDS?", "do allergens have to be in bold?", "will the EHO check?". Framing: acknowledge the fear, then remove the guesswork with facts. Not "you could be fined" (they know; it paralyses) but "here is the rule, here is the label, here is the proof":

• "A cake in a box on a stall is PPDS. The label needs the name and the full ingredients with the 14 allergens emphasised. ProvenBatch builds it from the packs you actually used."
• "Most labelling failures the FSA found in small businesses were missing labels or missing ingredients lists, not wrong lists." (Doing something correct beats doing nothing.)
• "'May contain everything' is not a label; the FSA says it must follow a risk assessment."
• The trial terms as the fear-reducer: 30 days, everything unlocked, no card, read-only at the end, nothing deleted.
• The onboarding promise, because that is where they die: "Photograph the pack; the declaration is read for you." Kafoodle's "long process to set up when filling ingredients yourself" is the objection to pre-empt.

Established business already labelling by hand (Word/Canva/Avery, a Brother or Dymo). They are not afraid; they are tired, and their risk is a stale label. Framing: "The label follows the batch." Change a supplier pack, swap flour brands, add glitter: the label regenerates and the record shows which pack went in. Secondary: "records your EHO can read" and "recall watch against the packs you actually use" (the 2024 mustard incident sat in bought-in ingredients, not recipes). Cost last: "£9 a month, about what the FSA reckons a small outlet spends on label stock in a year." Do not lead with "criminal offence" for this group; the FSS consumer quote about small outlets that "change their ingredients often and don't keep up" is the better mirror.

Revised order: first-timers: fear → resolved by "know it's right"; established: change-proofing (time + error) → customer trust → cost.

B5.3 Message angles per vertical (plain voice; the fact behind each is verified unless marked; the angle's effect is inference)

• Home bakers / cottage bakeries. (1) "A boxed cake, cupcakes in a box, brownies bagged for a stall: all PPDS" (GOV.UK bakers guide 2021; FSS example). (2) "Working from home does not exempt you. Councils are writing to home bakers and cake sheds by name" (Staffordshire TS, Sep 2026). (3) "The decoration is part of the label" (Magic Sparkles; milk the most-recalled allergen). (4) "Stop writing 'may contain all 14'. It is not a label, and allergic customers walk away from it" (FSA technical guidance; FSS quotes). (5) "If you used Bake Diary, this is the sub-£10 slot with Natasha's Law labels built in" (Bake Diary €6.95 [reported], closed 31 May 2025 [verified]).
• Caterers / meal-prep. (1) "Packed lunches, meal boxes, soup in pots and enclosed platters are PPDS; open platters and made-to-order are not" (GOV.UK event caterers guide, 17 Jul 2026). (2) "Thirty-five meals a week with different ingredient lists is exactly the workload manual labels fail at" (2019 consultation: "complexity of ingredient substitution"). (3) "One supplier swap should not mean re-typing every label" (Kafoodle review). (4) "Your customers trust written answers more — 87% vs 75%" (FSA Oct 2025).
• Butchers. (1) "Sausages, burgers, marinated steaks and stir-fry packs packaged before the customer asks are PPDS; loose meat in the counter is not" (GOV.UK butchers guide, 17 Jul 2026). (2) "A butcher's label also needs the meat percentage" (same guide; confirm QUID support before using [inference]). (3) "A regular customer asked her butcher to 'surprise' her with a sausage and had a reaction" (FSS 2023) — a story, not a threat. (4) "Sulphites and rusk are the quiet ones" [inference from practice, not a sourced stat].
• Delis / farm shops. (1) "Cheese, olives, chutneys and cooked meats you portion and wrap before sale are PPDS; sliced to order is not" (GOV.UK introduction and butchers guide; no deli-specific guide exists [verified absence]). (2) "Allergic customers want to buy local and mostly don't" (FSS: "I would like to buy more locally, but I don't trust them"). (3) "Trading Standards may be the inspector here" (Business Companion, Mar 2025: a folded-over bag is prepacked, an open bag is not). (4) "Bought-in prepacked is the maker's label; made-and-packed here is yours" (FSA technical guidance ¶95).
• Cafés / sandwich bars. (1) "Prepacked sandwiches, salad boxes, pots of soup and packaged pies in the chiller are PPDS; the open salad bar and unpackaged cakes are not" (GOV.UK restaurants/cafés/pubs guide, 17 Jul 2026). (2) "Natasha's Law came from a baguette" (NARF). (3) "Cafés are already trusted (79%); a missing label is what breaks it" (Food and You 2). (4) "The FSA's stated worry is small businesses that don't keep labels up to date when the kitchen changes something" (FSA SME research).
• Market stalls / street food. (1) "If you pack it at home and sell it from the stall, it is PPDS. 'Made to order' only covers what you put in a box after they ask" (GOV.UK mobile sellers guide; NCASS). (2) "Trading Standards reminders now name market traders" (Staffordshire). (3) "Buyers trust a marketplace seller far less than a café (21% vs 79%); a proper label closes that gap" (stall ≈ marketplace is inference). (4) "Labels can be handwritten if legible; the problem is forty lines at 6am."
• Chocolatiers. (1) "Milk is the most frequently undeclared allergen in UK recalls" (Our Food 2023/2024). (2) "Hand-packed boxes and bars for a stall, fair or counter are PPDS; a pick-and-mix filled to order is not." (3) "'May contain' must follow a risk assessment, and coeliac and allergic buyers avoid it." (4) "The names inside your couverture — soya lecithin, milk powder, nuts — belong on your label, in the right order" (FIC Art 9(1)(c) via FIR reg 10).
• Preserves / sauces. (1) "Jars filled and sealed before sale are PPDS wherever you sell them; the rule follows the jar." (2) "Sulphites, celery and mustard in chutneys are the quiet ones; mustard was at the centre of 2024's biggest allergen recall" (Our Food 2024). (3) "A recall against an ingredient you bought is your problem too" (FSA incidents 2024/25: labelling and cross-contamination the main causes). (4) "Jars you supply to a farm shop are prepacked, not PPDS — they need the full label, which is the same batch record" [inference on FSA scope].

Phrases the evidence supports: "criminal offence"; "potentially unlimited fine"; "applies to all business sizes, including home-based"; "packaged before it is ordered or selected"; "may contain must follow a risk assessment"; "most small-business failures were no label or no ingredients list"; "87% trust written information". Avoid: "hand-written labels are illegal"; "£5,000 fine" (out of date in E&W since 2015); any home-baker prosecution story (none found); vendor testimonials as proof; "Natasha's Law says…" for anything beyond FIR/FIC.

B6. Channel sequencing for a solo founder — 90 days from 1 October

Bottom line. With roughly ten hours a week and £150 a month, the order is: fix activation first (because the benchmark says 4–8% of opt-in trials pay and the beta says onboarding is where they die), then coach and admin partnerships (the only proven source of beta signups), then exact-match search plus the four pages that catch people at the registration moment, then the Metricool-run social calendar with a reactive trigger routine, then the institutional rails and the referral credit; everything is gated at week four on one measured leading indicator and killed or cut to maintenance if it misses. Nothing here needs daily manual posting or any spend beyond the £150 envelope [inference throughout, built on §A and §B evidence].

Precondition (week 0, ~3 hours, £0): carry utm_*/gclid from the site into the signup record, add the "how did you hear about us?" field, and issue one promo code per partner — without these no channel below can be judged (the 15 Sep Metricool research already says so [repo]).

Total: ~10 hours a week; £100–150 a month. Off the table and not in this table: daily manual community posting, cold email or DMs, exhibiting, any purchased list, any channel outside Facebook/Instagram/TikTok/YouTube.

B7. Lawful outreach mechanics — sole trader vs limited company

Bottom line. For a sole trader (or an ordinary England/Wales/NI partnership) the only first-contact routes that need no prior consent are a live phone call to a number not on the TPS, an addressed letter, and a face-to-face conversation; every email, SMS, WhatsApp or social DM needs consent or a genuine soft opt-in, and the ICO's own example says a free-trial signup is "negotiations for a sale" [verified]. For a limited company, LLP or Scottish partnership the PECR consent rule does not apply to email/SMS/DMs, but you must identify yourself, give a working opt-out, honour it, and satisfy UK GDPR (legitimate interests with an assessment) for any named person's address [verified]. The ICO's direct-marketing guidance is current as of 28 April 2026; the Guide to PECR pages are still "under review" and the small-organisations update is pending.

B7.1 Which guidance is current

DUAA commencement (legislation.gov.uk) [verified]: 19 Jun 2025 Royal Assent; 20 Aug 2025 (SI 2025/904) the definition of "direct marketing" inserted into PECR reg 2 — "the communication (by whatever means) of advertising or marketing material which is directed to particular individuals"; 5 Feb 2026 (SI 2026/82) charity soft opt-in (reg 22(3A)), PECR enforcement moved to the DPA 2018 penalty regime (s.115 + Sch 13) — ICO statement 5 Feb 2026: fines "up to £17.5 million or 4% of global turnover under PECR"; recognised legitimate interests (Art 6(1)(ea)

• Annex 1); cookie exceptions; 19 Jun 2026 remaining provisions. **Recognised legitimate

interests do not include direct marketing** (Annex 1 lists only public-task disclosure, security, emergencies, crime, safeguarding) [verified]; direct marketing sits in Art 6(11) as something that "may" be a legitimate interest — the ICO: "You must still do the three-part test" and "If PECR require consent, you must not use legitimate interests" [verified].

B7.2 Who is an individual subscriber (this decides everything)

PECR reg 2 [verified]: individual = "a living individual and includes an unincorporated body of such individuals" — sole traders and ordinary (E/W/NI) partnerships; corporate subscriber = companies, royal-charter bodies, Scottish partnerships, corporations sole, "any other legal entity distinct from its members" — Ltd, LLP, public bodies. ICO (28 Apr 2026): "individual subscribers (people, sole traders, ordinary partnerships)" vs "corporate subscribers… limited companies, LLPs and Scottish partnerships" [verified]. Scotland: a sole trader is an individual anywhere; only the Scottish partnership differs [verified]. Generic addresses: "The rules… apply even if you only hold a generic or role-based address" — info@ at a sole trader is still an individual's [verified]. "If this is not clear, assume they are an individual." (Guide to PECR, Using marketing lists) [verified]. Practical rule [inference]: without a Companies House entry or "Ltd/LLP" on their site, treat every home baker, stall, jam maker and caterer as an individual — which is the brief's own rule.

B7.3 Route by route

B7.4 Consent wording and the record the ICO expects [verified unless marked]

Wording: an affirmative act ("Silence, pre-ticked boxes or inactivity should not constitute consent"); "the name of your organisation"; "why you want the data"; "what you will do with the data"; "that people can withdraw their consent at any time" and how; "prominent, concise, separate from other terms and conditions, and in plain language"; "a separate opt-in for each" purpose and channel; confirmation of having read a privacy policy is not consent; consent "is specific to receiving electronic mail marketing to a particular number or address". Model wording assembled from those requirements [inference; not an ICO template]:

☐ Yes, email me from ProvenBatch (David Biley trading as ProvenBatch) about PPDS labelling tips, product updates and offers. ☐ Yes, text me the same. You can stop at any time using the unsubscribe link in every email, by replying STOP, or by emailing hello@provenbatch.co.uk. Privacy notice: provenbatch.co.uk/privacy.

Records (ICO "How should we obtain, record and manage consent?" plus the direct-marketing guidance): who (name or identifier); when (dated document or timestamp; for oral consent a note made at the time); how (a copy of the capture form; for oral, the words used); what they were told ("a master copy of the document or data capture form containing the consent statement in use at that time"); withdrawal and when; plus "whether the customer is an individual or a company"; which method applies — consent or soft opt-in ("a simple set of flags or preference fields in your system is usually enough"); the source; channels consented to; objections and opt-outs; a suppression list checked before every send. Refresh: "consider refreshing consent every two years"; third-party consent older than six months is not usable. Privacy information at the point of collection: purposes, sharing, the right to object, and the UK GDPR Art 13 list (identity, lawful basis, recipients, retention, rights, ICO complaint route).

B8. Trial to paid

Bottom line. The best current primary benchmark (ChartMogul with Kyle Poyar, Jan 2026, 200 self-serve B2B products; US/global, so discount it) puts an opt-in, no-card trial at 4–6% trial-to-paid as "good" and 10–15% as "great", median 8% across models; card-required trials run ~5× higher but from fewer signups, so revenue per visitor is similar [verified]. Trial length barely moves conversion in the only randomised experiments that exist, whereas reaching a real first-value event in the first week does, so ProvenBatch's lever is not 14-vs-30 days or a card wall but getting one real PPDS label out of one real product inside the first session, with a done-for-you fallback for anyone who has not photographed a pack by day 2 [inference on verified evidence]. No UK trial-conversion figure exists anywhere found (FreeAgent, Crunch, Xero publish none).

B8.1 Benchmarks [all US/global; verified unless marked]

The circulating "25% / 60%" averages have no traceable primary source (Lincoln Murphy's 2014 post does not contain them) [verified absence]; the "72-hour" activation statistic is unsourced in every page that repeats it — the nearest real evidence is ChartMogul's finding that "conversions peak in week 1" (2,500 companies, 2025) [verified]. Do not quote 25/60 or 72 hours. Trial length: 14 days is 62% of products, 30 days 14% [verified]; the two randomised experiments found a 7-day trial beats 14/30 by +5.59% relative (Yoganarasimhan et al., large SaaS firm) and a 7-day vs 3-day trial had no immediate effect but +20.9% total conversion over two years for a "task-oriented" product (Zhang & Duan 2025, 680,588 users) [verified]. Keep 30 days; treat days 0–3 as the trial that matters [inference].

Activation. Median activation rate 25% (Lenny's 2022, 500+ products); "healthy" 25–35% (Appcues, Jun 2026) [verified]. Method: list 3–5 candidate first-value events, correlate each with 30/60/90-day retention, set a window (most use 7 days), validate by interview [verified]. Checklist completers converting ~3× (Sked Social) and HubSpot's five-actions-in-two-weeks 3× are reported only. Concierge/done-for-you: ConvertKit's free concierge migration is credited with $1.3k → $5k MRR in six months and ~1.5% vs ~5.5% churn for migrated accounts [reported — Failory; Kit's own page 403]; Podia moves "products, courses, and people by hand" free on every plan [verified]; Groove's founder welcome email drew a 41% reply rate [reported]. No controlled measurement of a setup offer at a sub-£40 price exists [verified absence]. Read-only vs lock-out: Basecamp freezes ("data will remain intact, though inaccessible"), Todoist and Notion downgrade to free, HEY recycles the address after 90 days [verified]; no published data compares read-only against lock-out; a read-only end state is functionally a reverse trial, so ChartMogul's 4–6% / 8–12% is the best prior [inference]. Under PECR, service messages are outside the rules but "if your service message has elements that are direct marketing… it will count as direct marketing" [verified].

B8.2 Applied to ProvenBatch's barrier — proposals [inference, built on the shipped product as described in outputs/USER-GUIDE.md]

• Activation definition: a real label produced from a batch of a real product whose recipe uses at least one supplier product with a declaration read from a pack photo, within 7 days of signup ("real" = not the demo data). Instrument the chain the Today card already draws: pack photographed and declaration accepted → recipe with quantities made a Product → batch with packs confirmed → label printed. Report weekly the share reaching each step by day 1/3/7/30. Target ≥30% activated by day 7 and ≥50% of activated trials paying — which at 30% activation is ~15%, the "great" band. Re-run the correlation once ~100 trials have aged past day 30.
• First session — "first label in ten minutes": possible only if the session is scoped to one product and only the packs it needs (typically 4–8). Lead with "Which product will you label first?", take the recipe (typed, pasted or photographed), generate the pack list from the recipe lines and walk the camera through them ("Pack 1 of 6: photograph the flour bag's ingredients panel"). That turns "enter dozens of declarations" into "photograph six packs". Keep the demo off the critical path. Show the label taking shape as each declaration lands (a preview of derivation, not a printable label — it must obey the labelling design document). Make the drop-pile the second door for people who already have pack photos on their phone.
• Lifecycle emails under PECR: at signup an unticked "Send me occasional tips and product news" box (consent; do not lean on the soft opt-in even though it is available — an untick-to- refuse pattern is what the brand said it would not do). Service-only sequence for everyone, each message about the account and free of upgrade pitches: day 0 "Your first label: which product?"; day 1 only if no pack photographed — the concierge offer; day 3 if pack but no label — the exact next step; day 7 on first label — "here's what the EHO can now see", or the concierge offer once more; day 23 and 29 — the existing 7-day and 1-day notices, stating plainly what read-only means; day 30 — the existing read-only notice; day 37 and 60 — one post-expiry note each, then silence. Plan comparisons, annual discounts and feature news go only to the consented cohort. Behaviour triggers over dates; a Supabase scheduled function on the milestone table is enough.
• Concierge wording: "We'll do your first product with you — free, during your trial. Photograph the packs for one product you sell (most need five to ten) and drop them on Today, or email them to your account's receipts address. We'll read them, check every declaration against the pack, and set up the recipe so your first label is waiting for you to approve. Nothing is printed until you've checked it. Usually done the next working day." Offer at day 1 and day 7 to non-activated trials only; cap per week; measure accepted vs declined; automate or stop once the sample says so. Rob Walling's "refund month one if you complete onboarding" is the reserve.
• Read-only end state: "Your trial has ended. Nothing has been deleted and nothing has been charged. Everything you recorded is still here: you can open any batch, view and export any label or record, and show an inspector exactly what went into anything you made. What's paused is new work: recording a batch, printing a label for it, adding a pack. Choose a plan (from £9 a month) and it all resumes where you left off." Past labels and batch records stay viewable and exportable (they are the EHO evidence); reprinting for a new batch is new work and stays paused. Report read-only reactivations at 30/60/90 days as their own funnel line.

B9. Referral and word of mouth

Bottom line. Ship a two-sided "give a month, get a month" credit first — no cash, no affiliate software, no tracking beyond a code in Settings and a Stripe credit — because every cash or commission scheme read (Xero, Tide, Octopus, Stocksmith, Metricool) needs a qualifying period, fraud controls or $39–99/month of tooling, and the only one that fits a solo founder at £150/month is the FreeAgent pattern: a stacking credit both sides earn after the referee's first payment, never during a trial [verified terms; inference on the choice]. Coach affiliates are a post-GA rail at the 20–30%-for-12-months norm; "show this to your EHO" has no precedent of an EHO recommending software, and printed inserts have no evidence at all.

"Show this to your EHO." CompliChef sells a "secure one-time access code… read-only access to your compliance records"; FoodCore's "EHO pack" sits on its £65 tier only; SFBB on GOV.UK (5 Jun 2025) is paper — "Store all your completed diary pages safely until your next visit" [verified]. ProvenBatch already ships Export EHO pack and live inspector access on every active plan [repo]. No story of an EHO recommending software was found. The plausible word-of-mouth unit is the customer showing the pack to the trader next to them — which only works if the pack and matrix are shareable by link, which FoodCore's matrix is and ours is not [repo] [inference]. Printed inserts: no evidence of Avery, Brother, MUNBYN or any UK label-stock seller running partner inserts [verified absence within budget]; the only bundle found is the reverse one (Planglow's software locked to Planglow labels).

What to ship first, and why: every account gets a code and share link in Settings; the referee gets the normal 30-day trial and, when they choose a plan, their first paid month free; the referrer gets one month's credit when the referee's first payment clears; credits stack until the referrer's year is free, then stop (FreeAgent's cap); the beta six earn a month's extension per referral instead. It costs no tooling, a referral is the only social proof available before real reviews exist, and the offer belongs on the read-only banner so the archive state becomes a reactivation path — which neither FoodCore nor Bake Diary did. Second, cheap and complementary: make the EHO pack and matrix shareable by link. Not first: coach affiliates (post-GA; keep CakeFlix 30% / Stocksmith 20%×12 as the template), cash rewards, inserts, "EHO recommends".

B10. Objections and the evidence-backed answer to each

Bottom line. The strongest ammunition is primary and free: the FSA's own text says made-to-order is not PPDS but "in anticipation of an order" is, "may contain allergens" blanket statements should not be used, non-compliance is a criminal offence with an unlimited fine, and Our Food 2023 admits "a significant backlog in the number of food businesses awaiting inspection" — the honest answer to "my council never asks" [verified]. The evidence that an objection is actually voiced comes from our own beta form and in-app feedback, Planglow's customer FAQ and one public Facebook thread on Bake Diary; verbatim forum quotes for "never inspected" and "another subscription" were not captured.

B10.1 Master list (voiced evidence: BF = production beta_requests, 9 rows; IAF = in-app feedback_items; PF = Planglow FAQ, 13 Oct 2021; SCM = Sugar Cookie Marketing Facebook thread, 10 May 2025)

B10.2 The ten most likely objections per vertical (mapped to the master list; the note is the vertical's twist)

• Home bakers / cake sheds: O2, O1, O3, O8/O9, O4, O6, O11, O10, O16, O17. Twist: lead with the shed — self-select from a cabinet is PPDS by the FSA's own example.
• Caterers / meal-prep: O8 (most orders are distance sales: no ingredients list required but allergen info before purchase and at delivery), O12, O1 (they may already pay FoodCore or CompliChef for food safety), O14, O4, O3 (they are inspected more; keep the answer to the offence, not the backlog), O5, O13-style "our kitchen system does it", O11 (staff will use it), O7. Twist: the meal-prep pot in the fridge for collection was "packed in anticipation of an order".
• Butchers: O13, O7 (the FSA's own butcher example), O12 (seasonings, rusk), O3, O1, O10 (scale rolls), O11, O5, O4 (shared mincers — the one place PAL is justified, and it must be named), O15. Twist: the seasoning mix is the recurring substitution risk.
• Delis / farm shops: O8 ("we sell other people's products" — prepacked by another business is not PPDS, ¶95, but your scotch eggs and salads are), O13, O12, O1, O3, O7, O4, O10 (jars, tubs), O5, O11. Twist: split the shelf — bought-in prepacked vs made-and-packed-here.
• Cafés / sandwiches: O14, O9 ("made in front of the customer" is genuinely not PPDS; the grab-and-go fridge is), O1, O10, O11, O3, O4, O12, O5, O7. Twist: GOV.UK's "burger under a hot lamp" example.
• Market stalls / street food: O15, O8, O1 (NCASS/NMTF members already pay memberships), O10 (weather), O3 (a different council every market), O4, O11 (phone-only), O6, O7, O16. Twist: packed at home, sold from "a moveable and/or temporary premises" by the same business is PPDS (¶89(iii)).
• Chocolatiers: O12 (brand substitution — the chocolatier in our pipeline typed it), O1, O4 (nuts and milk — where specific PAL is real), O10 (tiny labels; note the <10 cm² rule, ¶96), O8 (gifting and online), O3, O2 (Canva branding), O7, O11, O17. Twist: per-batch pack tracking is exactly the problem they typed into the form.
• Preserves / sauces: O8 (online sales), O7 ("I make one jam"), O1, O10 (jar labels), O2, O4, O3, O16 (registering across councils for markets), O12 (pectin, sugar), O6. Twist: jars sold at a market by the maker are PPDS; jars supplied to a farm shop are prepacked and need the full label, which the app also handles [repo].

C. The plan

C11. The 90-day acquisition plan — one page, 1 October to 31 December 2026, one founder, ~10 h/week, £150/month

Everything here is [inference] built on §A–§B. The 1 October hook is the fifth anniversary of Natasha's Law commencing; every pitch below leads with it.

Week 0 (before 1 Oct) — measurement and the four assets. Carry UTM/gclid into the signup record; add "how did you hear about us?"; one promo code per partner. Ship the one-product first session and the day-1 concierge email. Publish: "Bake Diary alternative UK", "ProvenBatch vs FoodCore" (facts only), the free no-signup PPDS label checker, and "After you register: what the inspector will ask to see". Claim the directory listings for the badges. Referral code in Settings scaffolded.

Monthly gates. 31 Oct: activation ≥25% or everything else pauses; at least one partner session dated. 30 Nov: cost per started trial known for search and social; one institutional listing live; referral shipped. 31 Dec: trial-to-paid on the October cohort (day-30 aged) — plan on 4–8%, target ≥10%; the decision on whether the £6–20-per-trial ceiling survives is made on this number, not before.

Budget. Google £60–100 · Metricool Starter ~£17 · one boost £25 · travel £30–50 (Nov only) · everything else £0 → £100–150/month. Hours. Activation 3 · partnerships 2 · search and pages 2 · social 1.5 · rails 1 · referral 0.5 → ~10/week.

Not in the plan, by decision: daily manual group posting; cold email or DMs to anyone not a verified Ltd/LLP; exhibiting; any list purchase; Reddit, forums, LinkedIn; testimonials before real ones exist.

C12. The twenty leads to pursue first

All UK, all with 2025–2026 own-site evidence read on 20 Sep 2026 unless marked [reported]. Route column applies §B7: a published business address at a Ltd company, association, public body or publisher is a corporate subscriber; a coach or small operator whose incorporation is unverified gets their own contact form or explicit pitch page, never a cold email. Ranked by trust × reach × ease × timing.

Next five, verified but ranked out for cost or timing: Craft Bakers Association (Industry Supporter packages from £750+VAT; a £200 e-shot to members is the cheap test; Jan 2026 PDF); Scottish Bakers (Allied Trade membership, info@scottishbakers.org, Q1 2027); Dead Simple Accounting ("Accountant for Caterers & Bakers", publishes a tools list — one email); Enterprise Nation (adviser profile £20/mo; partnerships mailbox); Bako (five depots, "In the Mix" newsletter; a pack-data feed in 2027). Excluded as unverifiable or conflicted: NCASS (bundles its own Digital Food Safety System); Pilgrim Foodservice (sells Planglow); Guild of Jam and Preserve Makers (domain redirects elsewhere); Karma Kitchen (domain for sale); Scottish Craft Butchers (DNS); Finch Bakery (a retail brand, not a coach); Reflex Labels (industrial). Anaphylaxis UK and NARF are active and high-trust, but a for-profit's approach to a bereaved family's charity must be a donation or Natasha's Day support first, never a marketing ask — parked until there is revenue.

Decisions worth reopening

None of the §4 decisions is contradicted by anything found in this pass, so none is proposed for reopening. The one number that does need changing is not a §4 decision but a §3 planning assumption: the "£6–20 per started trial" ceiling only holds at ~20% trial-to-paid, and the best opt-in, no-card benchmark is 4–8% (§0.7, §B8). Two adjacent points, stated so they are not mistaken for reopening: addressed post to a business at its published shop address and email to a verified limited company are lawful without consent under the current ICO guidance (§B7) and are not excluded by §4's "no cold email or DMs to sole traders"; they are low-volume, manual routes for delis, farm shops and cafés, not channels.

What I could not find

• Verbatim customer voice. No public Facebook posts, Mumsnet threads, TikTok captions or YouTube comments could be read (403/404/CAPTCHA on every attempt); "takes me hours", "my EHO said", "may contain all 14", "never been inspected", "another subscription" were not captured from customers. The substitutes are our beta form, in-app feedback, the FSA's 2019 consultation, Planglow's customer FAQ, review-site quotes and the FSS consumer research.
• The FSA's PPDS evaluation (April 2023) full chapters — food.gov.uk returns 410; figures rest on the FSA blog, Food Manufacture and Roythornes. Later Food and You 2 hypersensitivity chapters likewise; only the 2021 channel-confidence figures are verified.
• National statistics on PPDS enforcement since Oct 2021 — none published; the FSA says England/NI food standards data is "currently unavailable". No prosecution of a home baker or market stall for PPDS labelling was found.
• Any UK trial-to-paid figure for SMB SaaS; any controlled measurement of read-only vs lock-out, or of a done-for-you setup offer, at a sub-£40 price. The "25%/60%" and "72 hours" statistics have no primary source.
• Paid-ad activity of any analogue (Google Ads Transparency is a JavaScript shell; Meta's Ad Library 403). Follower counts for FoodCore, Nutritics, Bakesy. Any founder interview for FoodCore, AllergenKit, Bakesy or Bake Diary; Bake Diary's founder name and stated closure reason.
• Council or FSA pages linking third-party tools — none in ten pages; the East Suffolk PDF (405) may be the only instance beside West Norfolk.
• Blocked sites: Pilgrim Foodservice (403; its Planglow arrangement is confirmed from Planglow's side), Avery UK, Brother's Natasha's Law blog, British Baker / bakeryinfo (405), The Grocer (405), Etsy's food policy, Amazon UK seller help, alerts.food.gov.uk, TPS Online (empty render), MPS licence costs, WhatDoTheyKnow, Guild of Fine Food, Q Guild, Bury Market, KFMA, NMTF's Market Near Me (522), FSB member benefits (JS), Bizerba and Avery Berkel, Kit's concierge page, Canva's affiliate page, Bird & Bird's "free deals as a sale" article (paywall).
• Not checked (search budget): Cake Shed, Jam Jar, Homemade.io, Orderly, Shoppable and Shopify/Square/SumUp seller directories; Cake Craft Company (verified active only), BakeryBits, Kite, Reflex, Label Bar, Tommy Labels, Sticker Mule, Dymo; Kitchen Table Projects, Cook Space; BFP, Costco, Booker's and Brakes's small-business Natasha's Law marketing (Brakes and KFF PDFs downloaded but no extractor); Levy Market, Geraud, Market Place Europe; Business of Cake, Cake Business School; Xero/FreeAgent partner directories; Monzo Business referral; coach graduate showcases; Etsy's and Amazon's current policy wording; whether TikTok Shop's invite-only food gate pre-dates June 2025.
• Member counts for A Bigger Slice, The Home Baking Business Community UK (7,000+ is an extract), FRA, BSG, CBA; Farm Retail Association supplier-membership price; NMTF partnerships email; OLBAA's £50 sponsorship; Cake International's visitor count; CMTIA's and BBF's emails.
• Pending ICO material: the "PECR advice for small organisations" update (Drafting, due Summer 2026); the promised guidance on the higher PECR fines; TPS/CTPS licence fees.
• One open thread: Safer Food Group's allergy course cites "UK Government statutory guidance published July 2026" — not identified; if real, it is a launch-week content hook.
• The FHRS figures are a 14-authority sample (28,163 records); the ~95–100k private-address and ~55k awaiting-inspection totals are extrapolations, not counts.

Sources

All accessed 20 Sep 2026. R = fetched and read (or pulled and parsed); E = extract or secondary only. Grouped by the pass that used them; a source used by several passes is listed once.

Official — FSA, FSS, GOV.UK, legislation.gov.uk

• FHRS open data — https://ratings.food.gov.uk/open-data (dataset 17 Sep 2026) R · API help — https://api.ratings.food.gov.uk/help (undated) R · /BusinessTypes/basic, /Establishments, /Ratings, /SortOptions, /Authorities/basic (live, 20 Sep 2026) R · per-LA files https://ratings.food.gov.uk/api/open-data-files/FHRS{code}en-GB.xml (17 authorities, extracts 16–20 Sep 2026) R · FSA data catalogue entry — https://data.food.gov.uk/catalog/datasets/38dd8d6a-5ab1-4f50-b753-ab33288e3200 (undated) R · Open Government Licence v3 — https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/ R
• FHRS guidance for businesses — https://www.gov.uk/government/publications/food-hygiene-rating-scheme-fhrs-guidance-for-businesses/food-hygiene-rating-scheme-fhrs-guidance-for-businesses (updated 30 Jun 2026) R · Register a food business — https://www.gov.uk/food-business-registration (25 Jun 2026) R · register.food.gov.uk privacy notice (undated) R and /new landing R · Starting a food business — https://www.gov.uk/guidance/starting-a-food-business (updated 19 Aug 2026) R · Running a food business — https://www.gov.uk/running-food-business R
• FSA September 2026 Board: Local authority performance update — https://www.gov.uk/government/publications/food-standards-agency-september-2026-board-meeting/local-authority-performance-update-food-standards-agency-september-2026-board-meeting R · Future of Food Regulation report — …/future-of-food-regulation-report-to-the-fsa-board-september-2026 (3 Sep 2026) R · Chief Executive's report R · Business Committee report (15 Sep 2026) R
• FSA December 2025 Board: position on the Codex PAL standard — https://www.gov.uk/government/publications/fsa-25-12-05-fsa-position-on-the-codex-precautionary-allergen-labelling-standard-including-allergen-thresholds/… R
• Audit of allergen controls — Rhondda Cynon Taf (9–11 Feb 2026) — https://www.gov.uk/government/publications/audit-of-allergen-controls-and-relevant-open-audit-actions-rhondda-cynon-taf/… R
• PPDS guides: introduction (updated 17 Jul 2026) — https://www.gov.uk/government/publications/introduction-to-allergen-labelling-for-ppds-food/… R · bakers (9 Jul 2021) R · butchers, mobile sellers and street food, event caterers, restaurants/cafés/pubs (all 17 Jul 2026) R · labelling guidance for PPDS (17 Jun 2021) R · Allergen guidance for food businesses (updated 17 Jul 2026) R · technical guidance (23 Aug 2023, updated Mar 2025) R · PAL page — https://www.gov.uk/food-labelling-and-packaging/precautionary-allergen-labelling-pal R · allergen labelling for manufacturers (14 Dec 2017) R · FSA technical guidance June 2020 Part 3 ¶86–103 (PDF mirror at abcfoodlaw.co.uk) R
• Food Information Regulations 2014 regs 10, 11 — https://www.legislation.gov.uk/uksi/2014/1855/regulation/10 R · LASPO 2012 s85 R · Food Safety Act 1990 ss14, 35 R · Regulation 1169/2011 Art 44 R · Impact Assessment 2019/144 (PDF) — https://www.legislation.gov.uk/ukia/2019/144/pdfs/ukia20190144en.pdf R · 2019 consultation outcome (25 Jun 2019) — https://www.gov.uk/government/consultations/food-labelling-changing-food-allergen-information-laws/outcome/summary-of-responses-and-government-response R
• FSA blog, evaluation of Natasha's Law (19 Jul 2023) — https://food.blog.gov.uk/2023/07/19/… R · Surveillance Sampling 2022-23 (22 Feb 2024) — https://science.food.gov.uk/article/127614-… R · Retail Surveillance 2024/25 (26 Jun 2025) — https://science.food.gov.uk/article/140609-… R · Our Food 2023 (PDF, 8 Oct 2024) R · Our Food 2024 (PDF, 19 Jun 2025) R · Annual incidents report 2024/25 (25 Jun 2026) R · Allergen information for non-prepacked foods (7 Oct 2025) — https://science.food.gov.uk/article/142304-… R · SME out-of-home research (3 Oct 2024) — https://science.food.gov.uk/article/123212-… R · Food and You 2 Wave 11 (31 Mar 2026) R · Ipsos, Food and You 2 Wave 2 (10 Aug 2021) R · UK Food Security Report 2024 Theme 5 (11 Dec 2024) R · FSA press release via WiredGov (24 Feb 2022) R · Mustard/peanut guidance (30 Sep 2024) R · Allergy alerts sign-up pages R · School food standards allergy guide (14 Sep 2026) R · SFBB on GOV.UK (5 Jun 2025) R
• FSS PPDS consumer research (PDF, June 2023) — https://www.foodstandards.gov.scot/sites/default/files/migration/downloads/PPDSconsumerresearch_report.pdf R
• ICO: Direct marketing guidance hub and sub-pages (updated 28 Apr 2026) — https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/direct-marketing-guidance/ R · electronic mail guidance (28 Apr 2026) R · live calls guidance (under review) R · Guide to PECR pages (under review) R · plans for new guidance R · DUAA summary (19 Jun 2025) and "what does it mean" (19 Jun 2026) R · statement on commencement (5 Feb 2026) R · charities soft opt-in news (28 Apr 2026) R · "One year on" (23 Jun 2026) R · legitimate interests (23 Mar 2026) R · consent guidance R · right to be informed R · B2B marketing page R
• PECR 2003 regs 2, 19, 21, 22 (as at 5 Feb 2026), 23, 26 — https://www.legislation.gov.uk/uksi/2003/2426/… R · UK GDPR Art 6 and Annex 1 R · DUAA 2025 ss110, 115, Sch 13 R · SI 2025/904 and SI 2026/82 R · Clifford Chance (6 Feb 2026) R · MPS — https://www.mpsonline.org.uk/ R (thin) · TPS Online E (empty render)
• Councils: Salford, Ealing, North Norfolk, Oldham (registration; prosecution 18 Dec 2023), Worcestershire RS, Brighton & Hove, North East Lincolnshire (1 Mar 2022), Haringey, Basingstoke & Deane, Luton, Runnymede, North Yorkshire, Scottish Borders (25 Jun 2021), Reigate & Banstead, Wigan (PDF v2 14 Apr 2021), King's Lynn & West Norfolk, Buckinghamshire, Newcastle (9 May 2025), Pembrokeshire (30 Sep 2025), Barnsley (27 Jan 2026), West Sussex (27 Feb 2026), Hartlepool (4 Mar 2026), South Norfolk & Broadland (7 Oct 2022) — all R · Cornwall food register on data.gov.uk (29 Sep 2020) R · Kent & Medway Growth Hub (10 Feb 2022) R · WhatDoTheyKnow E (403) · East Suffolk PDF E (405)

Charities, trade bodies, press

• Anaphylaxis UK: Celia Marsh PFD (7 Dec 2022), mustard incident (21 Oct 2024), bake-sale guidance (7 Aug 2025), PAL update (4 Sep 2023) R · NARF: Owen Carey inquest, National Allergy Strategy (22 Apr 2026), TikTok coverage (3 Jun 2025), What is Natasha's Law R · Allergy UK Awareness Week R · CIEH press release (6 Jun 2025), EHN (3 Jul 2025), four-step plan (13 Oct 2021) R · Food Manufacture (4 Jun 2025; 2 Oct 2023; 10 Apr 2019) R · Roythornes (2023) R · C&C Solicitors (Mar 2026) R · Walker Morris (3 Oct 2023) R · Business Companion PPDS (Mar 2025) and bread/cakes (Jun 2025) R · A Little Bit of Stone (15 Sep 2026; 11 May 2026) R · Magic Sparkles (13 Sep 2026) R · Labelservice blog (16 Sep 2026) R (claim contradicted) · GeraEats recalls (25 Jun 2026) E · Speciality Food Magazine (advertise page; 1 Oct 2021 article) R · Exhibition News (Cake International) E · British Baker / bakeryinfo E (405) · Google News RSS listings E
• Platforms: TikTok Shop UK F&B listing guidelines (updated 25 Aug 2026) — https://seller-uk.tiktok.com/university/essay?knowledge_id=7753844604159745 R · eBay UK food policy R · Meta commerce policies R · Skilltopia (29 Jan 2026) R · High Speed Training on Etsy (23 Jul 2021) R · Etsy policy E (403)

Referrers, partners, leads (own pages)

• Farm Retail Association (finder, membership, home) R · NMTF (home, /deals, /details, /faq) R · NABMA R · Pedddle R · farmers-market.org.uk R · Stallfinder R · NCASS (home, find-a-caterer, PPDS page, Karma Kitchen pages) R · Nextdoor R · National Craft Butchers R · Q Guild E · Scottish Bakers R · Craft Bakers Association (packages PDF, Jan 2026) R partial · British Sugarcraft Guild R · The Makers Market (home, T&Cs) R · Mission Kitchen R · Encore Kitchens R · Karma Kitchen (for-sale page) R · Broadland Food Innovation Centre R
• High Speed Training (Paid On Results; hub; Savvy Baker case study 21 Aug 2026) R · Virtual College (Awin affiliates) R · iHASCO and Food Alert R · Smart Horizons R · Safer Food Group R
• Protectivity (product page 7 Jan 2026; FAQ; knowledge centre; contact) R · CMTIA R · Superscript R · PolicyBee R · Simply Business (guide updated 31 Mar 2026; US partners page) R · Becca's Bouqcakes blog R
• Dead Simple Accounting R · Livingstones Accountants R
• Brother UK PPDS page R (via curl) · MUNBYN UK R (terms blocked) · NIIMBOT UK R · Avery UK E (403) · Handy Labels E (403) · Good Cake Day R · Cake Craft Company R · OLBAA (uk, us podcast) R; sponsorship price E · Reflex Labels R
• Planglow (Pilgrim article 7 Dec 2021; Booker 11 Apr 2024; pricing; trial form; software page; FAQs 13 Oct 2021; 2021 guide) R · Pilgrim Foodservice E (403) · Bidfood Natasha's Law R · Craft Guild of Chefs (21 Jan 2022) R · Erudus (home, caterers, retailers, wholesalers, integration partners, checklist 20 Sep 2022) R · Bako R · Brakes and KFF PDFs E (no extractor)
• CakeFlix affiliate pages R · Annie Bennett (links, join, contact) R · The Cake Business Club R · A Bigger Slice (login wall) E · The Business of Cake Making (Podbean; Daisy Cake & Co) R · Slice of Success RSS (13 May 2025) R · Janelle Copeland (12 May 2026) R · Sugar Cookie Marketing Facebook post (10 May 2025) R
• Enterprise Nation R · BIPC via Grow London Local R · Buckinghamshire Business First R · FSB E (JS) · Cake International (dates, exhibitor list) R · Anaphylaxis UK / NARF (activity) R

Analogues and trial benchmarks

• FoodCore (home, pricing, about, product, blog, vertical and FAQ pages; Trustpilot; GetApp) R · AllergenKit (home, about, matrix, Natasha's Law) R · CompliChef (.co.uk home, labels, switch; Trustpilot; .com checked) R · Nutritics (home, pricing; Capterra; GetApp; Trustpilot; restauranttools.ai) R · Kafoodle (home, trial request; Capterra; GetApp; Trustpilot) R · Bakesy (home, pricing, resources; App Store GB/US; iTunes lookup API; Google Play) R · Stocksmith (home, pricing, affiliates, compare/bake-diary, blog 31 Mar and 1 Jul 2026) R · Bake Diary (domain check; iTunes/Play search) R; €6.95 E · BakeMargin (20 Feb 2026) R · BakerInbox (15 Jun 2026; pricing) R · Bake Boost R · Crumb Coach (18 Aug 2026) R · Paddl R · BakeProfit R · CakeBoss (+ Capterra) R · Allergen Checker R · Marka R · Castiron E · Cakenote E · Baking It E (403) · Google Ads Transparency (JS shell) and Meta Ad Library (403) E
• ChartMogul/Poyar 2026 conversion report (growthunhinged.com; chartmogul.com reports 1 and 2; Poyar note 4 Feb 2026) R · ChartMogul GTM report 2025 R · Lenny's Newsletter (1 Aug 2023; 25 Oct 2022) R · First Page Sage (5 Sep 2025) R · Ada Chen Rekhi compilation R · Sixteen Ventures (14 Jun 2014) R · Recurly (16 Jan 2025; blog) R · Yoganarasimhan et al. (arXiv 2006.13420) R · Zhang & Duan 2025 (PMC12217587) R · Startups for the Rest of Us ep. 758 (18 Feb 2025) R · Userpilot (two posts, 2026) R secondary · Appcues (4 and 12 Jun 2026) R · Userlist (updated 22 Apr 2026) R · earlystagefounder.com (Groove) R secondary · Mixergy (Groove) R · Failory (ConvertKit) R secondary · Podia /switch R · Poyar reverse trials (29 Jun 2022) R · Basecamp pricing and help R · Todoist help R · Notion help R · HEY FAQs R · Databox (12 Apr 2023) R · Crazy Egg, UserGuiding, Chameleon, 1Capture, Ordway, shno.co R (checked for unsourced claims)
• Referral: FreeAgent T&Cs (3 Feb 2026) R · Xero UK refer-a-friend R · Tide R · Octopus R · SumUp Pay (6 Mar 2026) R · Starling R · Squarespace Circle R · Shopify Affiliates R · Notion Affiliates R · Metricool affiliate R · Canva via linkjolt E · Rewardful, FirstPromoter, Tolt, ReferralCandy, PartnerStack pricing R

Repository and production data [repo]

• outputs/gtm/beta-pipeline.md; production beta_requests (9 completed rows) and feedback_items (10 most recent), read 20 Sep 2026, no personal data quoted · outputs/docs/gtm-channels-research.md · outputs/docs/metricool-growth-research.md · master competitor sheet · outputs/RESEARCH.md · outputs/docs/go-to-market-decisions.md (D-12/D-13) · outputs/USER-GUIDE.md · outputs/gtm/drafts/feedback-for-free-year-definition-2026-09-14.md · outputs/docs/provenbatch-website-content-foundation.md

Market

Last updated 15 Sep 2026

Metricool as the growth engine for the 1 October launch — tiers, ads, and a loop a robot can run

Researched 15 Sep 2026 against app v0.381.0 on production, the live Metricool brand (ProvenBatch, id 6676783, read through the claude.ai Metricool connector that morning), Metricool's own pricing and help-centre pages, xAI's connector and automation pages, and UK ad-cost benchmarks published in 2026 — none of it from memory (AGENTS.md #19b). Where a page could not be fetched it is marked below rather than filled in. Deliverable: this document plus four one-page decision memos in outputs/gtm/drafts/ dated 15 Sep 2026. RESEARCH.md §28 carries the headlines. Nothing here was built, bought, scheduled or spent: every action needs Dave's word (AGENTS.md #10 shape).

✅ Status update 15 Sep 2026 (Dave): brand ProvenBatch (6676783) is now on Starter monthly. The Free 20 posts/month wall no longer applies. Historical Free-plan notes below remain as of the morning research read; treat Starter as current for ops.

The question, as Dave put it (15 Sep): how do we maximise Metricool to grow ProvenBatch fast from the 1 October public free-trial launch, as autonomously as possible, with Grok orchestrating, considering every Metricool tier, products and services we are not using yet, and ads — wherever ROI can be forecast. Dave's framing for the answers: paid channels are fully reopened (the 14 Sep Google-only decision is on the table), the forecast plans against ~£150 a month all-in for the first 90 days, and weekly batch approval is the ceiling on autonomy.

0. The answer in one page

1. Stay on Metricool Free until a specific wall is hit, then go straight to Starter (~£14–17/mo). Of the four tiers, Starter buys the only three things we would actually use — unlimited posts (Free is 20/month; the queue is already running at ~15 a fortnight), unlimited analytics history (Free keeps 30 days, which means the launch baseline is lost by November), and Flows once it becomes a paid add-on. Advanced (~£37–46/mo) adds the post-approval workflow, Looker Studio, API and Metricool's hosted MCP — none of which we need, because the claude.ai Metricool connector already works on the Free plan (verified 15 Sep: brand settings, scheduled posts, analytics, best-time all returned; only the review-mode create returns 403). §2.
2. Nothing can be judged on ROI until two measurement gaps close, both cheap and cookieless: the Cloudflare Web Analytics toggle (D-27 already sanctions it) and carrying the utm_*/gclid parameters the site already forwards into the app's signup record. Today the site sees only a click that leaves for the app; the app sees a business with no origin. That gap makes every channel below worth exactly £0 on paper. §4.
3. Paid, reopened and modelled: Google exact-match Search stays the first bet, a £25 Meta boost of the best launch-week Reel is the second, and a one-week TikTok Spark Ads test is the third — all inside £150/month, in that order, each with a cost-per-started-trial gate. The economics have not changed since 31 Jul: allowable CAC £30–100, so at a 10–20% opt-in trial→paid rate the most we can pay for a started trial is roughly £6–£20. Anything over £40 after £100 spent is killed. Meta conversion campaigns and anything needing a pixel stay off until the consent question (#1822) is decided. §5–§6.
4. The autonomous loop is one Grok automation firing twice a week against one approval card: Monday it drafts the coming week (posts, ≤2 trend ideas, one boost candidate, last week's numbers, ads against their kill rules) and delivers a single card in Charlie/Grok chat (the delivery surface since 19 Sep 2026); Dave's ✅ / ✏️ / ❌; Tuesday's fire schedules the approved batch live in Metricool. Metricool's own automations (Autolists for evergreen recycling, best-time slots, a Flows keyword that DMs the trial link) do the rest. What it cannot do yet: Grok holds no Metricool connector. Adding Metricool's hosted MCP as a Grok custom connector is a ten-minute test; if it 403s on Free, that is the Advanced trigger, or the existing Claude growth routine stays the Metricool executor. §7.
5. The repo is stale on Metricool in two places, corrected today: the queue is not drafts (15 posts 15–27 Sep, autoPublish: true, draft: false), and the brand carries three connected ad accounts — Facebook Ads act_1804831247189540 (the repo names a different id), Google Ads 9992474342, and TikTok Ads 7670576612999725072 (nowhere in the repo). §1.

Ceiling check. Starter Metricool (~£17 monthly) + Google (~£60–100 actual, volume-limited) + one boost (£25) + generated b-roll clips (~£12) ≈ £115–155/month. A TikTok Spark week (£140 at the £20/day ad-group minimum) only fits by pausing Google that week. The larger options — Meta conversion campaigns at the £300–600/month test floor the July research cites — are modelled in §6 as gated escalations Dave would have to fund separately.

1. Where we are on 15 Sep 2026

1a. The live brand, read this morning

So the ad-account plumbing the 14 Sep memos list as "need from Dave: Meta ad account" is at least partly done: all three networks' ad accounts are connected to the Metricool brand. Whether the accounts hold a payment method is not visible from the API and remains Dave's to confirm.

1b. The queue is live, not drafted

getScheduledPosts (15 Sep–31 Dec) returned 15 posts, 15–27 September, every one autoPublish: true, draft: false, created 14 Sep 12:57–12:58 by social@stellaapps.com. Nine are Instagram Reel + TikTok pairs (three of them also YouTube Shorts), four are Facebook-only text posts, four are YouTube uploads on 18 Sep (overview, walkthrough, vertical overview, longform). Every caption closes "Opens 1 October. provenbatch.co.uk/trial". One extra row dated 31 Dec is a draft placeholder reading "[DROPPED — missed 14 Sep 08:28 slot; Charlie 15 Sep. Do not publish.]".

This supersedes three repo claims at once: HANDOVER's "Posts are live as drafts; nothing publishes while drafted", the metricool-drafting skill's "review mode only — this skill never takes a post out of draft", and the 30 Aug beta-line rule (the queue now uses the 14 Sep amendment (e) pre-launch line, correctly). The HANDOVER paragraph is corrected in the same commit as this document; the skill is not edited here (documents only), but §7 says what it should say.

Nothing is scheduled after 27 September. The launch week itself — 1–7 October — is empty in Metricool. That is the first thing the loop in §7 has to fill, and it is why the loop needs to exist before 1 October rather than after.

1c. The 30-day baseline (15 Aug – 14 Sep, getAnalyticsDataByMetrics)

The numbers a launch will be measured against. Small, and worth writing down precisely because the Free plan's 30-day history means they will be unreadable after mid-October unless exported.

Read: TikTok is already the reach channel by an order of magnitude — one Reel/TikTok pair on 24 Aug did 816 TikTok views against 160 on Instagram; Facebook is the credibility surface the July research predicted (people look, few interact); YouTube is search inventory that compounds slowly. getBestTimeToPostByNetwork for TikTok (7–14 Sep) peaks at 10:00, 12:00 and 18:00 UK on Wednesday–Friday, with the weekend a clear trough; for Instagram it returns all zeros — the account has too few followers for Metricool to compute anything, which itself says the 19:00–21:00 slots in social-content.md §3 are a guess and TikTok's measured slots should lead.

1d. What the MCP actually does on the Free plan (empirical, 15 Sep)

Metricool's own MCP marketing page says access "requires the Advanced plan or higher". The claude.ai connector evidently does not enforce that on reads or plain creates. Do not build on the assumption it stays that way — the loop in §7 keeps a fallback — but do not pay for Advanced to get something we already have.

1e. The skill contradiction, for the record

.claude/skills/metricool-drafting/SKILL.md mandates createScheduledPostForReview only; .claude/skills/social-video/SKILL.md (and the removed meme-video experiment README) say the Free plan refuses that flow and to use draft: true. The second is right on Free. The 14 Sep batch used neither — it scheduled live. Whichever autonomy model Dave picks (memo 4), the drafting skill's "never take a post out of draft" line is already untrue of the queue and should be rewritten to describe the batch-approval loop.

2. Metricool tier map — what each tier buys us

Prices from metricool.com/pricing (fetched 15 Sep; the page bills in EUR/USD, GBP figures below are approximate at €1 ≈ £0.86 and are not what the invoice will say). Per-brand prices are the smallest brand count on each tier; we are one brand.

Now the same table from our side. The rule that prunes it is AGENTS.md #18 — Facebook, Instagram, TikTok, YouTube and nothing else — plus #12 (no robot replies to customers) and D-27 (no Metricool tracker on the site, no SmartLinks).

Verdict: Free until the October post cap bites (it will), then Starter monthly (~£17, cancel any month), not annual, until trial→paid is known. Advanced only if the Grok connector test fails. Custom never.

3. The organic engine — what Metricool should run for us

The 31 Jul and 30 Aug research already settled the content shape (short-form, chaos-first, product at the reveal, 2 posts a week beats a blitz, TikTok 21–34s, burned captions, first 1.5 s decide). What was not settled is what Metricool itself automates. Four things:

1. Cadence and slots from measured data, not the calendar file. TikTok's own best-time curve (§1c) says Wed–Fri at 10:00 / 12:00 / 18:00. The loop asks getBestTimeToPostByNetwork every Monday and places the week's pairs on the top three slots; Facebook text posts go out at 19:45 as now (its curve is unmeasurable); YouTube uploads midday Thursday (search inventory, timing matters least).
2. Two lanes of content, one of them recycled. Lane A is new material: two Reel/TikTok pairs a week from the social-content.md library and the trend intake (≤2 [trend] ideas, already the drafting skill's rule). Lane B is evergreen: the PPDS / "may contain" / HACCP explainers are true for years. An Autolist holds them as a circular list at one slot a week per network, so the feed never goes quiet when Lane A is thin (Cake International week, Christmas). Every Autolist item must carry the current CTA line — the 13 Aug stale-legal-claim lesson applies doubly to a list that republishes itself, so the loop re-reads the list monthly against the source file.
3. Trending audio at publish time, never baked in (the two-lane rule in media-and-social.md): Instagram via audioConfiguration (read back the resolved title — the resolver fuzzy-matches), TikTok via the Commercial Music Library at direct-post.
4. One Flows keyword per campaign. "Comment LABEL and I'll send you the link" is the highest- converting CTA pattern on Instagram in 2026 because a comment is cheap and a DM is personal. Metricool's Comment → DM template does: optional public reply (≤300 chars) → first DM asking for a reaction (opens Meta's 24-hour window) → follow-up DM carrying the link with a button. Sends, interactions and CTR are reported per flow. Decision for Dave (memo 4): the DM text is his, fixed, reviewed once; the trigger is the viewer's. If he says no, the CTA stays "link in bio".

Cost of the organic engine per month: Metricool Free/Starter £0–17; generated b-roll clips ~$0.35–2.80 each, two a week ≈ £8–15; narration inside an existing plan; app footage from the mobile harness free. ≈ £10–35/month. (1 Oct 2026, #2988: the b-roll and narration vendors used for these figures are closed; both lines need a replacement tool.) Everything else is robot time.

What organic can plausibly deliver by December, from the §1c base: TikTok grew from 0 to ~3,100 monthly views in five weeks with eleven videos and no follower base. Holding the cadence and adding Flows, a 3–5× view growth by December is the range the July research's "nobody owns the food-safety-educator seat" finding supports, i.e. 10–15k TikTok views/month, 1–2k Instagram, ~1k Facebook page views — and at a 1–2% profile-to-link rate and 5–10% link-to-trial, that is roughly 5–20 started trials a month from organic alone. It is a forecast, not a promise; the loop's Friday numbers replace it with a measurement within three weeks of launch.

4. Measurement — decision 0, because nothing else can be read without it

Today, deliberately (D-27), the marketing site has no analytics at all; the Google Ads tag is shipped dormant (ADS_TAGS_ENABLED = false, #1822); the site can witness only trial_start_click (launch.js, "the account creation itself happens in the app and is not observable from here"); the app records a business with no origin; and beta_requests.heard_via — the self-reported "how did you hear about us" — retires with /beta on 1 October. So on 2 October we will know how many trials started and nothing about where any of them came from.

Three fixes, ordered by cost and by whether they touch PECR:

A cookieless alternative to M3 for Google exists and is enough at our volume: with M2 storing gclid at signup, conversions can be imported into Google Ads offline (Dave uploads a CSV of gclid, conversion time weekly, or the loop prepares it) — no tag, no banner, and the exact-match campaign still learns which keywords produced trials. Meta has no equivalent without a pixel or CAPI, which is one more reason Meta stays at "boost for reach" rather than "campaign for conversions" in this window.

Recommendation: M1 today, M2 as the one small build this research asks for before 1 October, M3 deferred until trial→paid is measured and the consent question is worth its cost. Memo 2.

5. Paid acquisition — reopened, and modelled channel by channel

5a. The economics that bound every channel (unchanged since gtm-channels-research.md §5a)

Two consequences. First, the 14 Sep kill rule of "> £40 per trial after £100" is generous by a factor of two to four against these economics — it is a stop-the-bleeding rule, not a this is working rule; the continue gate has to be ≤ £20 per started trial and the scale gate has to come from measured trial→paid, not from clicks. Second, at £150/month the whole paid budget buys roughly 5–25 started trials a month if a channel performs at its best case, which is the same order as organic (§3). Paid is a supplement and a learning budget in this window, not the engine.

5b. Channel benchmarks, UK, 2026 (fetched 15 Sep — each row's source in §10)

5c. Per £100 of media — forecast started trials and cost per trial

Formula: clicks = £100 ÷ CPC; trials = clicks × click→trial; cost per trial = £100 ÷ trials.

Against the £6–20 ceiling in §5a: only the best cases clear it, and only Google's mid case comes close. That is the honest reading and it matches the July verdict — paid at this ACV is a learning budget until something (landing conversion, creative, trial→paid) proves better than the benchmark. The gates below are how the loop finds out cheaply.

5d. Gates the loop applies every Friday (per channel, on M2's attributed numbers)

6. ROI model — the three months after launch

Assumptions: Starter Metricool from October (£17 monthly), generated b-roll ~£12/month, ARPU £14, mid case for every channel unless stated, trial→paid 15% at month 3, no churn inside the window (it is too short to matter). Organic trials from §3's range at the low end. Costs are cash; time is not costed. All figures are forecasts to be replaced by the Friday numbers.

6a. The recommended plan inside £150/month

Payback. 5–8 paying at £14 ARPU is £70–112 MRR against ~£430 spent: 4–6 months to recover the quarter's cash, inside the 22-month expected lifetime, so ROI-positive on the July LTV — and that is at mid-case throughout. It also crosses the July research's break-even of 8 Starter or 4 Standard customers for the fixed cost base only at the top of the range. Growth "fast" in this window means tens of trials, not hundreds; the levers that change that are trial→paid (product, not marketing) and organic reach compounding (Flows, TikTok cadence), not the £150.

6b. The gated escalation ladder (Dave funds it or it does not exist)

7. Autonomy and orchestration — the weekly loop

7a. What may run without a human, and what may not

7b. The loop, on the pattern the digest already proves

The beta-updates-digest Grok automation (11 Sep 2026) is the proven shape: a scheduled fire reads the repo and the database, delivers one card in Charlie/Grok chat, and a later fire reads Dave's ✅ / ✏️ / ❌ in that chat and fulfils. Automations cannot be triggered by a reply, only by schedule (or email on SuperGrok), which is why fulfilment is a second scheduled fire.

Caps, in the jobs.json style: 1 card per draft fire; ≤ 8 posts scheduled per fulfil; ≤ 2 trend ideas; ≤ 1 boost recommendation; £0 of spend changed by the routine, ever. Decision kind social_ref already exists.

7c. Who runs it — the one open technical question

Either way: Grok's TUI scheduler_create is not a Routine (7-day, session-scoped — claude-to-grok-transfer-research.md §2) and must not be used for this. Grok Bot, the separate agent app, is not required: xAI's scheduled Automations are the product the digest runs on, and sources conflict on Grok Bot's price ($200/month standalone versus bundled with SuperGrok) — verify at x.ai before assuming either.

7d. Before 1 October, in order

1. Dave: M1 toggle; the G1 connector test; the Flows yes/no; the tier yes/no (memo 1, 2, 4).
2. A session: ship M2 (one small app issue, to be filed only if Dave says so — this research files nothing); rewrite the drafting skill to the batch-approval loop; register the routine in jobs.d/; export the §1c baseline JSON to the repo before it ages out.
3. The loop's first Draft fire: Monday 28 September, filling 1–7 October — launch-week copy switches from "Opens 1 October" to "Start your free 30-day trial" (launch.js flips the site at 00:01; the queue does not flip itself).

8. Products and services we are not using — considered, with a verdict

9. Recommendation and the 90-day calendar

Do, in this order:

1. Measurement first (memo 2): M1 today; M2 before 1 October; M3 deferred.
2. Metricool Starter monthly in October (memo 1), Free until then; nothing above Starter unless the Grok connector needs it.
3. The paid mix inside £150/month (memo 3): Google exact-match at an £8/day cap from 1 October, one £25 boost of the best launch-week Reel in week two, a single TikTok Spark week in November only if Google under-spends, every channel on the §5d gates. This supersedes the 14 Sep Google-only decision by adding the boost and the Spark test; it keeps Meta campaigns off.
4. The Grok-orchestrated weekly loop (memo 4): first Draft fire Monday 28 September; Flows keyword if Dave accepts the fixed DM; Autolist for the evergreen lane.

10. What this research did not do, and follow-ups

• Did not test the Grok custom connector against Metricool's MCP — Dave's grok.com account is needed. It is the single fact that decides G1 versus G2 and Free versus Advanced.
• Did not read Google Keyword Planner (dashboard-only, as the July research already noted); the exact-match volume assumption is "low hundreds a month" and could be lower.
• Did not verify Autolist availability on Free by creating one — a write on the live brand.
• Did not price Grok Bot from x.ai directly — two 2026 sources disagree; the loop does not need it.
• Did not fetch docs.x.ai/docs/guides/automations (404); the Automations facts come from xAI's connectors pages and three secondary write-ups of the 16 Jul 2026 launch.
• GBP prices for Metricool are conversions, not invoice figures; the pricing page bills EUR/USD.
• Follow-ups that would harden this most: the first three Friday scoreboards (they replace §3 and §6's forecasts); an M2-attributed cost per trial by channel; a trial→paid reading on 30 Nov.

Sources (all fetched 15 Sep 2026 unless dated)

• Live Metricool brand: getBrandSettings, getScheduledPosts, getAnalyticsAvailableMetrics, getAnalyticsDataByMetrics, getBestTimeToPostByNetwork via the claude.ai Metricool connector.
• Metricool pricing: metricool.com/pricing · metricool.com/premium-vs-free-metricool-plans (13 Jul 2026) · help.metricool.com "Fair Use Policy for Social Media Scheduling" (600 posts/brand/month) · help.metricool.com "Your guide to the Advanced Analytics add-on" · metricool.com/mcps-for-marketing ("Advanced plan or higher") · help.metricool.com "How to manage Flows", "Flows on Instagram", "Flows on TikTok" · metricool.com/press-release-metricool-flows (1 Sep 2026: free for an initial period, later a paid add-on within Starter and Advanced) · help.metricool.com "Ads Campaigns Management" and "Create ads campaigns from Metricool" (Google and Meta creation; Meta Pixel required; TikTok monitored) · help.metricool.com "Schedule content from an Autolist" (200 posts, circular) · help.metricool.com "Best time to post" · metricool.com "How to add audio to your Instagram Reels" (Instagram Audio API, 18 May 2026) · releasebot.io Metricool notes to 11 Sep 2026 (Reporting section, Trial Reels with trending audio).
• xAI / Grok: docs.x.ai/grok/connectors ("Connectors are available to all Grok users"; New Connector → Custom → MCP server URL) · x.ai/news/grok-connectors (6 May 2026: GitHub, Google Workspace, Bring Your Own MCP) · MindStudio, Basenor and AI/TLDR write-ups of Grok Automations (16 Jul 2026: schedules free for everyone; email triggers on SuperGrok) · poster.ly Grok Bot guide (18 Aug 2026: remote MCP servers only, up to 50 routines) · aibuilderclub.com Grok Bot pricing (30 Aug 2026) and vellum.ai breakdown (20 Aug 2026) — these two disagree on price.
• Trial→paid: ChartMogul 2026 study via kirro.io and growthspreeofficial.com (opt-in median 8.9%, range 8–22%); First Page Sage via userpilot.com (18.2%).
• Meta: gtm-channels-research.md §5b (UK CPC £0.80–1.60, CPL £20–40, 2% UK location fee from 1 Jul 2026) · admetrics.io boost-vs-Ads-Manager test ($3.09 vs $1.04 per click) · enrichlabs.ai 2026 benchmarks (leads CPC $1.92, CPL ~$27.66) · growthspreeofficial.com B2B SaaS Meta benchmarks 2026.
• TikTok: nonsensical.agency "TikTok Ads Cost UK 2026" (£20/day ad-group minimum, CPM £3–5 broad / £8–12 niche, CPC £0.30–0.70 traffic) · stackmatix.com and adliftr.com 2026 cost breakdowns (B2B CPL $25–60; learning-phase exit rates under $50/day) · enrichlabs.ai Spark Ads guide 2026.
• Repo: outputs/docs/gtm-channels-research.md §5 · outputs/docs/social-media-operations-plan.md §3–§4 · outputs/docs/go-to-market-decisions.md D-02, D-12, D-27, amendments (e)–(k) · outputs/gtm/drafts/*-2026-09-14.md · outputs/docs/claude-to-grok-transfer-research.md §1c, §2, §4 · outputs/ops/routine-setup.md §4, §7 · outputs/provenbatch-site/src/data/launch.js · outputs/docs/handbook/media-and-social.md · RESEARCH.md §12, §16, §19.

Competitors

Last updated 3 Oct 2026

Competitor research is maintained in Google Drive, not in this repository. The master spreadsheet is the single source of truth.

Open the master competitor sheet

• Drive folder (one document per competitor, plus an overview)
• Overview document

Do not add competitor write-ups under outputs/docs/. Edit the sheet and the Drive documents instead.

Regulation

Last updated 19 Jul 2026

4. Regulation (UK)

Natasha's Law / PPDS — in force since Oct 2021

Food packed on site before being ordered or selected must carry the food name and a full ingredients list with the 14 regulated allergens emphasised. This is the app's whole reason to exist and is already implemented.

Ingredient list — how nested/compound ingredients must be declared (researched 19 Jul 2026)

Dave asked the exact question: do we merge sub-ingredients, name only the ingredient, or list them nested? Answer: it's a hybrid, and the full definitive write-up (with worked example, app mapping and gaps) now lives in bakery-manager-labelling-solution-design.md §1A — read that before touching label generation. Short version:

• The finished label is one flat list in descending weight order (Reg 1169/2011 Annex VII Part A).
• Bought compound ingredients (chocolate chips, digestives, baking spread…) are named with their sub-ingredients in brackets — Name (a, b, c) — Annex VII Part E. (Dave's "nested" option.)
• Home-made components / sub-recipes (our own caramel, biscuit base) are flattened to their raw ingredients and merged into the list by weight — you don't name them. (Dave's "merge" option.)
• "Name only the ingredient" is wrong except for genuinely single-component items — it hides allergens.
• All 14 allergens must be listed AND emphasised, always — even inside a compound under the 2% breakdown exemption. We always show the full breakdown (never rely on the exemption).
• The app already does the hybrid correctly (Case A via Name (declaration), Case B via expandToLeaves flatten from v0.18.0). Open gaps to backlog: QUID %, net quantity, and "Use by" vs "Best before" for perishable cream/cheesecake items. See design doc §1A.

Precautionary allergen labelling ("may contain")

• PAL is voluntary, not a legal requirement, and should only follow a real risk assessment of unavoidable cross-contamination that can't be controlled by segregation and cleaning.
• FSA best practice: name the specific allergen — "may contain peanuts", not "may contain nuts".
• ⚠️ Implication we have not resolved: we auto-propagate a supplier's "may contain" onto our labels. That is a defensible default, but it is not a risk assessment, and it can produce generic "may contain nuts" wording that FSA guidance discourages. Worth a decision.
• Watch: FSA is considering standardising PAL, with Codex thresholds (ED05). UK needed a position for CCFL May 2026; Codex adoption was on the agenda for July 2026; any UK change is not expected before late 2026. This is the live regulatory item for us.

Benedict's Law — does NOT apply to us

Corrected 17 Jul 2026. Our labelling design doc said to "monitor Benedict's Law guidance (expected Sept 2026)" as though it affected our labels. It doesn't.

It became law in England in March 2026 via the Children's Wellbeing and Schools Bill, and requires schools to hold an allergy policy, an allergy risk register, spare adrenaline auto-injectors and staff training from 1 Sept 2026. It is education-sector legislation and explicitly does not extend to hospitality or food labelling. Trade press confusion on this point is common. Action: correct the labelling design doc.

Nutrition

Believed exempt for small producers (micro-enterprise exemption), which is why nutrition (#28) is ranked low. Unverified — confirm before building #28.

Regulation

Last updated 28 Jul 2026

8e. Mandatory additive warnings — the "Southampton Six" (28 Jul 2026)

Found while cleaning footnote markers off pack transcriptions (#256, #257).

Retained EU Regulation 1333/2008 Annex V requires six colours to carry the statement "may have an adverse effect on activity and attention in children": E102 (Tartrazine), E104 (Quinoline Yellow), E110 (Sunset Yellow FCF), E122 (Carmoisine/Azorubine), E124 (Ponceau 4R), E129 (Allura Red AC). Named after the 2007 University of Southampton study that prompted the rule.

This is not an allergen rule, so nothing in our allergen detection catches it — a separate labelling obligation riding on the ingredient list. Source: Reg 1333/2008 Annex V as retained in UK law; FSA guidance on food additives.

Evidence from our own data: two of Dave's colourings (sourcings 53, 55) contain E122, and the packs mark it with an asterisk pointing at the printed warning. Our transcription kept the pointer and dropped the target — which is how the gap surfaced at all.

Worth checking before building #257 whether the same pattern applies to other families: aspartame E951 ("contains a source of phenylalanine"), polyols ("excessive consumption may produce laxative effects"), high-caffeine drinks, liquorice. If so, model it generally as "additive → required statement" rather than special-casing colours.

Regulation

Last updated 30 Jul 2026

8e-1. It DOES generalise — the full family of mandatory statements (#257, researched 30 Jul 2026)

Answering the question §8e left open. Yes: model it generally. But the finding that matters is not the list — it is that the app can only ever decide a third of it, and the reason is structural rather than a gap we can close by trying harder.

Two regulations, not one

The colours rule is the odd one out. It lives in Reg 1333/2008 Annex V (food additives). Every other mandatory statement lives in Reg 1169/2011 Annex III (FIC), "Foods whose labelling must include one or more additional particulars". Both are retained UK law. A model built only around "additives" will not naturally reach Annex III, because two of its entries are not about additives at all — so the concept to build is "finished food → required statement", keyed by whatever triggers it, not "additive → statement".

The full set, and what triggers each

🔴 The finding that should shape #257: three kinds of trigger, and we can only compute one

• Presence-only — colours, aspartame, sweeteners, protective atmosphere. Detectable from the declaration text we already store. The app can decide these.
• Concentration in the finished food — liquorice (mg/kg, mg/l), caffeine (mg/l). Needs the quantity of the substance in the finished product, which we do not hold and cannot derive: a declaration says what is in a pack, never how much, and the recipe knows pack weights rather than the additive's concentration inside them. The app can never decide these.
• Percentage of the finished food — polyols >10%. Theoretically derivable from recipe quantities if we knew the polyol content of each pack. We do not. Cannot decide.

So the honest design is detect presence, then ask — for two of the three classes the app's role is to raise the question and record the human's answer, not to reach a verdict. That is the same shape as the existing allergen rule (the machine may detect, only a human may accept), which is convenient, but it needs saying out loud because a naive build would try to compute thresholds it has no inputs for and would then be confidently wrong in the silent direction — the #204 class.

A second finding: the label renderer has no concept of placement zones

Three distinct placements appear above — with the name, immediately after the ingredients list, and in the same field of vision as the name. Our label output has no notion of any of them; it has an ingredients block and an allergen emphasis. Whatever #257 builds needs somewhere to put a statement, and "after the ingredients list" is the only one the current layout can express. Worth deciding deliberately rather than discovering at render time.

A third: widening beyond bakers (D-24) pulled two new entries into scope

Neither would ever have mattered to a baker, and both are ordinary for businesses we now say we serve: date of freezing on frozen meat and meat preparations (a butcher), and "packaged in a protective atmosphere" (a deli or farm shop that MAP-packs). This is a small, concrete example of the positioning decision having a compliance consequence rather than just a copy consequence.

Relevance ranking for our actual users

Real today: the six colours — evidenced in Dave's own catalogue (sourcings 53, 55). Plausible soon: sweeteners, aspartame and polyols, via sugar-free icings, "no added sugar" ranges and protein bars. Narrow but real: liquorice (confectioners), date of freezing (butchers), protective atmosphere (delis). Effectively never: phytosterols.

⚠️ Sourcing caveat — read before writing any of this wording onto a label

⚠️ CORRECTED 25 Aug 2026 — the fetching half of this caveat is FALSIFIED. Re-tested from a cloud session, all four sites answer:

The original entry is kept below because a falsified reason invites a bad "correction" later, and because the network genuinely did behave that way when it was written — the environment's egress policy was widened around 9 Aug 2026, which is the likeliest cause. What changes as a result: this is no longer off-keyboard work. A session can now pull the retained text itself, so the character- for-character confirmation below should be done in-session and not handed to Dave. ⚠️ The substantive half of the caveat stands unchanged and is the part that matters — see the paragraph after the original.

Original entry (superseded, kept as the record): The primary legislative text could not be fetched from a cloud session. legislation.gov.uk, eur-lex.europa.eu, fsai.ie and businesscompanion.info all answer HTTP 403 to an automated fetch — the agent proxy was verified healthy at the time (recentRelayFailures: []), so this is the sites refusing bots, not our network.

The part that still holds, whatever the network does. The wordings and thresholds above come from secondary sources, cross-checked between several. That is good enough to design against and not good enough to print: statutory wording is exact, and a near-miss is a non-compliant label. Before #257 ships, each statement must be confirmed character-for-character against the retained text on legislation.gov.uk.

Sources: FSA — food additives; FSAI — labelling requirements for food additives; Business Companion — labelling of prepacked foods; Reg 1169/2011 consolidated text (EUR-Lex); CMS — compulsory warnings on colours in food and drink.

Regulation

Last updated 16 Aug 2026

14. HACCP / Safer Food, Better Business (SFBB) — the daily due-diligence norm for #36 (researched 9–10 Aug 2026)

Read directly for #36's Food safety build (outputs/docs/overnight-batch-issues-35-36-plan.md §C.10) — the app's first primary-source pass on this topic; RESEARCH.md had no HACCP section before this entry. England & Wales only — CookSafe (Scotland) and Safe Catering (Northern Ireland), the two regional equivalents CLAUDE.md already names, were not independently checked this session; do not assume they match SFBB's structure without reading them. ✅ DISCHARGED 6 Sep 2026 — both packs read in full for #1349: see §14c. This warning was right: neither pack has SFBB's daily opening/closing walk, CookSafe verifies weekly against its House Rules and reviews six-monthly, and Safe Catering uses a proprietor's hygiene inspection with a three-item 4-weekly review inside it. This paragraph stays as written because it is what stopped a session relabelling the SFBB seventeen as "CookSafe"; read §14c before touching anything nation-specific.

Primary sources read, verbatim where quoted below:

1. The GOV.UK publication landing page, gov.uk/government/publications/safer-food-better-business- sfbb/safer-food-better-business-sfbb (published 5 Jun 2025) — a shell page, exactly the food.gov.uk → GOV.UK trap CLAUDE.md and outputs/gtm/social-content.md §2a already flag: it names the pack's five sections and applicability but carries no prescriptive detail itself, linking out to the real documents as separate PDFs.
2. The SFBB introduction PDF (sfbb-introduction_2.pdf, 9 pages) — how the pack and diary work, registration duty, the Food Hygiene Rating scale, and the "Working with food?" hygiene factsheet.
3. The SFBB caterer's diary PDF (sfbb-diary-07-diary-and-4-weekly-review-fixed_0.pdf, 7 pages) — the actual daily record template and the 4-weekly review sheet.

Both PDFs failed to extract via WebFetch (returned corrupted/binary text) and via pdfplumber (this environment's cryptography package has a broken native _rust/cffi binding, which pdfplumber/pypdf both pull in transitively and crash on import even for an unencrypted PDF). pymupdf (import fitz) worked — a pure-C-extension reader with no cryptography dependency — and is the one to reach for first if this recurs. Worth recording: this is an environment-level Python packaging defect, not a content problem, and cost real time to diagnose.

What SFBB actually prescribes, and where our #36 seed matches or diverges from it:

• The diary is coarser than our schema assumed. Each day has exactly two attestations — "Opening checks" and "Closing checks" — each a single tick plus a name and signature under one sentence: "Our safe methods were followed and effectively supervised today." It is not a per-item log of individual readings (no "fridge temp: 4°C" line in the diary itself). The itemised detail — what each "safe method" actually checks, including any numeric limits for chilling/cooking/hot-holding — lives in the separate sector-specific "safe methods" sheets (e.g. the full caterer's pack), which this session did not fetch; that stays unverified, not guessed at. #36's seed splits "Fridge temperature" and "Freezer temperature" out as their own named checks rather than folding them into one bundled "Opening checks" tick — a reasonable product decision (a due-diligence app can usefully separate what a paper diary bundles), but worth knowing it's our structure, not a literal transcription of SFBB's. ⚠️ PARTLY CORRECTED 26 Aug 2026 — see §14b, which reads the pack this session skipped. The two-attestation finding is right about the diary page, but the caterer's pack prints the seventeen itemised opening and closing checks those two ticks attest to (pp. 66 and 82), so itemising them is a literal transcription of SFBB after all, not our own structure. Only the temperature split (fridge/freezer as named checks rather than 'prove it' readings) is ours. Read the way it stood, this entry invites a future session to "simplify" the itemised list back into one bundled tick on the grounds that SFBB bundles it — SFBB does not.
• ⚠️ CORRECTED 26 Aug 2026 (#730/#645 corpus review) — the reasoning below was falsified, the decision itself was not re-opened. The original entry said "no numeric temperature limit appears in either PDF read this session… none confirmed here against a primary FSA safe-method sheet" — true only of the two documents actually read (the intro and the diary), not of SFBB as a whole. The caterer's "safe methods" pack — sfbb-caterers-pack-fixed_0_3.pdf, live at assets.publishing.service.gov.uk (re-fetched and text-extracted with pymupdf, the #36 pack's own PDF-reading fix, since pdfplumber/WebFetch both still choke on this file) — does state primary numbers, verbatim: "Frozen food should be kept at -18°C or below"; food "can be put back in the fridge and kept at 8°C or below"; hot-held food must stay "at a safe temperature of 63°C or above"; and cooking gives explicit time/temperature combinations — "80°C for at least 6 seconds, 75°C for at least 30 seconds, 70°C for at least [longer]…" — not a single ≥75°C figure, which the commonly-repeated shorthand flattens. So the widely-cited 8°C / ‑18°C / 63°C figures ARE genuine primary FSA text, just from a document this session hadn't read yet. Decision §C.9 (ship the seeded checks with no default number) is UNCHANGED by this — #730 explicitly separates "the decision still looks right" from "the recorded reason for it was wrong," and a wrong reason sitting next to a right decision is exactly what invites a future session to "helpfully" reverse the decision on false grounds. If a default number is ever added, the cooking one specifically needs the time/temperature table, not a flat "≥75°C".
• "Extra checks" (SFBB's term) are irregular, non-daily checks — maintenance, deep-cleaning a freezer — logged once at the end of the week, not daily. Distinct from our four_weekly frequency, which maps more directly to the 4-weekly review below.
• The 4-weekly review is a walk-round + a fixed yes/no checklist, not a diary entry. It asks, among other things: "Have probes been calibrated in the last 4 weeks and results recorded?" — this is the primary-source anchor for #36's seeded "Probe thermometer calibration" check, though SFBB frames it as one item on a 4-weekly review, not a standalone repeating check. #36 seeded it at weekly frequency (a reasonable product simplification — calibrate more often than the legal minimum is conservative, not wrong) but if this is ever revisited, four_weekly is closer to the primary source's own cadence.
• Corrections are explicitly a narrative, not a structured record: "If things go wrong, write down what happened and what you did in your diary." SFBB's own due-diligence model is closer to a free-text incident note than #36's structured amend-with-supersession — our design is stricter (a real correction trail, enforced at the RLS layer) than the paper form it's replacing, which is a reasonable direction to diverge in, not a mismatch to fix.
• Who signs: "the person responsible for running the business," daily — matches #36's recorded_by capturing whichever team member is signed in, not a fixed single named operator.
• Registration and Food Hygiene Rating are out of scope for #36 (they're a one-off business registration duty and an EHO-assigned outcome, not a repeating check) but are useful context: using the pack correctly is explicitly stated as improving the Food Hygiene Rating outcome, which is the commercial argument for #36 existing at all.

• How the cadence is anchored: rolling from when you start, NOT a fixed calendar or week numbers (researched 16 Aug 2026, for the #558-UAT question "how is a weekly/4-weekly check's due day determined?"). The FSA guidance is explicit that the 4-weekly review is done "at the end of every 4 weeks" — you look back over the past 4 weeks' diary and complete it even if no problem was found. There is no FSA-published national calendar, week-numbering scheme, or fixed reference date: the 4 weeks run rolling from whenever a business starts, and 4 weeks is 28 days, deliberately not a calendar month (a month would drift between 28–31 days and lose the fixed-length review window). The daily diary is filled in each day; "weekly" extra checks are logged by the end of the week. Implication for our scheduling model: a business-set week-start day defining the week a weekly check must be completed within, plus 4-week blocks measured off that same grid, is faithful to SFBB — whereas ISO week-number parity (which starts weeks on Monday regardless of the business's own week-start) would diverge from it, so it was not adopted.
• Sources:
• GOV.UK — Safer food, better business (SFBB)
• FSA — SFBB introduction PDF
• FSA — SFBB caterer's diary + 4-weekly review PDF
• FSA — SFBB diary refill / 4-weekly review

Regulation

Last updated 12 Aug 2026

14a. HACCP plan authoring — the GOV.UK/MyHACCP primary-source pass for #440 (researched 12 Aug 2026)

Scoping pass for #440 (#36 phase 3); design decisions in outputs/docs/issue-440-haccp-plan.md. Extends §14 — same England & Wales framing, same "no numbers found, so ship none" outcome.

Read directly (verbatim quotes in the #440 doc):

• food.gov.uk/business-guidance/hazard-analysis-and-critical-control-point-haccp now 301-redirects to gov.uk/food-safety-management-systems — the food.gov.uk→GOV.UK migration §14 flagged has since swallowed the HACCP business-guidance page itself. The GOV.UK page states "If you run a food business, you need to have a food safety management system" and lists seven requirements to meet HACCP principles (identify hazards; identify CCPs; set limits for the CCPs; monitor the CCPs; put checks in place to make sure your system is working; put things right if there is a problem with a CCP; keep records). No numeric temperature or critical limit appears anywhere on it — consistent with §14's finding for the SFBB diary, and again the reason the app ships structure without numbers.

Known only via search extracts from FSA's own site — NOT a page read:

• MyHACCP (myhaccp.food.gov.uk) — the FSA's free HACCP-plan authoring tool, aimed at UK food manufacturing businesses with 50 or fewer employees; guides a business through 8 preparatory stages (A prerequisites, B management commitment, C scope of study, D select the team, E describe the product, F identify intended use, G flow diagram, H confirm flow diagram) and the 7 principles (1.1 identify hazards / 1.2 hazard analysis / 1.3 control measures; 2 determine CCPs; 3 critical limits; 4 monitoring; 5 corrective action plan; 6 validation, verification and review; 7 documentation), producing a downloadable PDF of the study. ⚠️ The site answers HTTP 403 to every non-browser fetch from this environment (WebFetch and curl with a browser UA alike — a WAF, not an outage; the FSA's acss.food.gov.uk copy of the authorised-officer guidance PDF is a 404 now too). The structure above comes from FSA-site search extracts, so treat exact stage/principle wording as unverified until someone reads the site in a real browser. #440's design deliberately doesn't depend on the wording — it ships no MyHACCP content, only a structure compatible with it.

The scope fact that shapes #440: SFBB is the FSA-approved food safety management system for caterers and retailers — a business running SFBB properly needs no bespoke HACCP plan; MyHACCP is the FSA's route for small manufacturers. Our PPDS users straddle the line, so plan authoring is an optional capability and the app must never imply the SFBB-style daily-checks half (#36 phases 1–2) is insufficient on its own.

Still unread, still not guessed at (unchanged from §14): the SFBB sector safe-methods packs; CookSafe (Scotland); Safe Catering (NI).

Sources:

• GOV.UK — Food safety management systems
• MyHACCP (FSA) — 403 to non-browser fetches; structure via FSA-site search extracts, 12 Aug 2026

Regulation

Last updated 26 Aug 2026

14b. The SFBB opening/closing checks — the verbatim primary source behind the #534 seed (researched 26 Aug 2026)

⚠️ This section was CITED before it was WRITTEN. index.html's SFBB_OUTLINE_CHECKS comment, safety_reviews' comment, goaudits-fsa-checks-ux-research.md and road-to-launch-overnight-batch- plan.md all pointed at "RESEARCH.md §14b" as the primary-source authority for what the seeded checks say — and no §14b existed. The seed's contents were correct (verified below, item for item), but for ten days the evidence for the app's only verbatim regulatory transcription was unciteable from the repo. Written here to close that, prompted by a Whisk & Whimsy observation (below) that sent a session looking for it.

Source read in full: the FSA Safer Food, Better Business for caterers pack, sfbb-caterers-pack-fixed_0_3.pdf (100 pages), fetched from assets.publishing.service.gov.uk and text-extracted with pymupdf — still the only reader that works on these files in this environment (WebFetch and pdfplumber both fail; §14 records why). The opening/closing lists appear twice, identically: as the safe method sheet (p.66) and again in the diary's own instructions (p.82). Quoted verbatim.

OPENING CHECKS — "You should do these checks at the beginning of the day. You can also add your own checks to the list." (nine items)

1. "Your fridges, chilled display equipment and freezers are working properly."
2. "Your other equipment (e.g. oven) is working properly."
3. "Staff are fit for work and wearing clean work clothes."
4. "Food preparation areas are clean and disinfected (work surfaces, equipment, utensils, etc.)."
5. "All areas are free from evidence of pest activity."
6. "There are plenty of handwashing and cleaning materials (soap, paper towels, sanitiser, etc.)."
7. "Hot running water is available at all sinks and hand wash basins."
8. "Probe thermometer is working and probe wipes are available."
9. "Allergen information is accurate for all items on sale."

CLOSING CHECKS — "You should do these checks at the end of the day." (eight items)

1. "All food is covered, labelled and put in the fridge/freezer (where appropriate)."
2. "Food on its Use By date has been thrown away."
3. "Dirty cleaning equipment has been cleaned or thrown away."
4. "Waste has been removed and new bags put into the bins."
5. "Food preparation areas are clean and disinfected (work surfaces, equipment, utensils etc.)."
6. "All washing up has been finished."
7. "Floors are swept and clean."
8. "'Prove it' checks have been recorded."

So SFBB is itemised, and the paper diary is not — both are true, and the distinction matters. §14 recorded that the diary page carries just two attestations ("Opening checks" / "Closing checks", one tick each). That is the signature line. The seventeen items above are what those two ticks attest to, printed on the facing instructions page and again in the safe method. A product that offers one bundled "hygiene check" is therefore reproducing the signature and discarding the checklist — the wrong half. Our per-item model is the faithful one, and #534's decision to itemise was right for a reason stronger than the "reasonable product decision" §14 hedged it as.

Our seed vs. the source — 17 of 17 present, three deliberate trims. SFBB_OUTLINE_CHECKS carries every opening and closing item in the source order, plus three temperature checks the FSA lists as 'prove it' readings rather than walk-round ticks (fridge morning/evening, freezer daily) and the weekly probe calibration (§14 explains why weekly not four_weekly). Trimmed for row width, with no loss of scope: "chilled display equipment" (folded into Fridges and freezers working), "probe wipes" (folded into Probe thermometer working), and "'Prove it'" → Records completed. The §C.9 posture holds throughout — names only, no numeric target, no hazard, no citation in the UI.

Whisk & Whimsy, 26 Aug 2026 — the legacy-seed gap this surfaced. W&W reported "several hygiene sub-checks, not one" during opening checks. They were right, and the cause is data, not code: their list is the pre-#534 six-check auto-seed (10 Aug), which bundled the whole walk into a single "Opening hygiene check" and "Closing hygiene check". #560's repair backfilled their food_safety_seeded_at on 16 Aug; #534's itemised outline shipped two days later, on 18 Aug, gated on an empty check list. Net effect: every business seeded before v0.210.0 is permanently locked out of the itemised outline — the "Start from a typical SFBB outline" button renders only in the empty state, and foodSafetySeedOutline() returns early on a non-empty list. Not a regression in #534, and correct for its own idempotency purpose; it simply has no top-up path. Production blast radius on 26 Aug 2026 is one business (W&W) — it is the only tenant with any checks at all — but it is Dave's own pilot, i.e. the one account whose EHO pack would be looked at first. Filed as its own issue; the repair is additive (offer the missing items, never silently insert them).

Sources:

• FSA — SFBB caterers pack (full 100-page safe methods + diary) — pp. 66 and 82, read 26 Aug 2026
• GOV.UK — Safer food, better business (SFBB)

Regulation

Last updated 6 Sep 2026

14c. CookSafe (Scotland) and Safe Catering (Northern Ireland) — the primary-source pass §14 said was owed (researched 6 Sep 2026)

Read for #1349, which makes the UK nation a stored fact (business_settings.nation) and seeds the food-safety module from the right pack. §14 flagged this gap on 9 Aug 2026 in as many words — "England & Wales only — CookSafe (Scotland) and Safe Catering (Northern Ireland) ... were not independently checked this session; do not assume they match SFBB's structure without reading them" — and that warning turned out to be the important sentence in the whole section. They do not match SFBB's structure. Neither pack has SFBB's daily opening/closing walk at all.

Sources read in full, both fetched as PDFs and text-extracted with pymupdf (still the only reader that works on these in this environment — WebFetch returns the GOV.UK shell page and pdfplumber crashes on import; §14 and §14b record why, and it cost nothing this time because they did):

1. CookSafe Food Safety Assurance System, Food Standards Scotland, Issue 1.2, May 2012, 126pp — foodstandards.gov.scot/sites/default/files/migration/downloads/CookSafe_Manual_Complete_September_2021.pdf
2. Safe Catering — your guide to making food safely, FSA in Northern Ireland, Issue 7, April 2019, 130pp — assets.publishing.service.gov.uk/media/69b3f32ffdbfc4d58fc8cf2e/safe-catering_0_0.pdf, plus its recording forms (safe-catering-recording-forms_0_0.pdf), SC5 and SC8 as separate PDFs.

⚠️ food.gov.uk/business-guidance/safe-catering 301s to GOV.UK — the same food.gov.uk → GOV.UK trap §14 flagged. The GOV.UK page is the one that carries the "Applies to" statement.

The three packs are siblings, and the FSA says so itself

Safe Catering's own foreword, verbatim: "Other similar guidance materials have also been developed by the Food Standards Agency i.e. Safer Food Better Business developed in England and CookSafe in Scotland." That is the authority for #1349's nation → pack mapping; it is not our inference.

GOV.UK on Safe Catering: "Food safety management guides for caterers and retailers in Northern Ireland", and explicitly "Applies to Northern Ireland".

🔴 Safe Catering is a JOINT FSA-NI / Food Safety Authority of Ireland product, which matters for #826 rather than for #1349: "This joint initiative with the Food Safety Authority of Ireland is intended to assist with consistency of application of food hygiene legislation right across the island of Ireland." That sentence is from the FSA-NI publication. The FSAI does publish its own Safe Catering Pack. The FSAI publishes its own Safe Catering pack with the same SC-numbered forms. (Struck 15 Sep 2026, #1879. Un-struck in part 16 Sep 2026, #1524, having been read form by form from the FSAI's own sheets — the resolution is below and the full read is §29d.)

🔴 RESOLVED, THREE WAYS — and "same SC-numbered forms" was two-thirds right (#1524, 16 Sep 2026).

1. The SC numbering IS used on the Irish side. #1879's strike was against the wrong artefact. It read the FSAI's Record Books web page, which titles the sheets "Recording Form n". The sheets themselves print their SC number on the artwork — SC4, SC5, SC6, SC7 and SC9 were all extracted directly from the PDFs — and the FSAI's own asset filenames are SC2-2012-refrigeration.pdf, SC5-2012-inspection.pdf, SC6-2012-training.pdf and SC7-2012-fitness.pdf. A page title is not the form.
2. The nine slots match FSA-NI's SC1–SC9 one for one, in order, by purpose. Two titles differ: FSAI 2 is Refrigeration (NI: Fridge/Cold room/Display Chill Temperature Records) and FSAI 9 is Transport and Delivery (NI: Customer Delivery Record).
3. The CONTENTS have diverged, because the editions have — the FSAI sheets are ©2012, FSA-NI's are Issue 7, April 2019. So this is not an identity of forms, and #1524 did not relabel the Northern Ireland arrays. The three divergences that reach the app are listed in §29d; the one that matters most here is that FSAI SC2 expects a freezer temperature ("It is recommended that fridge/freezer temperatures are checked at least once per day") where FSA-NI SC2 makes it optional ("Some businesses may wish to record freezer temperatures").

So the Northern Ireland profile #1349 built was indeed most of an Irish profile — the shape and the numbering transferred, the rows did not.

CookSafe (Scotland) — structure

"'CookSafe' is designed to assist catering businesses understand and implement a HACCP based system." Five sections: Introduction, Flow Diagram, HACCP Charts, House Rules, Records.

There is no daily opening/closing walk. The periodic verification is the Weekly Record: "The following ongoing checks should be carried out by the Manager or Proprietor during each working week and should be carried out by all businesses using 'CookSafe'." It asks "Have the House Rules been followed? YES / NO / N/A" against ten headings — Training, Personal Hygiene, Cleaning, Cross Contamination Prevention, Pest Control, Waste Control, Maintenance, Stock Control, Temperature Control, and Records ("Have all necessary Temperature Checks been recorded using the correct recording form/s?") — then "If the answer to any of the above questions is 'NO' then enter the corrective action details in the table below" under HOUSE RULES DEVIATIONS OBSERVED / CORRECTIVE ACTIONS TAKEN. It is signed once: "Manager/Proprietor's Signature ... Date".

Records section, its own numbered list: "1. Delivery Record 2. Cold Food Record 3. Hot Temperature Record 4. Hot Holding Record 5. Off Site Temperature Record 6. All-In-One Record (used as an alternative to records 1 - 5) 7. Weekly Record". The All-In-One is "To be completed daily". Cold units: "Temperature checks (Recommended twice daily)" with AM and PM columns; freezers get "Function checks (Recommended once daily)" — a function check, not a temperature reading, which is why #1349's CookSafe seed carries "Freezer working" as a tick and not a temperature.

Probe thermometer: MONTHLY, its own sheet — "The readings in iced water should be -1°C to +1°C", "The reading in boiling water should be between 99°C and 101°C", plus "The electronic display unit should be checked at least once per year."

Review: SIX-MONTHLY, not four-weekly. "It is essential that your HACCP based procedures are kept up to date. A review of your system must be carried out on a regular basis, ideally every six months or if any of the circumstances covered in the table below arise." The table is a list of triggers (new dish, new equipment or supplier, premises changes, House Rules changes, "A Local Authority inspection where deficiencies were noted", new hazard information, cleaning chemical changes, staff changes, customer complaint), not a fixed questionnaire.

Safe Catering (Northern Ireland) — structure

"developed principally for catering businesses, but it may also be used by retailers who have a catering function within the business." HACCP's seven steps, then a Declaration of Completion of your Safe Catering Plan signed and dated, with future review dates recorded on it.

No daily opening/closing walk here either. The premises walk is SC5 – Hygiene Inspection Checklist: "Simple checks of the premises which should be carried out by the Proprietor or Manager regularly", where "regularly" is the business's own choice — the form's footer is "Tick frequency checks carried out by proprietor or manager: Weekly / Fortnightly / Monthly". Its sections are Hygiene of Food Rooms & Equipment, Food Storage, Food Handling Practices, Personal Hygiene, Pest Control, Waste Control, Checks and Record Keeping, and then a Review (4 weekly) block of exactly three questions: "Any new suppliers and approved list updated?", "Any new menu items and steps in Safe Catering updated?", "Any new food handling methods or equipment and steps in Safe Catering updated?" Signed with Name / Position / Signed / Date.

Daily records are SC1–SC4, foldable into SC8 – All-In-One Record: "This form may be completed daily and used as an alternative to the individual records". SC2's footnote sets the floor: "It is recommended that fridge temperatures are checked at least once per day", on a form with AM and PM columns. SC4 is "(For Food To Be Held Hot For More Than 2 Hours)".

Safe Catering DOES state primary numbers, unlike CookSafe (which leaves critical limits blank for the business to write in): "Chilled food: max. 8°C; Hot Food: minimum 63°C" (SC1), "Core temperature above 75˚C" (SC3), "Keep hot food above 63˚C" (SC4). Recorded here for completeness; §C.9 is unchanged and #1349 ships no number in any seeded check name, exactly as §14/§730 settled for SFBB.

The daily sign-off: SFBB has one, the other two do not

SFBB's diary carries a daily attestation — "Our safe methods were followed and effectively supervised today" (§14). Neither CookSafe nor Safe Catering has a daily declaration sentence at all. CookSafe's signature is on the weekly record; Safe Catering's are per-form ("Manager/Supervisor check on ___ Initials") plus the one-off plan Declaration. This is why #1349's FOOD_SAFETY_PACKS carries an attributed flag and why the app now says "the end-of-day declaration" rather than "the SFBB daily declaration" to a Scottish or Northern Irish business: the app's own daily sign-off is a good product decision either way, but attributing its wording to a pack that does not contain it would be a fabricated citation.

🔴 CORRECTED IN PLACE, 16 Sep 2026 (#1524) — that last sentence describes only HALF of what shipped, and the half it leaves out is the citation. Found in browser UAT (outputs/mobile-harness/uat1524.js), not by reading the code. attributed governs the caption under the sign-off card; the quoted sentence above it is SAFETY_SIGNOFF_STATEMENT, a plain constant (part-1.js), and it is SFBB's line rendered in quotation marks to every business in every nation. So a Scottish business is shown, today, on main:

"Our safe methods were followed and effectively supervised today." The end-of-day declaration. Signing records your name and the time…

The caption stopped naming SFBB; the quotation marks did not stop quoting it. This is the exact #22 shape the attributed flag was introduced to prevent, in the line it was introduced for — a fix that looks complete because the thing it renamed is the thing anyone would check.

Not fixed by #1524, deliberately, and this is the reasoning rather than an omission. It affects GB-SCT and GB-NIR on main right now; changing it changes what an existing, non-IE business sees, which epic #827's dark-groundwork posture forbids this issue from doing (#1897: "OFF = BYTE-IDENTICAL TO TODAY"). It is #1349's own defect and wants its own issue, its own UAT and its own copy decision — an unattributed wording that works for all four nations, or a per-pack sentence with attributed: false printing none. Raised on #1524 rather than filed silently.

Fixed 18 Sep 2026 (#1930), option (b). §14c does not supply a genuine all-pack sentence — neither CookSafe nor Safe Catering has a daily declaration at all — so inventing one would be the same fabricated citation the attributed flag was introduced to stop. The quoted sentence is now FOOD_SAFETY_PACKS.sfbb.signoff, printed only where attributed: true, and omitted for CookSafe, Safe Catering and FSAI. Both the sign-off card (.fssignoff-stmt) and the EHO pack meta go through foodSafetySignoffStatement(), so they cannot disagree. The caption already behaved this way; the quote now matches it.

⚠️ The label does NOT differ by nation — verified, not assumed

The issue asked for this to be checked rather than believed, because the Windsor Framework keeps Northern Ireland under EU food-information law. Nothing on a PPDS label differs across the four nations. PPDS took effect 1 October 2021 across the whole UK; the 14 allergens are identical; emphasis within the ingredients list is required identically. What differs is only which agency publishes the guidance: GOV.UK's PPDS labelling guidance states "Applies to England, Northern Ireland and Wales" and points to Food Standards Scotland for the Scottish publication of the same requirement. The corpus already recorded this (ppds-natashas-law.md: "No difference in the substance of the requirement was found between the four nations, only in which agency publishes the guidance") and this pass confirms it against the regulators' current pages.

Consequence for the build, and it is the important one: business_settings.nation is read by the food-safety seed and by ProvenBot, and by nothing on the labelling path. A future session must not "extend" nation-awareness into the label engine — there is nothing there to vary, and a nation-split label would be a regression, not a feature. outputs/tests/uknations1349.js pins this.

What the app cannot yet express, recorded so it is not rediscovered

• CookSafe's six-monthly review. SAFETY_FREQUENCIES stops at four_weekly; there is no monthly or six-monthly frequency, and adding one is a CHECK-constraint migration on two databases plus a drift_info() change. #1349 therefore seeds no review check for Scotland rather than inventing a cadence the pack does not have.
• CookSafe's monthly probe check is seeded at four_weekly (28 days) — the nearest available and a slightly shorter interval than the pack asks for, which is the safe direction to round in.
• Safe Catering's weekly/fortnightly/monthly choice on SC5 is seeded at weekly, the most frequent option it offers and the only one of the three the app can express. A business that inspects monthly edits the row.
• The guided 4-weekly review (SFBB_REVIEW_ITEMS) is still SFBB's twelve questions for everyone. #1349 makes only its name nation-neutral. Rewording it per nation needs its own issue: CookSafe's equivalent is six-monthly and trigger-based, and Safe Catering's is the three-item block above.
• GOODSIN_REF_NOTE still cites the SFBB pack's delivery temperatures to every business. CookSafe states no equivalent figure (the business writes its own critical limit) and Safe Catering's SC1 states chilled max 8°C and hot min 63°C but no frozen-delivery figure, so there is no verified per-nation replacement to swap in. Left as it is, deliberately, and filed separately. ⚠️ Half of that is no longer true for IRELAND (#1524, 16 Sep 2026). The FSAI's SC9 note states all three: "Chilled food: 0°C to 5°C; Frozen food: less than or equal to -18°C; Hot food: greater than or equal to 63°C", and SC2 repeats the first two. So an Irish replacement is verified and is stricter than the Northern Irish one on chilled food (0–5 °C, not max 8 °C). #1524 ships no number (§C.9) and does not touch GOODSIN_REF_NOTE, which is a UK-wide string outside its scope — but a future issue swapping that note per nation now has the Irish figures and should not re-derive them, and must not assume Ireland and Northern Ireland share them.

Sources:

• Food Standards Scotland — CookSafe Guide
• FSS — CookSafe Manual, complete (PDF, Issue 1.2 May 2012) — read in full 6 Sep 2026
• GOV.UK — Safe catering (FSA in Northern Ireland)
• FSA NI — Safe Catering guide (PDF, Issue 7 April 2019) — read in full 6 Sep 2026
• FSA NI — Safe Catering recording forms SC1–SC9 (PDF)
• GOV.UK — PPDS labelling guidance ("Applies to England, Northern Ireland and Wales")
• Food Standards Scotland — Prepacked for direct sale

Regulation

Last updated 9 Sep 2026

29. Ireland — first non-UK jurisdiction (researched 9 Sep 2026; recreated 15 Sep 2026)

This is the Ireland research pass epic #827 and children #1519–#1525 cite. A first pass was written 9 Sep 2026 as RESEARCH.md §27 / §27a–§27g on origin/claude/intl-expansion-epic-split-0pvtix. That branch was deleted unmerged. On main, §27 is GitHub Actions cost (13 Sep) and §28 is used twice (card payments; Metricool). This section is the next free number, rebuilt 15 Sep 2026 (#1879) from the issue bodies and re-read against primary sources the same day. Until this section landed, the approved design record (outputs/docs/ireland-jurisdiction-profile-design-record.md, #1519) was the source for every Irish regulatory claim. The design record is the spec; this section is the research record.

Every regulatory and tax claim below has a primary source and a date. Claims from the 9 Sep issue bodies that did not survive the 15 Sep read are struck in place at the end of this section (and in §11 / §14c where they had already been copied).

How FSAI Guidance Note 28 was read (15 Sep 2026)

The issue that filed this recreate (#1879) inherited a 9 Sep warning that GN28's body was scanned images. That warning is wrong for the current file.

Sources read this pass (15 Sep 2026)

Reg (EU) 1169/2011 is cited through GN28 Rev 2 (which reproduces Art. 21 and the Commission Notice of 13.7.2017 in §12), not re-read from EUR-Lex in this pass.

29a. Ireland treats PPDS food as non-prepacked — there is no Natasha's Law

The claim #811, #825, #827 and every child asserted from 28 Aug 2026 holds, and has now been read from the instrument rather than from the FSAI's paraphrase.

S.I. 489/2014 Reg. 3, verbatim: "These Regulations apply to all food which is not prepacked food and is offered for sale or supply, including supply free of charge, to the final consumer or to a mass caterer, including— (a) food packed at a food business operator's premises at the consumer's request, and (b) food packed for direct sale or supply."

That is the UK's PPDS population, named in the Irish instrument as non-prepacked. The FSAI allergen page says the same in its own words: non-prepacked food includes "foods packed on the premises for direct sale to the consumer or mass caterer, e.g., lasagne made in a café kitchen and sold packaged from a fridge in the café" (fetched 15 Sep 2026).

What the operator must do — Reg. 4: written particulars of any allergen, at the point of presentation, sale or supply. Not a full ingredient list. Reg. 5(1) sets the manner (accessible before sale; English, or Irish and English; conspicuous; legible; no confusion as to which food). Reg. 6 exempts a separate declaration where the name of the food clearly refers to the allergen.

The 14 allergens are the same as the UK's — Reg. 2 points at Annex II of Reg (EU) 1169/2011 as amended by Delegated Regulation (EU) 78/2014; GN28 Rev 2 Annex I reproduces them.

The word "Contains" is guidance, not statute. GN28 Rev 2 §9: "In the absence of a list of ingredients, food allergen information must be provided in written format by including the word "Contains…" followed by the particular allergen(s) (e.g. Contains wheat, barely, soya and egg)." [sic — "barely" is the FSAI's typo]. The FSAI allergen page: "It is not acceptable to say 'Our food contains…'. You must identify the exact food, e.g., 'spaghetti bolognaise - contains milk, celery, wheat'." The statute's own words are Reg. 5(1)(e): no possibility of confusion as to which food.

The sentence that shapes the Irish label — GN28 Rev 2 §9: "Non-prepacked food usually does not require a list of ingredients, but where one is provided, any food allergens used in the production or preparation of that food must be emphasised in accordance with the requirements of the FIC Regulation and may not be repeated elsewhere outside of the ingredients list." So an Irish label is one of two shapes, never both: a "Contains:" statement with no ingredient list, or an ingredient list with allergens emphasised and no separate allergen line. The UK PPDS label prints both. That combination is what Irish guidance rules out.

QUID, date line, net quantity are Art. 9 / 22 / 24–25 particulars of prepacked food. They are not required for this declaration. (What the app prints anyway is a #1519 decision, not a research finding.)

What we now hold (26 Sep 2026, #1926). The Irish ProvenBot corpus at outputs/provenbot/knowledge/ie/labelling-allergens.md (plus the home-business and Safe Catering files) states this rule positively, summarised from the FSAI pages re-fetched the same day and from GN28 Rev 2. §29a is no longer only a record of what the UK corpus lacks. Licence and shape: §29h.

What S.I. 656/2024 actually changed: nothing about the declaration. Read from the Statute Book 15 Sep 2026, it inserts the Official Controls Regulation definition, substitutes sampling / second-expert-opinion / sample-division / compliance-notice / service-of-notice provisions, and its own explanatory note says it aligns "compliance notices and sampling" with other 2024 official-controls amendments. Regs 3–6 of S.I. 489/2014 are untouched and have been in operation since 13 December 2014. The FSAI page cites both instruments because together they are the "Regulations 2014 and 2024" (S.I. 656/2024 Reg. 1(2)). Citing "489 as updated by 656" is correct as a citation and wrong as a reason the declaration moved.

29b. US "Contains:" crossover — FALCPA (for #1519 / #1529)

The Irish non-prepacked declaration is structurally the same derivation as the US "Contains:" statement: named food + the word "Contains" + the allergen list. They differ in which allergen set applies, whether species must be named, and where the statement sits relative to an ingredient list.

21 U.S.C. § 343(w)(1) (FALCPA, as amended) — a food is misbranded if it is, or contains an ingredient that bears or contains, a major food allergen, unless either:

• (A) "the word "Contains", followed by the name of the food source from which the major food allergen is derived, is printed immediately after or is adjacent to the list of ingredients (in a type size no smaller than the type size used in the list of ingredients)"; or
• (B) the source name follows the ingredient in parentheses in the list (with the usual exceptions where the ingredient's name already uses the source name).

The FDA's own consumer page (fetched 15 Sep 2026) gives the example "Contains wheat, milk, and soy." The FASTER Act added sesame as the ninth major food allergen from 1 January 2023. Tree nut, fish and Crustacean shellfish must be named by type/species (§ 343(w)(2)) — the same species_named idea GN28 §12 requires for cereals and nuts in Ireland.

The shared derivation is allergenDeclaration()'s statement mode (named food + lead + allergens). Ireland prints the statement instead of a list; the US prints it after the list (or in the list). Whichever of #1520 / #1529 lands first builds that mode for both; the second must not fork it. The allergen set (eu14 vs the US nine) is #1528's data, not this derivation.

FALCPA's requirements apply to packaged foods offered for sale; they "do not apply to foods that are placed in a wrapper or container … following a customer's order at the point of purchase" (FDA Food Allergies page, 15 Sep 2026). That is the US analogue of "not this declaration" — recorded so #1529 does not treat FALCPA as covering every counter sale.

29c. Half the profile is already built — prepacked is EU FIC

LABEL_FORMATS = ["ppds", "prepacked"] with resolveLabelFormat(): the app already has two formats, and the second is EU FIC, which the UK retained essentially intact. An Irish business selling genuinely prepacked food is already in the right regime; that half is checked for Brexit-era divergence (FBO address must be EU-established — an Irish address is; language — English satisfies; allergen emphasis — identical), not rebuilt. The one divergence GN28 Rev 2 §9 forces on the Irish FIC row is dropping the separate Allergens: line (declaration: none), because an emphasised list's allergens "may not be repeated elsewhere". #1519 decides the rows; this section records the research that made the reuse cheap.

29d. FSAI Safe Catering — and the joint-product claim from the Irish side

The FSAI publishes the Safe Catering Pack as "a practical, easy-to-use, food safety management system", "designed for caterers but it may also be used by other food businesses", "ideal for businesses that have not yet developed their own food safety management system" (Safe Catering Pack page, fetched 15 Sep 2026). It contains a plan the operator completes, hygiene requirements, a Declaration of Completion and Review, and recording forms. A 31 July 2026 news item added sections on food donations, water supply and food safety culture.

The Record Books page (8 July 2022) lists nine forms: (1) Food Delivery, (2) Refrigeration, (3) Cooking/Cooling/Reheating, (4) Hot Hold Display, (5) Hygiene Inspection Checklist, (6) Hygiene Training, (7) Fitness to Work Assessment, (8) All-in-one daily record, (9) (the page continues; the takeaway-compliance page names SC1–SC9 including Transport and Delivery as SC9). Individual forms can be downloaded free; the pack can be purchased.

HACCP has been a legal requirement for all Irish food businesses since 1998 (FSAI HACCP-based Procedures page, fetched 15 Sep 2026). The Safe Catering Pack is the FSAI's route to one — the same relationship SFBB has to the UK obligation.

29d-1. The form-by-form read — done (#1524, 16 Sep 2026)

⚠️ The paragraph this replaces said the SC-numbering claim "is not confirmed from the Irish side" and left it to #1524. It is now confirmed, partly. Kept as a heading of its own rather than edited away, because the shape of the answer — two-thirds right — is the useful part.

How it was read. All nine recording forms were downloaded from the FSAI's own Record Books page on 16 Sep 2026 (fsai.ie/publications/safe-catering-pack-record-books → fsai.ie/getmedia/…) and their text extracted directly from the PDFs. FSA-NI's safe-catering-recording-forms_0_0.pdf (Issue 7, April 2019) was fetched the same day and diffed against them, so the comparison is sheet against sheet rather than sheet against §14c's prose. Both sets are linked at the end of §14c.

⚠️ What could NOT be read, said plainly. FSAI forms 1, 3, 4 and 8 (Food Delivery; Cooking/Cooling/Reheating; Hot Hold Display; All-in-one) are served as outlined artwork — their titles, SC numbers and a couple of printed example rows extract, their column headers and footnotes do not. Everything asserted about those four below comes from the Record Books page's own one-line description of each, and nothing else. Forms 2, 5, 6, 7 and 9 extracted in full. FSAI_OUTLINE_CHECKS therefore gives the rows derived from forms 1, 3 and 4 no hint at all — a hint is the source's own examples in plain English (#777), and writing one for a form nobody has read is the fabricated-citation move §14c refused for the daily declaration.

The nine slots, FSAI against FSA-NI:

The SC numbering is the FSAI's own, not FSA-NI's read back: SC5 and SC4 are printed on the artwork, SC9 - Transport and Delivery Records and SC6 - Hygiene Training Record extract as text, and four of the FSAI's asset filenames carry the SC number. §14c is corrected accordingly.

SC5 is where the two packs actually part company. Its seven section headings — Hygiene of Food Rooms & Equipment, Food Storage, Food Handling Practices, Personal Hygiene, Pest Control, Waste Control, Checks and Record Keeping — and its three-item "Review (4 weekly)" block are word for word the same in both. Its rows are not. FSA-NI Issue 7 rebuilt Food Handling Practices around a "clean area" concept the FSAI sheet has no trace of, and adds:

• "Is outer packaging removed from ready-to-eat food before being placed into a clean area?"
• "Are suitable BS EN approved cleaning chemicals available…" (FSAI: no BS EN)
• "Are separate cleaning cloths used in clean areas? If they are re-used are they laundered in a boil wash?" (FSAI: "Are cleaning cloths suitable for use and regularly cleaned and disinfected and used properly?")
• "Are wash hand basins clean with hot water…" (FSAI: warm water)
• "Is a separate probe thermometer used for ready-to-eat [food]…" (FSAI: "Are probe thermometers correctly used and cleaned/disinfected before and after use?")

Both carry "Are staff aware of food allergy hazards?", and neither pack's seed carries it as a row — recorded so that is a decision rather than an oversight. SC5's own header actor differs too: FSAI "carried out by the Manager or Supervisor regularly", FSA-NI "by the Proprietor or Manager". Both footers tick Weekly / Fortnightly / Monthly, so #1524 seeds weekly for the same reason #1349 did — the most frequent option offered and the only one of the three the app can express.

🔴 THE THREE DIFFERENCES THAT REACH THE SEED (the rest are recorded, not built):

1. Freezer temperature is expected, not optional. FSAI SC2: "This record book should be used for recording temperatures of fridges, freezers etc … It is recommended that fridge/freezer temperatures are checked at least once per day." FSA-NI SC2: "Some businesses may wish to record freezer temperatures." So the Irish outline carries a Freezer temperature row and the Northern Irish one does not. Both sheets carry AM and PM columns, so both seed a morning and an evening fridge reading.
2. SC5's rows differ (above), so every hint in FSAI_OUTLINE_CHECKS is written from the FSAI's own rows. The seven item names coincide with Safe Catering's because the seven sections genuinely are the same — forcing them apart would have been invention.
3. The temperature figures differ, and Ireland's are stricter. FSAI SC9 and SC2: "Chilled food: 0°C to 5°C; Frozen food: less than or equal to -18°C; Hot food: greater than or equal to 63°C." FSA-NI SC1: "Chilled food: max. 8°C; Hot Food: minimum 63°C", and no frozen figure at all (§14c). Nothing is seeded from this — §C.9 — but it closes half of §14c's GOODSIN_REF_NOTE gap.

Fixed 18 Sep 2026 (#1930). Browser UAT on #1524 found the daily sign-off still quoted SFBB's declaration verbatim to every nation, Ireland included once enabled — only the caption beneath it was attributed-aware. That was #1349's defect, live for Scotland and Northern Ireland, and #1524 left it (dark-groundwork: changing it would have changed what an existing non-IE business sees). The quoted sentence is now absent for the FSAI pack (and CookSafe / Safe Catering), matching attributed: false. Corrected in place in §14c under The daily sign-off.

Verdict for the build: the FSAI outline is built from the FSAI pack, and it differs from #1349's Northern Ireland branch by exactly one row name, every hint, the regulator and the site. FOOD_SAFETY_PACKS.fsai carries attributed: false for the same reason CookSafe and Safe Catering do: the FSAI pack's declaration is the one-off Declaration of Completion and Review signed when the plan is written, not a daily attestation, so the app says "the end-of-day declaration" plainly.

Not seeded, and why: forms 6 (Hygiene Training) and 7 (Fitness to Work) are personnel records rather than periodic monitoring, and form 9 (Transport and Delivery) covers deliveries to customers — #1349 seeded none of their Northern Irish equivalents either, and parity is deliberate. Form 8 folds 1–4 into one sheet, which is a recording convenience, not a different set of checks.

Sources for this pass (all fetched 16 Sep 2026):

• FSAI — Safe Catering Pack — €100, Republic of Ireland shipping only; five new sections (Allergens, Acrylamide, Food Safety Culture, Food Donations, Water Supply) downloadable free
• FSAI — Safe Catering Pack Record Books — the nine forms, free per-form PDF download
• FSA NI — Safe Catering recording forms SC1–SC9 (PDF, Issue 7 April 2019) — re-read for the diff

The FSAI also publishes HACCP Catering, Safe Food To Go, and Starting a Food Business at Home — the last is squarely ProvenBatch's customer. Which of those the seed uses is #1519 / #1524, not this section.

29e. Irish tax figures, and the €10,000 threshold that is not ours

Concrete figures, so #1523 can suppress the UK ones honestly rather than inventing an Irish Accounts tab (out of scope):

Do not read Revenue's €10,000 threshold as ours. TBE manual §2.2 (last reviewed May 2025), verbatim: the €10,000 B2C place-of-supply exception is available only where "the supplier is established, has a permanent address or is residing in only one Member State". And: "The €10,000 threshold does not apply to supplies of TBE services made by a supplier who is not established in the EU." The same sentence is on Revenue's Electronically supplied services page (published 6 July 2026) and on the VAT-thresholds page (6 May 2026), which adds that the €10,000 intra-Community distance-sales / TBE threshold "only applies where the supplier is established and has their permanent address, or usually resides, in only one Member State. Otherwise, the supplier must register for Irish VAT in respect of such supplies."

ProvenBatch is a UK sole trader, not established in the EU. Irish VAT applies from the first euro of a B2C digital sale to a customer in Ireland. That is why #825 §4 made the overseas billing route a gate, and why D-30 picked Stripe Managed Payments rather than non-Union OSS (decisions/1536-overseas-billing-route.md). The €10,000 figure sitting next to the €85,000 / €42,500 domestic thresholds is the intra-EU micro-business one.

The 3.5% Managed Payments add-on (on top of processing + Billing, on the VAT-inclusive amount) is a billing-route finding, recorded in 1536-overseas-billing-route.md §1 / §4 — it was never this allergen section. It is not restated here.

29f. Registration — what a refusal (or a corpus) has to get right

• You have to register your food business before you start operating, even if operating from home. FSAI Register Your Food Business, fetched 15 Sep 2026. Starting a Business: Key Facts: a person proposing to operate a food business "is legally obliged to register with or seek approval from a competent authority prior to commencement of trade, and failure to do so is an offence." The EU obligation underneath is Article 6(2) of Regulation (EC) No 852/2004 (cited on the FSAI hygiene-of-foodstuffs page).
• For restaurants, delis, retailers, mobile stalls and home businesses, that is a notification to the HSE through the local Environmental Health office — not a UK local-authority registration. (DAFM / SFPA for other establishment types.) FSAI Register and Competent Authorities pages, fetched 15 Sep 2026.
• Starting a Food Business at Home is the FSAI document aimed at ProvenBatch's customer (fetched 15 Sep 2026): home does not exempt the operator from Reg. 852/2004, HACCP, training or traceability.

⚠️ Struck, 15 Sep 2026: There is no charge. The business goes on the food business register with a unique reference number and receives an Acknowledgement of Notification of Food Business Establishment letter. The FSAI register page confirms where (HSE Environmental Health) and when (before operating). It does not state that registration is free, and it does not mention an acknowledgement letter. #1525's registration copy says only what the FSAI page says (#1519 §10.4).

ProvenBot's UK corpus is wrong about Ireland in a specific way: the PPDS / Natasha's Law file describes a full-ingredient-list rule Ireland does not have (§29a). A UK answer to an Irish user asking "what goes on my label?" does not merely cite the wrong regulator — it describes obligations that do not exist. #1525 owned the refusal. #1926 replaced that refusal with an Irish corpus (outputs/provenbot/knowledge/ie/); the registration file still says only what this page says, including the 15 Sep strike of fees and acknowledgement letters. The PPDS / Natasha bans stay. Licence: §29h.

29g. English alone satisfies the language rule — no i18n work

S.I. 489/2014 Reg. 5(1)(b): the written particulars must be "at least in the English or in the Irish language and in the English language". GN28 Rev 2 §9: "at least in the English language, or Irish and English languages, although other languages may also be used in addition to, but not instead of English." English alone satisfies it. This epic opens no Irish-language workstream.

29h. FSAI reuse terms (26 Sep 2026) — the licence that shapes the Irish corpus

#1926's first question: the UK ProvenBot corpus is reusable because Crown copyright material is published under the Open Government Licence v3.0. The FSAI is not a Crown body and OGL does not apply to it. The finding, from pages fetched 26 Sep 2026:

Website pages — reuse is permitted, with conditions. FSAI — Open Data and the Re-Use of Public Sector information (fetched 26 Sep 2026) states that the FSAI complies with the regulations on the Re-use of Public Sector Information and encourages the re-use of the information it produces. Verbatim: "All of the information featured on our website is the copyright of the FSAI unless otherwise indicated. You may re-use the information on this website free of charge in any format." Re-use includes copying, issuing copies to the public, publishing, broadcasting and translating. Conditions, as that page lists them: acknowledge the source and FSAI copyright; reproduce the information accurately; do not use it in a misleading way; do not use it for the principal purpose of advertising or promoting a particular product or service; do not use it for illegal, immoral, fraudulent or dishonest purposes. The page cites the Open Data Directive (EU) 2019/1024, transposed by S.I. 376/2021.

Guidance Note 28 Rev 2 PDF — stricter imprint. The publication page (Guidance Note 28, dated Wednesday, 25 June 2025, re-fetched 26 Sep 2026) still presents Revision 2 as the current file. The PDF it serves (gn-28-food-allergen-declaration-for-non-prepacked-foods-in-ireland-rev-2.pdf, 283 KB, 23 pages, fetched 26 Sep 2026) carries on its imprint page: © FSAI 2025; "Applications for reproduction should be made to the FSAI Communications Unit"; ISBN 978-1-910348-99-4. The contents page still carries "Draft / Not for publication". It is nonetheless the file fsai.ie serves as Rev 2 (same flag as the 15 Sep read above).

What that means for the corpus. Website pages are summarised and cited under the PSI terms, with source and copyright acknowledged on every Irish file. GN28 is summarised and cited rather than reprinted, because its own imprint asks for a Communications Unit application before reproduction. That is the conservative shape the terms actually permit. OGL v3 is not claimed anywhere on the Irish files.

Register page re-check (26 Sep 2026). FSAI — Register Your Food Business still says "You have to register your food business before you start operating, even if operating from home." Registration is through the local environmental health office of the HSE, DAFM, or the Sea-Fisheries Protection Authority. It still does not state a fee, a wait, a reference number, or an acknowledgement letter. The 15 Sep strike in §29f stands.

Labelling page re-check (26 Sep 2026). FSAI — Labelling / Allergens still lists food packed on the premises for direct sale (lasagne-in-the-café-fridge) as non-prepacked, still requires a written named-food declaration, and still says "It is not acceptable to say 'Our food contains…'". QR codes alone still do not comply with S.I. No. 489 of 2014.

Claims struck or corrected this pass (15 Sep 2026)

Corrected in place, not deleted — a struck wrong belief stops us rediscovering it.

1. FSAI Guidance Note 28's body is scanned images and could not be text-extracted. Rev 2 (25 June 2025) is real extractable text. OCR not used. The 9 Sep / #1879 "scanned images" premise was wrong for the file fsai.ie currently serves. (Rev 1 was not re-fetched; it is not the current revision.)
2. Guidance Note 28 Revision 1 is the current guidance. Revision 2, 25 June 2025.
3. S.I. 656/2024 updated the allergen-declaration rules. It updated sampling, second expert opinion, compliance notices and service of notices. Regs 3–6 of S.I. 489/2014 are unchanged since 13 December 2014. The FSAI's "updated by" citation remains a correct citation.
4. The FSAI pack uses the same SC-numbered forms as FSA-NI Safe Catering. Not verified from the FSAI's own pages (§29d; struck in §14c).
5. Registration is free and an acknowledgement letter is issued. Not on the FSAI pages this pass read (§29f).
6. Revenue's €10,000 threshold is a threshold we can use. It is the intra-EU micro-business place-of-supply exception. A third-country supplier has no threshold (§29e).

What survived, and is now sourced: PPDS-as-non-prepacked; no full ingredient list; "Contains" tied to the named food; English alone; QUID / date / net quantity not mandatory for this declaration; 14 allergens identical; Safe Catering is the FSAI HACCP pack; Irish VAT 23% from the first euro for a non-EU B2C TBE supply; the US "Contains:" statement is the same derivation with a different slot layout.

The spec that consumes this section is outputs/docs/ireland-jurisdiction-profile-design-record.md (#1519, approved 15 Sep 2026). Do not re-derive the label rows here.

Regulation

Last updated 15 Aug 2026

GoAudits + Labl.it + FSA — UX & layout research for our Food safety checks feature

Started 15 Aug 2026 (GoAudits + FSA). Expanded 15 Aug 2026 with Labl.it and a dedicated Layout & UX section, at Dave's request.

Research commissioned by Dave: dig into GoAudits (goaudits.com — a mature digital inspection/audit app that does FSA-style food-safety checks) and Labl.it (labl.it — a labelling competitor) for interface/workflow/layout lessons, and extract from the official FSA what a food-safety check record actually requires. All strands feed the Food safety feature we already ship (#36 phases 1/2/4 + #440 HACCP authoring).

This doc is the product/UX synthesis. The durable factual record (all source URLs, verbatim FSA quotes) lives in RESEARCH.md §14b (FSA primary-source closure), §15 (GoAudits benchmark) and §15a (Labl.it + layout/UX); this doc does not repeat every citation.

Posture reminder (unchanged): phases 1–2 shipped "names only, no numbers" and #440 ships "structure, never content." Nothing below proposes seeding a user's checks with a pre-filled temperature limit or auto-ticking anything (DESIGN-LANGUAGE "nothing may ever tick itself"). What the FSA research does change is that we now hold primary-source, verbatim numbers — so any reference figure we ever surface (help copy, a "typical outline", an EHO explainer) can be sourced to the FSA caterers pack rather than a food-safety blog.

1. The three products in one line each

• GoAudits — mobile-first inspection/audit platform (the SafetyCulture/iAuditor competitor): checklist → paged mobile inspection → auto PDF report → corrective action → dashboard trend. Enterprise-leaning, ~$10–30/user/mo, no free tier. No purpose-built allergen or SFBB workflow — food safety is generic checklist content. Its interaction & layout design is the thing to learn from.
• Labl.it — a hardware-first subscription prep/date-label printer (6.75" touchscreen device
• web admin), £28–34/mo inc. device, aimed at commercial kitchens (Hilton, Domino's, Turtle Bay). Concierge onboarding ("Menu Analyser" — their team pre-loads your products). No due-diligence / diary / FSA / HACCP product at all (only a passive print-log and a coming TempLog® probe). Its lessons are onboarding, the author-vs-reuse split, passive logging and permission tiers, not screen layout (much of its UI is on a physical device we can't inspect).
• ProvenBatch (us) — Food safety = safety_checks (name / frequency / tick|temperature + targets), a Today strip of what's due, four views (Today's checks / History / Corrective actions / HACCP plans), append-only entries with a correction trail, corrective actions (#182), and an EHO pack export (#441). No photos, no scoring, no signatures, no push.

The competitive picture that matters: the whole due-diligence/FSA-checks category is white space against Labl.it, and GoAudits treats it only generically. We are already the most FSA-specific of the three. So the job is not to copy a category-leader — it's to borrow GoAudits' proven field ergonomics and Labl.it's onboarding/reuse thinking, on top of a feature that already has the right compliance bones.

2. GoAudits — the interaction ideas worth stealing (ranked)

2.1 Failure reveals the fix, inline — "answer No → the corrective-action form appears"

GoAudits' single best idea. A corrective action ("Action Plan") is not a separate menu: answering a question No makes the fix button appear right there, bound to the failing item. The form is exactly four fields — follow-up notes · assignee (with a preconfigured default) · priority (Low/Med/High) · due date — then Save. It surfaces in the report and the Actions tab.

• Our state: we have Corrective actions as a first-class view (#182 "detect, don't decide"), and an out-of-range temperature entry already offers one. But raising it is a hop to a separate tab.
• Lesson: surface the "put it right?" prompt inline at the failed/out-of-range check in the Today strip, pre-linked to it. Small change on machinery we already own. Highest value-to-effort.

2.2 "Fail gates evidence" — the highest-leverage compliance-quality trick

A response option can be configured so answering it forces a comment and/or photo before you can proceed ("auditors cannot move on… unless they insert a comment or add a photo"). The app blocks progress rather than letting an inspector skip evidence on a fail.

• Lesson: when a check is recorded as failed/out-of-range, require the correction note (and, later, a photo) before the entry is accepted. This is fully compatible with our append-only model — it just makes the "what did you do?" narrative the FSA diary demands non-optional on a fail, which is exactly the record an EHO wants.

2.3 Photo-as-evidence, attached to the item, flowing into the report

Every question can carry a photo (capture/upload, with an on-device annotation canvas — draw, save, and the annotation persists into the PDF). Reviewers cite instant photo-embedded reports as the top strength.

• Our state: tick / temperature only; no image capture anywhere; the EHO pack has no photo to print.
• Lesson: optional photo on a check entry (and on a corrective-action resolution) materially strengthens the EHO pack — the evidence an inspector values under "confidence in management" (§6.3). Real storage cost; scope properly.

2.4 The report is the compliance evidence, one tap

Branded PDF at completion — cover page (logo + business + checklist + date), score/grade, per-section results, annotated photos inline, corrective-actions list, a summary field + signature pad, timestamp & geo — auto-emailed to recipients.

• Our state: the EHO pack (#441) is the right idea already; we print, we don't auto-distribute.
• Lesson: we're aligned on concept. Incremental adds: photos in the pack, a signed daily sign-off (§7.2), and share/email (lower priority).

Also aligned/small: dedicated Temperature field type (we have it — correct), voice-to-text comments (a genuine field-ergonomics win for a floury kitchen), N/A that drops out of any denominator (only if we ever score — we shouldn't, §5).

3. Labl.it — a different competitor, and what it teaches

Labl.it turned out not to be a self-serve PPDS design app — it's a subscription thermal-label device for kitchen prep/date labels, with allergens attached to finished products (not derived from ingredients) and set up for the customer by Labl.it's team. It has no recipe/ingredient graph, no real PPDS retail labels yet ("coming soon"), and no due-diligence/FSA/HACCP product. That makes most of our core — and all of our food-safety feature — its white space. But four UX ideas are worth taking:

1. Concierge / import onboarding beats the empty form. Labl.it removes the biggest adoption barrier — data entry — by ingesting a menu the customer already has ("Menu Analyser"). We don't need concierge staff, but we already have parse-recipe / parse-receipt infrastructure: an "import/parse my existing menu or supplier list to seed checks/products" onboarding beats an empty checklist. For food safety specifically, this maps to a one-tap "start from a typical SFBB outline" seed (structure only — §4.1, and #440 decision-5 posture).
2. **Split the author journey from the reuse journey, hard. Their everyday task is 3 taps (category → item → print); authoring is a separate admin surface. For us: recording a due check should be near-zero-friction and must never re-traverse the setup UI.** The Today strip is already this instinct — protect it; don't let "recording today's fridge temp" ever require opening the check editor.
3. Passive audit logging — capture evidence as a byproduct of normal work. Every print is auto-stamped with product/time/staff initials, giving "audit-ready" evidence with zero extra effort. Our append-only entries already do this in spirit; the lesson is to surface that trail as the selling point ("your diary writes itself, and it's EHO-ready"), and to keep capturing who + when automatically (recorded_by) rather than asking.
4. Permission split: edit vs. record. Central admin owns the templates; floor staff can only print. Prevents the exact failure mode of a well-meaning staffer editing a check wrong. Worth mirroring once we have multi-user tenants — an owner defines the checks; staff can only record against them (which also protects the append-only integrity).

And one automatic-emphasis lesson that reinforces our posture: Labl.it makes it structurally impossible to print an un-emphasised allergen (bold is automatic, never user-controlled). Same spirit as our "labels are derived, never hand-edited" — a good reminder for any check that touches allergen accuracy.

4. Layout & UX — concrete suggestions, grounded in our design language

This is the section Dave asked for: specific layout/interaction ideas, reconciled with DESIGN-LANGUAGE.md so they fit our app rather than importing GoAudits' paradigm wholesale.

4.0 The one big design decision: "scattered checks" vs a "run"

GoAudits and the FSA diary agree on a paradigm we don't currently use. GoAudits runs an inspection as a paged session (one question per screen, prev/next, sign off at the end). The SFBB diary groups the day into "Opening checks" and "Closing checks" — each a single grouped attestation, signed once. Our model today is individual checks scattered in a Today strip, each recorded on its own.

The suggestion: offer an "opening checks" / "closing checks" run — a single paged (or single-scroll on desktop) flow that walks the due checks in order and ends with one dated, named sign-off ("Our safe methods were followed and effectively supervised today"). This is simultaneously closer to how GoAudits feels and closer to what the FSA diary literally is — and it doesn't replace the Today strip, it's the thing the Today strip's "X due" chip opens into. Individual ad-hoc recording still works for a one-off fridge reading. This is the highest-value layout idea in the whole research, because both reference points independently point at it.

Constraint it must respect (DESIGN-LANGUAGE "nothing may ever tick itself"): a run pre-fills nothing and has no "mark all done" — each item is still an explicit, individually-taken action; the run just puts them in one ordered place with a sign-off at the end. A grouped attestation is fine (SFBB does exactly that); a defaulted tick is not.

4.1 App-level IA — keep it flat; borrow the "urgency-first home"

GoAudits' whole nav is a 3-item bottom tab bar (Home / Audits / Actions) and an urgency-first home (overdue count front-and-centre, tappable straight to the filtered list). We already lead with Today as the home on every screen (#173) and already show a Food safety block there.

• Keep our four-view segmented control (Today's checks / History / Corrective actions / HACCP plans) — it's our #369 "select switches the section" pattern and it works.
• Borrow the urgency-first treatment: the Today strip's Food safety block should lead with open corrective actions and overdue checks, each a .brow.stack row whose sub is a sentence, with the count as a pill warn (we already do a version of this — tighten it so overdue/ open actions sort to the top).

4.2 The per-check row/card, and the paged runner

From GoAudits' per-question layout (question text → single-select answer row → visible affordance row), adapted to our tokens:

• A check in the run = a card (.card) with the check name as the row title, the frequency as the .sub, then the response control:
• tick checks → a single explicit "Record ✓" action (not a pre-tick), plus an inline "problem?" affordance (see 4.3).
• temperature checks → the numeric input beside the target, using our existing "machine readings shown beside what they'd replace" (#249) treatment: show the target range next to the entry so an out-of-range value is visually obvious the instant it's typed.
• Affordances stay visible, not in an overflow (GoAudits lesson): under each check, a small row — Note · Photo (photo later) · Problem/Corrective action. Labelled, not hidden.
• Progress: on the paged runner, a simple "3 of 8" counter and prev/next; on desktop a single scroll is fine (GoAudits itself uses upload-only/scroll on its WebApp). Default paged on phones.

4.3 Inline corrective action + "fail gates evidence"

Combine 2.1 and 2.2 into our append-only model:

• Recording a tick check as "problem" (or entering an out-of-range temperature) reveals an inline corrective-action drawer at that check, pre-linked to it, with GoAudits' four fields: what you did / who / priority / due date. This is #182's "detect, don't decide" — the app computes out-of-range; the person decides and describes.
• Gate it: on a fail, the correction note is required before the entry commits (the FSA diary's "what did you do?" made non-optional). Respect #182's "don't ask a question the user cannot answer yet" — the gate only fires on an actual fail, never speculatively.

4.4 Corrective-actions list — a quick-filter tab strip

GoAudits' Actions screen is a tab strip (All / Open / Overdue / Closed / In progress) + a filter icon, with overdue elevated everywhere (its own tab, its own count on home). Ours is a flat list today.

• Borrow a light filter row on the Corrective actions view (our #451 filters pattern) with at least Open / Overdue / Closed, and sort overdue to the top. A corrective action is a process record (open→closed), plain-editable per DESIGN-LANGUAGE — this is a display change, not a data one.

4.5 The EHO pack (report) layout

GoAudits' PDF is a good skeleton for what #441 already does: cover (business + logo + date range) → summary → per-section results → annotated photos inline → corrective-actions list → signature + timestamp. We print portrait printdoc (the printAllergenMatrix pattern) already.

• Add over time: photos inline against their entries (§2.3), the daily sign-off attestations as a signature-style block (§7.2), and the HACCP plan section we already ship. Do not add a score/grade band (§5) — that's the one part of GoAudits' report we deliberately omit.

4.6 Onboarding & the author-vs-reuse split (Labl.it)

• Beat the blank checklist: a one-tap "Start from a typical SFBB outline" that inserts neutral, obviously-editable check names only (opening: fridges, staff fit-for-work, areas clean, pest-free, handwashing stocked, hot water, probe working, allergen info accurate; closing: food covered/labelled, use-by discarded, cleaning done, waste out, areas disinfected, washing-up, floors, records complete) — mirrored verbatim from the FSA pack (§6.1) and #440 decision-5 posture (structure, never numbers/hazards).
• Protect the reuse path: recording a due check must never open the check editor. The Today strip → run is the reuse journey; the check editor is the author journey. Keep them separate.

4.7 Small ergonomics worth copying

Voice-to-text on the correction note (kitchen hands are busy/dirty); the temperature field already correct; consistent status vocabulary + pill colour reused across Today, History, Actions and the pack (we already have the pill system — just apply it uniformly: warn for due/overdue/open, ok for recorded/closed).

4.8 Calendar / diary view — well-justified, but anchor it on the FSA weekly grid

Researched as its own question (RESEARCH.md §15a, calendar paragraph). The verdict is yes, worth doing — but be precise about which layout, because the evidence points at a specific shape rather than a generic month grid.

The evidence, ranked:

• Strongest — official and format-specific. The SFBB diary is a calendar: a week-to-view grid, Monday–Sunday, in 4-week blocks each followed by the 4-weekly review, each day cell holding opening/closing checks + "any problems — what did you do?" + Name/Signed. This is the exact paper artifact our target users already keep and EHOs expect to see — direct precedent for a weekly diary layout, and it dovetails with the opening/closing "run" (§4.0).
• Category is mixed on a true calendar grid. SafetyCulture (the leader) does offer a real List / Calendar toggle for scheduled inspections; Lumiform claims one. But GoAudits, Trail, Jolt and Operandio deliberately use daily task lists + due/overdue dashboards, not calendar grids — Trail even markets itself as a digital SFBB-diary replacement yet renders it as a daily list, not a grid. So a month grid is a differentiator, not table stakes.
• Highest everyday value is a "what's due" planner, not the month grid. The market treats the agenda/"due today / this week" surface as the daily driver; the month grid is a secondary "see-the-whole-month / prove-no-gaps" affordance.

The suggestion (layered, cheapest-first):

1. Week view = the SFBB diary page — the anchor. Seven day columns; each day shows its due/ recorded/missed checks and the sign-off state. This is the most defensible default and the natural home for the opening/closing run (§4.0). Reuses our pill colours: warn due/missed, ok recorded.
2. Month view = a compliance-at-a-glance heatmap — one cell per day, green/amber/red for all-done / partial / missed. This is the visual of the "confidence in management" story an EHO scores (§6.3): prove the diary has no gaps. A read projection over frequency + dated entries — no new data.
3. Keep the Today strip as the everyday driver (it already is the "what's due" planner the market values most); the calendar is the review/proof surface it opens into.

Hard constraint (DESIGN-LANGUAGE "nothing may ever tick itself", append-only integrity), as refined by §6.6: a calendar is a read/reporting surface. It must never let a user tap an empty past day to silently back-date a tick — that would falsify a due-diligence record. It shows the gap. It may offer to record an honest late entry for that day (§6.6) — but only one that is stamped with the true "recorded now" time, labelled "recorded late", and shown as such on the calendar (a distinct state, not indistinguishable green). A missed Tuesday either stays visibly missed, or becomes a visibly late-recorded Tuesday — never a silently-perfect one.

5. Scoring — a deliberate non-recommendation

GoAudits scores audits (per-option scores, N/A neutralised, overall % + grade bands, RAG dashboards) — but none of it is exposed in their templates; it's proprietary app logic. The FSA's own SFBB has no scoring at all — it's tick + exception + sign-off, and the inspector scores you (FHRS, §6.3). Labl.it has no scoring either.

Recommendation: do not add audit-style % scoring to daily checks. It misrepresents the SFBB model (pass-by-doing) and invites a "we scored 92% so we're compliant" misread — the exact compliance-claim overreach our posture avoids. If scoring ever appears, it belongs only to a clearly-labelled FHRS self-assessment ("how an EHO might see your records," an estimate, never a verdict) — a separate decision, not part of the daily-checks feature.

6. What the FSA actually requires — and how it validates our design

(Primary-source detail and verbatim quotes in RESEARCH.md §14b — the full 100-page SFBB caterers pack + CookSafe were extracted directly this pass, closing §14/§14a's gaps.)

6.1 The daily diary is exception-based, with a signed sign-off — now confirmed verbatim

Each day = a tick pair (Opening / Closing) + a free-text "Any problems or changes – what did you do?" + Name / Signed under "Our safe methods were followed and effectively supervised today." Validates our simple-tick + separate-corrections design, and the verbatim opening/closing lists (incl. the FSA's own "Allergen information is accurate for all items on sale" opening check) are the source for the §4.6 seed outline. That allergen check ties a legal daily food-safety check straight into our PPDS/label engine — a genuine product hook.

6.2 The numbers now have a primary source (England/Wales/NI)

Verbatim from the SFBB pack + GOV.UK: chilled 8°C (legal) / fridge 5°C (recommended); freezer −18°C; cook 70°C/2min + the equivalence table (80/6s, 75/30s, 70/2min, 65/10min, 60/45min); hot-hold 63°C; cold-display 4-hour rule; probe calibration iced −1 to 1°C, boiling 99 to 101°C. England publishes no numeric cooling/reheat figure. Scotland/NI have a statutory 82°C reheat; England/Wales don't — which is exactly why "store the figure as data, never hard-code" is right.

6.3 FHRS — what our users are judged on, and where our feature moves the needle

An EHO scores three areas (lower = better) and the rating is capped by the worst area, not the average: Food hygiene & safety / Structure / Confidence in management. Confidence in management is the area our feature most directly improves — complete, honest, up-to-date, non-back-fillable records are precisely the evidence of "confidence in standards being maintained in future." This is the commercial argument for the feature, and the copy framing (§7.7).

6.4 Record-keeping / retention — the honest answer

A defensible record needs what / who / when / corrective action / periodic review — all of which our schema captures. No statutory retention period exists (SFBB states none; GB law sets none — duty is "kept up to date and available for inspection"). The app must not assert a fixed legal retention figure.

6.5 Non-operating days — records track operating, not the calendar (VERIFIED, RESEARCH.md §14c)

The FSA does not require a record on a day the business didn't trade. The SFBB diary is built around opening and closing the business ("sign the diary every day… opening and closing checks have been done"), and the legal basis (Reg. (EC) 852/2004 Art. 5, retained) is proportionate to the nature and size of the business — so a seasonal/occasional/part-time business (market stall, event caterer, farm shop closed some days) keeps records for the days it operates, full stop. EHO concern is gaps on days you operated, not blank non-trading days.

• Design consequence: a non-operating day is "not required", not "missed". The app must know when a business operates — via a trading-days pattern (+ ad-hoc closures) or an explicit "open today" action (which also starts the opening-checks run, §4.0) — so the calendar shows closed days as neutral, never red, and "missed" only ever means an operating day with checks not recorded. Forcing a daily cadence on a 3-days-a-week business is our bug, and actively misleading as evidence (it paints a compliant business negligent).
• The one caveat: time-based controls on stored perishable stock (fridge/freezer temps, scheduled cleaning) attach to stock existing, not to trading — so they can still be live on a closed day. Distinguish "closed & empty" (nothing due) from "closed but holding stock" (stock-temperature checks may still apply).

6.6 Late entries — contemporaneous is the ideal; honest late is allowed; back-dating is falsification (VERIFIED, RESEARCH.md §14c)

The sharper principle behind "no back-filling": the integrity requirement is "no falsified records", not "no late records". UK good-documentation practice (MHRA ALCOA+ — the authoritative UK articulation; food EHO/consultant sources say the same) is explicit:

• Records should be contemporaneous (made at the time) — the ideal, and what SFBB assumes.
• A late entry is permitted when it (a) records the true date/time it was actually written, (b) also states the date it attests to, (c) is visibly flagged as a late entry (optionally with a reason), and (d) never overwrites or disguises itself as an original contemporaneous record.
• Back-dating is falsification — fatal to the Food Safety Act 1990 s.21 due-diligence defence, and EHOs reportedly spot back-filled paper diaries "in the first 15 minutes." An honestly-marked late entry is far stronger evidence than a back-dated one (it may read as a minor process weakness; a back-dated one reads as fraud).
• Design consequence: never allow silent back-dating. When a user records after the fact, capture and display both timestamps — the tamper-evident system entry time (immutable, our existing created_at append-only truth) and a new "attests-to" date — and render the entry as "recorded late" everywhere it appears (History, calendar, EHO pack). This removes the barrier for the did-the-check-forgot-to-log business and is exactly what protects their due-diligence defence.

Design principles this research surfaced (proposed — graduate to DESIGN-LANGUAGE.md when built)

Two refinements/additions to our compliance-record design language, both now primary-source-backed:

1. Records track operating, not the calendar (§6.5). "Due" and "missed" are defined relative to the business's operating days, never the raw calendar. A non-operating day is a first-class closed state, not an absence. (New principle.)
2. Never falsifiable, not never-late (§6.6). Refines the append-only rule and the §4.8 calendar constraint: the app forbids back-dating, not late recording. A late entry is allowed iff it is stamped with the true entry time, carries an attests-to date, and is visibly labelled late. (Refines "Append-only records with a correction trail" + "nothing may ever tick itself" — a late entry is still one explicit human action, never a default or a bulk fill.)

7. Recommendations (for Dave to triage into issues — none built)

Organised into waves; nothing here has been built. The GitHub epic mirrors this structure.

Wave 0 — foundational (unblock the rest; encode the two design principles):

• F1. Operating-days / trading-pattern awareness (§6.5) — checks due only on operating days; closed days a neutral state, never "missed"; distinguish closed-but-holding-stock. Unblocks a truthful calendar.
• F2. Honest late attestation (§6.6) — record after the fact with immutable entry time + an attests-to date + a visible "recorded late" marker; never back-date. Data-model + integrity.

Wave 1 — quick wins on existing machinery:

• Q1. Inline corrective action, note gated on a fail (§2.1, §2.2, §4.3) + Open/Overdue/Closed filter tabs on the Corrective actions view (§4.4). Highest value-to-effort.
• Q2. Daily "safe methods followed & supervised today" signed sign-off (§4.5, §6.1) — append-only attestation, verbatim SFBB sentence; strengthens the EHO pack.

Wave 2 — the layout payoff:

• L1. Opening-checks / closing-checks "run" (§4.0) — day grouped into one ordered flow ending in a sign-off, opened from the Today chip. Matches both GoAudits and the FSA diary; no auto-ticking.
• L2. Week (SFBB-diary) + month heatmap calendar view (§4.8) — read-only projection over frequency + dated entries; states closed / on-day / late / partial / missed. Depends on F1+F2.

Wave 3 — depth & evidence:

• D1. "Start from a typical SFBB outline" seed (§4.6) — structure-only check names, verbatim from the FSA pack; #440 decision-5 posture.
• D2. Photo evidence on check entries + corrective-action resolutions (§2.3, §4.5) — real storage cost; high compliance value in the pack.
• D3. Guided 4-weekly review checklist (RESEARCH.md §14b) using the verbatim FSA review items.
• D4. Goods-in / delivery check type (GoAudits "Food Receiving" block) — receipt-parsing adjacency.

Wave 4 — positioning & later:

• P1. Positioning & docs — FHRS-framed value copy (§6.3), "your diary writes itself, EHO-ready" passive-logging framing (§3.3), and sourcing our reference numbers to the FSA pack (§6.2).
• P2. Later / multi-user — permission split (owner authors checks, staff only record — Labl.it, §3.4); voice-to-text on notes (§4.7).

Explicitly not recommended: audit-style % scoring on daily checks (§5); seeded hazard/limit content (unchanged #440 posture); hardware/device dependency (Labl.it's model — our browser-based, print-anywhere approach is a differentiator to keep).

Generated by Claude Code

Capability

Last updated 18 Jul 2026

7. Accounts / simple bookkeeping for home bakers (researched 18 Jul 2026)

(A second §7 by historical accident — citations of "RESEARCH §7" elsewhere may mean either this or Open questions above. Kept unrenumbered so no existing citation breaks.)

Context: Dave wants an Accounts function — record cost of purchases and revenue from customer orders, on a monthly basis. Deliberately not complex given the audience.

What the market/best practice says:

• Keep it simple — no double-entry. Cottage-food / home-baker guidance is unanimous that simple income + expense tracking plus a profit-and-loss report at tax time is enough; double-entry bookkeeping is overkill. Wave (free) or even a spreadsheet is considered sufficient for most. (BakingSubs, FreshBooks.)
• Cash basis is the right default (and now HMRC's default). From 2024/25 the cash basis (record income when money is received, expenses when paid) is the default for UK sole traders, eligible up to £150k turnover ⚠️ corrected 1 Aug 2026 (#341): the £150k/£300k turnover limits were abolished from 2024-25 — cash basis is now available to any size of unincorporated business, and accruals is the opt-out (a tick-box on the return). It aligns taxable profit with actual cash flow and is the simplest mental model for a baker. (CWABC, LITRG; correction ICAEW/ ACCA.) → We should build cash basis. (Also superseded in part: the MTD dates bullet below — see §13 for the confirmed £50k/£30k/£20k phase-in.)
• Trading allowance £1,000. If gross trading income in the tax year is ≤ £1,000, a sole trader needn't register/report; above that they can deduct the £1,000 flat allowance instead of actual expenses. Useful context to surface, not something we must enforce. (LITRG.)
• The three jobs of the software: (1) track income, (2) track expenses, (3) produce a simple P&L. Everything else is a bonus. (BakingSubs, FreshBooks.)
• COGS is an optional advanced layer. Craftybase-style tools compute cost-of-goods-sold per sale from the recipe's material costs and show per-order profit; bakeries target ~40–60% margins. For a simple v1, total purchases as expenses (cash basis) is enough; per-sale COGS can come later and we already have the ingredient/recipe cost machinery to support it.
• Capital items: under cash basis, most equipment is just expensed in the month paid (only cars are special) — so a flat "expense in the month you pay" model is correct. (CWABC.)
• MTD for Income Tax starts Apr 2026 for >£50k income (>£30k Apr 2027) — most home bakers are well under, so not a near-term constraint, but a reason to keep clean monthly totals. (RRAccountants.)

Implications for our build:

• Model as a simple transactions ledger: dated entries, each either income (money in) or expense (money out), with an amount, a category, a note, and an optional link (to a customer order for income, or an ingredient/purchase for an expense).
• Monthly P&L view: pick a month → total income − total expenses = net profit, with a category breakdown. Cash basis (count it in the month the money moved).
• Revenue from orders needs order prices. Orders (#31) currently store no price/total, so to auto-derive revenue we must add a price to orders (this is backlog #61). Decision needed: derive income from orders vs. manual income entries vs. both.
• Reuse existing cost data where sensible (sourcing pack costs, recipe/bake costs) but a purchase is a dated cash event, distinct from the reference unit-cost we already hold.

Sources: see list below (accounting section).

Capability

Last updated 19 Jul 2026

8. Receipt OCR / parsing (researched 19 Jul 2026)

The receipt scanner (#67) uses on-device Tesseract (tesseract.js v5, no upload). Real-world reads were sometimes poor — the worst failure being two physically separate receipt rows collapsing into one item line (e.g. an Aldi receipt merged 496633 BAKING NUTS 1.09 A and 416555 BUTTER UNSALT 250G 7.96 A into a single line, taking only the last price). What the literature says works:

• Reconstruct rows from word bounding boxes, not from the flat text. Tesseract returns every word with a bbox (x0/y0/x1/y1) and a confidence. Grouping words by their vertical centre into rows, then sorting each row left-to-right, recovers the true physical lines even when Tesseract's own text output merged them. This is repeatedly cited as the single most effective fix for receipts (they are relational/tabular documents, not prose). Implemented as linesFromOcrData() (19 Jul), with a safe fallback to data.text when word boxes aren't present.
• Page-seg mode matters: --psm 4 ("a single column of text of variable sizes") suits receipts; we deliberately did not switch to a Tesseract worker to set it — an earlier worker rewrite (v0.24.1) broke the engine to 0 lines (see HANDOVER §4), and the proven path is Tesseract.recognize.
• Drop very low-confidence words to cut noise before row assembly.
• Reference/transaction numbers vary widely (added 19 Jul, v0.36.2). The old parser only read Tesco's 4-group 3RJC-1TRE-M058-YXXL code, so most receipts came through with a blank reference. Receipts label it many ways — Receipt No, Transaction, Trans, Txn, Invoice, Order, Reference/Ref (a genuine receipt number), and Auth Code, Sequence/Seq, EFT (a payment identifier) — or print an unlabelled code (Tesco's 4-group; Aldi's slash-grouped C456/014/807). parseReceiptReference now tries labelled values first (receipt-family before payment-family), then the 4-group, then the slash code, rejecting dates, times, prices and masked card numbers. Don't take Terminal/Merchant ID (not transaction-unique) or the card number.
• Parse defensively: even with good row separation, a line can still carry two price + tax-letter tokens; the parser now splits a row into one item per price token (parseReceipt/splitReceiptRow), handles Aldi's N x unit multiplier rows (qty/unit attach to the following item), and strips the leading 4–14 digit item code from the printed name. This means the merge is fixed at parse time too, independent of OCR quality.
• Summary/total lines survive OCR damage and leak in as items (added 19 Jul, v0.36.3). Seen live: a "Total: GBP 14.14" read as otal: GBP and a "…Items/Sales" total read as Itens Sales both got added as £14.14 items. Exact-word summary matching can't catch a mangled keyword. Two-part defence: (a) OCR-tolerant summary terms (otal for a T-dropped Total, gbp, sales?); (b) a post-parse sweep that drops any parsed item whose description still reads as a summary. Kept it safe — baking-ingredient names don't contain Total/GBP/VAT/Card/etc, so real items aren't at risk — and a price-less pending line no longer flushes on a summary line (which had let an address line leak once GBP counted as a summary word). A fuzzier amount-based total detector (a line whose amount ≈ the sum of the others) was considered but shelved as riskier — it can drop a real single-item line and is unreliable when several total lines repeat the same figure.
• Heavier options exist but don't fit our constraints: cloud OCR (Google Vision, Textract) and LLM-based extractors read receipts far better, but the product's promise is on-device, no upload, photo never stored — so we stay with local Tesseract + smarter parsing. > Corrected 27 Jul 2026 — we did the opposite, and the old promise is dead. The literature was > right that LLM extractors read receipts far better, and that is now the primary path: > parse-receipt (#168, Mobile M2) sends image_base64 to an edge function that reads the photo > with Claude vision. On-device Tesseract survives only as the fallback. Receipt images are also > stored now, in a private bucket with 6-year default retention (#120). > > So "on-device, no upload, photo never stored" is false on all three counts and must never be > repeated in marketing copy — it nearly was, in the 27 Jul commercial report, which is corrected. > The honest privacy claim is UK data residency: the Supabase project is eu-west-2 (London). > The Anthropic call is a US transfer requiring a documented transfer mechanism, and Anthropic is a > sub-processor who must appear on the published list.

Sources: see receipt-OCR entries in the list below.

Capability

Last updated 28 Jul 2026

8b. Dext as a reference for expense capture (#146, researched 28 Jul 2026)

Timeboxed spike, sequenced deliberately before #182 and #183 because what the category leader actually ships should shape both. Dext is the reference point for receipt capture in UK bookkeeping: ~700,000 businesses, Xero Small Business App of the Year 2024.

⚠️ Evidence caveat, stated up front. dext.com and help.dext.com both return 403 through the agent proxy, so none of their own pages could be read directly. Everything below comes from search-result extracts and third-party reviews. It is good enough to shape a design and not good enough to copy a spec from — anything marked below as unconfirmed needs a look at the real app before it drives a build.

What they do that bears on #182 (focused capture)

• No evidence of live edge detection or auto-capture. Repeated searching surfaced capture modes and a crop tool, never an auto-detecting viewfinder. Unconfirmed — absence in search results is not absence in the product — but it is a genuine signal that the market leader has not found live outline detection necessary, which materially lowers the priority of the hard half of #182.
• Crop is POST-capture, via a crop icon on the review screen. That is precisely the fallback #182 offers ("if this can't be done then at least an ability to crop and adjust before saving"), and it is what the leader ships as its primary answer.
• Three capture modes, and this is the most useful finding of the spike:
• Single — one receipt, one page
• Multiple — several separate receipts in one go (up to 50)
• Combine — one document spanning several photos, explicitly for long receipts and multi-page invoices (up to 50)

Combine is how they solve the long-receipt problem — by structure, not by optics. A till roll that will not fit one frame gets photographed in overlapping pieces and treated as one document. That is far cheaper than a clever camera and solves the case a supermarket shop actually produces.

Implication for #182: re-scope it. The expensive part (live outline detection at capture time) has no evidence behind it; the cheap parts — post-capture crop, and a Combine-style multi-photo single document — carry most of the value. Worth re-writing the issue before building. Done 28 Jul 2026: #182 rewritten to exactly that scope, with live outline detection descoped (not rejected) and the original request preserved at the foot of the issue. (Shipped: crop in v0.81.0, Combine in v0.82.0.)

What they do that bears on #183 (email-to-scan)

• Each account gets a unique inbound email address to forward receipts and invoices to. This is the standard pattern and is exactly what #183 describes, so #183's shape is validated.
• "Fetch" pulls invoices directly from supplier portals — a category beyond #183 entirely, and a reminder that email-in is the middle rung: photo → email → direct supplier connection.

Implication for #183: the unique-address model is the right one, and the security questions it raises (who may send to that address, how spoofing is handled, what happens to attachments that are not receipts) are the real work — not the plumbing. Unchanged conclusion: this needs Dave's infrastructure and security decisions before it is buildable. Done 28 Jul 2026: #183 updated with six named decisions (sender authorisation, spoofing / SPF-DKIM-DMARC, address secrecy and rotation, non-receipt attachments, failure visibility, inbound provider and UK data residency) and labelled security — it opens a write path into tenant data authenticated by something other than a signed-in session. (Shipped in v0.80.0; the decisions are §8d and the Worker README.)

What they do that we could extend cheaply

Supplier Rules — per recurring supplier, default the category, tax code and payment method. "Always categorise Costa Coffee as Meals & Entertainment." We already have supplier profiles (#101) that resolve a merchant name from a receipt ("TESCO STORES 3294" → your "Tesco"). Extending those to carry a default expense category is a small change on top of something that exists, and it attacks the same zero-typing goal M1 is for. Raised as #245 on 28 Jul 2026 (M1). Reading the code sharpened the case: #69 catalog matching already sets a category per line, so the real gap is the unmatched line, which falls back to "Supplier products" unconditionally — wrong on every line for a packaging or equipment supplier, and wrong most often during onboarding, when the catalog is empty so nothing matches. Tax code and payment method were deliberately left out: we have no such fields, and inventing them to complete someone else's feature would be building for an accounting workflow nobody has asked us for. (Shipped in v0.76.0.)

Line-item extraction — individual items, not just totals. We already do this, which is worth recording: on the capability that matters most for costing, we are not behind.

The accuracy claim, read honestly

Dext markets "up to 99.9% accuracy" for supplier, date, totals, tax and line items, "verified across millions of documents". Treat as marketing, not a benchmark: self-reported, no published methodology, no error taxonomy, and "up to" is doing real work. It is not a bar we have been shown to fall short of, and it should not be quoted back at us as one. Our own evidence base for parsing quality remains §8a, built from real receipts.

Sources: Dext receipts scanner product page · Dext capture product page · Dext Help — line item extraction · Dext Help — mobile app upload · Dext review, dupple.com · Dext review, aitoolshop.co · Dext on the Xero App Store (all read via search extracts on 28 Jul 2026 — the dext.com and help.dext.com pages 403 through the proxy)

Capability

Last updated 28 Jul 2026

8d. Inbound email providers and UK data residency (#183, researched 28 Jul 2026)

Decision 6 of #183 — the only one Dave left open. Brief: keep UK data residency if we can.

The framing that resolves it: residency is about STORAGE, not about every processor

The claim in §8 is "UK data residency — Supabase is eu-west-2 (London)", and it replaced a false claim that receipts never leave the device. It has never meant "no byte ever leaves the UK" — Anthropic already processes every scanned receipt (#168) and is named as a sub-processor for exactly that reason.

So the question is not "can mail be received in the UK" but "where does a durable copy come to rest?" If the inbound provider is configured to retain nothing — parse, hand the attachment to Supabase in London, keep no copy — the only lasting copy is in the UK and the claim stands, with a line added to the sub-processor list.

Legally, EU hosting is fine either way. UK adequacy regulations cover the EEA, and the European Commission renewed its UK adequacy decisions on 19 Dec 2025, so data flows both directions with no additional safeguards. This is a claim-accuracy question, not a lawfulness one — but the ICO still expects proportionate checks on the recipient, which is an argument for a provider with a real EU region rather than a global one that merely might keep data close.

The candidates

⚠️ AWS SES CANNOT RECEIVE MAIL IN LONDON. From AWS's own documentation source: email receiving is supported in us-east-1, us-west-2 and eu-west-1 only, and Europe (London) appears explicitly on the "not supported" list alongside Frankfurt, Paris, Milan and Stockholm. This is the single most decision-relevant fact here — the obvious "just use SES in the same region as Supabase" answer does not exist. (One 2026 third-party guide referenced an inbound-smtp.eu-west-2 endpoint, which contradicts the docs; the AWS source was read via its GitHub docs mirror, which can lag. Confirm in the SES console before relying on it either way.)

Cloudflare is the interesting one. It is already in the stack — support@provenbatch.co.uk runs on Email Routing (free, #213) — and Email Workers process inbound mail through an email() handler that streams rather than stores, which is exactly the "retain nothing" shape the framing above wants. If processing is transient and the attachment goes straight to Supabase, residency of stored data is preserved by construction and no second vendor enters the stack. But Cloudflare is a global edge network and their residency guarantees are a paid add-on (Data Localization Suite), and their docs 403 through the proxy so this could not be confirmed. Worth 30 minutes before defaulting to Mailgun, because if it holds it is clearly the best answer.

⚠️ This was answered on 29 Jul 2026 — see §8d-1 below. Short version: the guarantee does NOT exist at our tier, and we took Cloudflare anyway, for reasons that are written down rather than assumed.

Recommendation

1. Check Cloudflare Email Workers first — already in the stack, free, streams rather than stores. If it retains nothing, take it.
2. Otherwise Mailgun EU — a real EU region and the strongest inbound parsing of the three.
3. AWS SES eu-west-1 as the cheap fallback, noting it puts an Irish S3 bucket in the path unless the object is moved to Supabase immediately and deleted.
4. Rule out Postmark and SendGrid on residency alone.

Capability

Last updated 29 Jul 2026

8d-1. The Cloudflare answer, and what we actually shipped (#183, 29 Jul 2026)

The 30 minutes above were spent. The answer is not the comfortable one, and the distinction matters more than the verdict.

What is true

• Data Localization Suite is Enterprise-only. There is no contractual residency guarantee available on our plan, at any price short of Enterprise. The "needs proof" verdict above was looking for a guarantee that does not exist for us.
• But Email Workers genuinely stream. Mail arrives at an email() handler; nothing is persisted unless the Worker opts in to Cloudflare-side storage — KV, Queues, D1, R2, Durable Objects. Storing an inbound message in KV is a documented pattern, but it is a pattern you choose, not the default.

So both halves of the earlier hope were right and wrong at once: the behaviour is what we wanted, the guarantee is not available.

What we decided, and the honest framing

We took Cloudflare and shipped it in v0.79.1. The reasoning, stated plainly so nobody later mistakes it for something stronger:

The residency position rests on "no durable copy comes to rest at Cloudflare" — which is the framing §8d established and which is satisfied by construction, because the Worker declares no storage bindings at all. It is a framing, not a guarantee. If a customer ever asks for a contractual residency commitment, the honest answer is that we do not have one from Cloudflare, and the remedy is Mailgun EU.

That remedy stays cheap on purpose: the Worker is a thin adapter (~200 lines), and everything around it — the token, the allowlist, the source='email' row, the review queue — is provider-independent. Swapping providers is a rewrite of one file, not an architecture change.

🔴 The invariant, and why it is enforced three times

The whole argument collapses the moment someone adds a storage binding "just for a cache" or "just for rate limiting". That is a one-line change that silently retires a privacy claim, so it is guarded at three levels, deliberately redundant:

The third is the real one: it makes the invariant unforgeable rather than merely asserted. If a future change genuinely needs Cloudflare-side storage, widening that token is the moment to stop and re-read this section, rather than discovering the claim was quietly false months later.

Rate limiting is counted in Postgres for exactly this reason — the obvious place for it would have been KV, and that would have cost the argument.

The sub-processor consequence is better than expected

§8d assumed taking Cloudflare would add "a line to the sub-processor list". It adds nothing. D-12 already lists Cloudflare (hosting + DNS, corrected 29 Jul when Netlify was retired by D-20/#251), and D-20 moves the app, staging and both marketing sites onto Cloudflare Workers anyway.

So the choice that looked like it needed a residency proof turns out to add no new vendor, no new disclosure and no new cost — which is a materially stronger position than the Mailgun alternative, where a genuine second processor would have entered the stack. Worth weighing against the missing guarantee rather than treating the two as separate questions.

One more thing worth recording: DMARC's limit

Not residency, but it surfaced building this and belongs with the evidence base. DMARC authenticates the domain in From:, not the local part. It proves a message came from gmail.com; it does not prove it came from that Gmail user. For the big providers the distinction is academic — they do not let one account send as another. On a small self-run domain where any user can send as any address, allowlisting one person there effectively trusts everyone on it. That is a property of email, not a fixable defect, and it caps how much the #183 allowlist can promise.

Whichever is chosen: configure retention to zero, and add the provider to the published sub-processor list beside Anthropic.

⚠️ Evidence caveat. Only the AWS regions list was read from a primary source (AWS's own docs mirror on GitHub). developers.cloudflare.com, docs.aws.amazon.com and the Mailgun docs all 403 through the agent proxy, so the Cloudflare and Mailgun findings are search-extract evidence. Good enough to shortlist; not good enough to sign a contract on.

Sources: AWS SES regions — email receiving · AWS SES regions (docs) · Cloudflare Email Workers API · Cloudflare email storage and processing · Mailgun GDPR / EU region · Postmark vs Mailgun 2026 · ICO — adequacy regulations · ICO — data protection and the EU (read 28 Jul 2026; Cloudflare, AWS docs and Mailgun docs 403 through the proxy)

Capability

Last updated 28 Jul 2026

8c. BarcodeDetector on Safari — the WASM fallback is NOT dead weight (#170, checked 28 Jul 2026)

#170 says "BarcodeDetector where available + lazy-loaded WASM fallback (verify Safari support at build time)", and HANDOVER carried the hope that if Safari had shipped it the fallback could be dropped before it was ever written. It has not shipped. The fallback is the primary path on iOS, not a contingency, and that should be assumed from the start of the work rather than discovered halfway through.

What the evidence says, consistently across several independent sources:

• Not implemented in WebKit, and since every browser on iOS is WebKit, that means no iOS browser has it — not Safari, not Chrome for iOS, not Firefox for iOS.
• There is a partial implementation behind a feature flag, off by default. Guidance is explicitly to treat it as unavailable, because no ordinary user has toggled it.
• WebKit bug 281848 — "Shape Detection API doesn't work on iOS" — reports it broken since the iOS 18 update, i.e. the flagged implementation is not merely absent but faulty.
• Chromium-only in practice (as of early 2025 reporting). Firefox has a request ticket that has not been worked on.
• Not a W3C standard and not on the Standards Track — the Shape Detection APIs remain a draft.

Two consequences for how #170 gets built:

1. The WASM decoder is the iOS path, so it must be the well-tested one. Dave's own devices are iPhones and both known PWA installs are phones — so on the hardware this feature exists for, BarcodeDetector will essentially never be the code that runs. Building it "native first, fallback later" would test the branch that matters least.
2. ⚠️ Feature-detect by CAPABILITY, not by existence. 'BarcodeDetector' in window is not safe here: a user who has enabled the experimental flag would pass that check and then hit the broken iOS implementation. The detection must actually attempt a decode against a known image and fall through to WASM on failure or exception. An existence check would produce a scanner that silently never reads anything — precisely this project's recurring failure shape.

Re-check trigger: worth asking again only if WebKit's standards position changes or a WWDC release notes it. Nothing here is time-sensitive — the answer has been stable for years.

⚠️ Evidence caveat. developer.mozilla.org and caniuse.com both 403 through the agent proxy, as does bugs.webkit.org, so none of the primary compatibility tables could be read directly. This is search-extract evidence, consistent across sources but not first-hand. A five-minute check on a real iPhone would settle it beyond doubt, and that check is anyway needed before #170 ships.

Sources: MDN — Barcode Detection API · MDN — BarcodeDetector · caniuse — BarcodeDetector · WebKit bug 281848 — Shape Detection API doesn't work on iOS · WebKit Standards Positions · Chrome Platform Status — Barcode Detection API · Barcode Scanning on iOS: The Missing Web API and a WebAssembly Solution · soledad penadés — On barcodes and Web APIs (all read via search extracts on 28 Jul 2026 — MDN, caniuse and bugs.webkit.org 403 through the proxy)

Capability

Last updated 13 Aug 2026

8a. Supplier receipt formats — living record (started 19 Jul 2026)

Why this exists: rather than hand-build brittle per-supplier parsers now (premature — the generic parseReceipt already handles the observed variation, and we have no evidence of which suppliers it fails on), we keep a record of each supplier's receipt layout as real receipts come in. This is the evidence base: if a specific supplier keeps parsing badly, this tells us exactly what a targeted tweak would need to do. (13 Aug 2026: a plan to make this loop systematic — DB-backed chain profiles feeding the AI parser, cross-tenant quality telemetry, admin-console curation — is drafted in outputs/docs/receipt-parsing-knowledge-base-plan.md, awaiting Dave's decisions.) Add a supplier's row the first time you scan one of their receipts; note anything the generic parser got wrong. Fields: item-line shape · where the qty×unit sits · tax letters · date format · a reference/fingerprint unique to that chain · footer keywords · parser notes.

Aldi (id 3) — observed 19 Jul 2026 (real receipt, Aylesbury store).

• Item line: <6-digit code> <NAME> <price> <taxletter> e.g. 417009 EGGS LARGE FR 12PK 8.67 A.
• Multi-buys: a separate line ABOVE the item, N x <unit> e.g. 3 x 2.89 (3 × £2.89 = £8.67). Single items have no such line.
• Tax letter: single A (zero-rated shown as A 00.0% Net). Date: dd.mm.yy in the payment block (*9509 C456/014/807 14.07.26 08:55).
• Reference / transaction number = the Cnnn/nnn/nnn slash code on the payment line (e.g. C456/014/807). Settled 20 Jul after iterating: took the slash code, then the *NNNN, then the *NNNN+slash combined — all imperfect/fiddly — so per Dave we simply take the slash code. NOT the *NNNN, NOT the Auth Code. parseReceiptReference reads the slash code ahead of payment labels, skipping dd/mm/yyyy dates (v0.36.6).
• Header ALDI STORES + address. Footer: Total, N Items, Card Sales, Goods:, A 00.0% Net … Vat.
• Repeated-unit lines: Aldi prints each unit of a product on its own line with the same code + name + price (not N × name) — e.g. 7 separate 387457 SUGAR SOFT 500G 1.09 A lines. It also uses a N x unit multi-buy line above one item (e.g. 12 x 1.45 → one 12-pack). The parser handles both: N x unit sets qty on the next item; identical repeated lines are aggregated by name+unit price into one line with the summed qty (v0.37.0, backlog #114).
• Promotions/discounts print as a Promotion header + BUY 2 … FOR £x -0.19 lines (negative amount) — dropped (negative-amount lines are skipped). VAT-rate lines (A 00.0% Net … Vat) and the *ref line (*0132 C456/002/012 18.06.26 13:11) are dropped as footer/date lines.
• Parser status: handles the long/dense receipt — code stripped, N x unit → qty, repeats aggregated, promos/footer dropped, slash-code reference captured. Remaining risk is raw OCR quality on a long, crumpled thermal receipt (garbled names won't aggregate with their clean twins).

Tesco (id 1) — observed from an earlier real photo + test fixture.

• Item line: usually <qty> <NAME> <price> (name-led, £-prefixed prices common), e.g. 2 Tesco Baking Spread 500g £3.00; sometimes the price OCRs onto its own line below.
• Unit price printed as a separate £x.xx each line (ignored by the parser).
• Reference: 4 hyphen groups by the barcode, e.g. 3RJC-1TRE-M058-YXXL (parseReceiptReference). Date dd/mm/yyyy. Footer: Subtotal, TOTAL, Clubcard, Card.
• Parser status: handled well; watch for Clubcard/points lines (already in the summary filter).

Asda (id 18) — real evidence via #148 (22 Jul 2026); layout notes web-researched.

• Tax letter prints AFTER the amount: V = standard-rated, D = zero-rated (groceries/fresh), M = kiosk/tobacco standard, blank = exempt (postage/lottery). The parser's price regex already tolerates one trailing letter, so these don't corrupt the amount.
• Reference = the TC transaction code — a long grouped run of digits near the footer, e.g. TC: 3757 5108 7387 3809 4787 0 (REF_ASDA_TC, grouping preserved). VAT no. GB 362 0127 92 at the bottom. Date dd/mm/yyyy.
• Parser status: TC captured (v0.47.0 #148); profile prefers it first (v0.48.0 #101).

Web-researched core notes (v0.48.0 #101) — not yet confirmed against a real receipt

These seed each supplier's profile so parsing is supplier-aware the moment the user picks the shop (#150). Treat as provisional until a real receipt lands — then correct in place and promote to a dated "observed" block above. Encoded in the app as SUPPLIER_RECEIPT_PROFILES (keyed by chain name, never id); this record is the human-readable mirror.

• Sainsbury's (id 5): name-led item lines; Nectar points footer; transaction number is labelled (generic Tier-1 label reads it) — no distinctive unlabelled fingerprint confirmed, so the profile forces none. Date dd/mm/yyyy.
• Costco (id 17): item-number-led lines <item#> <SHORT CAPS DESC> <price> <A|E> (A = taxable, E = exempt — shopper convention, varies by location); member number in the header; the 4–14 digit leading-code rule already strips the item number. Transaction/receipt number is labelled/barcoded.
• B&M (id 16) and The Range (id 4): standard thermal; labelled transaction/receipt number (generic Tier-1); VAT number in the footer. No distinctive fingerprint yet — capture on first scan.
• Online / trade suppliers — Amazon (10), Vanilla Mart (11), Sephra (6), Ingenious Edibles (8), Rainbow Dust (9): these send invoices / order confirmations (tabular line items, VAT breakdown, a labelled Order/Invoice number the generic Tier-1 reads), not thermal receipts. Flagged invoice: true; item parsing may need an invoice path when a real one is captured.

Still fully uncaptured (no evidence, no research beyond "it's a till receipt"): none of the above block — every current supplier now has at least researched notes. Homemade (7) isn't a real receipt. When any real receipt arrives, replace its provisional block with a dated observed one.

Irish (EUR) receipts — #1521, 3 Oct 2026: no real Irish receipt has been recorded yet. The euro path (parse-receipt's EUR block, the on-device fallback) is built against the shapes the issue names — € before or after the amount (€2.45, 2,45 €, 2,45€), comma decimals, N x €unit multi-buy rows, VAT rate letters keyed at the foot, day-first dates — as constructed fixtures in outputs/tests/ireland1521.js, not as observed formats. When the first real Irish receipt is scanned (Dunnes, SuperValu, Tesco IE, Aldi IE, Lidl IE — the chain fingerprints are their own issue), record its row here as for the UK chains above and correct the fixtures to match. Grouped amounts (1.234,56, 1,234.56, also with a glued VAT letter, 1.234,56A) are read as one number on the euro fallback up to 9.999,99 (#3106 reviews). A space-grouped amount (1 234,56, ASCII or no-break/thin space, which may be a quantity and a price: 12 100,50) and any amount of five or more integer digits (10.500,00, 12345,67, which the price reader would otherwise read as its last four) are kept with a blank amount for the user to fill, never guessed. GBP (#3114, 4 Oct 2026): the UK fallback had the same gaps (£1,234.56 read as 234.56, 12345.67 as 2345.67). It now joins a comma-grouped amount (1,234.56 → 1234.56; a UK receipt never groups with a dot) and keeps a five-or-more-digit or malformed amount (1,234,56, 1.234.56, 12.34,56, 1.234,56) blank. An ordinary space is not GBP grouping (stand-in review of #3151): UK receipts do not group pounds with a space, but wholesale rows print "description qty price" (Wholesale Eggs 30 120.00 = £120.00), which must keep reading correctly, so only typeset no-break/narrow/thin-space grouping is kept blank. The cost, accepted: a genuinely space-grouped 1 234.56 would read as 234.56. The euro fallback keeps a malformed one blank too since #3142 (4 Oct 2026). Also 4 Oct (#3153, #3155): a GBP refund printed -£1.00 is skipped as a refund (the £ used to hide it, so it became a +£1.00 item), a minus glued between digits (Item 12-1,234.56) is an item code, not a refund, and a dd.mm.yy date inside an item line with 6+ letters (Wedding Cake 01.10.26 25.00) is lifted out before the line is read, on both currencies — the date is never the price and never its tail. A dated line whose remaining amount is time-shaped (0.00–23.59, one- or two-digit hour: Served by Sarah 04.10.26 14.32 as UK tills print it, and Birthday Cake 01.10.26 4.50, which cannot be told from 4.50 am) is kept blank, never priced at the time (stand-in reviews of #3161; Dave's rule). #3168 / #3157 (4 Oct 2026): the euro refund test now matches GBP's (any number of integer digits, the U+2212 minus), and the euro unreadable-amount rule's left boundary is (^|\D), so Mehl A,12345,67 is blank, not its tail. An ASCII-space 1 234.56 on GBP stays read as 234.56 by decision: it is indistinguishable from "qty 1 at £234.56", the other reading of the same characters — only a real receipt grouping pounds with a space would change that. A dated item start that is superseded by a priced line is kept as a blank item; an undated one is still dropped, because on the real receipts in receipt.js those are address and header lines.

Sources: real Aldi receipt (Dave, 14 Jul 2026); real Tesco receipt + receipt.js fixtures; real Asda TC (Dave, #148); web research on Tesco/Asda VAT-code letters and Costco receipt layout (22 Jul 2026, see §Sources — smallbusinessowneradvice.co.uk Tesco/Asda VAT FAQs, pricematcher Costco guide).

Capability

Last updated 1 Aug 2026

13. Accounting capability: Self Assessment, MTD, and the FreeAgent benchmark (#341, researched 1 Aug 2026)

Full report: outputs/docs/accounting-capability-research.md (current state from the code, the HMRC Self Assessment bar, gap analysis, MTD for VAT/ITSA, FreeAgent as reference, positioning recommendation, sized shortlist). It carries its own source list, with the same proxy caveat as §12 (GOV.UK unreachable directly; search-excerpt evidence cross-checked against ICAEW/ATT/ACCA/ LITRG). Headlines worth having here:

• The Self Assessment bar is lower than "accounting software" implies, and we're closer than feared. Records in any format (photos fine), kept ~5 years past the 31 Jan deadline (our 6-year image retention already conservative); cash basis is HMRC's default and our stated basis; flat "equipment expensed when paid" is correct cash-basis treatment; SA103S wants nine expense boxes — or a single total-expenses figure below £90k turnover.
• The structural gap is non-order income. Income derives only from Collected+priced orders — a market-stall business's walk-up takings can't be recorded at all, so the app can't hold complete income records for a big slice of the D-24 target. Shape the fix as daily takings entries — exactly the record HMRC's retail relaxations expect (VAT and MTD ITSA both).
• "Letal bank" resolved: it's Mettle (as #270 already records). FreeAgent is free with NatWest/RBS/Ulster/Mettle business banking (Mettle: ≥1 transaction/month) and the free version is the full product — so competing with FreeAgent on accounting is competing with free. FreeAgent's own KB declares stock/inventory out of scope (unavailable on cash basis at all) and tells users to run a specialised system and post summaries in — we are the complement, not the competitor.
• MTD for VAT: CSV export/import is explicitly a valid digital link (Notice 700/22 s4.2.1; only copy-paste breaks the chain), and bridging software is permitted indefinitely — so "export what a bridging tool needs" is a legitimate, compliant scope. Direct API filing is not worth it.
• MTD for Income Tax is live (6 Apr 2026, > £50k gross; £30k Apr 2027; £20k Apr 2028, assessed on 2026-27 income — SI 2026/336). Qualifying income is gross turnover, not profit, so the 2028 wave catches real target users (~£400/week). Mandated users need commercial software even for the year-end return. The record-keeping half of the products-working-together model needs no HMRC recognition and no fraud-prevention headers — becoming "recognised software" is a permanent compliance treadmill (device-data fraud headers on every call, spec change-log, strengthening-standards programme) and not worth pursuing.
• Positioning: operational record-keeper with clean handoff. For sub-threshold users, ProvenBatch alone can honestly cover Self Assessment once income is complete; for everyone else, the job is no-re-keying exports into FreeAgent/accountant/bridging software. Never claim "MTD compatible/recognised" — say "keeps the digital records; exports them for your MTD software or accountant".
• Sized shortlist (full table §7 of the report): the first slice is other income/daily takings (M) + tax-year P&L (S) + accountant export pack (S–M) + SA103 box mapping on categories (S) — all one-off builds, no compliance tail. Mileage log, home-working flat rate, personal-use flag, paid-date on orders, VAT-threshold nudge are all S. Order invoice PDF is M and judged in scope (operational, not accounting). A FreeAgent-style tax set-aside estimate is the first feature with a real ongoing tail — deferred. Out of scope: bank feeds (FCA/ aggregator territory), VAT bookkeeping, any HMRC API, double-entry/balance sheet, payroll.
• One dated caveat for future readers: the 2026-27 mileage flat rate rose 45p → 55p (first 10,000 miles; announced 21 May 2026, backdated to 6 Apr) — many guides still show 45p, which remains correct only for 2025-26 returns.

Full write-up

From outputs/docs/accounting-capability-research.md

Accounting capability — what "basic accounting" should cover (#341)

Researched 1 Aug 2026, against app v0.95.0. ✅ Epic #346 subsequently built the core scope (v0.116.0–v0.124.0, closed 5 Aug 2026); the VAT/export analysis remains the standing reference for what was deliberately not built. This is the full write-up for issue #341 — a research issue. RESEARCH.md §13 carries the headlines; this document carries the detail and the sizing, so a future session can turn it into scoped build issues.

The question: what is genuinely missing for a small food business to run its basic bookkeeping through ProvenBatch well enough to do a Self Assessment tax return, or hand clean records to an accountant, without keeping a second system in parallel — and how big is closing that gap?

1. What Accounts does today (v0.95.0, from the code)

The Accounts tab (index.html, renderAccounts() and around) is a monthly cash-basis money-in / money-out record:

• Income is derived, not entered: orders with status = "Collected" and a price, counted in the month of collected_at (fallback due_date). collected_at is stamped when the order is advanced to Collected and is explicitly commented as the "cash-basis income date". Collected but unpriced orders raise a "heads up" strip and are excluded until priced. There is no other income path — no manual income entry, no till/stall takings, no non-order income of any kind.
• Expenses are a flat categorised ledger (expenses: spent_on, category, amount, supplier_id, receipt_ref, item links). Five categories, fixed: Supplier products, Packaging, Equipment, Fees, Other (EXPENSE_CATEGORIES, CHECK-constrained in both DBs). Lines link to saved items per category (supplier products / packaging / equipment / fees), suppliers carry an optional default category (#245), and items can be moved between categories with their expenses.
• Capture is strong: multi-line expense form, on-device OCR receipt scanning with AI parsing (parse-receipt), supplier auto-detection, supplier-scoped item matching, inbound email capture, and a receipt-drafts inbox. Receipt images are stored privately with the expense, deduplicated, with a retention setting defaulting to 6 years "in line with HMRC record-keeping", a review-&-purge flow and per-image "keep forever" pins.
• Reporting is one month at a time: Income / Expenses / Net profit KPIs, expenses-by-category, income-by-order, searchable expense list. ‹ › month navigation only — no year view, no tax-year view (6 Apr–5 Apr), no export of the P&L, no category totals across months.
• Export: the #209 full tenant export (Settings) produces a zip with one CSV per table — expenses.csv, orders.csv etc. — raw table dumps for portability, not accounting-shaped output. #337 (single multi-tab spreadsheet) and #338 (CSV import) are open follow-ons.
• The page footer states the basis plainly: "Cash basis: income counts in the month an order is collected; expenses in the month you paid. A simple record for your own books — not tax advice."

What does not exist anywhere in the app: VAT (the only "VAT" in the codebase is the receipt scanner's regex for discarding summary lines), invoicing, payments/paid-status on orders (price and collected date only), bank feeds or reconciliation, chart of accounts, mileage or use-of-home records, drawings/personal-use records, capital allowances, balance sheet, tax-year anything, MTD anything.

2. What HMRC actually requires for Self Assessment (the bar to clear)

(Researched 1 Aug 2026. GOV.UK is proxy-blocked from this sandbox, so facts were assembled from search excerpts of GOV.UK/HMRC PDFs cross-checked against professional bodies (ICAEW, ATT, ACCA, LITRG). Figures worth re-verifying against GOV.UK before hard-coding are flagged.)

The bar is genuinely low — much lower than "accounting software" implies:

• Records: all sales and income; all business expenses; the evidence behind them (receipts, bank statements, invoices, till rolls). No prescribed format — "on paper, digitally or as part of a software program"; photos/scans of receipts are acceptable. Records are kept in case HMRC asks (penalty up to £3,000/year for inadequate records), never submitted.
• Retention: at least 5 years after the 31 January filing deadline (≈ 5¾–6¾ years after the transaction). Our receipt-image default of 6 years sits at the bottom edge of the worst case — fine in practice, and the setting already allows longer. VAT-registered businesses: 6 years.
• Cash basis is now the default (since 2024-25; turnover limits abolished — any size unincorporated business). Accruals is the opt-out, ticked on the return. Under cash basis: income when received, expenses when paid, no debtors/creditors/stock valuation at year end, and equipment is simply an expense in the month paid (capital allowances survive only for cars). Our model's basis and its flat treatment of equipment are both correct, not naive.
• The return itself (SA103S, turnover < £90k) wants remarkably little: turnover, and expenses in nine boxes (goods bought for resale/used; car/van/travel; staff; rent/rates/power/ insurance; repairs; professional fees; interest/bank charges; phone/stationery/office; other). Below £90k turnover there is a further easement: a single total-expenses figure is permitted with no itemisation at all. Tax years run 6 Apr–5 Apr.
• Simplified expenses (optional flat rates): business mileage 45p/mile first 10,000 (2025-26), ⚠️ raised to 55p for 2026-27 (announced 21 May 2026, backdated to 6 Apr — many guides still say 45p), 25p after; working-from-home £10/£18/£26 a month by hours band (25–50/51–100/101+) — though a baker's oven-heavy electricity may beat the flat rate via actual-cost apportionment.
• Trading allowance: gross trading income ≤ £1,000/year needs no registration at all; above it, register by 5 October after the tax year, then deduct EITHER the flat £1,000 OR actual expenses — never both. (A £3,000 reporting threshold was announced for "this Parliament" but is not in force — watch, don't build.)
• Drawings are never an expense; goods taken for personal use under cash basis are handled by disallowing their cost (under accruals, by adding market value to income — the Sharkey v Wernher rule). Private shares of mixed costs (phone, car, home) are apportioned "just and reasonably".
• VAT: registration threshold £90,000 taxable turnover in any rolling 12 months — and zero-rated food sales (most cold bread/cakes) still count toward the threshold, a genuine trap for a growing bakery. Registering makes MTD for VAT mandatory (digital records, software filing) — a step-change in bookkeeping burden.
• NIC: compulsory Class 2 is gone (since April 2024); Class 4 is 6% between £12,570 and £50,270, 2% above, assessed from the return — nothing to book in-year. Below the small-profits threshold (£6,845 in 2025-26) voluntary Class 2 (~£3.50/wk) protects the State Pension — a prompt worth surfacing one day, not a bookkeeping feature.

3. Gap analysis — today's model vs "good enough" bookkeeping

Measured against §2, what we have is closer than the issue feared, with one structural hole.

Already right (and worth saying so):

• Cash basis, correctly stated in the UI, is HMRC's default. Flat "equipment is an expense when paid" is the correct cash-basis treatment, not a simplification.
• Expense records — dated, categorised, supplier-linked, searchable — with receipt evidence attached, privately stored, deduplicated and retention-managed already exceed what most sole traders hold. The evidence side is our strongest suit.
• Income from orders is a true record of what was earned from whom, better than a bare till total.

The gaps, in order of how much they block "do a return from this app alone":

1. Non-order income doesn't exist. Income is only derivable from Collected+priced orders. A market-stall or farmers'-market business — squarely in D-24's target — takes most of its money as walk-up sales with no order behind them. Until takings can be recorded directly (a dated "money in" entry: stall day, till total, other income), the app cannot hold complete income records for a large slice of target users, and nothing downstream (year totals, return prep, accountant handoff) is trustworthy. This is the structural gap.
2. No tax-year view. The return needs 6 Apr–5 Apr totals; the app shows one month at a time with no year totals, no category totals across months, no export of either. A "Tax year" P&L (income, expenses by category, net) is the single highest-leverage addition — it converts twelve month-views into the numbers the SA103 actually asks for.
3. Categories don't speak SA103. Our five categories are operationally right but need a mapping to the nine SA103S boxes (Supplier products + Packaging → "goods bought for resale or goods used"; Equipment → its cash-basis expense box; Fees/Other → split across professional fees, premises, travel, other). FreeAgent's pattern (§5a) — each category carries its HMRC box, assigned once — fits perfectly, and below £90k turnover the single-figure easement means even an imperfect mapping can't produce a wrong return, only a less useful breakdown.
4. Expense types with no natural home: mileage (flat-rate log), home-working flat rate, and the private-use share of mixed costs. Absorbable under "Fees"/"Other" by a diligent user today, but un-prompted; a mileage log and a monthly WFH flat-rate line are small, self-contained adds.
5. Personal use / drawings: no way to mark goods taken for own use (cash basis: the cost should be disallowed) or record drawings (not tax-relevant on cash basis, but the number an accountant asks for first). Small.
6. Income date nuance: collected_at proxies "money received" — right for cash-on-collection, wrong for invoiced/paid-later customers. An optional paid-on date (or payment status) on orders would make the cash-basis date honest. Small, and pairs with any invoicing work.
7. No accounting-shaped export. #209 exports raw tables; an accountant wants a tax-year P&L by category, an income list, an expense list with evidence references. This "accountant pack" is the deliverable that makes "hand clean records to an accountant" literally true (see §6).
8. No VAT-threshold awareness. We hold rolling income; a gentle "your last 12 months' income is approaching £90,000 — VAT registration has rules worth reading" nudge is cheap insurance against the zero-rated-sales trap. ⚠️ Corrected 30 Aug 2026 (#829): the parenthetical here used to read "Actual VAT bookkeeping stays out — §4", which conflated two separable things. §4's verdict is about MTD submission and still stands. Capturing a net/VAT/gross split on an expense line is bookkeeping, not submission, and is now decided IN — outputs/docs/decisions/829-expense-capture-vat.md, tracked as #901.

4. Making Tax Digital — what it is, and whether we should be in it

(Researched 1 Aug 2026, same sourcing caveat as §2. Canonical sources: VAT Notice 700/22, the Income Tax (Digital Obligations) Regulations 2026 (SI 2026/336), HMRC Developer Hub guides — verified via search excerpts + ICAEW/ICAS/ATT/LITRG cross-checks.)

4a. MTD for VAT (mandatory for all VAT-registered businesses since April 2022)

"Functional compatible software" is defined as a set of programs joined by digital links that together keep the records digitally, compute the return from them, and submit via the VAT API. The required digital records are modest (per-supply date, net value, VAT rate; per-purchase date, value, input tax) — and retail-scheme users need only a digital record of daily gross takings, not individual sales. Two facts decide our posture:

• A CSV export/import is explicitly a valid digital link. Notice 700/22 s4.2.1 lists "XML, CSV import and export, and download and upload of files" (even emailing the file) as digital links; the only named violation is copy-and-paste/re-keying. So a ledger app that exports clean CSV into a bridging tool or accountant's software is a legitimate part of functional compatible software — with no HMRC integration of its own.
• Bridging software is permitted indefinitely — HMRC has stated it has no plans to stop spreadsheet+bridging, and no sunset exists in current guidance.

Verdict: our users are overwhelmingly unregistered (< £90k), and D-16 keeps even Stella Apps out of VAT. If a customer registers, the honest scope is exactly what #341 suspected: "export what a bridging tool needs" — never direct API submission. Real VAT bookkeeping (rate-coding every sale, VAT invoices, a VAT account) is FreeAgent's job.

4b. MTD for Income Tax (ITSA) — live now, and creeping toward our users

Confirmed phase-in (consolidated into SI 2026/336, in force 1 April 2026):

Qualifying income is GROSS turnover, not profit — self-employment plus property income combined. That matters: a baker turning over ~£400/week crosses £20k, so the April 2028 wave catches a real slice of D-24's target market (and it is assessed on 2026-27 income — the records being kept now). Below £20k nothing is announced; general partnerships aren't in scope at all.

What a mandated user must do: keep digital records (each transaction: date, amount, category — categories mirroring the SA103F headings, with a retail election to record one daily gross takings figure instead of each sale, and "three-line" totals for turnover under £90k), submit cumulative quarterly updates (category totals only — no transactions — due 7 Aug / 7 Nov / 7 Feb / 7 May), then a year-end final declaration through commercial software — HMRC has confirmed its own free filing service will not be available to mandated users. Penalties are points-based (£200 at four points), with a first-year easement on quarterly-update lateness for 2026-27.

Two structural facts help us: records may live in one product and be filed through another — GOV.UK explicitly supports the "products that work together" model, spreadsheets+bridging included — and the record-keeping half requires no HMRC recognition, no Developer Hub account, and no fraud-prevention headers, because it calls no HMRC API.

4c. What becoming "HMRC recognised" actually takes

There is no HMRC fee at any stage — the cost is engineering and permanent compliance:

• Developer Hub account → sandbox build (OAuth 2.0 per-user authorisation) → production approval (evidence review, up to 10 working days, six-month completion window) → listing on the GOV.UK software choices pages ("recognised", explicitly not "approved").
• Fraud prevention headers are the hidden cost: a legal obligation (s135 FA 2002 directions) to collect and transmit end-user device data on every API call — for a browser SaaS like ours, Gov-Client-* headers carrying public IP/port, a minted persistent device ID, timezone, local IPs, screen geometry, browser JS user agent, plugins, MFA status, plus Gov-Vendor-* server data. That means client-side collection JS, server forwarding, UK GDPR privacy-policy wording, a validator API to pass, a change-log to track forever — and HMRC may fine or cut off vendors who persistently get it wrong.
• ITSA products must meet minimum functionality standards (records + quarterly updates + signposting, or explicit pairing with another product), and HMRC published a plan in March 2026 to strengthen third-party software standards further — the treadmill is accelerating, not settling.

Verdict on recognition: not worth pursuing. It buys a listing on a GOV.UK page next to FreeAgent (free with the user's bank) and hundreds of others, at the price of a permanent compliance workstream utterly orthogonal to what makes ProvenBatch valuable. The one cost of staying out: we may never describe ProvenBatch as "MTD compatible" or "MTD recognised" — the truthful phrasing is "keeps the digital records; exports them for your MTD software or accountant".

5. FreeAgent as the reference product

(Researched via search-result synthesis 1 Aug 2026 — the sandbox proxy 403s direct page fetches, same caveat as gtm-channels-research.md. Sources are freeagent.com and support.freeagent.com KB articles via search; spot-check before quoting verbatim.)

First, the bank. #341 half-remembers "Letal bank" — it is Mettle, NatWest Group's app-based business account. Issue #270 already records it: Dave opened Mettle for Stella Apps on 29 Jul 2026 specifically because it includes the full FreeAgent platform free. FreeAgent (Edinburgh, bought by RBS in 2018 for £53m) is free with business banking from exactly NatWest, Royal Bank of Scotland, Ulster Bank and Mettle — on Mettle the condition is at least one transaction a month, and the account must have an Open Banking feed enabled (re-authorised every 90 days). Otherwise it is £19/mo ex VAT for a sole trader. Crucially the free version is the whole product — FreeAgent does not tier by feature; only add-ons (Smart Capture Unlimited £5/mo, Amazon integration) cost extra.

5a. What it does, and whether each part is relevant to ProvenBatch

5b. What FreeAgent deliberately does NOT do — the complement space

FreeAgent's own KB draws the line for us: its stock feature is "best suited to service-based businesses that occasionally supply small quantities of goods", is unavailable at all on cash-basis accounting (our users' default basis!), and for real inventory it tells users to run a specialised system and post monthly summary journals into FreeAgent. There is no per-product COGS, no recipes/BOM, no batches, no yields/wastage, no purchase orders, no supplier price tracking, no order management.

That is ProvenBatch's entire operational layer. The complement thesis: everything we are sits in FreeAgent's declared out-of-scope, and vice versa. The natural seam is the one FreeAgent itself names — the operational system produces periodic summaries that flow into the accounting layer. Which resolves #341's "second system in parallel" worry into a sharper question: for a user who banks with NatWest Group (a big slice of UK small businesses), the second system is free and HMRC-recognised — so the goal is not to replace it but to make ProvenBatch's records flow cleanly into it (or into an accountant's hands) with no re-keying. Competing with FreeAgent on accounting is competing with free, and losing.

6. Recommendation and positioning

Position ProvenBatch as the operational record-keeper that produces accountant-ready, MTD-import-ready output — and stay out of the filing business entirely.

The reasoning, assembled from §§2–5:

1. For the smallest users (under the VAT threshold, under every MTD threshold — most of the market today), Self Assessment is genuinely coverable from ProvenBatch alone: cash-basis income and expense records with evidence, a tax-year P&L, and either nine SA103S box totals or the single-figure easement. They file free via HMRC online. This is the "run your basic books here, no second system" promise we can honestly make — once the §3 gaps (chiefly non-order income) are closed.
2. For users with an accountant or accounting software, the second system is often free (FreeAgent via NatWest Group banking) and always better at accounting than we will ever be. Our job is the seam: clean, categorised, import-capable exports so nothing is re-keyed. Re-keying is also exactly what breaks MTD digital links — so "no re-keying" is simultaneously the convenience feature and the compliance feature.
3. MTD changes the timeline, not the strategy. April 2028's £20k gross threshold (assessed on 2026-27 income) will pull a real slice of target users into mandatory digital records — and the records that satisfy MTD ITSA (dated, categorised transactions; daily gross takings for retail) are the same records that close our §3 gaps. Build the ledger MTD-shaped now; never build the filing.
4. Do not pursue HMRC recognition (§4c). Marketing copy must say "keeps digital records and exports them for your accountant or MTD software", never "MTD compatible/recognised".

One deliberate echo of existing decisions: this is the accounting analogue of D-16 (don't VAT-register: stay under the machinery, keep the record clean) and of the labelling design rule (labels are derived from records; here, the return is derived from records — by someone else's software).

7. Shortlist and sizing

Sizing: S = a day or two inside the existing Accounts code; M = a new drawer/subsystem but established patterns; L = a genuinely new subsystem. "Ongoing" flags a maintenance or compliance tail beyond normal code ownership.

Deliberately out of scope (and why): bank feeds/reconciliation (FCA-regulated open-banking access or aggregator contracts + 90-day reauth UX — bigger than Accounts itself, and free in FreeAgent); VAT bookkeeping and returns (rate-coding every sale; MTD VAT filing); any HMRC API integration (§4c's treadmill); double-entry, balance sheet, trial balance (accruals machinery our cash-basis user doesn't need); payroll; Corporation Tax; Self Assessment filing.

A sensible first build slice is 1+2+3+4: complete income, the tax-year lens, the accountant pack, and box mapping — that is the entire "Self Assessment or clean handoff" promise, all one-off builds with no compliance tail.

Sources

(All accessed 1 Aug 2026. The sandbox proxy blocks direct GOV.UK/developer-hub fetches, so GOV.UK content arrived via search excerpts cross-checked against professional bodies — same caveat as gtm-channels-research.md. Items flagged in-line above deserve a direct GOV.UK read before being hard-coded into a build.)

Self Assessment / bookkeeping (canonical): gov.uk/self-employed-records (records + retention); gov.uk/simpler-income-tax-cash-basis; gov.uk/simpler-income-tax-simplified-expenses; gov.uk/guidance/tax-free-allowances-on-property-and-trading-income; gov.uk/capital-allowances + helpsheet HS252; gov.uk/vat-registration; gov.uk/self-employed-national-insurance-rates; SA103S/ SA103F 2025 & 2026 form + notes PDFs (assets.publishing.service.gov.uk); HMRC BIM70020/70030/72015. Cross-checks: ICAEW (cash-basis tips Nov 2025), ATT (55p mileage announcement 21 May 2026, backdated to 6 Apr 2026), ACCA (2024-25 cash-basis changes), LITRG (NIC).

MTD (canonical): VAT Notice 700/22 esp. s3 (records) and s4.2.1 (digital links — CSV listed as valid, copy-paste excluded); Income Tax (Digital Obligations) Regulations 2026, SI 2026/336 (legislation.gov.uk — consolidates and revokes SI 2021/1076); gov.uk/guidance/ check-if-youre-eligible-for-making-tax-digital-for-income-tax; gov.uk/guidance/ use-making-tax-digital-for-income-tax; gov.uk/guidance/choose-the-right-software-for-making-tax- digital-for-income-tax (products-working-together model); developer.service.hmrc.gov.uk — VAT and ITSA end-to-end service guides, fraud-prevention guide + change-log, terms of use. Cross-checks: ICAEW TAXguides 01/25 & 04/25, ICAS, LITRG, Tax Adviser magazine; QuickBooks/Xero bridging pages (HMRC "no plans to stop spreadsheets" statement).

FreeAgent: freeagent.com features/pricing pages; support.freeagent.com KB — notably 360008882080 (free via NatWest/RBS/Ulster/Mettle + conditions), 115001224344 (categories carry SA103 "tax reporting types"), 115001219890 (Self Assessment scope), 5116952535954 (MTD ITSA); mettle.co.uk/ features/freeagent (one-transaction-a-month condition); FreeAgent stock-valuation KB 115001224124 (stock unavailable on cash basis; "use a specialised stock system and post journals").

Capability

Last updated 6 Sep 2026

20. SumUp integration — API capability, auth, and why it stays closed (#1107, researched 6 Sep 2026)

Full report: outputs/docs/sumup-integration-research.md (endpoint-by-endpoint capability, the OAuth scope table, sizing for two build slices, and the evidence gate). Verified against SumUp's live developer docs and their published OpenAPI spec on 6 Sep 2026, not from memory. Headlines:

• Technically easier than expected. The read scope we would need, transactions.history, is a DEFAULT OAuth scope — no SumUp review, no partner agreement, no fee, and a sandbox to build against. (payments/payment_instruments need manual verification; we would need neither.) The connecting business does nothing in the SumUp dashboard — it is an ordinary OAuth consent redirect. The one real prerequisite is ours: registering a SumUp OAuth app needs "a SumUp merchant account with completed account details", i.e. Dave signing up.
• The landing zone now exists, which was not true when #58 closed. #31 (orders) shipped v0.20.0 and #347 (other_income — dated money-in, built for stall takings) shipped in epic #346. So #58's "pairs naturally with #31" framing is stale, and the honest value is not #58's takings-vs-units_sold reconciliation — it is "stop making them type their takings in", one row per day into other_income.
• But Dave's actual reason for closing #58 is untouched — "not clear which payment methods businesses will use… a race to integrate many." Nothing in the docs answers that; it is a customer-evidence question. The unlock is one question to the beta group (#708): which card reader do you use? A fragmented answer is itself the answer — build generic CSV import, never a provider integration.
• No webhooks for card-present sales (they cover checkouts you created only), so any build must poll transactions/history with a changes_since cursor — holding a per-business, long-lived third-party credential, a class of secret ProvenBatch stores nowhere today (verified: zero refresh_token/oauth hits across every migration and all 14 edge functions). That new security surface, not the code, is what makes Slice A effort: high rather than medium. The cross-tenant polling pattern is proven (lifecycle-emails.yml), so only the credential is new.
• Per-product reconciliation is possible but a trap. Line items (products[]: name, quantity, price, VAT) exist only on the detail endpoint, not the history listing — so it is N+1 per transaction, against an undocumented rate limit (429 appears exactly once in SumUp's whole OpenAPI spec, on member invitations), and products[] is populated only if the merchant rings sales through SumUp's item catalogue rather than keying in an amount. Do not build it.
• Cheaper first move: generic takings CSV import (#338 is already open). SumUp exports sales history and a product-sales report with Quantity as CSV. No OAuth, no stored credential, no polling — and it works for Zettle, Square and a spreadsheet too, which answers the "race to integrate many" objection instead of sidestepping it. §13 already establishes CSV as a valid MTD digital link.
• This is not a bank feed. §13 put bank feeds out of scope as FCA/aggregator territory; that reasoning does not carry over — SumUp's is a first-party merchant API authorised by the merchant to their own payment provider. Worth one confirmation before shipping, not a blocker.
• Four things could not be verified from public docs and need a real account: rate limits, history retention, the /v0.1/me merchant-code endpoint (used everywhere, absent from the published spec), and whether the product-sales-report CSV is standard or POS-tier. None changes the recommendation.

Recommendation: leave #58 closed, close #1107 with the research. Revisit only on the evidence gate above — an awaiting evidence shape in WAYS-OF-WORKING §1's exact sense.

Sources (fetched 6 Sep 2026): github.com/sumup/sumup-openapi openapi.yaml · developer.sumup.com — /api, /api/transactions/list, /api/transactions/get, /api/receipts/get, /api/merchants/get, /tools/authorization/{oauth,register-app,api-keys,authorization}, /online-payments/webhooks, /webhook-docs/introduction/getting-started, /problem, /getting-started, /help · help.sumup.com — item catalogue, sales history, product sales report CSV export. Full list with what each settled: outputs/docs/sumup-integration-research.md §8.

Full write-up

From outputs/docs/sumup-integration-research.md

SumUp integration — what the API actually offers, and whether to build it (#1107)

Researched 6 Sep 2026 against app v0.331.0, verified against SumUp's live developer documentation and their published OpenAPI specification rather than from memory (CLAUDE.md #19b). This is the full write-up for #1107, a research spike — the deliverable is this document and a recommendation, not code. RESEARCH.md §20 carries the headlines; the detail and the sizing are here, so a future session can turn it into scoped build issues without re-doing the API reading.

The question: #58 ("SumUp integration… bring back payments made against a business account for validation versus sold items") was closed not_planned on 1 Aug 2026. Dave re-raised it on 2 Sep 2026 as research. So: what does SumUp's API actually let a connected business's data do for us, what would a business have to do to connect, what does it cost, where would it plug in — and is it worth building?

Recommendation, up front

Leave #58 closed and do not build this yet — but the reason has changed, and so has the size of the job.

1. Technically it is more feasible than expected. The read scope we would need, transactions.history, is one of SumUp's default OAuth scopes — no SumUp review, no partner agreement, no manual verification. (payments and payment_instruments need approval; we would need neither.) The connect flow is an ordinary OAuth authorization-code redirect: the business clicks "Connect SumUp", signs in, approves. No SumUp dashboard steps for the business at all.
2. The landing zone already exists, which was not true when #58 was closed. #31 (customer orders) shipped in v0.20.0 and #347 (other_income — dated money-in entries, explicitly for stall takings) shipped as part of epic #346. #58's stated dependency is satisfied and its framing ("pairs naturally with #31") is stale.
3. But Dave's own reason for closing #58 is untouched by any of this — "It's not clear which payment methods businesses will use, and this could become a race to integrate many." Nothing in SumUp's documentation answers that. It is a customer-evidence question, not a technical one, and we still have no evidence.
4. The build is bigger than it looks, for one specific reason: there are no webhooks for card-present sales, so this must be a polling integration holding a per-business, long-lived, revocable third-party credential — a class of secret ProvenBatch stores nowhere today (verified: zero refresh_token/oauth references across all migrations and all 14 edge functions). That is the real cost, and it is a permanent one, not a one-off build.
5. There is a cheaper first move that answers Dave's objection instead of ignoring it: CSV import. SumUp exports sales history and a product-sales report (with Quantity) as CSV. A generic "import a takings CSV" feature fills other_income with no OAuth, no stored credential, no polling — and works for every card provider, not just SumUp, which is precisely the "race to integrate many" that closed #58. #338 (CSV import) is already an open follow-on from the accounting work.

So: leave #58 closed with a pointer here. If the evidence arrives (§7), build Slice A only (§5) — roughly a effort: high feature slice, not a medium one. Do not build Slice B.

1. What SumUp's API actually exposes

Verified against developer.sumup.com and github.com/sumup/sumup-openapi (openapi.yaml, fetched 6 Sep 2026). The API is REST/JSON. The relevant surface for this question is small.

1.1 The endpoint that matters

GET /v2.1/merchants/{merchant_code}/transactions/history

Scopes: one of transactions.history or transactions.read.

Query parameters that matter for reconciliation:

Response is { items: [...], links: [...] } — links carries the pagination cursors.

Two things are worth pulling out:

• CASH is a payment type. SumUp's app lets a merchant record cash sales alongside card ones, so a business that rings everything through SumUp would give us a genuinely complete daily takings figure, not just the card half. That is better than it first appears for the tax-records use case (§4).
• changes_since exists, which means an incremental poll is cheap and correct — including picking up refunds and chargebacks against sales we already imported.

1.2 What a history item contains — and what it does not

Each item in the history listing is TransactionHistory: transaction_id, transaction_code, amount, currency, timestamp, status, payment_type, card_type, type, user (the merchant email), installments_count, payout_date, payout_type, refunded_amount, plus product_summary — a free-text one-liner taken from the related checkout's description.

🔴 The history listing carries no line items. There is no products array on TransactionHistory. It gives you money and time, not what was sold.

1.3 Line-item detail exists, but on a different endpoint

GET /v2.1/merchants/{merchant_code}/transactions?id=… | transaction_code=…

The detailed TransactionFull response does carry a products array, described in the spec as "List of products from the merchant's catalogue for which the transaction serves as a payment", with per-line name, description, price, quantity, vat_rate, vat_amount, total_price, total_with_vat. There is a vat_rates breakdown and a transaction_events array (payouts, refunds) alongside it. GET /v1.1/receipts/{transaction_id} exposes the same product detail.

This is the finding that decides the shape of any build, and it cuts both ways:

• ✅ A real per-product units_sold cross-check is possible. #58's original ask is not fantasy.
• ❌ It costs one extra API call per transaction — the list gives totals, the detail gives lines. A market stall doing 80 sales a day is 80 extra calls, per business, per day, against an undocumented rate limit (§3).
• ❌ products is only populated if the merchant rings the sale through SumUp's item catalogue. A business that keys in "£4.50" and taps charge — which is how a great many small food businesses actually use a card reader — produces a transaction with an amount and no products at all. We would be building a reconciliation feature whose core data is optional and invisible until after a business connects.

1.4 Everything else on the API

• Payouts (GET /v1.0/merchants/{merchant_code}/payouts) — what SumUp actually settled to the bank, net of fees. Useful for bank reconciliation; not what #58 asked for.
• Merchants (GET /v1/merchants/{merchant_code}) — profile, default_currency, country, company identifiers. Scope user.profile_readonly.
• Checkouts, Readers, Customers, Members, Roles — for taking payments and running a till. Out of scope: ProvenBatch is not becoming a payment terminal.
• ⚠️ There is no catalogue endpoint in the published OpenAPI spec. The products scope exists ("View and modify products, shelves, prices, and VAT rates") but no /products path is in sumup-openapi. So we cannot read a merchant's item list up front to build a mapping screen — we would have to discover their product names by observing transactions.
• ⚠️ Merchant-code discovery is not in the published spec either. Every transactions call needs {merchant_code}. GET /v0.1/me is widely used to obtain it and appears in SumUp's own SDK issue tracker, but it is not a documented path in sumup-openapi. Building on it means building on an undocumented endpoint. This needs confirming against a real account before any build.