UCAR-OS, Multi-Tenant University Intelligence Platform

UCAR-OS turns a university's scattered spreadsheets into one system a rector can actually query, across academics, finance, HR, research, and infrastructure, with answers in plain French. We built it at Hack4UCAR and placed second. I worked remotely, building the entire frontend, the deployment, and the live demo, while the rest of the team was on-site for the 36 hours.

A university's data lives in disconnected spreadsheets and PDFs. No single system can answer a rector asking "why did dropouts spike at one school this term, and what should we do?", because that pulls from academic, HR, budget, and infrastructure data at once. It also has to serve many faculties under one roof without ever leaking one institution's data into another's.

1. 01

   Nine services behind one gateway

   A Kong API gateway fronts nine FastAPI services, each owning a single domain: identity, ingestion, preprocessing, core data, analytics, the AI council, reports, notifications, and a learning loop.

2. 02

   True multi-tenancy in the database

   Every row carries a tenant ID, and Postgres row-level security enforces isolation in the database itself, so application code physically cannot leak one institution's data into another's.

3. 03

   Le Cabinet, a six-agent AI council

   A router decides which specialists (academic, finance, HR, research, infrastructure, ESG) belong in a given question. They answer in parallel, and a synthesis step merges them into one recommendation that spells out where they agree and where they conflict. Every consultation is logged, and a demo cache replays the key questions instantly so a flaky network can't break the pitch.

4. 04

   An event-driven pipeline

   Uploaded files flow through a Kafka bus from ingestion to cleaning to storage, and detected anomalies like dropout spikes or budget gaps fire alerts on their own.

5. 05

   Analytics and branded reports

   A ClickHouse store powers the KPI time-series and forecasts, and a separate service renders branded PDF reports, both on demand and on a schedule.

6. 06

   Built to run, not just to demo

   Every service exposes metrics, and a Helm chart deploys the whole stack to Kubernetes with dashboards and alerts. Locally it comes up with a single command.

A Next.js frontend talks to a Kong gateway, which fans out to nine FastAPI services over a shared data layer of Postgres, ClickHouse, Kafka, and MinIO. Ingestion, preprocessing, and core data form a Kafka pipeline; analytics feeds the notifications; and Le Cabinet runs the six-agent council. Postgres row-level security keeps each institution's data isolated.

1. 01

   Building a hackathon project remotely while three teammates ran the floor on-site for 36 hours forced the cleanest split of responsibility I've ever shipped: I built features end-to-end, owned the UI, the deployment pipeline, and the live demo path; they owned the data, the agents, and the judges. We had to make every interface (API contracts, the demo script, the K8s manifests) good enough that we never needed a hallway conversation, because there was no hallway.

2. 02

   Pushing tenant isolation down into PostgreSQL Row-Level Security instead of guarding it in application code was the single highest-leverage decision, it makes leaks structurally impossible and turns `SET LOCAL app.current_tenant` into the only thing the IAM middleware has to get right.

3. 03

   "Le Cabinet" worked as a demo because the Synthesis layer surfaces *disagreements* between agents, not just consensus, judges immediately understood the value when the Finance and ESG agents disagreed on a campus expansion and the synthesis explained the trade-off.

4. 04

   The deterministic demo cache (hero questions replaying in <50 ms with zero LLM calls and `SIMULATE_AGENT_LATENCY_MS` choreography) was a hackathon-saving call, venue Wi-Fi was unreliable and rate limits would have killed the live cabinet stream during judging.

5. 05

   Splitting OLTP (PostgreSQL with RLS) from OLAP (ClickHouse) early let analytics_service answer cross-institution KPI queries fast without ever touching the transactional tables, and it kept the schema boundaries clean enough that 9 services could share the data layer without stepping on each other.

6. 06

   Kong DB-less + a Helm chart with ServiceMonitors and PrometheusRule alerts looked like overkill for a hackathon, but it turned the demo into a real K8s deployment story instead of a pile of docker-compose services, and judges noticed.