Offbite — Offline… | Presentation #729

Creator prompt

The idea behind this presentation

# ROLE You are an expert hackathon pitch-deck strategist, product designer, technical architect, and jury-facing storyteller. Your job is to create a **7-slide idea-screening pitch deck** for the **iQOO Hackathon 2026 — HealthTech Track — Hyderabad City Battle**. This is NOT a generic startup pitch. The deck must be designed specifically for a **3–5 minute judge-facing screening pitch** in a phone-first hackathon environment. Your goal is not to make the project look artificially complicated. Your goal is to make the judges think: > “The problem is real, the differentiation is clear, the architecture is technically credible, the phone is genuinely necessary, the team understands its limitations, and this is realistic to build during the hackathon.” --- # PROJECT ## Product **Offbite** ### One-line positioning **Offline-first nutrition and macro logging for the moments connectivity disappears.** ### Team **Git Gang · 2 members** ### Track **HealthTech** ### Event **iQOO Hackathon 2026 — Hyderabad City Battle** ### Submission stage **IDEA SCREENING** Important: Nothing is built yet beyond UI/UX mockups. Therefore: * Do NOT present prototype results as existing results. * Do NOT invent benchmarks. * Do NOT imply that implementation is complete. * Any performance figure must be explicitly labelled as an **engineering target**, **design target**, or **planned benchmark**. * Never use words such as “proven”, “verified”, “measured”, “achieved”, “real-time” or “production-ready” unless explicitly supported. * The deck must feel ambitious but completely honest. --- # HACKATHON CONTEXT Design against the actual iQOO Hackathon 2026 scoring structure: * End Product Quality — 30% * Novelty & Impact — 20% * Creative Phone Use — 15% * Technical Depth — 15% * Office Kit Usage — 10% * Demo & Presentation — 10% The official format is phone-first, with the iQOO phone serving as build and demo surface. Local/open-source AI at the core earns brownie points, and Office Kit bridges phone and laptop workflows. The HealthTech track covers AI-powered healthcare, wellness, fitness and mental-health solutions. The pitch is 3–5 minutes. The deck should visibly support these judging dimensions without ever sounding like it was designed merely to “game the rubric.” NEVER write phrases such as: * “designed to score points” * “rubric optimization” * “hackathon scoring strategy” * “we included this for marks” Every feature must look like a natural part of the product. --- # CORE USER Do NOT target “everyone.” Primary users: * Gym-goers * Frequent flyers * Trekkers * Outdoor athletes * People who frequently lose connectivity while still wanting to log food Anchor the entire story to situations such as: * Gym basement * Airplane * Rural trail * Outdoor training location The central human insight is: > **The moments people want to log their food do not always have reliable connectivity.** --- # PROBLEM Cloud-based nutrition trackers have three important failure modes: ## 1. Network dependency Cloud NLP and cloud-backed logging can fail or degrade when connectivity disappears. Examples: * Gym basement * Airplane * Rural trail ## 2. Non-deterministic arithmetic LLMs are probabilistic systems. They can interpret, generate and reason about language, but the deck must not imply that free-form LLM generation is the ideal place to perform nutrition arithmetic. The core issue is: > **Natural-language understanding is probabilistic; nutrition arithmetic should be deterministic and reproducible.** ## 3. Privacy exposure Raw voice, dietary logs and related personal wellness information may otherwise be transmitted to third-party servers. Do NOT make legal/compliance claims such as “HIPAA compliant”, “GDPR compliant”, “zero liability”, etc. Instead say: > **Sensitive nutrition and voice data can remain on-device by design.** --- # THE CENTRAL DIFFERENTIATOR This is the most important idea in the entire deck. Do NOT position Offbite simply as: > “an offline AI nutrition app.” That is not differentiated enough. Position it as: # **AI interprets. Deterministic systems calculate. Local storage records.** Or: # **Separate language uncertainty from nutrition arithmetic.** The architectural principle is: ### Probabilistic layer Understands what the user meant. ### Deterministic layer Performs nutrition lookup and arithmetic. ### Local state Stores the resulting record. This separation is the core innovation story. --- # ARCHITECTURE — IMPORTANT TECHNICAL CORRECTION Do NOT depict **Llama 3.2 1B-Instruct as directly processing camera images**. Meta identifies Llama 3.2 1B and 3B as lightweight **text-only** models, while the 11B and 90B variants are the multimodal vision models. Therefore the deck must show the architecture honestly: ## INPUT ### Camera Photo of the actual plated food. ### Voice User says or corrects portion size. ↓ ## ON-DEVICE VISION MODULE A separate local vision component identifies or proposes the dish/entity from the photo. Do not invent a specific vision model name unless explicitly supplied. If no vision model has been selected yet, label it: > **On-device vision module — model selected during implementation benchmarking** Do not pretend a model has already been chosen. ↓ ## PROBABILISTIC EAR **Llama 3.2 1B-Instruct** Role: * Natural-language understanding * Entity extraction * Portion interpretation * Intent classification * Structured JSON generation Role explicitly excludes: * Nutrition arithmetic * Final calorie calculation * Final macro calculation * Direct database mutation The deck should communicate: > **The model interprets. It does not perform the final nutrition math.** --- # DETERMINISTIC CORE Use: ## Local SQLite Seeded from: **IFCT 2017 — Indian Food Composition Tables — National Institute of Nutrition / ICMR** The data story: * IFCT contains nutrient information for 528 key foods/raw ingredients. * Composite Indian dishes are not simply “looked up” directly from IFCT. * Therefore Offbite adds a **recipe layer** mapping composite dishes such as: * Paneer bhurji * Dal * Sabzi * Similar common dishes into ingredient ratios. Architecture: **Vision/entity extraction** → structured dish candidate **Voice** → portion information **Llama 3.2 1B** → validated JSON **Recipe layer + IFCT** → ingredient/nutrient lookup **Deterministic calculator** → calories/macros **SQLite** → local record Important technical language: Do NOT write: > “SQLite calculates the macros.” Write: > **“Deterministic runtime calculates; SQLite stores.”** --- # ERROR-HONESTY PRINCIPLE This must be visibly communicated. Do NOT claim: * 0% hallucination * 100% accuracy * error-free pipeline * guaranteed nutrition accuracy * perfect food recognition Instead say: > **“The arithmetic path is deterministic; the main uncertainty remains entity and portion extraction.”** This makes the architecture more credible. The deck should distinguish: ### What is deterministic * Lookup logic * Recipe mapping logic * Arithmetic * Record storage ### What remains probabilistic * Food/entity extraction * Portion interpretation * Voice understanding * Vision interpretation --- # HARDWARE STORY Target device: **iQOO 15** Target platform: **Snapdragon 8 Elite Gen 5** Qualcomm documents the Snapdragon 8 Elite Gen 5 with a Hexagon NPU and support for INT2, INT4, INT8, INT16 and FP8/FP16 precision. Use this only as hardware context. Do NOT claim that the exact Offbite workload has already been measured on the target phone. ### NPU story Llama 3.2 1B: * INT4 / quantized deployment * target on-device acceleration * NPU-first design If using a performance figure: > **~70 tokens/sec** label it clearly: > **ENGINEERING TARGET — NOT BENCHMARKED** Never present it as achieved. --- # THERMAL STORY Heavy background work such as: * vector/index maintenance * weekly report generation * other non-interactive heavy processing should be designed for appropriate thermal/power states. Use phrasing such as: > **“Charge-state gating for non-interactive heavy workloads.”** Do NOT claim exact thermal limits or measured thermal performance. Do not over-explain the vapor chamber. The point is simply: > **Interactive inference gets priority; expensive background work waits for suitable power/thermal conditions.** --- # OFFICE KIT STORY Use only documented consumer-facing Office Kit concepts: * File transfer * Clipboard sync * Screen mirror * Phone/laptop bridge Do NOT claim: * Native Office Kit API * undocumented SDK access * special integration that has not been verified Product use case: ### Weekly wellness handoff Offbite generates a local weekly wellness summary: * activity * calorie/macro adherence * logged meals Then: **Phone → Office Kit → PC** for review or transfer. The Office Kit should feel like a useful product workflow, not a hackathon checkbox. --- # RED LIGHT STORY The deck may show: ### Phone-only debugging workflow Because NLU is decoupled from UI: * test local prompts * inspect structured JSON * debug model behavior * inspect local outputs using the phone and Office Kit screen mirroring. Do not overemphasize the hackathon rule. Present it as: > **“The architecture keeps model debugging possible even during phone-only build periods.”** --- # DEMO STORY The demo concept is: # **THE AIRPLANE MODE TEST** Stage sequence: 1. Put the iQOO 15 into Airplane Mode. 2. Ensure Wi-Fi and cellular connectivity are disabled. 3. Photograph an actual plate of home-cooked food. 4. Speak the portion size. 5. Run the local pipeline. 6. Show the structured intent. 7. Show recipe-layer + IFCT lookup. 8. Show deterministic calculation. 9. Show locally logged nutrition result. Example: **Photo:** rotis + paneer bhurji **Voice:** > “I ate two rotis and about 150 grams of paneer bhurji.” Example local result: **Meal logged** * 2 rotis * 150 g paneer bhurji * calculated calories * protein * carbs * fat * saved locally The demo must explicitly say: > **“This demonstrates zero cloud dependency. It does not, by itself, prove nutrition accuracy.”** If a latency number is shown: > **<200 ms target** must be labelled: > **TARGET — NOT BENCHMARKED** --- # 7-SLIDE STRUCTURE ## SLIDE 1 — TITLE ### Goal Make the judge understand the product in under 10 seconds. ### Content **OFFBITE** **Nutrition logging that still works when the connection disappears.** Small context: **HealthTech · iQOO Hackathon 2026 · Hyderabad City Battle** **Git Gang · 2 members** ### Visual Show a minimal product flow: **Plate photo → Voice portion → Logged macros** Do not overcrowd the title slide. The judge should immediately know: * What it is * Who it is for * Why it matters --- # SLIDE 2 — PROBLEM ### Title **Cloud fails exactly where logging matters.** Use three large cards: ### NETWORK DEPENDENCY Gym basement Airplane Rural trail ### NON-DETERMINISTIC ARITHMETIC LLM-generated calculations can vary or be wrong. ### DATA EXPOSURE Voice and dietary information may leave the device. At the bottom: > **People do not stop eating when connectivity disappears. Their nutrition logs should not have to stop either.** Do not attack competitors aggressively. Do not claim HealthifyMe/MyFitnessPal/Cronometer are universally incapable of offline functionality unless verified. Use generic wording: > **“Cloud-backed workflows introduce network dependency.”** --- # SLIDE 3 — SOLUTION ### Title **Two brains. One local nutrition record.** Visual architecture: ```text CAMERA + VOICE ↓ ON-DEVICE VISION ↓ LLAMA 3.2 1B PROBABILISTIC EAR ↓ VALIDATED JSON ↓ RECIPE LAYER + IFCT ↓ DETERMINISTIC RUNTIME ↓ SQLITE ↓ LOCAL NUTRITION RECORD ``` Two highlighted sections: ### PROBABILISTIC EAR **Understands** * dish/entity * intent * portion language * JSON structure ### DETERMINISTIC CORE **Calculates** * nutrient lookup * recipe mapping * arithmetic * local state Bottom statement: > **The model can misunderstand. The calculator should not improvise.** Make the difference between uncertain interpretation and deterministic arithmetic visually obvious. --- # SLIDE 4 — RUNTIME ### Title **From plate photo to logged macros — entirely on-device.** Create a clean horizontal 5-step pipeline: ### 01 **PLATE PHOTO** Identify dish ↓ ### 02 **VOICE** Capture portion ↓ ### 03 **LOCAL AI** Produce validated JSON ↓ ### 04 **RECIPE + IFCT** Resolve nutrients ↓ ### 05 **DETERMINISTIC RUNTIME** Calculate + save Add a small result card on the right: **MEAL LOGGED** Paneer Bhurji · 150 g Calories · Protein · Carbs · Fat If showing latency: > **Target local-path latency: <200 ms** Small caption: > **Engineering target — not benchmarked** No step may be left unexplained. --- # SLIDE 5 — WHY THIS PHONE ### Title **The phone is not just the screen. It is the runtime.** Use three cards: ### DEVICE **Snapdragon 8 Elite Gen 5** Hexagon NPU INT4-capable on-device AI ### DATA **IFCT 2017** 528 key foods * Offbite recipe layer for composite Indian dishes ### RUNTIME **NPU-first** Interactive inference prioritized Heavy background tasks deferred to suitable charge/thermal states For the ~70 token/sec claim: > **TARGET ONLY — UNBENCHMARKED** Do not make this slide feel like a specification sheet. The message is: > **The iQOO phone provides the compute, camera, voice input and local storage needed to keep the full nutrition loop on-device.** --- # SLIDE 6 — BUILD + OFFICE KIT ### Title **Built phone-first. Reviewed without breaking the workflow.** Show two real product workflows. ### WEEKLY WELLNESS HANDOFF Phone: **Weekly nutrition/activity report** ↓ Office Kit: **File transfer + clipboard sync** ↓ PC: **Review / archive / share** ### PHONE-ONLY DEBUGGING **Local model** → JSON → prompt debugging → screen mirror → larger display Bottom: > **Office Kit extends the workflow without moving inference off-device.** Do NOT mention scoring. Do NOT mention “rubric”. Do NOT claim undocumented APIs. --- # SLIDE 7 — DEMO ### Title **AIRPLANE MODE TEST** Make this slide visual and extremely simple. ### STEP 01 **AIRPLANE MODE ON** Wi-Fi + cellular OFF ↓ ### STEP 02 **PHOTOGRAPH ACTUAL FOOD** Rotis + paneer bhurji ↓ ### STEP 03 **SAY THE PORTION** Voice input ↓ ### STEP 04 **LOCAL TRACE** JSON Recipe layer IFCT lookup Deterministic calculation ↓ ### STEP 05 **MEAL LOGGED** Calories + macros Stored locally At the top or bottom: > **PROVES:** No cloud dependency > **DOES NOT PROVE:** Nutrition accuracy Small footer: > **Latency target: <200 ms · not benchmarked** This is the final credibility statement. --- # VISUAL DESIGN Use: * 16:9 * near-black background * white typography * one restrained orange accent * subtle neutral gray secondary text * card-based layouts * generous whitespace * consistent header system * monospace section labels Example: **01 / PROBLEM** **02 / SOLUTION** **03 / RUNTIME** Do NOT use: * gradient bars * decorative side stripes * random accent lines * excessive glowing effects * cyberpunk overload * unnecessary 3D objects * giant hardware renders * stock fitness photos * generic AI brain graphics * decorative circuit-board imagery * excessive icons * dense paragraphs The aesthetic should feel: **premium + technical + restrained + product-first** not: **generic AI startup + neon cyberpunk.** --- # VISUAL STORYTELLING RULE Every slide must have at least one visual element that explains the system. Prefer: * diagrams * small UI mockups * data flow * device workflow * result cards * before/after * input/output visuals Avoid slides composed primarily of text. --- # TYPOGRAPHY RULE Use a strong hierarchy: ### Slide title Large, bold, short. ### Section label Small monospace. ### Main point Large emphasis. ### Explanation Small and restrained. Never write long paragraphs. A judge should be able to understand the slide in **3 seconds without reading every word.** --- # JUDGE-QUESTION DEFENSE The deck must proactively eliminate these questions: ### “Why not just use a normal nutrition app?” Answer: > **Because Offbite separates natural-language interpretation from deterministic nutrition computation and keeps the critical loop on-device.** ### “Why does it need AI?” Answer: > **AI handles ambiguous human input — what food, what portion, what intent. It is not trusted with final arithmetic.** ### “What happens if the model gets the food wrong?” Answer: > **Entity extraction remains the uncertainty surface; the user can correct the structured input before the deterministic calculation.** ### “Is the whole pipeline 100% accurate?” Answer: > **No. The arithmetic path is deterministic; recognition and interpretation can still be wrong.** ### “How does the image actually get understood?” Answer: > **A separate on-device vision module handles image understanding; Llama 3.2 1B handles text/intent interpretation.** Never imply Llama 3.2 1B itself is the vision model. ### “Why Llama 3.2 1B?” Answer: > **It is small enough for an on-device NLU role, where the goal is structured interpretation rather than large-scale reasoning.** ### “Why SQLite?” Answer: > **The critical nutrition state can remain local, deterministic and immediately available without a network dependency.** ### “What makes this novel?” Answer: > **The separation of probabilistic language understanding from deterministic nutrition state computation in a phone-first offline workflow.** ### “Why iQOO?” Answer: > **The product depends on capable on-device AI, camera, voice input and local compute; the iQOO hardware is part of the runtime rather than merely the display.** ### “Where is the cloud?” Answer: > **There is intentionally no cloud dependency in the critical meal-logging path.** ### “Have you benchmarked it?” Answer: > **No. This is an idea-screening submission. Any latency or throughput figures shown are engineering targets, not achieved benchmarks.** --- # CLAIM DISCIPLINE The AI generating the deck must follow this rule: ## NEVER INVENT Do not invent: * accuracy percentages * token throughput results * latency results * battery percentages * thermal measurements * memory measurements * benchmark scores * user counts * market size * clinical validation * medical outcomes * nutrition accuracy * compliance certifications * hospital deployments * production readiness * competitor weaknesses that are not verified Whenever the deck needs to show an expected number, label it: **TARGET** **DESIGN TARGET** or **UNBENCHMARKED** --- # HEALTH SAFETY / PRODUCT POSITIONING Offbite is a: **nutrition logging and wellness tool** not: **medical diagnosis system** Do not claim: * disease diagnosis * treatment * medical advice * medical-grade nutrition accuracy * clinical decision support Avoid making medical claims unless explicitly supported. --- # COMPETITOR POSITIONING Do not create a competitor comparison table unless necessary. Do not say: > “HealthifyMe is bad.” Do not say: > “MyFitnessPal cannot do X.” Instead state the category-level differentiation: > **“Cloud-backed nutrition workflows introduce connectivity and data-exposure tradeoffs; Offbite is designed around an offline-first local loop.”** This keeps the deck factual and avoids unnecessary attacks. --- # FINAL NARRATIVE The entire presentation must tell one story: ### 1. **People want to log food even when connectivity disappears.** ### 2. **Current AI systems also create a second problem: probabilistic systems should not be the final authority on arithmetic.** ### 3. **Offbite separates the jobs.** ### 4. **AI understands what the user means.** ### 5. **Deterministic tools calculate what that means nutritionally.** ### 6. **The entire critical loop lives on the phone.** ### 7. **The Airplane Mode Test demonstrates the core proposition.** The audience should leave remembering exactly one sentence: # **“Offbite lets AI understand the meal — without letting AI decide the math.”** --- # QUALITY CONTROL BEFORE FINAL OUTPUT Before generating the final PPT, internally verify: ### Architecture * Is Llama 3.2 1B clearly text/NLU-only? * Is image understanding assigned to a separate vision component? * Is deterministic calculation separate from the database? * Is the recipe layer clearly distinct from IFCT? ### Claims * Are all metrics labeled as targets? * Are there zero invented benchmarks? * Are there zero “0% hallucination” claims? * Are there zero “100% accuracy” claims? * Are there no undocumented Office Kit API claims? ### Product * Is the target user specific? * Is the plate + voice experience obvious? * Is the final nutrition result visible? * Is offline operation central? ### iQOO * Is the phone actually necessary? * Is the NPU story credible? * Is Office Kit integrated naturally? * Is the demo phone-first? ### Presentation * Can a judge understand each slide in 3 seconds? * Does every technical diagram resolve completely? * Are there no dangling arrows or unexplained blocks? * Is there enough visual proof? * Does the deck look like a product, not a research paper? ### Final test If removing a technical claim makes the deck less impressive but **more truthful**, remove the claim. The final deck must optimize for: # **CREDIBILITY > COMPLEXITY** # **CLARITY > JARGON** # **DEMO > CLAIMS** # **PRODUCT > ARCHITECTURE**

Offbite — Offline… | Presentation #729 | Presenton

Offbite — Offline Nutrition, Deterministic by Design

The idea behind this presentation

About this Offbite — Offline Nutrition, Deterministic by Design presentation example

Three things to review before creating your version

Story structure

Visual hierarchy

Design consistency

Turn inspiration into an original presentation