Standing service issue-triage-suggestions-checked-and-tuned-monthly · revised 12 October 2026
Standing service
Keep your issue-triage suggestions matching how your team labels, month after month
Each month 30 fresh issues are labelled by your people and compared with the workflow's suggestions; the label guide is tuned with your approval and the permission check is repeated.
This starts a conversation by email. Nothing is charged, and nothing is read or run, until we have agreed scope, access and terms with you in writing.
The responsibility you hand over
A triage workflow starts well and drifts as the product, the label list and the model change. Nobody re-measures agreement, and a permission change can quietly give the workflow more power than it was tested with.
Who it’s for: A team that runs an issue-triage workflow and wants to know whether its suggestions still match how people label.
Usually starts when: Labels or products have changed since the workflow was tested, or people have stopped trusting its suggestions.
The result: Each month your people label 30 fresh issues, the workflow's suggestions are compared with their labels, and the label guide is tuned with your approval. The workflow's permissions are re-checked each month, and a short summary shows the trend.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target for sending each month's sheet is agreed in writing before it starts.
The service runs once a month after the month closes. It is not a pager and has no round-the-clock cover.
What must remain true
- Each month 30 fresh issues are labelled by your person before they see the workflow's suggestions, and the counts of agreement are recorded with links
- The workflow files still hold only the permissions agreed, and every label it can apply is on your list
What we watch
- New issues and the workflow's suggestions, read through a Read-only account or a monthly export
- The workflow files and label list in the repository
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A month closes. | We send the agreement sheet, the permission check and the summary. |
| Agreement falls below the level agreed in writing. | We list the labels that cause it and propose a label-guide change for your approval, or recommend a replay. Linked job: Issue triage suggestions |
| The workflow files show a new write permission or a new label outside your list. | We flag it first in the summary and propose the change that removes it. |
We do on our own
- Read issues and workflow output
- Compare suggestions with your labels
- Open a pull request with a proposed guide change
We ask you first
- Any change to labels, permissions or the workflow
- Wider access to the repository
- Any use of issue text for another purpose
We escalate to you when
- The workflow gains a permission that was not agreed
- Agreement falls two months running
- Issue text looks like an attempt to instruct the model
How you know it held. Each month your labeller can recount the agreement from the sheet, and the permission check lists the workflow file permissions line by line.
How we keep it true
This service is never finished. Each month's summary shows whether what it watches stayed true, and it continues until you end it.
Label new issues, link duplicates and ask for missing details; people still decide Job Optional
A workflow suggests labels from your list, up to three possible duplicates and one missing-detail question on each new issue. It never closes or edits anything, and it is tested on 100 past issues.
Bought separately, once
The one-off job that builds and tests the workflow on 100 past issues.
What is included, and what is not
- The monthly agreement sheet with links
- Proposed label-guide changes as a pull request
- The permission check result
- A short summary and trend
Included
- One repository running the issue-triage workflow, with up to 30 labels
- A monthly fresh sample of 30 issues, labelled by your named person before the workflow's suggestions are shown to them
- Agreement and duplicate-precision counts, with links
- A monthly permission check of the workflow files and a short summary
Not included
- Closing, editing or assigning issues
- Triage of private tickets with personal data
- Changing your labels without your approval
- A promise of any agreement level
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each month 30 issues have a person's label recorded before the suggestion was shown, and the sheet links each issue. The sheet states that 30 issues can only show a large change.
Evidence: The monthly sheet with timestamps and links.
The permission check lists every permission in the workflow files and shows no write permission beyond the agreed label and comment step.
Evidence: The line-by-line permission list.
No label guide change is made without your written approval.
Evidence: The change log with approvals and the merged pull requests.
Sign-off. You read each sheet and tell us whether the label list and level still suit you. A month counts as delivered when you have received the sheet and the summary.
If it fails. If the export is missing or changed shape we say so, explain what we need 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 triage workflow already running, built by us or by you, with an editable label guide
- At least 30 new issues a month
- A named person who labels the monthly sample
- A Read-only account or a monthly export
We stop and tell you if
- Two months pass without the sample being labelled
- Fewer than 30 new issues a month
- The workflow gains write permissions we did not agree
What could go wrong
The service reads and reports, and proposes changes as pull requests you merge. Close one and nothing changes. Ending the service leaves your workflow as it is.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A month of 30 issues is a small sample. | The summary shows counts, not only percentages, and says when a change is within what 30 issues can show. |
| Issue text from strangers carries instructions. | Ticket and issue text is analysed offline: the model gets the text and returns rows a script validates, with no tools, no network and no secrets, so a hidden instruction cannot run a command or send data. It could still skew a row, so a script validates every row and your reviewer re-checks a sample. |
| The labeller sees the workflow's answer first and agrees with it. | The sample is labelled before the suggestions are shown, and the sheet records the order. |
A separate automated reviewer checks the work before hand-over. Your named person labels the sample and approves every change. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
Questions
Do I need the one-off build first?
No, but the monthly service needs a workflow to measure. The one-off job builds and tests one.
Does the service change our workflow?
Only by pull request, which you merge. We never push.
Why check permissions each month?
A later edit can give a workflow more power than it was tested with. The check lists every permission line by line.
Also part of
Send an enquiry
Send us
- How many issues arrive a month and which workflow you run
- Who labels the monthly sample
- No issue text, tokens or logins in the first enquiry
Later, once you agree
- A monthly export of new issues and the workflow's output, or a Read-only account
- The current label guide and workflow files
- The name of your labeller
You keep the repository, the workflow and the model key, and the workflow runs in your account with your key. We read issues and the workflow's output through a Read-only account or an export, and propose changes only as pull requests you merge. Our automated agents read them in a sandbox; we make no "no training" or "no storage" promise here, and the agreement names the model provider, country, retention and training status before anything is shared.
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 “issue-triage-suggestions-checked-and-tuned-monthly” as the subject.