Skip to content

Architecture & Data Model

Part of the Aashray Business Logic. Related: every domain file, this doc is the shared foundation they all build on.

This is the backbone that ties the whole system together: what the three systems are, how one membership record anchors everything, and who can access what. Read this first, every domain file assumes it.

The three systems, and how they relate

Aashray is really one system exposed through two different doors:

  • The backend holds the shared data and enforces its rules, including pricing, availability, booking permissions, and booking state changes. It is the authority for those enforced rules.
  • The member app is the front door for members. It's where they book stays, meals, travel, Adhyayans, and Utsavs, and pay for them.
  • The staff panel is the front door for staff. It's where the team manages rooms, food, travel, Adhyayans, Utsavs, wifi, maintenance, and the other day-to-day operations.

The member app and the staff panel are clients of the backend. They do not talk directly to each other. The backend handles shared data and its rules. A client can also have its own navigation, display, or local-state behavior. When sources differ, these docs state the backend rule and the client behavior separately.

Every person and every booking is tied to one membership record

Every member, and every guest or Mumukshu a member brings along, is ultimately represented by a single membership record. Nearly everything else connects back to that record: bookings, guests, payments, feedback, service requests, and more.

One pattern is worth remembering, because it shows up in every kind of booking: a booking always records two things, who it's for, and who made it. Most of the time these are the same person (a self-booking). But when a member books a stay, a meal, an Adhyayan, or an Utsav spot for a guest, or on behalf of a Mumukshu they're representing (a "Mumukshu" booking), the booking records both the person it's for and the member who made it. This single idea is what makes self, guest, and Mumukshu booking all work the same way across every part of the system, rather than each being a separate mechanism.

Three tiers of access

The system recognizes three distinct kinds of login, and they should never be confused with one another:

  1. A member account. This is the everyday login used in the member app, a phone number and password. There's no public sign-up; every account is issued ahead of time by the centre. The one exception is a guest whom a member books for: the backend gives that guest a card with the shared starter password, so the guest can also sign in (see Accounts, Identity & Authentication).
  2. A staff account, with different roles. Staff log into the staff panel with their own credentials, and, depending on what they've been granted, can see and manage different combinations of rooms, food, travel, Adhyayans, Utsavs, wifi, and other services. Not every staff member can do everything; access is scoped per person.
  3. A lightweight travel-coordinator login. Certain travelers are designated by staff to help coordinate a specific bus group. Rather than a full staff account, they log in with a one-time code sent to their phone, and what they can do is deliberately narrow, see Travel for exactly what a coordinator can and cannot do. A coordinator is not staff and has no staff-level access.

Temporary access links are not a fourth tier. A super admin can issue a time-limited link, for example for an event coordinator, that opens chosen staff-panel views without a staff login. The link has no account, password, or code behind it: whoever holds the link gets the read-only Utsav or read-only Adhyayan role until the link expires or staff revoke it. It is a borrowed slice of staff access (tier 2), not a separate kind of login. The staff panel shows these views as read-only; the backend does not fully enforce that. See Accounts, Identity & Authentication for the rules and known gaps.

How to read this documentation set

This repo has one documentation track:

  • This business-logic set describes what the system is supposed to do, in plain language, for anyone, engineer, designer, or product owner, who needs the rules without reading code. These pages are the single source of truth for Aashray business logic.

Start with this file, then read Booking Lifecycle & Engine for how a booking actually happens end to end, then move into whichever domain file matches what you're investigating: Accounts, Identity & Authentication, Stay: Rooms & Flats, Food, Travel, Adhyayan & Utsav, Payments, Credits & Reconciliation, Services: WiFi, Maintenance, Support & Gate, or Notifications, Short Links & App Updates. Each domain file is organized around how the business actually delivers that service, the operational process staff run, the decisions they make, the mechanics that turn a request into a real outcome, with a member's request framed as the trigger that feeds into that process, not the whole story. A member-facing "how do I ask for this" section always exists, but it isn't the spine of the document.