Alhuda Business Rules
This folder is the single source of truth for how Alhuda operates. Features are built from these rules — not the other way round. If code and a rule disagree, the rule wins and the code is a bug (or the rule is changed first, deliberately).
How to read a rule
Every rule has an ID, a status and a source.
### PAX-003 · Infant age is measured on each flight date
Status: PROPOSED · Owner: Operations · Source: IATA passenger type codes
<the rule, stated so it can be tested>
Enforced by: <migration / RPC / test> (filled in when built)
| Status | Meaning | Can we build on it? |
|---|---|---|
| DECIDED | Management has confirmed it. | Yes. |
| PROPOSED | Industry-standard default we recommend; not yet confirmed. | Only with a note in the PR; confirm before release. |
| OPEN | Needs a business decision. Options are listed. | No. |
| LAW | Required by statute or regulator. Not optional. | Yes — must. |
Files
| File | Covers | ID prefix |
|---|---|---|
| 01-customer-lifecycle.md | Lead → quotation → booking → approvals → travel → completion / cancellation; transfers | LC, SAL (leads and quotations) |
| 02-passengers-and-children.md | Adult / child / infant classification, entitlements, documents, guardians | PAX |
| 03-pricing-cancellation-refunds.md | Rates, discounts, cancellation charges, refunds | PRC |
| 04-inventory-and-groups.md | Group capacity, hotels, meals, ground transport, holds, releases | INV |
| 05-airline-group-ticketing.md | Airline group requests, quotations, PNRs, blocks, FOC, release, ticketing | AIR (§ numbers) |
| 06-visa.md | Visa cases, readiness, fees | VISA |
| 07-finance-accounting-tax.md | Revenue recognition, GST, TCS, TDS, ledgers, maker-checker | FIN |
| 08-access-control.md | Roles, permissions, segregation of duties, joiners/leavers, MFA; confirmations, role dashboards, how dates and password boxes look | ACC, UX |
| 09-audit-and-data-protection.md | Audit trail, retention, personal data | AUD |
| 10-cancellation-chain.md | Customer cancellation → seat release → airline cancellation → airline refund → ledger, tickets and visa | CXL |
| 11-partners.md | Partner onboarding, status, pricing from the rate sheet, credit limit, holds, isolation | PTR |
| 12-journey-and-customer-360.md | The universal customer journey flow chart; readiness; Customer 360 page | JRN, C360 |
| 13-duty-of-care-and-incidents.md | Emergencies and incidents, including death abroad | INC |
| 14-field-operations-and-health.md | Tour-leader app, check-ins and location; vaccination, insurance, special needs | FLD, HLT |
| 15-platform-reliability.md | Staging, plan/PITR, migration pipeline, edge-function deploys, CI gates, monitoring, backups and restore tests | PLT |
| 16-after-trip-experience.md | Feedback, complaints, supplier scorecards, returning pilgrims | CX |
| 17-intelligence.md | Intelligence everywhere: alerts, next best action, consistency checks, forecasts, AI guardrails | INT |
| 18-work-and-intake.md | One work inbox: arrivals from every channel, who owns a job, targets, business hours, escalation | WRK |
| 19-performance.md | How handling is measured: speed, throughput, outcomes, quality; and what is never measured. How fast the software is: requests per screen, what the browser downloads and caches | PERF, PRF |
| 20-traveller-app.md | The traveller's app: my trip, the guide per trip type, the programme and notices of a departure, passport scans that wait for review, who the app serves, the traveller's own documents, reminders and the offline copy on the phone, the notification inbox | TRV |
| 21-parties.md | Every customer, partner, employee and supplier has a permanent code (CU-, BP-, EM-, SU-); the ledger codes stay; the booking import finds parties by code | PTY |
| 22-leave-and-employment.md | Leave from the Employee Agreement v3: the leave year, CL/SL and EL, probation, holidays and the holiday calendar, HR and management approval, peak season, notice period, leave without pay, comp-off, the ledger and year end; the employee agreement issued, signed, countersigned and kept | LV, EA |
| 23-communications.md | What every booking e-mail says (the booking number, the lead customer and all travellers, the departure, the money); the reminder e-mails — payment due and overdue, departure, missing documents — who gets them, when they stop, the settings; the automatic WhatsApp notices — booking confirmed, payment received with the receipt PDF | COMM |
| PROGRAM.md | The upgrade program: waves, workstreams, status | — |
| decisions-log.md | Dated record of every decision and who made it | — |
Working agreement
- Rule first. A PR that adds or changes behaviour links the rule IDs it implements. If no rule exists, add one (status PROPOSED or OPEN) in the same PR.
- Enforce where it can't be bypassed.
src/lib/api.tsruns in the browser, so a rule that protects money, data or access is enforced in the database (RLS, constraints, SECURITY DEFINER RPCs) or an edge function — never only in the UI. - Test the rule, not the implementation. Tests name the rule ID they prove (
it('PAX-004: infant cannot occupy a seat', …)). - Decisions are logged. Changing a rule's status to DECIDED adds a line to decisions-log.md.
- Don't delete rules. Superseded rules are marked
SUPERSEDED by <ID>so history stays readable.