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. No function names, routes, table/column names, ENUM literals, HTTP methods, or file paths — just cold, factual statements of what happens and why. Where a rule isn't fully working today, that's stated plainly too, in a "Known limitations today" note, rather than left out. Every implementation detail behind these rules — exact routes, database schema, admin mechanics, and every known code-level defect — lives in the paired Technical Reference, one file per domain, always linked from the top of its business-logic counterpart.
The backend is the source of truth. Where the member app or the admin panel behaves differently from what's described here, the backend wins — the two clients are just different front doors onto the same system (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 | How staff decide whether and how to run a trip (fleet, thresholds, routes), then what a member can request, the coordinator role |
| 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 |
Not here — moved to the technical set (they're staff/engineering reference material, not business rules): the full admin-panel page map, the exhaustive API route index, and the master discrepancies log. See Technical Reference.
Reference material¶
- Member-app UI reference — screen-by-screen UI detail (copy, fields, states) for the app lives in the Aashray app's own business-logic documentation, maintained in the
aashray-apprepository rather than duplicated here. Domain files describe backend/admin behavior and note where the app's documentation covers a topic in more detail, without repeating its content. - Technical Reference — the engineering companion to every file in this set. Business and technical files always pair up one-to-one by name, and cross-link at the top of the page.
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 described in a file doesn't fully hold in practice today, that file says so directly in a "Known limitations today" note. The engineering root cause for each one lives in the matching technical file.
Conventions used throughout¶
- Plain language only. No code identifiers, routes, database structure, or HTTP detail — if you're looking for that, follow the link to the paired technical file.
- Every domain file leads with the operational reality — how the business actually delivers the thing — not 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 don't 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.
- Provenance is marked. A few sections (fleet sizing, route preferences, planned changes) are explicitly sourced from direct conversations with SRATRC staff rather than from reading code — those sections say so, since they describe practice rather than anything the system currently automates.