Manideep Gouraram New Jersey • New York

I build reliable AI systems for real-world workflows.

Applied AI Engineer & Systems Builder

I investigate complicated problems, turn them into structured systems, and build working products across AI, software, and data.

GitHub LinkedIn

Selected work

Systems built around the hard part of the problem.

Each project starts with a workflow that is easy to describe and difficult to get right.

01 / AI restaurant ordering assistant

Tableside

A restaurant assistant should answer to the menu.

I built a diner experience and owner workflow around a simple constraint: the assistant must work from restaurant-provided menu information, while ordering safeguards check what reaches the cart.

  • Menu truth
  • Ordering safeguards
  • Product experience
Explore the product: Tableside
Tableside chat on a synthetic demo restaurant. The diner writes “Please add one Tomato Basil Soup and place the order.” The waiter replies with an order summary: Tomato Basil Soup, quantity 1, $7.00; subtotal $7.00, tax $0.46, total $7.46; then asks “Shall I go ahead and place this order?”
Product screenshot · synthetic demo dataCropped from a captured session. The waiter asked for confirmation; no order was submitted.

Diagram of implemented behavior

  1. 01 Request“Add the soup and place the order”Diner message in the chat panel
  2. 02 Menu dataTool looks up the itemScoped to this restaurant by the server
  3. 03 GuardStrict schema · server priceNo price or restaurant id from the model
  4. 04 CartSame add-to-cart actionAs the menu button uses
  1. Asked first · seen in the captured demo

    A server-priced summary ($7.46) and “Shall I go ahead and place this order?” No order was submitted.

  2. Submitted · only after the diner confirms

    The order goes through only when the diner confirms the exact cart they were shown. Not exercised in the captured demo.

  3. Rejected

    Submission without a confirmation tied to that cart. An earlier live test showed a model trying exactly this.

Diagram of the implemented request path and its three possible outcomes. Every cart change passes through the same validated server functions as the menu buttons.

02 / Operations intelligence

Fulfillment Exception Causality Engine

An exception tells you what broke. What should you investigate first?

I built an independent prototype that reconstructs fulfillment events, traces downstream impact, and produces a structured investigation for operators.

  • Event correlation
  • Deterministic reasoning
  • Synthetic scenarios
Explore the investigation: Fulfillment Exception Causality Engine

Illustrative synthetic scenario

  1. Top-ranked candidate:Labor shortfall in packing.NV-05 · 1 of 7 planned staff · strong evidence
  2. Intermediate:Pack delayed.36 orders · 2 h 21 min later
  3. Intermediate:Carrier cutoff missed.36 orders · 1 h 38 min later
  4. Intermediate:Carrier handoff delayed.36 orders · 25 min later
  5. Symptom:Delivery promise at risk.36 orders · 19 due within 24 h
First investigation target:Check packing staffing at NV-05.Investigation priority P1 · score 86
Illustrative synthetic scenario. Sequence taken from the engine's output for exception EXC-0011 on its simulated demo dataset.

Method

A repeatable way to work through ambiguity.

The industries change. The way I investigate a difficult workflow stays consistent.

  1. 01

    Understand

    Map the people, decisions, data, and failure points in the workflow.

  2. 02

    Decompose

    Separate the visible symptom from the underlying questions the system must answer.

  3. 03

    Model

    Define events, states, constraints, and what counts as sufficient evidence.

  4. 04

    Build

    Turn the model into a working interface and reliable data flow.

  5. 05

    Break

    Look for unsupported claims, bad inputs, edge cases, and unsafe actions.

  6. 06

    Evaluate

    Check behavior against controlled scenarios and record what the system misses.

  7. 07

    Improve

    Fix the failure mode, then re-run the same evaluation.

Capabilities

The work sits at the intersection of four disciplines.

Curiosity is useful when it turns into working systems.

My background in Analytics & Systems led me from studying data to building tools that help people make better decisions inside complex workflows. I like problems that require both technical depth and an understanding of the person using the result.

More about me

Let's talk

Have a hard workflow worth making clearer?

I'm interested in full-time applied AI, product engineering, and systems roles, especially where I can own a problem from investigation through implementation.