Run the day
Customer storefront, POS, kitchen display, owner home, inventory, purchasing, finance, rosters and customer workflows.
Project README · Munim
The back office that keeps honest books.
Munim is an operating system for small restaurant groups, cloud kitchens and shops. It brings the counter, kitchen, stock, purchasing and books together, then adds an AI back office that explains what happened and prepares human-reviewed actions.
The One Guarantee
Nothing changes the books without a named person's approval, and every number shown traces to a source row. When evidence is missing, Munim says “Cannot verify.”
Product in one view
See what needs attention
Deterministic watchers surface business signals. Ask and investigations help staff explore them through evidence-backed snapshots.
Prepare the next action
Intelligence may create a sourced draft. A named person reviews it; only Core can apply the approved command.
The public demo uses synthetic business data. Supplier agents and donation recipients are simulated. Payments are recorded; Munim does not process them.
Architecture
Munim is split into a deterministic system of record and a separately permissioned intelligence service. The web client talks to Core through a typed API; Core owns identity, authorization, database writes, evidence snapshots, approvals and audit. Intelligence receives a signed run token and calls Core tools for scoped data. It never receives direct book-table write access.
Web app→Core API→PostgreSQLCore-scoped snapshots→Intelligence→Nebius Token Factory→NVIDIA Nemotron
Web apps
The marketing site in apps/site is separate from the customer storefront and staff product app in apps/web; both use Next.js, React and TypeScript.
Core
Hono and TypeScript validate commands and scope, maintain PostgreSQL state and expose trusted internal APIs.
Intelligence
Python service for routing, specialist skills, answer validation, extraction, narration, traces and spend accounting.
Database
PostgreSQL schemas separate core business records, evidence, intelligence workflow state and platform configuration. Supabase can host the database and auth/storage integrations.
Nemotron roles through Token Factory
The project uses role-based model configuration: the task selects a role, and the configured provider/model serves it. The owner has confirmed successful live application inference through Nebius Token Factory. This table shows the repository's configured Token Factory model IDs; it does not claim that each role was independently benchmarked in every deployment.
Router
nvidia/Nemotron-3_5-LightningClassifies a request into a constrained workflow.
Reasoner
nvidia/nemotron-3-super-120b-a12bAnswers with read-only evidence tools and selects only rule-approved negotiation moves.
Extractor and vision
nvidia/Nemotron-3.5-Super-VLExtracts structured fields from simulated supplier text and synthetic invoice images.
Narrator
nvidia/Nemotron-3.5-Super-VLExplains already-detected findings; templates remain the fallback.
Role separation keeps fast constrained routing separate from deeper reasoning and schema-focused vision/extraction. The application, not the model, decides which tools are exposed and what actions are permitted. Prices, permissions and data scope remain application configuration.
How an AI answer is grounded
- Scope. Core verifies the member and issues a short-lived signed run token for one tenant and outlet scope.
- Route. The Manager chooses a constrained workflow and loads only the relevant specialist skills/tools.
- Read. Tools request curated SQL snapshots from Core; models receive bounded digests and evidence handles.
- Validate. Every number and claim must resolve to evidence inside the active tenant scope. Invalid answers abstain.
- Approve. Proposed changes wait in an inbox. Core rechecks authority and source snapshots before applying an approved command with its audit record.
A model can explain and propose. It cannot post a journal entry, change stock, set a price, or approve its own draft.
Data, events and graph
Core commands run in PostgreSQL transactions with idempotency, audit entries and outbox events. Workers retry unpublished events, while Intelligence claims each event ID once. PostgreSQL notifications wake authorized streams; clients re-read under their own scope.
The supply graph connects suppliers, ingredients, dishes and outlets so staff can trace exposure to a supplier or price change. A graph port supports the in-tree PostgreSQL implementation; FalkorDB is an optional adapter. The active backend depends on deployment configuration.
Tenant-bearing tables use row-level security. Business money is stored in integer minor units with currency, and business times use timezone-aware timestamps. Current schema details live in ordered SQL migrations.
Deployment and dependencies
The marketing/site package has three production JavaScript dependencies: Next.js, React and React DOM. Its development tools are TypeScript, Vitest and React/Node type packages. The product app in apps/web is a separate Vercel workload with its own direct dependencies. The complete product also needs Node API/worker processes, a Python Intelligence service, PostgreSQL, and optionally a supplier simulator and object storage.
Vercel is suitable for the Next.js site. A Vercel-only site build does not deploy the Python service, persistent worker, database or supplier simulator. The Nebius profile uses a dedicated Supabase project and requires server-side Token Factory credentials and priced Nemotron role configuration.
See the Nebius deployment and interactive-demo page for the hosting profile and model roles.
Architecture deep dives
Project documentation: docs/architecture/ in the repository, including AI routing, data and events, security/approvals, and deployment.