A concise introduction for partners, and other interested individuals.

Loewe — the project's alias(codename) and entry point (“Ask Loewe”).

Loewe is an AI powered career workspace for undergraduates: one place to explore roles, build and sync a living profile, network with context, manage applications, and see progress—guided by an agentic AI that plans steps, cites sources, and stays aligned with each student’s goals. The promise is simple: right information & support at the right time.

• Fragmentation. Students spread their career work across spreadsheets, email, LinkedIn, school portals, and one-off chat threads—with no single profile or clear history.
• Generic advice. Tools that ignore major, skills, values, and timeline produce shallow, forgettable recommendations.
• Low follow-through. Without tracking applications, conversations, and deadlines, exploration rarely turns into outcomes.
• Access Inquality With students having to pay for career exploration platforms, cost remains a stumbling block especially for lower-income earners

Loewe gives students a structured workspace with a persistent matching profile (skills, aspirations, constraints, and feedback from saves and dismissals) as the single source of truth for guidance and ranking.

We bridge the gap between what schools already provide (career content, programs, alumni networks) and what students experience day to day: curated, institution-scoped resources and networking paths—including direct, relevant alumni to learn from and connect with—without forcing students to fight dense websites or brittle directory search.

Loewe (the AI layer) goes beyond a single chat bubble: it supports planned steps, scheduled and on-demand work, answers grounded in sources, and surfaces verification and rationale where roles are shown—so recommendations feel personal, explainable, and trustworthy.

Institutions get a path from pilot (first tenant) to additional colleges through branding, allowlists, curated resources, and tenant-scoped data—aligned with how career centers actually operate.

What the product is designed to deliver, mapped to student-facing pillars. Exact rollout varies by release; the list below is the intended surface area.

For students: A career journey that feels connected—explore + network → save → apply → track—with school career resources and alumni within reach—and AI that is transparent (sources, verification) and respectful of noise (notifications and digests when they matter).

• Docker Compose: docker compose config can be validated on every push or pull request.
• Frontend: npm run lint (if present) and npm run build.
• Backend: python manage.py check, OpenAPI validate, and optionally a schema diff against a committed snapshot.

flowchart LR
  Browser[Browser_SPA]
  ViteProxy[Vite_dev_proxy_slash_api]
  Django[Django_Gunicorn_API]
  PG[(PostgreSQL)]
  Redis[(Redis)]
  Worker[Celery_worker]
  Beat[Celery_Beat]
  Browser --> ViteProxy
  ViteProxy --> Django
  Django --> PG
  Django --> Redis
  Worker --> Redis
  Beat --> Redis
  Worker --> PG

• Browser loads the React app built/served by Vite in development.
• In development, Vite proxies HTTP requests under /api to the Django server (configure the proxy in the Vite config), so the SPA uses the same /api path it would use behind a reverse proxy in production.
• Django handles HTTP for /api/v1/…, talks to PostgreSQL for persistence, and uses Redis for Celery broker/result backends and health.
• Celery workers pick tasks from Redis; Beat schedules periodic tasks. Workers may read/write the database for long-running or agentic work.

• REST API under /api/v1/ with JSON bodies and consistent error envelopes.
• Authentication: JWT (access + refresh); protected routes require a valid access token.
• Health: /healthz and /readyz for load balancers and ops.
• Agentic work: HTTP views may enqueue Celery tasks or return async responses (e.g. HTTP 202 accepted with a run_id); clients poll run status where needed.

• Single-page application (SPA): navigation happens in the browser without full page reloads.
• The app uses apiRequest-style helpers and generated types from OpenAPI; JWT access is typically kept in memory and refresh in sessionStorage (exact storage choices are an implementation detail—keep tokens out of plain URLs and logs).
• Streaming: some Loewe responses use SSE (server-sent events) for incremental UI updates.

Further detail (pagination rules, idempotency keys, deployment topology) belongs in your own API and operations docs when you maintain this repo separately.

• UX direction (“Career Map”) — Calm, editorial feel: Manrope + Inter, purple-forward palette, bento-style layouts, and a feed of rich cards with verification and “why this fits you” patterns—not generic dashboard clutter. Original design mockups were used as a visual north star, not as production markup.
• Multi-tenant product — Institutions are modeled as tenants (e.g. first tenant Amherst); student-scoped data carries institution scope so the same codebase can serve more schools via configuration and row-level separation.
• Trust and transparency — The product emphasizes citations, verification metadata on opportunities where available, flags for suspicious signals, and agent run visibility—so automation is not a black box.
• Security and PII — FERPA-sensitive posture is assumed for U.S. higher-education contexts: treat auth, CORS, rate limits, and AI data handling as first-class concerns; document retention and incident response for your deployment.