On 2026-09-14 we ran a public simulation of 50 GitHub issues through TriageFlow. Each issue received a label, a priority and a triage suggestion with a verifiable reason. Measured end-to-end latency was about 10 seconds per issue (≈3 s classification + ≈6 s delivery, remainder network overhead). The GitHub App had zero access to source code (permissions: Issues and repository metadata only — no contents key in the public App manifest). Per-issue raw results (id, type, labels, priority, suggestion, latency, rationale flag) are published with the benchmark repository described under Dataset; the exact reproduction steps below regenerate the same measurements.
| Metric | Result |
|---|---|
| Issues processed | 50 |
| Issues labelled automatically | 50 / 50 |
| Issues with priority assigned | 50 / 50 |
| Issues with verifiable suggestion | 50 / 50 |
| Median per-issue latency | ≈10 s (≈3 s classify + ≈6 s delivery) |
| Duplicate groups collapsed | Reported in dataset (5 same-bug reports → 1 group) |
| Audit rationale stored | 50 / 50 (in triage history, no thread spam) |
| Source-code access used | 0 (permissions: Issues + metadata only) |
Illustrative cost frame: manual triage ≈3 minutes per ticket; at $85/hour engineering cost, a 50-ticket backlog costs ≈$212.50 of engineering time. TriageFlow Starter ($49/mo) covers 1,000 issues/mo. (Illustrative example — actual savings vary.)
The complete per-issue dataset (one row per issue: id, type, labels, priority, suggestion, latency seconds, rationale flag) is published together with the 50-ticket benchmark repository, whose Issues tab lists the labelled sample issues. Reproduce locally with the method below — no signup required.
Zero Source-Code Access by Design: the TriageFlow GitHub App only requests permissions for Issues and repository metadata — contents: none — and never trains AI models on private tickets. Verified in the public App manifest. Operated by Universal Global Services Ltd (London, Companies House No 17423506).