Beeline: Campus Life Intelligence Hub

Inspiration

Campus services are useful on their own, but students have to connect them while walking between classes. A short dining line is not helpful if the walk makes you late. A bus departure is not helpful if walking gets you there sooner. We built Beeline around those everyday decisions and the time students lose making them.

The name comes from the paths people choose when the official route does not fit their needs. Our question was simple: could the same campus data help one student plan a better afternoon and help an operator find a recurring service problem?

What it does

Beeline has a student view and an operations view.

For students, Today combines a synthetic class schedule with dining, transit, laundry, packages and events. Ask keeps the constraints from a conversation, including a vegetarian meal, time to eat, an onward destination and an arrival deadline. Recommendations show their inputs and distinguish public reference facts from modeled conditions. Saving a reminder requires confirmation, and the reminder stays inside Beeline. Housing requests are prepared for the student to submit; Beeline does not submit them to HokieServ.

For operators, Beeline runs analytical SQL, shows the results and charts, ranks recurring time losses, and replays a proposed change against the same synthetic demand. Recommendations name the responsible campus team or external partner. Consent controls, local access policies and small-group suppression make the data boundaries visible.

A campus clock makes the demo repeatable. Moving it changes the decisions across the application while keeping every screen on the same campus minute.

How we built it

The application uses Next.js, React and TypeScript. Public reference snapshots supply campus places, walking paths, transit schedules and selected service rules. A deterministic generator creates 6,300 synthetic students and 30 days of campus activity. No real student records are used.

The public demo runs analytical SQL locally in DuckDB over synthetic data. Mutable state, including conversations, preferences and in-app reminders, is stored in SQLite on a persistent Railway volume. A Linux container supplies the native database libraries used by the Next.js server.

The repository contains Databricks adapter, pipeline, governance and agent assets. Live Databricks workspace execution is unverified. The public demo does not use hosted Databricks SQL, live Unity Catalog, live Genie or Agent Bricks.

The current local planner selects typed tools and renders answers from their results. The local analyst executes query templates and exposes the SQL. These are working local implementations, with integration contracts available for future workspace verification.

Challenges we ran into

The hardest planning bug appeared in a follow-up: asking for a safer lunch option could lose the original diet and class deadline. We made the journey constraints persist and included the walk after the meal in feasibility.

Another challenge was keeping modeled information honest. Queue lengths, delays and machine states can make a demo convincing, but they must never look like live measurements. The interface labels those inputs and lets the viewer inspect their sources.

Deployment also required the right runtime. DuckDB and SQLite use native modules, and mutable state needs disk persistence. We deployed a Linux container with a persistent volume and checked both engines through the public health endpoint.

Accomplishments we are proud of

• A complete student decision includes walking, waiting, eating and onward travel.
• Follow-up questions preserve the original constraints and explain feasible backups.
• Reminders require confirmation and survive refreshes.
• Analysts can inspect the SQL, chart data and recommendation replay.
• Desktop and Pixel 7 browser emulation cover the main demo, privacy controls, charts and campus clock.
• The same synthetic dataset supports both the student story and the operations explanation.

What we learned

A recommendation earns trust when someone can inspect its inputs and see its limits. We also learned that a campus-wide total is easy to misread: cohort size, modeled assumptions and replay conditions need to sit beside the result. Repeatable demo time helped us catch errors that ordinary page checks missed.

What's next

Verify the Databricks assets in an authorized workspace, then compare the local and workspace results. Validate assumptions with campus service owners before connecting any live service. Add measured wait and availability feeds only when the provider permits it and students understand the consent boundary. Test the recommendations with students before treating modeled time savings as real impact.

Independent student concept. Not affiliated with or endorsed by Virginia Tech, Blacksburg Transit or the Town of Blacksburg. All student data is synthetic.

Built With

• databricks
• docker
• duckdb
• gtfs
• next.js
• node.js
• openstreetmap
• playwright
• railway
• react
• sqlite
• tailwind
• typescript
• vitest