Student project · 2026

A resource finder where safety never depends on a language model

Students often do not know which campus office handles their question, and a chatbot that guesses can do real harm when the message is about a crisis, sexual misconduct or a threat. This prototype checks every message with deterministic safety rules first. Everything else is answered only from approved knowledge-base sources, with citations.

ScopePhases 0–9 built and validated locally
Cost$0 local stack, no paid services
Release statusBlocked pending human decisions, by design

Student experience

Grounded answers, honest about their sources

Answers cite the sources they used. Each citation shows its review status and freshness, and the interface says plainly when a source is old or has not had a governed review.

Student chat: an answer about RIH hours with a numbered source citation, a baseline-review label, freshness notices and feedback buttons — A cited answer. The source is labelled as a baseline record awaiting governed review and as updated over a year ago.

Welcome screen with three example questions and a note that crisis, misconduct and threat messages are checked first — Welcome screen. Crisis, sexual misconduct and threat messages are checked before anything else.

Conversation history with three saved conversations and a clarifying question asking whether the student means a counseling or a medical appointment — Conversation history and a clarifying question for an ambiguous request. Captured at commit 24a35bc, before fix e380883 changed the answer to the 'Medical appointment' option. Answers come from unreviewed baseline records.

Resource directory cards showing category, freshness, review status and content version for each source — The resource directory: every page the assistant may cite, with its provenance and review status.

A cited answer about immunization records in the dark theme — Dark theme. Text and control colors are checked against WCAG AA contrast in both themes.

Safety design

Safety first, then governed retrieval

A deterministic router reads the original message before any planner, tool, retrieval or model. Crisis, Title IX and conduct messages get fixed guidance and stop there, and that guidance is still returned if storage or retrieval fails. No model output can lower a safety decision, and the optional local model never writes answer text.

Diagram of one chat turn: request guards, safety router, decline or guidance, planner, governed executor, governed retrieval and answer, with the terminal safety branch and fail-closed denials — One chat turn, every stage on the server. Independent student prototype, not an official UMBC or Retriever Integrated Health service. Synthetic data only.

Governed operations

A staff area checked by the server

Reviewers and administrators sign in to review sources, record risk and release decisions, and watch aggregate telemetry. Access is role-based and defined as policy files that deny by default. The accounts shown are throwaway demo accounts.

Staff sign-in page with empty username and password fields — Staff sign-in. Access is checked by the server, not the browser.

Reviewer source queue listing each source with status, freshness, citability and approve, reject and retire actions — Source review. A decision applies to the exact content version shown.

Governance dashboard showing release readiness blocked pending human decisions, the list of decisions waiting for a person, and battery check results — Release governance: readiness stays blocked until people decide. Evidence from candidate 9c8c7d2 (2026-10-15), not the latest commit. The red-team scenarios are AI-drafted. The readiness rules are not jointly accepted, so a 'ready' status is not trusted.

Observability dashboard with request, chat-turn, tool-call and security-event counts and per-route latency — Observability: aggregates only. No message text, identities or raw paths are recorded.

Admin audit log listing allowed and denied policy decisions with the rule that decided each — Audit log of policy decisions, including a denied request from a reviewer for admin-only data.

Architecture

Two hardened containers on a loopback-only stack

A React and TypeScript frontend behind nginx, and a FastAPI backend with governed tools and retrieval, SQLite storage and OpenTelemetry. It runs with Docker Compose or on a local Kubernetes cluster (kind) with default-deny network policies.

System architecture: student and staff browsers, the nginx frontend container, the FastAPI backend with the safety-first chat pipeline and staff operations, data, observability, assurance and deployment targets — System architecture. Independent student prototype, not an official UMBC or Retriever Integrated Health service. Synthetic data only. The 12-language crisis lexicon is AI-drafted and has not been reviewed by native speakers.

Known limitations

What this prototype is not

It is not meant for real students, real health information or public deployment, and it claims no clinical validation or certification.
Keyword and pattern safety routing misses unusual phrasing, crisis messages in uncovered languages and implicit risk outside its lists. The multilingual and implicit-risk terms are AI-drafted and have had no native-speaker or clinical review.
The citable sources are baseline records carried over from an earlier version, dated 2025, and not yet reviewed under governed retrieval.
It runs as a single API process over local HTTP, without multi-factor authentication.
Release readiness is blocked pending human decisions. Nothing here is production-ready.