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
- Sales asks for a 25% discount to save two accounts.
- An engineer finds the 15% cap in billing, raises it, and ships the same day.
- Three weeks later Finance sees margin below the board’s floor.
- Two weeks after that, someone learns the cap was protecting that floor. The person who set it left in March.
Nobody did anything wrong. The code said 15%. It did not say why.
With AppThentic
- The engineer opens the rule, or their AI assistant looks it up.
- They see the approved reason: protects the board’s margin floor on enterprise deals, owned by the Head of Finance.
- Change impact shows the margin report and the approval workflow that assume 15%.
- The request goes to Finance with the context attached. Finance approves an exception for the two accounts instead of raising the cap for everyone.
- The decision is recorded with who asked, who decided and why.
A real example of the stakes
On 1 August 2012, Knight Capital deployed new trading code. It reused an old configuration flag that had once switched on a retired function, and one of eight servers did not get the new code. In about 45 minutes the firm lost roughly $460 million. The code that ran had been unused for years; nobody active knew what the flag still controlled.
Every company has its own retired flags and forgotten thresholds. The question is whether anyone can find out why they exist before touching them.
See Change impact and the Product tour.