HTML show
workflow
github

DelayLens

What it is

"When should I leave?" You pick a London bus route, an arrival deadline and your walking times. DelayLens estimates your chance of arriving on time for every possible departure, using bus trips it actually recorded. It recommends the latest departure that meets your risk tolerance, which defaults to a 10% chance of being late. When the data is thin it says so. It shows counts only when there are fewer than 5 recorded trips, a preliminary estimate with no recommendation for 5–14, and a full estimate with a 90% band and "leave by" time for 15 or more.

Headline demo result: bus 29 (Mornington Crescent to Tottenham Court Road), Saturday 24 Oct, 17:00 deadline, 5-minute walks each end. The result is leave by 16:22, about a 92% chance (p=0.9174). It is based on 56 recorded trips and is a historical replay of inferred arrivals.

Who built what

D, data (Jintian Wang): TfL poller every 30 seconds with raw JSONL backups. Tiger Data/TimescaleDB storage with hypertables, a continuous aggregate and a columnstore policy. Conservative stop-event and trip inference. Several overnight collection runs. The 60-minute bus 24 validation. Branch integration and PR merging.
M, model (Olivia Guo): NumPy empirical-replay model. It sets aside recording gaps instead of counting them as late. A bootstrap over whole bus runs gives the 90% band, and a curve takes about 8.5 ms. She also added an advisor, a handoff loader and the backtest (Brier scores about 0.13), plus the Devpost and judge Q&A drafts.
B, backend (David):
- A FastAPI service that reads the database into an in-memory snapshot refreshed every 60 seconds.
- Ask DelayLens, where Gemini interprets the question and the model computes every number, with a 21-case test set.
- A calibration backtest at /api/calibration.
- Input hardening: 44 bad requests found 3 HTTP 500s, which were fixed.
- An offline snapshot mode, so no database or keys are needed.
- Demo scripts (./scripts/demo.sh) and a locked-snapshot API smoke test.
- The backup demo video and the submission handoff packet.
F, frontend: React/Vite/TypeScript UI with the departure chart, a bus 29 journey schematic, voice input for Ask, and a methodology and coverage view. It is desktop-only. The accepted work went in through PR #66.
Claude: Documentation, AGENTS.md, and the bus 29 short-segment export.

Verification state

Tests: 247 backend tests pass (28 live tests deselected), Ruff passes, and 47 frontend tests plus the production build pass. CI on main was successful when last checked.
Data runs: The database pipeline holds 56 short and 48 long inferred bus 29 segments. The independent standalone runs are below the 15-run threshold: 5 journeys from the 180-minute run and 4 from the overnight run. These counts are not pooled.
Demo checks: On loopback, 20 warm requests give a p95 of about 4.3 ms. A 93-second captioned backup video and a morning-data comparison (80 short and 70 long segments) are recorded.

What is still open

Not claimed or tested:
- public deployment or a VM that survived overnight
- real microphone or live Gemini calls
- physical offline rehearsal
- measured arrivals (everything is inferred from predictions)
- probability calibration
Sample size: the standalone bus 29 runs are still under the 15-run target.

Do this now: tell me who is submitting to Devpost, you or someone else. Then I'll draft the exact field-by-field text from docs/devpost-draft.md for them to paste.