Inspiration
The idea behind ONIT came from a simple frustration:
Getting an answer is often not the same as solving the problem.
When something goes wrong in the real world, people usually don't have one perfectly written question. They have screenshots, documents, emails, reference numbers, incomplete information, changing policies, and a lot of uncertainty.
And after asking an AI what to do, they are still the person who has to figure out:
What is actually true? What evidence supports it? What should I do next? And can I trust this recommendation enough to act on it?
I wanted to build something that could handle that part.
Instead of creating another AI assistant that is mainly good at conversation, I wanted to build a system that could stay with a problem until there is a clear path forward.
That became the idea behind ONIT:
AI shouldn't just answer the problem. It should help move the case forward.
Why ONIT?
Most AI assistants are designed around a conversation.
ONIT is designed around a case.
A real-world problem can involve multiple documents, missing information, external research, changing policies, conflicting evidence, and decisions that may have consequences.
ONIT brings those pieces together in one persistent workflow:
Problem → Evidence → Research → Decision → Resolution Plan → Human Approval
The goal isn't simply to generate another AI answer.
The goal is to move a real-world problem toward resolution.
How ONIT Works
1. Case Intake
The user describes a real-world problem in natural language.
ONIT creates a persistent case containing the problem, organization, relevant context, and case state.
The user doesn't have to understand the workflow or manually decide what steps the AI should take.
2. Document Understanding — Nutrient
Supporting documents can contain some of the most important facts in a case, but those facts may be buried inside unstructured documents.
ONIT uses Nutrient Document Web Services (DWS) to process supporting documents and extract structured facts that matter to the case.
For the demonstration, Nutrient extracts information such as:
- passenger
- booking reference
- airline
- cancellation date
- amount paid
- refund status
- requested resolution
This turns an unstructured document into structured evidence that ONIT can use throughout the case.
Nutrient does the heavy lifting at the document-understanding stage, transforming the user's document into usable case evidence rather than simply displaying the document to an AI model.
3. Case Analysis
ONIT analyzes what is already known and identifies what still needs to be verified.
This creates a separation between:
- facts supplied by the user
- facts extracted from documents
- information requiring external verification
- remaining uncertainty
Instead of immediately jumping from a question to an answer, ONIT first tries to understand the actual case.
4. Live Research — SerpApi
Real-world information can change.
Policies, procedures, eligibility requirements, and available options may not be safely answered from a model's existing knowledge alone.
ONIT therefore uses SerpApi to perform live web research relevant to the specific case.
When an organization is known, ONIT can make the research more targeted and prioritize authoritative sources.
For the flight-cancellation demonstration, ONIT researches current information relevant to the case and can prioritize official Japan Airlines sources.
The research results are stored with the case so the reasoning remains traceable rather than hidden inside a model response.
This gives ONIT a way to distinguish between:
- supporting evidence
- conflicting evidence
- information that still needs verification
5. Evidence Synthesis
ONIT brings the user's evidence and externally researched evidence together.
The document tells ONIT what happened.
The live research helps determine what the relevant rules, policies, or procedures say.
ONIT then evaluates the available evidence instead of treating every piece of retrieved information as equally reliable.
This is important because real-world cases are rarely perfectly clean.
6. Evidence-Backed Decision
ONIT produces a decision based on the available evidence.
The decision includes:
- reasoning
- relevant sources
- evidence strength
- confidence
- remaining uncertainty
This is deliberately different from simply asking an LLM:
"What should I do?"
The goal is to make the reasoning behind the recommendation visible and connected to the case evidence.
7. Resolution Plan
A decision by itself can still leave work for the user.
ONIT turns the decision into a concrete sequence of next steps.
Instead of ending with:
"Here's what you should do."
the case now has a structured path that can move it toward resolution.
8. Human Approval
ONIT does not pretend that a consequential external action happened when it did not.
Before a consequential action, the case reaches a human approval boundary.
The human can review the recommendation and decide whether the proposed action should proceed.
The goal is not autonomous action at any cost.
The goal is to move the problem forward while keeping the human in control.
9. Action and Resolution
Once approved, ONIT can move the case toward the appropriate resolution action.
In the demonstration, the approved resolution is prepared as part of a flight-cancellation refund-resolution flow.
The flight scenario is only a demonstration.
The underlying action layer is designed around the case rather than around flights specifically.
Demonstration
For the hackathon demonstration, ONIT uses a synthetic flight-cancellation case involving Japan Airlines.
The document is explicitly marked as a synthetic demonstration and does not represent a real customer incident.
The scenario shows the complete ONIT workflow:
Problem → Evidence → Research → Decision → Resolution Plan → Human Approval
The document is processed with Nutrient, relevant information is researched live through SerpApi, the evidence is synthesized, and ONIT produces an evidence-backed decision and resolution plan.
The flight scenario is only the demonstration.
The underlying ONIT workflow is not flight-specific.
The same architecture can be applied to other evidence-heavy problems such as:
- billing disputes
- insurance claims
- warranty cases
- consumer issues
- travel disruptions
- administrative procedures
- cases involving multiple documents and changing information
Why This Approach?
The key idea behind ONIT is simple:
AI should not stop at answering the problem. It should help move the case forward.
A chatbot can provide an answer.
A case-resolution system needs to understand evidence, investigate missing information, reason over sources, make uncertainty visible, create a plan, and know when a human should make the final call.
That is the gap ONIT is trying to address.
What I Learned
Building ONIT changed the way I think about AI.
When I started, I thought the interesting part would be getting AI to understand a user's problem and generate a good recommendation.
It turned out that wasn't the hardest part.
The hard part was everything around the recommendation.
Real cases are messy.
A document might contain the most important fact. A policy might have changed. Two search results might say different things. Something important might still be missing.
And even if the AI reaches what looks like a reasonable conclusion, that doesn't automatically mean it should be allowed to act on it.
That made me rethink the architecture.
Instead of treating the conversation as the product, I started treating the case itself as the product.
The problem, documents, extracted facts, research, sources, decisions, uncertainty, plans, and approval state all need to remain connected.
I also learned that I don't want ONIT to hide uncertainty just because a confident answer looks better.
If the evidence conflicts, that should be visible.
If something still needs to be verified, that should be visible too.
And if the system reaches a point where a real-world action could have consequences, there should be a clear boundary where a human can say yes or no.
That changed what I wanted ONIT to be.
I don't want to build an AI that simply sounds intelligent.
I want to build one that can take messy information, figure out what is actually known, investigate what is missing, explain why it reached a decision, and help someone safely take the next step.
That is a much more interesting problem to me.
What's Next
The flight-cancellation example is only where I chose to demonstrate the idea.
What I'm interested in building next is what happens when ONIT is given a completely different kind of problem.
A billing dispute.
An insurance claim.
A warranty issue.
A complicated administrative procedure.
A problem involving several documents and changing information.
The challenge is not to create a separate chatbot for each of these.
It is to make the same underlying case engine flexible enough to understand the differences between them while keeping the same fundamental loop:
Understand → Verify → Decide → Plan → Approve → Act → Resolve
Over time, I want ONIT to become better at identifying the evidence a case needs, finding authoritative information, tracking changes after the initial decision, and preparing actions that a human can safely approve.
There is still a lot to figure out.
And honestly, that's what makes the project interesting.
The question I'm exploring with ONIT is no longer:
"Can AI answer this?"
It's:
"Can AI understand this case well enough to help move it toward resolution?"
ONIT — Your problems, moving forward.
Built With
- ai
- artificial
- css
- document
- fastapi
- intelligence
- next.js
- nutrient
- processing
- python
- react
- serpapi
- tailwind
- typescript
- web
Log in or sign up for Devpost to join the conversation.