Skip to content

How Business Logic Docs Stay Accurate

This page defines how to check and update the business-logic docs. This repo contains one doc set. The set is the single source of truth for the written business rules of Aashray.

Authority

  • The backend is the primary source for rules that it enforces on the server.
  • The member app is the source for the member-visible flow, including behavior that exists only in the app.
  • The staff panel is the source for the staff-visible flow, including behavior that exists only in the panel.
  • Confirmed staff practice and product decisions define processes that the software does not enforce.
  • This repo is the single source of truth for the written business rules.
  • Existing docs are a starting point, not proof that a rule is still correct.

Source baseline

  • For code-backed rules, check the current main branch of aashray-backend, aashray-app, and aashray-admin.
  • Treat local feature branches, old generated docs, and client copies of prices or statuses as unverified until main confirms them.
  • Record the source and review date when a page reports a difference between sources.
  • If an approved flow exists in a separate pull request but is not in main, document the approved flow as staff practice or product decision and state the code alignment gap.

Current review record

This set was checked on 2026-09-01 against these origin/main commits:

  • aashray-backend: bfd274c13a89928fcabfc5e168a4729315223d59
  • aashray-app: 508794d762c76955a0af8027e951470237444323
  • aashray-admin: 21f6f953160a8b69d2b406b6db628488021613c4

When sources differ, do not force one answer. State each relevant behavior, identify its source in plain language, and record the difference in Known limitations today when current behavior differs from intended behavior.

What each domain page must explain

  • The business outcome.
  • The people or teams involved.
  • The conditions that start the process.
  • The checks and decisions in the process.
  • The result for the member and staff.
  • Prices, limits, cutoffs, timing, and status changes.
  • The source of each important rule: backend, member app, staff panel, staff practice, or product decision.
  • Known differences between intended and current behavior.

Each page must use plain language. Do not add routes, code names, database details, or other implementation detail.

How to update a domain page

  1. Choose the domain. Use the page that owns the rule. Put shared rules in the relevant hub page.
  2. Define the question. Decide whether the claim concerns backend behavior, a client flow, staff practice, or intended policy.
  3. Check the relevant sources. Read the backend for enforced rules. Follow the member flow in the app. Follow the staff flow in the panel. Confirm operating practice with the staff team when software does not enforce it.
  4. Check each claim. Verify every price, cutoff, day count, limit, status, notification, and cancellation or credit rule.
  5. Write the current rule. State what happens today. Do not present an intended rule as current behavior.
  6. Record a known limitation. State the intended behavior, the current behavior, and the effect when they differ.
  7. Check related pages. Update pages that repeat or depend on the changed rule.
  8. Build the site. Run make build. Fix every broken link or navigation entry before review.

Which source answers which question

Use the source that matches the question:

Question Source
What does the server enforce? Current backend behavior
What does a member see or do? Current member-app behavior and backend behavior
What does staff see or do? Current staff-panel behavior, backend behavior, and confirmed staff practice
What should happen but does not happen in software? Confirmed product decision or staff practice
Which claims need review? Existing documentation

If no source confirms a claim, do not state it as a current rule. Remove it or ask the product owner or staff team to confirm it.

When a product rule changes

  1. Identify the affected business domain.
  2. Recheck the backend behavior.
  3. Recheck the member and staff flows.
  4. Update the owning page and its dependent pages.
  5. Run make build.
  6. Review the change with the product owner or the staff team when the rule comes from operating practice.