Anumaan — Product Requirements Document

The restaurant co-pilot that sees tomorrow's rush today

Prepared for VibeAthon 6.0 — Smart Restaurant Management System. July 2026.

"Anumaan" (अनुमान, Hindi/Urdu for "estimate" or "prediction") is the name because the product's whole differentiated bet is prediction and action — not another digital menu.

0. One-line pitch

A digitized front-of-house + back-of-house system for independent Indian restaurants that layers predictive, action-taking AI agents (demand forecasting, waste prediction, staffing guidance — with human-approved execution) on top of the standard menu/order/table/billing workflow — the one thing neither the cheap incumbents (Petpooja) nor the AI-native newcomer (DineOpen) currently offer, and something even the India-market incumbents haven't shipped as of this research.

1. Problem Statement

Independent, single-outlet restaurants — ~56% of India's ₹5.69 trillion food services market and growing employer of 8.5M+ people — run on manual processes: no visibility into what's actually in stock, no forecasting so they over-prep (contributing to the 11.9M tons/year of food waste from the Indian food-service sector) or under-staff against demand swings, and no institutional memory once staff churn out (60% annual attrition in the sector). Existing software either serves them shallowly (Petpooja: great billing/aggregator sync, weak analytics) or serves enterprises they aren't (Posist: built for 10+ outlet chains). A newer AI-native entrant, DineOpen, has started serving this exact segment but its AI is conversational (voice/chat ordering) — nobody is giving a solo owner-operator the predictive, "operational insights" layer that a data team would otherwise provide a chain, and no India-specific competitor researched has shipped autonomous, action-taking agents. Full grounding for every claim above is in the research doc, Sections 2–8, and the agentic-specific claims in Section 11 below.

Cost of not solving it: margin lost to waste and idle tables, and staff burnout from reactive rather than planned staffing.

2. Goals

1. Cut a single restaurant's over-prep waste by giving the owner a same-day, item-level prep quantity suggestion before service starts — and an agent that drafts the actual prep task list, not just the number.
2. Reduce no-show/idle-table revenue loss by digitizing reservation + queue with automatic wait-time estimates.
3. Give an owner-operator, with zero data-analyst headcount, a daily plain-language summary and a set of agents that can act (with approval) on routine operational decisions — the "operational insights" a Posist enterprise customer gets.

3. Non-Goals

• Multi-outlet / franchise management. Posist's turf; requires org-hierarchy, role-inheritance, and cross-location reporting that cannot be responsibly built solo at this scope. Single restaurant only.
• Delivery aggregator integration (Zomato/Swiggy sync). UrbanPiper/Petpooja already own this; out of scope.
• Native iOS/Android apps. A mobile-first responsive PWA covers the "modern interface" requirement without an App Store review cycle.
• Real payment gateway / merchant settlement integration. Display a UPI QR/deep link for the bill amount; do not build actual payment reconciliation, refunds, or a merchant account integration.
• Conversational AI ordering (voice/chat-to-order). Deliberately left to competitors like DineOpen — building it would make us a clone rather than a distinct product.
• Historical-data-dependent "real" ML forecasting. A brand-new restaurant has no sales history, so forecasting works from day-one seed data + a transparent heuristic — see Section 9.
• Any agent action involving real money movement, supplier payment/commitment, or autonomous customer-facing marketing messages. (See Section 5.4 and 11.) Too much financial/brand risk to automate without a human approval step; these tools are simply not built, not gated by a policy layer on top of tools that exist.
• Fully autonomous execution with no approval step, for anything that changes what a customer sees or receives. The one exception is the Compliance Nudge Agent, which only ever notifies — see Section 5.4.

4. Personas

• Raj, owner-operator (primary persona): runs one 30–40 cover casual-dining restaurant or cafe. No dedicated IT or analytics staff. Price-sensitive, time-poor, needs decisions made for him (with his sign-off), not more dashboards to interpret.
• Meena, kitchen/floor staff: needs a dead-simple order queue and table status view; high turnover means near-zero training time is a real constraint (60% sector attrition), so UI must be self-explanatory in under two minutes — this now includes reading agent-generated tasks on the Kitchen Board.
• Aditi, customer: dines in, wants to know what's actually available before ordering, doesn't want to download an app, wants to know how long the wait is.

5. Detailed Requirements

5.1 Customer PWA

(Menu browsing without login, live availability, cart/order, queue with live wait estimate, bill + UPI display, order-status notifications, optional OTP capture for notifications only.)

5.2 Staff / Kitchen Display

• Kitchen Board now also receives agent-drafted prep tasks once the Owner approves them (see 5.4) — rendered identically to any other task, so staff don't need to know or care whether a task came from a human or an agent.

5.3 Owner/Manager Dashboard

• New tab: Agent Activity Log — timestamped record of every agent proposal, its basis, approval/rejection status, and resulting action. This is a real trust feature — it answers the obvious question of how anyone knows the AI isn't doing something random.

5.4 AI / Predictive Layer

Base layer:

• Demand forecast: expected order volume by hour/item, from day-of-week pattern + seed data (Section 9).
• Inventory/stockout prediction: flags items at risk of running out before close.
• Daily Briefing: plain-language morning/evening summary, LLM-narrated over real structured data only.
• Ask Anumaan: free-text Q&A grounded only in the restaurant's own data; explicitly refuses when data is insufficient rather than guessing.

Agentic layer (why this is real and not just a buzzword, see Section 11): the same forecast/briefing/Q&A data now feeds three scoped agents that can propose — and, after approval, execute — actions, instead of only describing them:

1. Prep & Forecast Agent: drafts a same-day prep checklist and, when stockout risk is flagged, a restock note. Surfaces on the Owner's Daily Briefing for one-tap approval; once approved, becomes real tasks on the Kitchen Board (5.2).
2. Anumaan Agent: the same Ask Anumaan assistant can now propose scoped actions in response to a request — e.g., "86 the item about to run out," "notify the next 3 people in the queue" — rendered as an approve/reject card, never executed silently.
3. Compliance Nudge Agent: the one fully autonomous (no approval gate) agent — checks at a configured cutoff whether the FSSAI compliance checklist (5.5) was completed, and notifies the Owner if not. Safe to run unattended because it only ever notifies; it never changes restaurant-facing state.

Guardrail model: every agent action is either notify-only (auto-executes — Compliance Nudge Agent only) or propose-then-approve (drafts, waits for a human tap — the other two). No agent is given a tool that moves money, commits to a supplier, or sends a customer-facing marketing message — enforced by simply not building those tools, not by a policy filter sitting on top of tools that exist.

5.5 FSSAI Digital Compliance Log, agent-monitored

• Daily temperature/cleaning checklist, staff-completed with timestamp, append-only.
• FSSAI license + Food Safety Connect QR code shown on the customer-facing menu page.
• Monitored by the Compliance Nudge Agent (5.4.3) rather than relying on the Owner remembering to check.

6. Screens & Information Architecture

Customer PWA: Menu Home, Item Detail, Cart/Order Review, Order Status, Queue/Wait Screen, Bill/Pay Screen, optional OTP capture sheet.

Staff / Kitchen Display: Order Queue Board (now shows both human- and agent-originated tasks, visually identical), Table Status Board, Menu Availability Toggle Grid.

Owner/Manager Dashboard:

1. Home / Daily Briefing — now includes the Prep & Forecast Agent's proposal card as the primary "hero" element, not a separate screen.
2. Orders · 3. Tables · 4. Inventory · 5. Staff · 6. Customers · 7. Sales & Analytics
3. Ask Anumaan — persistent chat-style panel that now also renders agent proposal/approval cards inline with its answers.
4. Agent Activity Log — full history of agent proposals and outcomes.
5. Compliance Log
6. Settings / Menu Management

Shared auth screens: Sign up / Log in, role selection, restaurant setup wizard (doubles as historical-data seeding step, Section 9).

7. Core User Flows

Flows A–E cover the dine-in order, the walk-in queue, kitchen fulfilment, the owner's morning routine, and 86'ing an item. Flow F covers the agent loop:

Flow F — Agent proposal and approval: Prep & Forecast Agent generates a draft prep checklist/restock note each morning → appears on Owner's Daily Briefing as a proposal card with its basis shown ("based on today's orders vs. your seeded Friday average") → Owner taps Approve or Reject → on approval, tasks appear on the Kitchen Board and the action is logged in the Agent Activity Log; on rejection, nothing changes and the rejection is logged.

8. Data Model

Entities (Restaurant, MenuItem, Table, Order/OrderItem, Reservation/QueueEntry, InventoryItem, StaffMember, Customer, DailySummary), plus:

Restaurant → AgentAction (many: agent name, proposal payload, basis/explanation, status [proposed/approved/rejected/auto-executed], timestamp, resulting change reference) — this is what populates the Agent Activity Log (5.3) and is also what the evaluation suite's trajectory checks (Section 12) validate against.

9. AI Feature Spec — Honest Version

The cold-start problem is handled by seed data and a heuristic-then-LLM-narration approach: forecasting is a transparent formula (forecast_qty = seeded_avg_qty × trend_factor), not a black-box model, and the LLM's job is to narrate that number, not invent new ones.

Extension for agents: the same honesty rule applies to actions, not just words. An agent proposal must state its basis (Section 5.4), must never claim a tool it doesn't have (there is no supplier-ordering or payment tool — if asked, the agent explains it can only draft a restock note for a human to act on), and must default to proposing rather than executing for anything except the notify-only Compliance Nudge Agent. We will not claim these agents are "autonomous" in the unqualified sense marketed by larger platforms (e.g., Toast IQ's chat-driven direct execution) — ours are deliberately approval-gated, and that's stated as a design choice, not hidden as a limitation.

10. Design Requirements & Guidelines

Mobile-first customer PWA, a two-minute rule for staff screens, bilingual-ready, tolerant of patchy connectivity, one consistent design system — plus:

• Agent proposal cards need a distinct, consistent visual pattern wherever they appear (Daily Briefing, Ask Anumaan) — clear "this is a suggestion, not a done action" affordance, with visible Approve/Reject controls and the basis/explanation text always visible, never hidden behind a tooltip.
• The Agent Activity Log should read like a clean audit trail, not a developer log — plain language, not raw JSON, even though the underlying data is structured.

11. Differentiation vs Competitors

• vs Petpooja / Posist: not competing on billing depth or multi-outlet scale.
• vs DineOpen: core wedge — predictive/agentic vs. conversational ordering.
• Grounding for the agentic wedge specifically: 2026 industry coverage frames this year as the shift from "AI as novelty" to "agentic AI as operational necessity" in restaurants, with Toast (US market) as the clearest reference point — Toast IQ (launched Oct 2025) already takes real-time action from a chat interface, and Toast IQ Grow (May 2026) is a dedicated autonomous marketing agent. Checking whether India-specific competitors have caught up: Petpooja (65,000+ restaurants) and Restroworks/Posist (20,000+ restaurants) show only "basic" AI integrations as of this research — no evidence of autonomous, action-taking agents. DineOpen remains conversational, not agentic. This is a genuine, time-limited white space in the India market, not an invented one — full sourcing in the market research.

12. Evaluation Strategy

Full detail lives in the evaluation suite and its runnable fixture — summarized here so the PRD is self-contained on what "we tested this properly" means for this build:

• Deterministic checks (forecast formula, permissions, state machines) — rule-based, run on every change, effectively free.
• Grounding checks (Daily Briefing, Ask Anumaan) — reference-grounded LLM-as-judge, calibrated against 15–20 human-graded examples before being trusted (≥80% agreement target).
• Tool-use/trajectory checks (the three agents) — verifies correct tool, correct parameters, and that the approval gate is respected; run across 5 trials per case since agents are stochastic.
• End-to-end scenario checks — the actual click-through flows (Section 7), human-graded against golden transcripts.
• Adversarial/red-team checks — attempts to push an agent outside its scope (e.g., "give this table a discount without telling the owner") — must be refused, since the tools to do otherwise simply don't exist.

This structure is borrowed from Anthropic's own published guidance on evaluating agentic systems and current LLM-as-judge practice, not invented for this project.

Every factual claim in this PRD traces to the market research or the sourcing in Section 11/12 above. Where a figure or capability could not be verified, this document says so explicitly rather than asserting it.