Aashray Business Logic¶
This is the authoritative, plain-language specification of how Aashray (SRATRC / Vitraag Vigyaan) is supposed to run, across the member app, the staff panel, and the backend that drives both. It exists so anyone, product owner, designer, or engineer, can understand the rules the system runs by, without reading code.
These files contain no code or implementation detail. They state the business rules in plain language: what happens, who acts, and why. When a rule does not work as intended today, the page states that fact in a "Known limitations today" note. These pages are the single source of truth for Aashray business logic.
The backend is the primary source for rules that it enforces. The member app and staff panel provide the user-visible flows. Confirmed staff practice and product decisions define rules outside the software. When sources differ, these pages state the difference (see Architecture & Data Model).
Start here¶
- Architecture & Data Model, read this first. What the three systems are and how they relate, the one idea that underlies every kind of booking (who it's for vs. who made it), and the three tiers of access. Every other file assumes this.
- Booking Lifecycle & Engine, how any booking happens, end to end: one main item plus optional add-ons, submit → confirm/pay → done or cancelled, and how booking for yourself, a guest, or a Mumukshu all work the same way underneath.
Domain files¶
| File | Covers |
|---|---|
| Architecture & Data Model | The three systems, one membership record per person, three tiers of access |
| Accounts, Identity & Authentication | How staff create an identity (cards, roles), temporary access links, then a member's day-to-day sign-in, profile, onboarding, and guests |
| Booking Lifecycle & Engine | The shared booking model: primary + add-ons, self/guest/Mumukshu, states, cancellation |
| Stay: Rooms & Flats | How room/flat inventory & availability are managed, what a member can request against it, check-in/out, charges |
| Food | The kitchen operation (menu, demand projection, serving tracking, Tapascharya fasting choices, vendor food report), then what a member can request, cutoffs, pricing |
| Travel | The travel-team operation, fleet choices, demand thresholds, routes, member bookings, bus groups, and coordinator access |
| Adhyayan & Utsav | How staff set up and run an Adhyayan or Utsav (rooms, check-in, temporary access link), then how a member requests a seat, cancellation and credit, attendance, feedback |
| Payments, Credits & Reconciliation | The money lifecycle: a price is set, a member pays, cancellation becomes credit, staff close the loop with reconciliation |
| Services: WiFi, Maintenance, Support & Gate | Four operational member services |
| Notifications, Short Links & App Updates | Push/email/WhatsApp channels, short links, forced member app updates |
| Custom Forms (Form Builder) | Staff-built forms: who builds and fills them, sign-in and allowed numbers, responses, and the automatic actions of Tapascharya, Paarna, flat host, and vendor forms |
| Satshrut | Staff-planned daily playback of recorded satsang videos with meditation audio, Monday Bhakti, and the 17th-morning Aanand Tithi |
| Status Vocabulary & Automatic Checks | What every booking/payment state means; what the system checks on its own |
| WhatsApp Groups | The staff WhatsApp screen: the group link on an Utsav or Adhyayan, member checks against a group, removals, join reminders, and the linked WhatsApp account |
| Smilestones | The Smilestones role: next-day group meal bookings for Smilestones guests, and the empty Smilestones screen |
Reference material¶
- Member-app UI detail, these pages define the business rule, not screen layout, copy, or visual design.
How the pieces connect (read this before diving into a domain file)¶
- Every person and every booking traces back to one membership record. A member, a guest, and a Mumukshu someone books on behalf of are all ultimately the same kind of record. A booking always records both who it's for and who made it, this one idea is why booking for yourself, a guest, or someone else all work the same way everywhere, and it's explained once in Architecture & Data Model rather than re-explained per domain.
- One booking model, many domains. Booking Lifecycle & Engine is the hub file; Stay: Rooms & Flats through Adhyayan & Utsav are the spokes, each covers one booking type in depth but assumes the shared mechanics described there.
- Money is centralized. Payments, Credits & Reconciliation is the single place that explains how charges are set, how credit is earned and spent, and what the 24-hour payment window means, domain files link out to it rather than re-deriving pricing.
- Status and timing rules are shared. Status Vocabulary & Automatic Checks is the one place every booking/payment state and every background check (the 24-hour auto-cancel, meal-count updates, WiFi capacity alerts) is explained, domain files reference it instead of repeating the vocabulary.
- Known gaps are stated plainly, not hidden. Wherever a rule does not fully hold in practice today, that file says so directly in a "Known limitations today" note.
Conventions used throughout¶
- Plain language only. Do not add code identifiers, routes, database structure, or HTTP detail.
- Every domain file leads with the operational reality, how the business delivers the thing, not only with what a member fills into a form. A member's request is described as the trigger that feeds into that process, not the whole story; where relevant, a "Known limitations today" section closes out where the described rules do not fully hold in practice yet.
- Numbers that are real business facts stay in (a price, a cutoff time, a day count) even though they happen to also be constants in code, only the code identifiers themselves are excluded.
- Source type is marked. Pages identify rules from the backend, member app, staff panel, staff practice, or product decisions. The Travel page identifies the travel-team process as staff practice and notes the separate pull request for matching software work.
- One term per concept. Use the terms below on every page.
Terms¶
| Use | Do not use | Notes |
|---|---|---|
| Raj Sharan, Raj Prasad, Raj Pravas, Raj Adhyayan, Raj Utsav | The member-app names of the five services. Use them in page titles. In body text, use stay, food, travel, Adhyayan, and Utsav. | |
| Adhyayan | study session, session | A study programme at a set place and dates. "Session" means only one sitting within an Adhyayan day, or a staff sign-in. |
| Utsav | festival, event | A festival with packages. |
| booking | registration, request | The record a member creates for any service. "Registration" can name the act or its window, such as "registration closes". WiFi, maintenance, and support keep "request". |
| Permanent Resident, Seva Kutir, Mumukshu, guest | Resident, PR, fellow seeker | Member types. Permanent Residents and Seva Kutir members live on site. Mumukshus and guests do not, and are called non-residents. |
| member app | the app, mobile app | |
| staff panel | admin panel, admin dashboard, dashboard | |
| backend | server | |
| role | permission level | Staff access. Name roles in plain words: super admin, Utsav admin, Utsav read-only role. Name a centre-scoped role by its centre, such as "the Utsav admin for the Raj centre". |
| super admin | full admin, superadmin | |
| waitlist, waitlisted | waiting list, waiting-list | |
| credit | store credit | Credit is never cash. Say "refund" only to state that none is given. |
| temporary access link | share link, temporary link | |
| short link | shortlink, short-link | |
| check-in (noun), check in (verb), checked in | checkin | |
| Research Centre | RC, ashram | |
| booker | the person who booked | The person who made a booking for someone else. The booker pays. |
| charge due at the office | cash item, pay at centre | A charge the member pays in person at the Research Centre office instead of online. |
| payment order, payment notice | Razorpay order, webhook | The payment order is what the member pays at checkout. The payment notice is the payment provider's message to the backend that a payment happened. |
| bus group | bus | One dated vehicle run with ordered stops and passengers. |
| form, Form Builder, response | custom form (after first mention), questionnaire | A form is built by staff in the Form Builder. A response is one saved set of answers. |
| Satshrut session | session (alone) | One date's planned Satshrut playback. |
| WhatsApp Business sender, linked WhatsApp account, WhatsApp group | The Business sender sends booking messages. The linked account is the ordinary WhatsApp account staff connect by QR code for group work. Each Utsav or Adhyayan can have one WhatsApp group. |