> ## Documentation Index
> Fetch the complete documentation index at: https://docs.meridian.study/llms.txt
> Use this file to discover all available pages before exploring further.

# Compass Overview

> Utilization, scheduling, and Compass reporting

# 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

<CardGroup cols={2}>
  <Card title="Scheduling & booking" icon="calendar-check">
    Reservations, conflict handling, and recurring use of rooms and resources
  </Card>

  <Card title="Utilization & capacity" icon="chart-line">
    How spaces are actually used—load, peaks, underused assets, and planning inputs
  </Card>

  <Card title="Space intelligence" icon="door-open">
    Discovery, amenities, live availability, and qualitative signals (noise, temperature, equipment)
  </Card>

  <Card title="Compass reporting" icon="chart-bar">
    Operational and utilization reports scoped to the Compass domain (distinct from Atlas org reports or Beacon event/approval analytics)
  </Card>
</CardGroup>

## 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](/compass/frontend) and [Web client best practices](/frontend/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

<CardGroup cols={2}>
  <Card title="Compass frontend" icon="code" href="/compass/frontend">
    UI structure and conventions for scheduling and space surfaces
  </Card>

  <Card title="Web client best practices" icon="browser" href="/frontend/best-practices">
    Shared React app conventions and backend interaction (`useFetch`, `postRequest`)
  </Card>

  <Card title="HTTP API" icon="book" href="/api-reference/introduction">
    REST entrypoints used by scheduling and room flows
  </Card>

  <Card title="Atlas (organizations)" icon="map" href="/atlas/overview">
    Org context when bookings or events are org-scoped
  </Card>
</CardGroup>

***

## Related pages

<CardGroup cols={2}>
  <Card title="Beacon overview" icon="tower-broadcast" href="/beacon/overview">
    Events, approvals, and how Beacon shares org and scheduling context with Compass.
  </Card>

  <Card title="Backend best practices" icon="server" href="/backend/best-practices">
    Room and scheduling routes in `Meridian/backend` next to the rest of the API.
  </Card>

  <Card title="Authentication overview" icon="shield" href="/backend/auth/overview">
    Tenant subdomains, JWTs, and how scheduling UIs authenticate.
  </Card>

  <Card title="Multi-tenant identity" icon="users" href="/backend/multi-tenant-identity">
    Cross-subdomain SSO when operators move between schools.
  </Card>

  <Card title="Testing" icon="flask" href="/testing">
    Tests and CI for backend and frontend scheduling changes.
  </Card>

  <Card title="Getting started" icon="rocket" href="/getting-started">
    Local stack setup before running Compass flows end-to-end.
  </Card>
</CardGroup>