Changing a rule safely
The path from "can we change this?" to a decision the right people made, with the reason on record.
Most incidents caused by business logic start the same way: a reasonable request, a correct reading of the code, and nobody who remembers why the rule was there.
Without AppThentic
- Product: Sellers are complaining that payouts take a day. Competitors pay on delivery. Can we pay instantly?
- Engineer: The delay is one line, a 24-hour hold in the payouts scheduler. Nothing references it. Removed, shipped the same day.
- Three weeks later, Finance: ₹38 lakh went to sellers for orders the payment gateway later flagged as fraud. The money has already left, and the bank will not reverse a completed payout.
- Everyone: The hold was there so the gateway’s fraud check could finish before money moved. It can take up to a day. The person who set the hold left in March.
Nobody did anything wrong. The code said 24 hours. It did not say why.
With AppThentic
The engineer opens the rule before touching it, or their AI coding tool looks it up for them.
58PAYOUT_HOLD = timedelta(hours=24)
The gateway's fraud check can take up to 24 hours to flag an order. Paying out before it finishes means paying for fraud we can't claw back.
Gateway fraud review · Seller reserve balance · Daily payouts reconciliation
- The engineer sees the reason and the owner in one place, before the change is written.
- Change impact shows the fraud review and reconciliation that assume the hold.
- The request goes to Payments with that context attached. Priya decides: payout on delivery for sellers older than six months, the hold for everyone else.
- The decision is recorded with who asked, who decided and why. The next person who wants faster payouts gets this answer first.
If the change skips this and goes straight to a pull request, om flags it there and asks Priya before merge. See Pull request guardrail.
See Change impact and the Product tour.