Skip to main content

​
Compass

Compass is Meridian’s surface for how campus time and physical resources are used: utilization, scheduling, booking, and the operational feedback loops that keep spaces honest. It overlaps with Atlas and Beacon in the data model (orgs host events; events need rooms), but Compass is framed around utilization and scheduling, not org administration or approval policy. Each pillar product has its own reporting; Compass covers utilization, occupancy, booking patterns, and related operational views.

​
Key features

Scheduling & booking

Reservations, conflict handling, and recurring use of rooms and resources

Utilization & capacity

How spaces are actually used—load, peaks, underused assets, and planning inputs

Space intelligence

Discovery, amenities, live availability, and qualitative signals (noise, temperature, equipment)

Compass reporting

Operational and utilization reports scoped to the Compass domain (distinct from Atlas org reports or Beacon event/approval analytics)

​
Core capabilities

​
Utilization

  • Usage patterns across buildings and room types
  • Evidence for space planning and policy (open hours, staffing, maintenance)
  • Tie-ins to booking and event-driven demand where the product exposes them

​
Scheduling

  • Time-based allocation of rooms and related resources
  • Conflict detection and practical constraints (capacity, blackout windows, integrations)
  • Calendar-oriented surfaces for students, staff, and operators

​
Cross-module reality

  • Atlas owns the org/club record, membership, and org-side governance; Compass consumes that context when spaces are booked in an org context.
  • Beacon owns event lifecycle, approvals, and stakeholders; Compass supplies scheduling and rooms when an event needs a place.

​
Architecture

Compass integrates with:
  • Frontend: primary web app in Meridian/frontend (see Compass frontend and Web client best practices)
  • Backend API: room and scheduling endpoints alongside the rest of the monolith
  • Real-time: WebSockets where live availability is surfaced
  • Beacon / Atlas: shared org and event data; boundaries are product framing, not separate databases

​
Who uses it

  • Students & staff: find space, book time, see what’s available now
  • Operators & facilities: utilization, issues, and scheduling load
  • Institutional planning: reporting that answers “how hard are we running this real estate?”

​
Getting started

Compass frontend

UI structure and conventions for scheduling and space surfaces

Web client best practices

Shared React app conventions and backend interaction (useFetch, postRequest)

HTTP API

REST entrypoints used by scheduling and room flows

Atlas (organizations)

Org context when bookings or events are org-scoped

Beacon overview

Events, approvals, and how Beacon shares org and scheduling context with Compass.

Backend best practices

Room and scheduling routes in Meridian/backend next to the rest of the API.

Authentication overview

Tenant subdomains, JWTs, and how scheduling UIs authenticate.

Multi-tenant identity

Cross-subdomain SSO when operators move between schools.

Testing

Tests and CI for backend and frontend scheduling changes.

Getting started

Local stack setup before running Compass flows end-to-end.