Offline AI Appliances — one job, one box, no cloud

Act as an embedded AI product engineer. Stage 1: clone the Gemma Translator repo and build it exactly as published on a Raspberry Pi 5 with active cooling and a 5V 5A supply. Measure tokens per second against the published roughly 7, per-stage latency for Moonshine, Gemma and TTS, and temperature and throttling over a 30-minute soak; document every deviation from the repo. Stage 2: fork it into a paperwork reader: camera capture, Baidu Unlimited OCR (or a smaller fallback if it will not fit or run fast enough), a quantized Gemma summarizer with a fixed output template (sender, what it is, amount, due date, action needed, confidence), and Kyutai Pocket TTS reading the summary aloud. Build a 20-letter test set with consent, hand-transcribed and hand-labeled for bills and deadlines by a second person. Report p50 and p95 seconds per page, character error rate, and bill-flag precision and recall. Prove offline: nftables drop on output, tcpdump during all 20 pages, zero packets. Design a printed case with camera mount and a big button. Then a two-week trial with one non-technical person: local usage log, no remote telemetry, interview at the end. Apply the falsifier: over about 10 s per page or reverting to a phone app within a week means the form factor is not earning its keep.

ROLE AND STANCE
You are an embedded AI product engineer building a one-job offline appliance for a non-technical person. Source claims to test: Gemma Translator runs speech recognition (Moonshine), translation (Gemma) and TTS on a Raspberry Pi 5 with no network at about 7 tokens per second, 'enough to hold a conversation', and is a weekend build from its BOM and STLs; Baidu Unlimited OCR (3B, MIT) reads 100-page PDFs in one pass with tables and reading order intact; Kyutai Pocket TTS clones voices locally at 6x real time; Qwen 3.8 27B fits a 24GB card; Soup fine-tunes on a 4GB GPU. Vendor benchmarks are claims until measured on your board.

CONTEXT
- Base: Gemma Translator repo, deployment script, BOM, STL case.
- Parts bin: Unlimited OCR, Pocket TTS, Moonshine, quantized Gemma via llama.cpp; Jetson Orin Nano as a fallback board; Sharp Memory Display for a low-power status screen.
- Target user: an elderly relative or similar; the box reads letters aloud and flags bills and deadlines.

HARD CONSTRAINTS
1. No network at runtime. Prove it with a firewall drop rule and a packet capture.
2. No remote telemetry. Usage logs stay on the device and are shown to the user.
3. Test letters are used with the owner's consent; images and text are deleted after the study unless the owner says otherwise.
4. The box never pays, emails or acts; it reads, summarizes and flags, and says 'I am not sure' when OCR confidence or the summary is weak.
5. Every performance number is measured on the target board under a 30-minute soak, not a cold single run.

DELIVERABLES IN ORDER
1. stage1.md: Gemma Translator built as published, tokens per second, per-stage latency, temperature and throttle flags, deviations.
2. testset/: 20 letters, hand transcription, hand labels for bill, amount, due date, action, made by a second person.
3. pipeline/: capture, OCR, summarize, TTS, with per-stage timing and a confidence rule.
4. bench.md: p50 and p95 seconds per page, character error rate, bill-flag precision and recall, watts, peak temperature; Unlimited OCR versus a smaller fallback OCR if needed.
5. offline_proof/: nftables rules, tcpdump pcap, ss output, all from a full 20-letter run.
6. case/: modified STL or CadQuery source with camera mount, button, speaker grille, BOM with prices.
7. trial.md: two-week usage log summary and end interview.
8. verdict.md: falsifier result and GAPS.

BUILT-IN GAP ANALYSIS
Write GAPS: models that did not fit in memory or ran too slowly and what replaced them; letter types missing from the test set (handwritten, multi-page, low light); thermal throttling events; claims not testable on this hardware (27B models, 100-page PDFs). Fill gaps you can, such as adding handwritten samples or rerunning with a heatsink change.

SELF-QUESTIONS
- Which stage dominates latency, and does quantization or a smaller OCR model fix it without wrecking accuracy?
- Does Unlimited OCR even run on a Pi 5's 8GB or 16GB RAM, or does this force a Jetson?
- What happens when the letter is crooked, folded, or in dim light?
- Does the summary ever invent an amount or date not in the OCR text?
- Is the voice clear to someone with hearing loss at the speaker's volume?

STOP CONDITIONS
Stop and report if stage 1 cannot reach within 30% of the published 7 tokens per second, if p95 per page exceeds 30 s with every model option, or if the trial user declines.

RETURN FORMAT
Verdict line, bench table, offline proof summary, file list, GAPS, self-question answers.

Clone the Gemma Translator repository and follow its README and deployment script exactly on a Raspberry Pi 5 with the official active cooler and a 5V 5A supply. Record OS image, Python version, model files and their quantization, and every command. Do not change anything until the published build works. Then measure: tokens per second for Gemma during translation (compare to the published roughly 7), Moonshine latency per utterance, TTS real-time factor, and end-to-end latency from end of speech to start of playback, each over 20 utterances with p50 and p95. Run a 30-minute continuous soak and log vcgencmd measure_temp and get_throttled every 10 s, plus watts from a USB meter. Write stage1.md with results and every deviation from the repo's instructions, including missing steps you had to work out.

With the owner's consent, collect 20 real letters representative of the target user's mail: utility bills, bank statements, medical appointment letters, government notices, marketing, and at least two handwritten or low-quality items. Photograph each with the same camera and stand planned for the device, and also under dim light and at a 15-degree tilt for a robustness subset. Have a second person, not the builder, hand-transcribe each letter and label: is it a bill (yes or no), amount due, due date, sender, and action needed. Store under testset/ with images, transcription text and labels.csv. Redact account numbers in any copy that leaves the device, and write a deletion date. Include at least one two-page letter so the pipeline's multi-page handling is tested.

Fork the repo. Replace the speech input path with a camera capture on button press, with automatic crop and deskew in OpenCV. Run Baidu Unlimited OCR locally; if it does not fit RAM or exceeds 20 s per page on the Pi, benchmark a smaller OCR fallback and record both. Feed OCR text to quantized Gemma via llama.cpp with a fixed template: sender, what it is, amount, due date, action needed, confidence. Add a rule: if OCR mean confidence is low or any amount or date in the summary does not appear verbatim in the OCR text, the box says 'I am not sure about this letter, please ask someone to check it.' Speak the summary with Kyutai Pocket TTS at a slow rate. Time every stage with perf_counter and log locally.

Add an nftables rule dropping all output except loopback, disable Wi-Fi and Bluetooth, and start tcpdump on all interfaces. Run all 20 letters plus robustness variants through the pipeline during a 30-minute soak. Compute: seconds per page p50 and p95 by stage; character error rate with jiwer against the transcriptions; bill-flag precision and recall, amount exact-match rate, and due-date exact-match rate against labels.csv; rate of 'not sure' responses and whether they landed on genuinely hard letters; peak temperature and throttle events; average watts. Stop tcpdump and confirm zero non-loopback packets; save the pcap and ss -tupn output in offline_proof/. Write bench.md comparing Unlimited OCR with the fallback if both ran. Break results out by letter type so weak categories are visible.

Modify the Gemma Translator STL or write a CadQuery case: camera on an arm over a letter tray, one large button, speaker grille facing the user, vents over the Pi's cooler, optional Sharp Memory Display for a status line. Write a BOM with part numbers and prices. Give the box to one non-technical person for two weeks with a one-page printed guide in large type. On the device, log locally: button presses, pages read, 'not sure' events, and replays. No remote telemetry. Observe the first use without helping and note where they hesitate. At the end, interview them: what they used it for, what annoyed them, whether they went back to a phone app or asking family, and when. Record the build time.

Write verdict.md. State p95 seconds per page against the roughly 10 s falsifier threshold, bill-flag recall and precision, amount accuracy, the offline proof result, and the trial outcome: did the person keep using it or revert to a phone app within a week? Give one verdict line: does the appliance form factor earn its keep at today's edge compute? Then GAPS: each source claim (7 tokens per second on Pi 5; weekend build from BOM; Unlimited OCR reads 100 pages in one pass; Pocket TTS 6x real time; 27B on one 24GB card; Soup on 4GB) marked verified, unverified or false on this hardware with the measurement that decides it; letter types not covered; failures during the trial. Recommend the single change most likely to fix the worst gap, such as a Jetson Orin Nano, a smaller OCR, or a better camera stand.

You are an independent reviewer of an offline paperwork-reader appliance. Open stage1.md, testset/, pipeline/, bench.md, offline_proof/, case/, trial.md and verdict.md. List every claim in bench.md and verdict.md. Mark each verified (cite the log line, pcap, or computation), unverified (say what measurement would prove it), or false. Check: tokens per second and latency were measured under a 30-minute soak with throttle state recorded; labels were made by someone other than the builder; every spoken amount or date appears in OCR text, or triggered a 'not sure' warning; the pcap shows zero non-loopback packets during the full run; no remote telemetry exists in code; consent and deletion are documented for real letters; the trial outcome comes from the device log and interview, not the builder's impression. List missing pieces: untested letter types, models that never ran, robustness variants skipped. Rank problems by harm to the user first (a missed bill is worse than a slow page), then by whether they flip the falsifier verdict. Fix the top three now and report before and after. End with what needs new hardware, more letters, or a longer trial.