Standing service dependency-update-auto-merge-log-and-rules-retested-every-month · revised 12 October 2026
Standing service
Have your auto-merge log read and its rules re-tested every month
Each month every automatic merge is re-checked against your rules, the rule and kill-switch tests are re-run on a test repository, and you get a report. Nothing in your repository is changed for you.
This starts a conversation by email. Nothing is charged, and nothing is monitored, until we have agreed scope, access and terms with you in writing.
The responsibility you hand over
Rules that were right at launch drift when checks, branch rules and bot settings change. Nobody reads a log that no one asked for. A weakened required check turns safe merging into risky merging without any alarm.
Who it’s for: Lead whose dependency bumps merge automatically and who wants evidence that the rules still hold.
Usually starts when: Your checks, branch rules or bot settings changed, or a merged bump broke something, or a month passed with nobody reading the log.
The result: Every month each merge in the log is re-computed against your rules file, your branch settings are compared with the settings the job was tested under, the rule tests and the kill switch are re-run on a test repository, and you receive a report listing anything that changed.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A date for each monthly report is agreed in writing before it starts.
Hours are agreed in writing before the service starts. It runs once a month and is not staffed round the clock.
What must remain true
- Every logged merge is re-computed against the rules and any failed rule is identified in the report
- The report identifies any required check or branch rule weaker than the tested baseline
- The report includes rule and kill-switch re-run results and lists any failing case first
What we watch
- The month's decision log and merge history
- The branch rules and required checks export
- The rules file and your list of changes
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A month closes and the exports are available. | We re-compute every merge, compare the settings with the baseline, re-run the tests and send the report. |
| You change a required check, a branch rule or a bot setting. | We re-run the rule tests on the new settings on a test repository before you rely on them. |
| A merged bump is reverted or breaks the build. | We list it first in the report with the rule decisions behind it. |
We do on our own
- Re-compute each merge against the rules
- Compare settings with the baseline
- Re-run the rule and kill-switch tests on a test repository
- Write the report
We ask you first
- Any change to the rules file
- Any change to a rule, setting or page in your own systems
- Any wider access than the exports named here
- Contacting your customers or anyone outside your team
We escalate to you when
- A merge that broke a rule
- A required check removed or made optional
- The log has fewer rows than the repository's merge history shows
- The kill switch fails on the test repository
How you know it held. After our report is frozen, you re-compute up to 10 logged merges, all if fewer, and get the same verdict; with no merges, you verify the zero count against merge history.
How we keep it true
This service is never finished. Each month's report shows whether the things it watches stayed true, and it continues until you end it.
Let dependency update PRs merge themselves when your own checks and rules pass Job Optional
Update pull requests from your dependency bot merge on their own only when your checks are green and your written rules hold. Every merge is logged with a revert link, and you hold the kill switch.
Bought separately, each time it is needed; not part of the monthly fee
The one-off job; buy it first if you do not yet have one.
What is included, and what is not
- The monthly report
- The re-check table, merge by merge
- The settings comparison
- The re-run results
Included
- One repository and the job built under the one-off job on this site or one you can show us
- A re-check of every logged merge for the month against the rules
- A comparison of today's required checks and branch rules with the saved baseline
- A re-run of the rule tests and the kill-switch test on a test repository after any change you report
- A monthly report with counts, any weakened setting and any merge that broke a rule
Not included
- Changing the rules, the job or any repository setting
- Holding your token or merging anything
- Judging whether a package is safe
- Round-the-clock cover or a response-time guarantee
- Any promise about fewer bugs or less work
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
After our report is frozen, you pick up to 10 logged merges (all if fewer), re-compute each from the metadata and get the same verdict on every one. An omitted merge, wrong verdict or unflagged weakened required check fails the whole test; with no merges, you verify the zero count against merge history.
Evidence: The selected merges or zero-count history check, your results and the report's.
The report states the number of merges, the number outside the rules, the settings that differ from the baseline and what it cannot show.
Evidence: The monthly report.
The rule tests and the kill-switch test are re-run on a test repository each month and any failure is listed first.
Evidence: The re-run results.
Nothing in your repository has been merged, reverted or changed by us.
Evidence: Your repository's audit log for the month; we hold no token.
Sign-off. You read each report and re-run the acceptance checks with the files and steps supplied. A month counts as delivered only when those checks pass.
If it fails. If we cannot do a month because an export is missing or has changed, we say so and do not guess. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- A job with a decision log you can export
- The rules file and a saved record of the branch settings it was tested under
- A named person who reads the report and changes rules
We stop and tell you if
- The log is incomplete or missing
- Required checks are weakened and you will not restore them
- Nobody on your side can change a rule
What could go wrong
The service reads exports and reports, so there is nothing to undo. Ending it leaves your systems exactly as they are; you keep every report.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The exported log is incomplete, so a merge is missed. | The report compares the log's row count with the repository's merge history and says if they differ. |
| The report is read as proof that merges are safe. | The report says it checks merges against your rules, not packages against harm. |
| Exports carry private repository details. | We ask for pull request metadata and settings only, never source code. |
Each report is checked by a separate automated reviewer before hand-over. A person on your side re-computes a sample of merges and decides every rule change. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
Stays with a person
- You or your named person change every rule and setting
- You hold the kill switch and the token
Access we would need
- A monthly export of the decision log and the merge history
- A read-only export of branch rules
- A test repository for the re-runs
Questions
Do you merge or revert anything?
No. We read the log and report. You or your person make every change.
Do you say whether a package is safe?
No. We check merges against your rules and your settings.
Send an enquiry
Send us
- Which repository and job
- Roughly how many bot pull requests merge a month
- No logins, keys, customer data or payment details in the first enquiry
Later, once you agree
- A monthly export of the decision log and the repository's merge history
- A read-only export of the branch rules and required checks
- Your list of check, rule or bot changes during the month
You keep the repository, job and every login; we receive metadata and settings exports and work on a test copy, never holding your token or changing your repository. You run any token-dependent tests in your own test account and send the results. Before sharing exports, the terms state any model provider, country, retention, training status and deletion date for our copies.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “dependency-update-auto-merge-log-and-rules-retested-every-month” as the subject.