SETU - Unified AI for Supply Chains

One live graph, four AI engines: predicts delays, catches counterfeit material, scores real vendor trust, and negotiates — for contractors and suppliers alike, in 12 Indian languages.

Comment

Setu — Our Story

Inspiration

The brief for this hackathon had one line that stuck with us before we'd even picked a track: "the winning teams won't just wrap a chatbot around a prompt." That felt like a challenge. It's so easy to bolt an LLM onto a search bar and call it AI. We wanted to design something where the AI was doing the hard part — not describing a problem, but reasoning through it.

Supply chain felt like the right track the moment we stopped thinking about it as a database problem and started thinking about it as a graph problem. A construction project isn't really a list of purchase orders — it's a web of dependencies. This vendor feeds that shipment, that shipment blocks this task, this task is on the critical path for the whole floor. The moment we saw it that way, the idea of modeling it as one live knowledge graph — with AI engines reasoning directly over that graph instead of over a chat window — felt obvious. We named the idea Setu, "bridge," because that's what it's meant to be: the thing connecting a contractor's world to a supplier's world, instead of leaving both sides to guess at each other over WhatsApp.

The idea we're proposing

Setu is a live knowledge graph of a construction project's materials, vendors, shipments, and tasks, with AI engines reading and writing to it directly. A Risk Engine forecasting cascading delays. A Verify Engine catching counterfeit material from a delivery photo before it's installed. A Trust Engine scoring vendors from how they actually communicate, not a star rating entered once. An Action Engine drafting outreach and answering questions with a real graph query instead of a guess. Around that core: a marketplace for discovering and tracking suppliers, a set of frontier features (a what-if simulator, drawing intelligence, a voice agent, and vernacular AI fine-tuned across twelve Indian languages), and two separate portals — one for the contractor, one for the supplier — both reading the same underlying truth.

To be upfront about where we are: this is the plan, not the finished product. What we've actually built at this stage is everything needed to communicate and validate that plan properly — a full written proposal, a construction-themed pitch deck, an interactive clickable demo that simulates every screen described above (with real, live AI calls behind its suggestion buttons and chat assistant, running on representative sample data rather than a real deployed backend), and a recorded video walkthrough. The graph database, the production engines, and real vendor data are the work ahead of us, laid out below.

How we got here

We deliberately started with the narrowest possible version of the idea — one graph, four engines — and got that fully specified before letting ourselves add anything else. That discipline mattered, because the moment we let ourselves think bigger, the idea kept growing: a marketplace layer for discovering suppliers, a provenance ledger so a delivery's paper trail survives long after the project finishes, a second portal for the supplier's side of every interaction. Each addition had to earn its place by plugging into the same graph in our design — nothing was allowed to become a bolted-on separate screen, even on paper.

Rather than pitch this purely as slides, we built an interactive mockup so judges could click through something that feels like a real interface, not a hypothetical one. That decision mattered more than we expected — once you have a real clickable interface in front of you, "it would be cool if this button actually did something" stops being a hypothetical, so we wired real, live AI into the demo itself: the suggestion buttons scattered across every screen, and a chat assistant, both making genuine model calls rather than showing pre-written text, in English plus eleven major Indian languages. Getting that working is one of the things we're proudest of from this stage, even knowing the underlying data behind it is representative rather than a live production system.

The last stretch of this stage was turning the idea into a complete, presentable case: the proposal document, the deck, and a full demo video — script, AI-generated voiceover, captions, all of it.

Challenges we ran into

Scoping was the hardest part, and it wasn't really a technical problem — it was an editorial one. Once you can imagine twenty-plus real features, the temptation is to pitch all of them. Deciding which four or five actually carry the story, and which ones are supporting cast, took more iteration than any single diagram did.

We also learned a real lesson about the gap between "works in front of me" and "works anywhere," while building the interactive demo: getting live AI responses working in our own environment was one thing, and discovering that didn't automatically carry over the moment the file was opened somewhere else was a more sobering one. We made a conscious call to be upfront about that boundary rather than paper over it, since honestly representing what's real versus simulated at this stage matters to us.

Producing the demo video surfaced its own surprise: the AI-generated voiceover came back at barely half the length we'd planned the script's timing around, and every caption and on-screen cue had to be rebuilt around the real audio instead of our estimate. And along the way, a rendering bug taught us something about debugging blind — a chart in our deck was rendering completely invisible because of an unsupported fill setting, and we only found it by inspecting the underlying data rather than eyeballing the slide.

What we're proud of

A complete, honest, and — we think — genuinely compelling case for the idea: a proposal, a deck, and a working interactive demo that doesn't just describe a graph-and-AI platform but lets you click through one, with real AI responses in twelve languages, before a single line of production backend exists. That felt like the right way to spend a hackathon's proposal stage — proving the idea is buildable and worth building, not just describable.

What we learned

The clearest technical lesson was about matching the AI technique to the actual shape of each problem instead of reaching for an LLM everywhere: delay prediction wants a real forecasting model, not a language model guessing at probabilities; reading a delivery photo wants a vision model; only the genuinely messy, human part — a vendor's WhatsApp message, a plain-language question — actually needs an LLM. The clearest non-technical lesson was that real vendor communication is messy, multilingual, and code-switches constantly between languages mid-sentence, and almost nothing we looked at in this space takes that seriously. That gap is the part of the problem we're most convinced is worth solving.

How we plan to build it: architecture and roadmap

Everything above is the pitch. Here's the plan for turning it into a working system.

Phase 1 — Stage 2 prototype (immediate next step)

We're scoping the first real build to the highest-signal slice rather than attempting all four engines at once:

  • Stand up a Neo4j AuraDB instance and seed it with a real, small dataset (one project's worth of vendors, POs, and shipments).
  • Build the Risk Engine end-to-end: real graph traversal for cascading delay impact, with a lightweight statistical model (gradient-boosted or similar, not an LLM) scoring delay probability from vendor history and logistics signals.
  • Build the Verify Engine's core loop: a vision-language model call that checks a real delivery photo against a PO record and flags mismatches.
  • Everything else (Trust Engine, Action Engine, the marketplace, frontier features) stays on the roadmap below rather than in this first build, so we ship one thing that actually works end-to-end instead of five things that half-work.

System architecture

┌─────────────────────────────────────────────────────────────┐
│  Data sources                                                │
│  POs & invoices · vendor WhatsApp/email · delivery photos ·  │
│  GPS/logistics feeds · structural drawings                   │
└───────────────────────────┬───────────────────────────────────┘
                            ▼
┌─────────────────────────────────────────────────────────────┐
│  Ingestion layer                                              │
│  Document intelligence (PO/invoice/drawing parsing)           │
│  WhatsApp Business API webhook · GPS/IoT feed listener         │
└───────────────────────────┬───────────────────────────────────┘
                            ▼
┌─────────────────────────────────────────────────────────────┐
│  Neo4j AuraDB — the graph core                                 │
│  Nodes: Project, PO, SKU, Vendor, Shipment, Site, Task,        │
│         Certificate                                            │
│  Relationships: ORDERED_BY, FABRICATED_BY, SHIPPED_VIA,        │
│         DEPENDS_ON, DELAYS, VERIFIED_AGAINST, SUBSTITUTES_FOR   │
└──────┬─────────┬─────────┬─────────┬───────────────────────────┘
       ▼         ▼         ▼         ▼
   ┌───────┐ ┌────────┐ ┌───────┐ ┌────────┐
   │ Risk  │ │ Verify │ │ Trust │ │ Action │   ← independent services,
   │Engine │ │ Engine │ │Engine │ │ Engine │     each calling the graph
   │(stats │ │ (VLM)  │ │ (NLP  │ │ (LLM   │     directly, not each other
   │ model)│ │        │ │ score)│ │ agent) │
   └───┬───┘ └───┬────┘ └───┬───┘ └───┬────┘
       └─────────┴──────────┴─────────┘
                     ▼
┌─────────────────────────────────────────────────────────────┐
│  Application layer                                             │
│  Contractor web app (Control Tower, Marketplace, Analytics)    │
│  Supplier portal (web/PWA)                                      │
│  API gateway tying both to the engines above                   │
└─────────────────────────────────────────────────────────────┘

Phase 2 — Pilot

Run the Phase 1 build on one real, live project with real vendors, replacing our representative demo data with an actual data feed. This is where the Trust Engine gets built properly, since it needs real message history to score against — something we can't ethically fabricate, only collect going forward.

Phase 3 — Multi-site and marketplace

Once the core loop is validated, extend the graph across multiple concurrent projects (this is where the Control Tower's portfolio view starts earning its keep), and build out Supplier Discovery and Logistics Tracking against real vendor listings rather than sample ones.

Phase 4 — Cross-company network

The furthest-out piece of the vision: federated, privacy-preserving benchmarking that lets multiple companies improve their shared vendor risk scoring without any one of them exposing raw commercial data to a competitor. This is the part of the roadmap we're most excited about and least in a hurry to rush — it only makes sense once Phases 1–3 have real data behind them.

Built With

Share this project:

Updates

Submission history