Manideep Gouraram

About

I'm interested in problems where the answer isn't obvious.

I studied Analytics & Systems at the University of Bridgeport. What pulled me further into engineering was seeing how much work sits between finding a pattern and building a system someone can trust and use.

From questions to tools

I started by asking better questions of data. Then I wanted to build the tools that could act on those answers. Today I work across software, AI, and product decisions to make complicated workflows easier to understand and use.

What I care about

Three principles I keep coming back to.

  1. 01

    Understand the workflow

    Before building, I map who decides what, with which data, and where it goes wrong.

    The fulfillment workflow problem
  2. 02

    Make claims traceable

    Every conclusion a system shows should point back to the evidence behind it, or say that the evidence is missing.

    How the engine ranks candidate conditions
  3. 03

    Build for the person making the decision

    A diner at a table and an operator facing a queue need different things. The interface should fit the decision in front of them.

    Tableside walkthrough

How I work, in one example

A decision I had to take back.

  1. What I decided

    In Tableside, I first made order confirmation a rule in the assistant's instructions: summarize the cart, then wait for a clear yes before placing the order.

  2. What broke

    In a live test, a model read “Place the order” as that yes and tried to submit straight away.

  3. What I changed

    I moved the rule into the server. An order now goes through only after a confirmation step from an earlier turn, tied to a fingerprint of the exact cart the diner was shown. A unit test checks that ‘place the order’ alone cannot submit an order.

  4. How I checked it

    In a later session on a synthetic demo restaurant, “add the soup and place the order” produced a priced summary and a question. The log shows no submission, and no order was created.

The instructions describe the behavior I want; the code is what enforces it.See the decision in the case study

Why these problems

A diner at a restaurant table and an operator facing a fulfillment exception queue look nothing alike. Both work with incomplete information, both face a decision with consequences (what reaches the order, which upstream condition to check first), and both need a clear next step they can trust. That is the common thread in the two projects here.

Long term

I want to build something useful enough to become a company: something that creates value for people and, eventually, opportunities for others. Right now I want to keep growing by owning difficult problems and building systems that stand up to real use.

Education

Master's in Management Science (Analytics & Systems)

University of Bridgeport

Bachelor's in Electronics and Communication Engineering

J.B. Institute of Engineering and Technology