--- title: "Offline Field Manual" date: "2026-07-15" canonical: "https://raytally.com/en/ideas/2026-07-15-bonsai-27b-a-27b-class-model-that-runs-on-a-phone/" generator: "RayTally · dev-prompt-v4" signal: query: "Bonsai 27B: A 27B-Class model that runs on a phone" observed_at: "2026-07-15T00:47:08.009Z" sources: - url: "https://prismml.com/news/bonsai-27b" boundary: "Published at 2026-07-14. Observed at 2026-07-15T00:47:08.009Z." - url: "https://www.ibm.com/docs/en/masv-and-l/maximo-manage/cd?topic=overview-maximo-mobile" boundary: "No publication timestamp is present in the source record." - url: "https://upkeep.com/" boundary: "No publication timestamp is present in the source record." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-07-15-bonsai-27b-a-27b-class-model-that-runs-on-a-phone/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea Offline Field Manual Helps technicians photograph a fault offline and get a page-cited inspection sequence after loading equipment documents in advance. ## Product concept Offline Field Manual is a mobile app for maintenance technicians that uses an on-device model to search drawings, manuals, and fault records where there is no signal. Before leaving, users load equipment materials onto their phone; once in the equipment room, they photograph an alarm panel and the first screen lists likely fault sections and the next inspection steps. Each judgment links to local document page numbers, and when parts look similar, the app asks for another photo of the nameplate or connector instead of guessing. Photos, readings, and completed steps from the repair stay together in one field record, and users decide whether to sync after connectivity returns. It applies offline large-model capabilities to the point in the job with the worst connectivity and the most documentation, rather than making only an offline chat box. ## Why now (backed by facts) On July 14, 2026, PrismML released Bonsai 27B with image and text input: the 1-bit version is about 3.9 GB, can run locally through MLX on Apple devices such as iPhones, and its model weights use the Apache 2.0 license. This makes it possible for the first time to build a complete prototype in which field photos, local manuals, and multi-step inspection sequences all stay on the phone using one deployable model, without handing core judgment to the cloud. ## Direction (model inference, not independently verified) Target user: Equipment maintenance, facilities operations, and field-service staff use it before entering underground equipment rooms, remote areas of a plant, or other low-connectivity sites. They load the relevant equipment manuals and history onto their phone, then need to confirm the right page and next measurement as soon as an alarm appears. Minimal entry point: Build for iPhone first: import a set of PDF manuals, extract page content on-device with PDFKit and Vision, then use the MLX version of Bonsai 27B to match a field photo to up to three relevant sections, produce a page-cited inspection checklist, and save photos, readings, and checked results as a local record. The strongest case against: The strongest case against this is that general-purpose vision models may still misidentify similar parts, obscured nameplates, and modified equipment often enough to fail enterprise safety review. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) Choose one equipment category with many public manuals and clear fault codes. Make a short airplane-mode demo that goes from an alarm photo to a manual page, then publish it by specific model on YouTube, repair forums, and relevant technical communities; model numbers and fault codes are clear search entry points. ## Competitors & gaps (model inference) - IBM Maximo Mobile: Maximo Mobile already covers offline work orders, asset information, photos, and field records, but IBM documentation states that capabilities such as Assist still require an internet connection. This idea’s opening is to run visual inspection, manual lookup, cited answers, and requests for additional photos entirely on-device. - UpKeep: UpKeep already provides offline work-order records and automatic sync after reconnection, but its public pages do not state that AI diagnostics can run offline on a phone. Rather than building a full CMMS, this idea focuses on offline equipment-document retrieval and evidence-based inspection sequences. ## How it makes money (model inference) Charge a monthly fee per technician seat, with team plans charging extra for equipment document packs, access controls, and optional sync. ## Source context Theme: Bonsai 27B models that run on phones Trigger Hacker News post (original English): Bonsai 27B: A 27B-Class model that runs on a phone Heat at capture: ~401 points, 153 comments (point-in-time values) Points and comments are a historical snapshot from the moment of capture and drift over time. They only explain “why now”; do not present them as precise market numbers. ## Sources - Announcing Bonsai 27B: The First 27B-Class Model to Run on a Phone (https://prismml.com/news/bonsai-27b) - Maximo Mobile overview (https://www.ibm.com/docs/en/masv-and-l/maximo-manage/cd?topic=overview-maximo-mobile) - CMMS Software | AI-Powered Maintenance Platform (https://upkeep.com/) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.