Business rules
What AppThentic counts as a business rule, and what it leaves out.
A business rule is a decision the business made that the system enforces. Changing it changes what a customer pays, gets or is allowed to do, or what risk the company carries.
Examples
| Rule | Where it usually lives |
|---|---|
| Refunds are allowed for 30 days after delivery | A condition in the refunds service |
| Discounts are capped at 15% without approval | Billing code and a pricing config |
| Orders above ₹50,000 wait for a manual check | A risk rule and a review queue |
| B2B customers get 60-day payment terms | Invoicing code and the partner contract |
| Accounts younger than 7 days cannot withdraw | Payout eligibility checks |
What is not a business rule
AppThentic leaves out logic that does not encode a business decision: retries, caching, formatting, framework wiring, input validation that only protects the system itself. Asking owners about those wastes their attention.
Signals AppThentic looks for
- Conditions on money: amounts, caps, thresholds, currencies.
- Conditions on time: windows, deadlines, expiries, cool-off periods.
- Conditions on who: roles, customer segments, regions, account age.
- Conditions on state: statuses, approvals, overrides, exceptions.
- Values that appear in both code and conversation: a “30” in code that someone argued about in a ticket.
One rule, many places
A rule often lives in more than one place. The refund window may be in the refunds service, the support macros, the finance reconciliation and the terms of service. AppThentic treats these as one rule with several locations, so a single answer explains all of them and a change to one location flags the others.