Synthetic CI monthly ledger: six red attempts are not six accepted fixes

A declared excerpt of six red attempts

Run labels R-1 through R-6 and cause labels C-A through C-D are invented. For this specification, an accepted fix requires the reviewed repair to be merged by the customer and the agreed job to execute successfully on the default branch. That rule must be agreed in the actual contract; the example does not change any supplier's terms. No real run, merge or delivery occurred.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

red attempt | cause | current disposition                         | accepted fixes
R-1         | C-A   | wrong command, later repaired and accepted   | 1 total for C-A
R-2         | C-A   | repeat before that same repair               | no additional fix
R-3         | C-B   | intermittent assertion, investigation open   | 0
R-4         | C-B   | retry failed; later green retry unexplained  | 0
R-5         | C-C   | expired secret, account-holder action open   | 0
R-6         | C-D   | workflow fix proposed; customer not merged  | 0

red attempts = 6; distinct cause groups = 4
accepted fixes = 1; unresolved cause groups = 3

Report the missing responsibility alongside the count

C-A needs its retained before/after run evidence. C-B needs investigation evidence and an authorised decision on any quarantine; a lucky green rerun does not close it. C-C belongs to the account holder. C-D needs customer review and merge before the default-branch acceptance check. Give each open cause an owner and next authorised action, without promising dates the service cannot meet.

• An unresolved failure does not consume a completed-fix allowance under the current SI page; confirm final counting terms in writing.
• A proposed pull request and customer-accepted fix are different report fields.
• Multiple causes exposed in one run need separately agreed grouping; the toy history does not resolve that case.

Use the report to decide whether the monthly scope fits

The existing £295/month responsibility covers named default-branch workflows on one repository, up to four fixes, with an agreed monthly summary. It excludes customer-held merges, secrets/runners/billing changes, application bugs and guaranteed response time. This ledger illustrates what to ask for, not a claim that four fixes were delivered. If only C-A was an eligible one-off fault, the existing £149 repair could be the smaller purchase. If most causes remain outside the supplier's scope, retain the account actions internally or re-scope rather than renewing by habit.

• Existing monitoring and free provider notifications may already meet part of the need.
• No automatic premium-lane escalation or new package is implied.

Evidence limits and first enquiry

Local count checks verify the six red attempts, four groups and one accepted outcome as authored; they do not classify real failures, test CI, establish recurring value or validate either price. Use redacted run context and a synthetic ledger initially, identify who merges and who holds the budget, and state your response to £295/month or £149 for the relevant scope. No code, personal logs, credentials or invitations. Written scope, secure access and payment terms precede monitoring; an enquiry is not a subscription.