Pull request guardrail

A decision can be undone in one line, by someone who never knew it was a decision. The reviewer checks that the code is correct. Nobody checks that the rule it removes was still needed.

Without AppThentic

1. Meera, Product: Sellers want to be paid on delivery. Can we drop the payout delay?
2. Engineer: Opens PR #2304, “Pay sellers on delivery”. It deletes a 24-hour delay in payouts/settle.ts.
3. Reviewer: The diff is small and the tests pass. Approved and merged.
4. A month later, Finance: Payouts went out on orders later flagged as fraud. The 24-hour hold was what caught them.

With AppThentic

om reads every pull request and merge request in GitHub, GitLab and Bitbucket. When one changes an approved rule, it comments before merge.

1. om spots the rule the change touches, from the diff.
2. om explains what it protects: the reason, the incident behind it, and what depends on it.
3. om asks the owner to review, in the PR.
4. The owner approves or blocks, in the PR itself.

What the owner decides

• Approve. The change merges. The rule gets a new version with the owner’s reason for the change, and the old version stays in its history.
• Block. The merge stops, and the owner explains why on the PR. Priya blocks PR #2304 and adds that she is open to dropping the hold for sellers older than six months.

Either way, the decision is recorded on the rule, with who decided, when and why. The next PR that touches the hold starts from that decision.

What om does not flag

Changes that touch no approved rule merge as they always have. om comments only where a decision is at stake.

Before the PR

The same check runs earlier: in AI coding tools before the assistant edits the code, and at the requirement, before anyone writes it. See AI coding tools and Change impact.

Who uses it

Engineering leads, reviewers, and the owners of rules that carry money and risk.