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 admin 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 fellow seeker 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 & Auth | How staff create an identity (cards, permission levels), 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), then what a member can request, cutoffs, pricing |
| Travel | The travel-team operation, fleet choices, demand thresholds, routes, member requests, bus groups, and coordinator access |
| Adhyayan & Utsav | How staff set up and run a session/festival, then how a member requests a seat, 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 & Config | Push/email/WhatsApp channels, short links, forced app updates |
| Status Vocabulary & Automatic Checks | What every booking/payment state means; what the system checks on its own |
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 fellow seeker (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 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 credits are 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.