Munim × Nebius Token Factory × NVIDIA Nemotron

An AI back office that can show its work.

Munim uses Nemotron models for routing, reasoning, supplier extraction, invoice vision and concise narration. Token Factory serves those role-configured models; Munim's core application controls the data, validation and approvals around every inference call.

Live integration: the project owner has confirmed successful application inference through Nebius Token Factory with the Nemotron model roles listed below. Historical performance measurements shown in the project materials were made against NVIDIA's separate endpoint and are not Token Factory benchmarks.

Demo businesses and records are synthetic. Supplier agents and food-donation recipients are simulated. Payments are recorded, never processed. The public interactive demo is a separate hosted deployment; its active inference provider depends on that deployment's environment configuration.

Deployment architecture

Vercel and Supabase around a dedicated AI service.

The Nebius deployment profile provisions a separate Vercel web/API pair and a separate Supabase project. It supplies the Token Factory key to the intelligence service and keeps the existing public demo resources isolated. Model roles are platform configuration, so a deployment must point them at the Nemotron IDs above before its interactive AI path is described as Token Factory-backed.

Web app

Vercel

The staff and storefront experience are delivered as a Next.js app.

Application API

Vercel

The TypeScript API validates identity, scope, evidence and approvals before business data changes.

System of record

Supabase Postgres

PostgreSQL stores tenant-scoped operational records with database access controls.

Inference

Nebius Token Factory

The Python intelligence service calls the configured NVIDIA Nemotron model for each model role.

The verified Token Factory application test and the hosting profile are separate facts: testing confirms the inference integration; each hosted deployment still needs its own credentials, database, role configuration and live verification.

Role-based model routing

One model role per kind of work.

Model IDs are stored by provider in Munim's platform configuration. The AI service builds a role from that configuration, so a model choice does not change who can read or write business data.

Router

nvidia/Nemotron-3_5-Lightning

Chooses the next workflow from a constrained set of routes, so the right specialist can handle the request.

Why this role: A fast model fits a small, structured decision that happens before deeper reasoning.

Reasoner

nvidia/nemotron-3-super-120b-a12b

Works through multi-step questions with read-only business tools and chooses among bounded negotiation moves.

Why this role: The reasoning role handles the most context-heavy tasks; application rules still set the allowed actions and prices.

Extractor

nvidia/Nemotron-3.5-Super-VL

Turns simulated supplier replies into typed quote fields that can be checked against their source text.

Why this role: Schema-shaped extraction keeps untrusted supplier content separate from tools and business writes.

Invoice vision

nvidia/Nemotron-3.5-Super-VL

Reads synthetic supplier invoice images and prepares structured fields for a human-reviewed draft.

Why this role: The vision-language model can process the invoice image while validation and approval remain in Munim.

Narrator

nvidia/Nemotron-3.5-Super-VL

Writes short explanations from an already-detected finding and its cited cells.

Why this role: Narration explains the evidence; deterministic findings and templates remain available if model output fails validation.

The AI boundary

Inference is one part of the workflow.

Nebius hosts inference. Munim's database, API and approval path decide what the model can see and what may change.

  1. 01

    Authenticate and scope

    Core verifies the person and business, then issues a signed, short-lived run token for the allowed scope.

  2. 02

    Route to a specialist

    The configured Nemotron router selects a supported workflow. The Manager chooses only from tools exposed for that run.

  3. 03

    Read the books

    Read tools return curated PostgreSQL snapshots through core. The AI service has no database client or book-table write permission.

  4. 04

    Validate the answer

    Every figure must resolve to a snapshot cell. Extracted fields must match their source; unsupported claims are withheld.

  5. 05

    Ask a person to decide

    Changes land as drafts. Core applies one only after a named person approves it, in the same transaction as its audit record.

Open demos

Explore Munim with a synthetic business.

The staff demo provides open access through a demo-persona picker. Choose Nandini Mehrotra, the synthetic Cobnut owner, then explore the modules below.

Ask Munim and inspect its sources

Choose the synthetic owner and ask about the seeded business records. Open a source chip to inspect its rows; if the records cannot support an answer, Munim should say “Cannot verify.”

Open staff demo →

Review findings and drafts

Explore the owner inbox, see evidence-backed findings and inspect the approval boundary around a draft.

Open staff demo →

Try purchasing workflows

Explore stock and quote requests with simulated suppliers. A purchase-order draft never sends a real order.

Open staff demo →