Overrides
Sometimes a change has to ship before an agent can re-check it. An override lets an admin approve it, on the record, with a reason that can never be edited or removed.
Who can override
Organisation admins, or the account owner for a personal account, on the Team and Business plans. Other members can see overrides but cannot make them.
How to override
Open the failing run. The Details link on the Slipmark policy check goes straight to it, or find it under the repository on your dashboard.
In the Organisation rules section of the run's proof page, write why and choose Approve with this reason. The reason must be at least 10 characters. Write it for someone reading it a year from now, such as “Hotfix for incident 412, security review booked for Monday”.
Slipmark posts a new, passing Slipmark policy check on the pull request's head commit. Its title names who approved it and the summary carries the reason, so reviewers see it on GitHub without leaving the pull request.
An override covers that run's commit only. Push another commit and the rules are checked again from scratch.
The account log
Approving from Slack
With the Slipmark Slack app, a failing pull request has an Approve with reason button in its thread. It works exactly like approving on Slipmark Cloud: the same reason is required, Slipmark checks the person is a GitHub admin of the account at that moment, and the approval is written to the account log and shown on the GitHub check as approved from Slack. The first time, Slack asks the person to link their Slack user to their GitHub account.
Every override is written to the account log, along with every rule change:
- a rule created, with its patterns and agents
- a rule turned on or off
- an override, with the run, the rules that failed, who approved it and the reason
The account log works like the run ledger. It is append-only: entries cannot be edited or deleted, by you or by us through the application. Each entry includes the hash of the one before it, so changing or removing any entry breaks the chain and shows. If you send alerts to Slack, Teams, email or elsewhere, each override is also posted there as it happens, and a PagerDuty incident for that pull request closes.
On Business, the account log goes into every evidence pack as a rule history and an exceptions report, with a check that the log is intact. That answers two questions auditors ask: were the controls in place for the whole period, and what happened when they were bypassed.