Change impact
See what a change touches before anyone writes code, and stop a pull request from quietly undoing an approved rule.
The expensive failures are rarely in the line that changed. They are in the system three teams away that quietly depended on the old value.
What change impact shows
Before a rule changes, om shows:
- Every location of the rule: services, configs, jobs, help pages and contracts.
- What depends on it: other rules, reconciliations, reports and downstream services that assume its current value.
- The approved reason, and whether the change still respects it.
- The owner, who should be part of the decision.
Example
A product manager wants refunds to move from 30 to 45 days. Change impact shows five dependants. One of them, the daily finance reconciliation, assumes every refund settles within the payment partner’s 35-day chargeback window. At 45 days it would break. The approved reason says exactly why 30 was chosen.
The change can still happen. It happens with Finance in the room, and the reconciliation changes with it.
From a requirement to a PRD
Know the blast radius before anyone writes code. Meera in Product explains what she wants in plain words:
Let borrowers pause one EMI a year, without a penalty.
- om shows what it touches: interest accrual, credit bureau reporting, the collections dialer and the late-fee rule, across three teams.
- om asks what is unclear: “Should a paused EMI be reported to the credit bureau as on time? If not, a borrower who used the pause could see their score drop.” Meera answers, or asks Compliance first.
- om writes the PRD: the goal, her decision on bureau reporting, the systems that change, and the open questions.
- om hands it to the right developer. It suggests the owners of the systems the change touches, here Lending and Collections, and the PRD goes to them with the blast radius attached.
Rework is caught at the requirement, not in QA or production.
On every pull request
om reads pull requests and merge requests in GitHub, GitLab and Bitbucket. When one changes an approved rule, om comments on it before merge:
om on PR #2304 · “Pay sellers on delivery”: This removes the 24-hour COD payout hold Priya S. approved in June 2026. It stops about 40 fraud payouts a month. I’ve asked her to review.
The owner approves or blocks in the PR itself. Either way, the decision is recorded on the rule, with who decided and why. An approved change gets a new version of the rule and its reason. See Pull request guardrail.
Where to see it
- In AppThentic, from the rule’s page.
- On pull requests that change a known rule.
- In AI coding tools, before the assistant edits the code. See AI coding tools.
See the Product tour for this change step by step.