DEV Community: Gnana-Shishir-Kumar

EndoSeg: What We Built, What We Didn't, and Why the Overlay Lies a Little

Gnana-Shishir-Kumar — Wed, 15 Jul 2026 22:24:13 +0000

EndoSeg was built for the Nebius Serverless AI Builders Challenge

Nebius Serverless AI Builders Challenge

nebius.com

Team

Shishir — [LinkedIn]
Je Sai Kailash Pulipati — [LinkedIn]
Maya Orzach — [LinkedIn]

What We Built

An estimated 1 in 10 women of reproductive age has endometriosis. The average time from first symptoms to diagnosis is still measured in years, and ultrasound is one of the few tools that can catch it early — if someone reviews the scan carefully. Most segmentation tools that try to help either run in a cloud you have to trust with a patient's pelvic ultrasound, or ship a black-box "AI diagnosis" that overstates what a pixel mask can actually tell you.

We built EndoSeg — a gynecological ultrasound segmentation tool that fine-tunes a lesion segmenter on Nebius Serverless GPU Jobs, exports it to ONNX, and then runs inference entirely in the browser. The scan never leaves the device unless the user explicitly opts in to a cloud comparison.

Just as important: We are shipping this with an honest account of what the model does and doesn't know. It segments lesion-like pixels. It does not diagnose endometriosis. That distinction is the whole point of this writeup.

What it does:

🔬 Browser-side lesion segmentation — ONNX Runtime Web (WebGPU → WASM fallback) runs the fine-tuned U-Net locally in a Web Worker, so a scan can be reviewed with zero data leaving the device
☁️ Optional cloud compare — a Nebius Serverless Endpoint serves the same model behind a token-hiding proxy, so a user can voluntarily check local vs. cloud mask agreement
⚙️ Full training pipeline on Nebius Jobs — three chained GPU/CPU jobs (preprocess → fine-tune → ONNX export + parity check) trained on the MMOTU ultrasound dataset
📊 Transparent metrics, not vibes — reported Dice/IoU on val and test splits, plus per-sample variance, instead of a single flattering aggregate number
🚫 No overclaiming by design — the UI cannot output "endometrioma," "chocolate cyst," or any disease probability from the network, because the model was never trained to produce one
🩺 Explicit scope disclaimer — research/education only, not a medical device, does not replace clinician review

Demo

Show Me the Code

https://github.com/Gnana-Shishir-Kumar/nebius-challenge

How We Used Nebius

Nebius Serverless isn't a side detail here — it's the entire training and (optional) serving path. Here's the full pipeline:

MMOTU ultrasound dataset (1,469 frames)
        ↓
  Nebius Job N1 — preprocess (CPU)
  binarizes 8 MMOTU class masks → single lesion/background mask
        ↓
  Nebius Job N2 — U-Net fine-tune (GPU, Dice + BCE loss, 50 epochs)
        ↓
  Nebius Job N3 — ONNX export + parity check
        ↓
  Static browser app (ONNX Runtime Web)
  ├── Default path: local inference in a Web Worker (WebGPU → WASM)
  └── Opt-in path: Nebius Serverless Endpoint + token-hiding proxy
                   ("Compare to cloud" button)

Nebius services used:

Serverless Jobs — the core of the training pipeline. Job N1 binarizes MMOTU's 8 tumor-type class masks down to a single foreground/background mask (the PRD scoped this as binary lesion segmentation, not tumor-type classification). Job N2 fine-tunes a U-Net on GPU with a combined Dice + BCE loss over 50 epochs. Job N3 exports the trained weights to ONNX and runs a parity check between the PyTorch and ONNX outputs before anything ships to the browser.

Serverless Endpoint — powers the optional "Compare to cloud" feature. Rather than exposing raw model access, requests go through a token-hiding proxy, so the browser app never holds a credential capable of hitting Nebius directly. This is used purely for a local-vs-cloud mask agreement check, not as the primary inference path.

GPU compute for fine-tuning — the U-Net training run (Job N2) is the one step that actually needs a GPU; everything downstream (preprocess, export, browser inference) runs on CPU or client hardware, which kept the compute footprint deliberately small.

Why browser-side inference matters

Most medical-image tools in this space — and most prior segmentation entries in Nebius's own healthcare track — treat the cloud as the default: upload an image, get a mask back. That's a reasonable pattern for most imaging, but pelvic ultrasound is different — it's a category of data people are understandably wary of sending anywhere.

EndoSeg flips the default:

The model weights are fetched once and cached; every subsequent inference happens locally in a Web Worker
Images never touch a server unless the user explicitly clicks "Compare to cloud"
The Nebius Endpoint exists as an opt-in verification step, not a requirement to use the tool

This is the structural differentiator versus prior bio/healthcare-track winners I looked at before building: privacy isn't a footnote, it's the architecture.

The honesty problem this solves

Here's the harder thing I want to be upfront about, because it's more important than the architecture: it would have been easy to make EndoSeg look like it does more than it does.

What the UI could show	What the model actually outputs
Teal overlay, Dice score, agreement %, "max probability"	A per-pixel lesion-vs-background mask
"Endometrioma / Chocolate Cyst" style labels	Nothing from the network — this would be a JS shape heuristic, not a classifier
Cloud vs. local "agreement"	Mask overlap between two segmenters, not diagnostic truth

There is no code path in EndoSeg that computes P(endometriosis), healthy vs. diseased, or endometrioma vs. other-cyst from learned class labels. MMOTU's 8 class IDs are discarded at preprocessing (mask > 0). If a healthy ovary scan still produces a finding-like overlay, that's expected behavior of a segmenter, not a bug in a diagnostic tool — because it was never built to be the latter.

Numbers that we stand behind, trained on MMOTU (1,469 frames), 50 epochs:

Split	Dice	IoU
Val (best @ epoch 33)	0.764	0.670
Test	0.755	0.655

Caveats that matter: per-sample Dice on held-out test images ranged from 0.02 to 0.97 — medium/large lesions segment well, small/thin ones sometimes get a confident but wrong "typical blob." Aggregate Dice hides that spread. Also, this MMOTU mirror has no recoverable patient IDs, so the split is stratified by file, not strictly patient-disjoint.

Data sources

Trained and evaluated on the MMOTU (Multi-Modality Ovarian Tumor Ultrasound) public dataset, 1,469 annotated frames across 8 original tumor-type classes, collapsed to a binary lesion mask for this MVP.

Tech Stack

Training/serving infra: Nebius Serverless Jobs (preprocess, fine-tune, export), Nebius Serverless Endpoint (optional cloud compare)
Model: U-Net, Dice + BCE loss, exported to ONNX
Inference: ONNX Runtime Web, WebGPU with WASM fallback, running in a Web Worker
Frontend: Static browser app, no server-side dependency for the default path
Dataset: MMOTU (ultrasound, 8-class → binarized to lesion/background)

Research/education only. EndoSeg is not a medical device. It does not diagnose endometriosis, score disease risk, or replace imaging review by a clinician.

EZRide Intel — I Built an AI Assistant for Boston's Hidden Free Bus Using Notion MCP

Gnana-Shishir-Kumar — Sun, 29 Mar 2026 22:57:36 +0000

This is a submission for the Notion MCP Challenge

What I Built

Most people in Boston and Cambridge have no idea that a completely free public shuttle has been running since 2002 — no fare, no ID, no registration. It connects North Station in Boston all the way to Cambridgeport via Kendall Square and MIT, and it's open to everyone.

It's called EZRide. And almost nobody knows it exists.

I built EZRide Intel — an AI-powered transit assistant that makes this hidden public resource discoverable, with Notion as the sole database layer. No PostgreSQL, no Firebase, no JSON files at runtime. Every read, every write, every analytics query goes through Notion MCP.

What it does:

🚌 AI Transit Assistant — answers questions about routes, stops, schedules, and fares using data served live from Notion
📊 Ridership Analytics Dashboard — historical ridership analysis from 2015-2025 with Chart.js visualizations, all data sourced from a Notion Analytics database
⚠️ Live Alert Management — active stop closures shown in the sidebar, resolvable with one click that updates Notion in real time via pages.update
🗺️ Trip Planner — saves formatted trip plans directly to Notion as rich pages using blocks.children.append
🔍 Notion Global Search — searches across all EZRide databases simultaneously using the Notion search API
🕐 Recent Searches — sidebar shows live questions pulled from the Notion Query Log DB, updated after every chat interaction

Video Demo

https://youtu.be/LBt1OOiA-vg

Show Me the Code

https://github.com/Gnana-Shishir-Kumar/ezride-intel

How I Used Notion MCP

Notion MCP is not a side integration in this project — it is the entire data layer. Here's the full architecture:

Charles River TMA data (charlesrivertma.org)
        ↓
   ingest.py (one-time seed script)
        ↓
  Notion Workspace (5 databases via MCP)
  ├── Routes DB      — 4 service patterns with stops, times, directions
  ├── Stops DB       — 16 stops with neighborhoods and service notes  
  ├── Alerts DB      — active stop closures, resolvable via pages.update
  ├── Query Log DB   — every user question + AI answer + timestamp
  └── Analytics DB   — ridership data 2015-2025 (11 years)
        ↕
   agent.py — reads all 5 DBs → Gemini generates answer → logs back to Notion
        ↓
   Flask web app (localhost:5000)

Notion MCP tools used:

databases.query — the core of the RAG pipeline. Every user question triggers live queries to Routes, Stops, Alerts, and Analytics databases. The results become Gemini's context window — so the AI's knowledge comes entirely from Notion at runtime.

pages.create — used in two ways: the ingest script seeds all 16 stops, 4 routes, 2 alerts, and 11 years of analytics into Notion on setup. Then at runtime, every user question is logged as a new page in the Query Log DB.

pages.update — powers the human-in-the-loop alert resolution. When a transit alert is resolved, clicking "Mark Resolved" in the UI calls pages.update to change the Status property from Active → Resolved in Notion live. No page refresh needed.

blocks.children.append — the Trip Planner creates a full rich Notion page with headings, callout blocks, and bulleted stop lists when a user saves a trip plan. The page appears instantly in their Notion workspace.

search — the global search bar queries across all EZRide databases simultaneously using Notion's search API, returning matching stops, routes, and analytics records.

Why Notion as the database matters

Most projects use Notion as a UI layer on top of a "real" database. In EZRide Intel, Notion is the database. There is no fallback. If you disconnect the Notion integration, the AI has no context, the dashboard has no data, and the query log has nowhere to write.

This means:

Non-technical users can edit stop data, add alerts, or update schedules directly in Notion — no code changes needed
The Query Log becomes a living analytics dashboard in Notion itself — you can see what people are asking in real time
Alerts can be managed by a transit operator directly in Notion, and the web app reflects changes instantly

The civic problem this solves

EZRide averaged 500,000 passengers per year before COVID — yet Cambridge city councillors have said publicly that even bus drivers don't know the routes are open to the public. People get turned away at the door. The awareness gap is real.

EZRide Intel makes the service discoverable through natural language. Ask it anything:

"Is EZRide really free?" → Yes, 100% free, no ID required
"What stops are near MIT?" → Main/Vassar and Vassar/Mass Ave for weekdays
"How did COVID affect ridership?" → Annual riders dropped from 508,000 in 2019 to 142,000 in 2020 — a 72% decline
"Are there any current stop closures?" → Broadway/Galileo closed Mon-Fri, use Kendall Square (71 Ames St)

Data sources

All route, stop, and schedule data sourced from the Charles River TMA official site. Historical ridership anchor points from official statements: 2012 daily average of 2,500 riders and pre-COVID annual ridership of ~500,000 sourced from Streetsblog Massachusetts and Wikipedia. Intermediate years reconstructed as realistic synthetic data following known trends.

Tech Stack

Backend: Python + Flask
AI: Google Gemini 2.5 Flash via google-generativeai
Database: Notion (via notion-client Python SDK)
Frontend: Vanilla HTML/CSS/JavaScript + Chart.js
Data ingestion: Custom Python seed script (ingest.py)
Pattern: RAG (Retrieval Augmented Generation) — Notion data as context window