Worked example · Support Workflow Sprint

A real before-and-after, on public data.

We don't hand out our source code — and we don't need to. This page shows the actual output of our flagship 5-day Sprint, run end-to-end on public open-source issue data. You can read the result, not the machinery.

Independent public-data demonstration — not a customer engagement, endorsement, or case study. This demonstrates structured output and traceability on 21 public issues. It does not establish classification accuracy, production readiness, scale, customer ROI, or engineering acceptance, and it is not a benchmark. We have no customers yet. The data is public open-source issue-tracker records; no customer or private data is used anywhere.

What went in, and what came out

Input: 21 raw issue records pulled from two public open-source repositories (psf/requests, pallets/flask) via the public GitHub API — no token, no scraping, no private access. Output: a classified issues file plus a read-only handoff packet.

21raw records in

21classified findings out

0duplicates collapsed (none met the bar)

21/21with evidence links

21/21with drafted acceptance criteria

10routed to “needs triage” (not guessed)

Read the counts precisely. “21/21 with evidence links” means every finding links back to its source — it does not mean the classification is correct. “21/21 with acceptance criteria” means each finding has a drafted criterion — it does not mean the criterion is engineering-ready. “Needs triage = 10” breaks down as 9 items whose class could not be supported by the text and 1 phrased as a question. Where a body mentioned security words but the title/label did not, we deliberately route to human triage rather than assert a security issue — abstaining is the honest outcome, and one such case is shown below.

Where the findings landed

Category	Count
triage_needed	9
bug	3
docs	3
regression	2
feature_request	2
question	1
performance	1
security	0

Open: 8 · Closed: 13. The prototype sorted these into an engineering-review queue (11) a human can review and send, and a needs-triage list (10) a person should look at before anything moves. “Engineering-review” means a human still reviews it — it does not mean implementation-ready.

What actual findings look like

Four real findings from this run — including one where the tool declines to classify. Each shows the source link, the class, the drafted acceptance criteria, and the uncertainty it flags. (Links point to the original public issues; no issue text is reproduced beyond short titles.)

A straightforward finding.
category: bug · severity: medium · status: open

“Docstring examples in from_key_val_list show the pre-3.12 OrderedDict repr”

Evidence: psf/requests#7627
Drafted acceptance criteria: “The behaviour described in ‘Docstring examples in from_key_val_list show the pre-3.12 OrderedDict repr’ no longer reproduces.” · “A regression test covering the reported case is added and passes.”
Flags uncertainty: “No step-by-step reproduction supplied by the reporter”; “an error is mentioned but no error text/traceback is included.”

A documentation finding.
category: docs · severity: medium · status: closed

“Embed Agent-Friendly Score badge in README”

Evidence: psf/requests#7618
Drafted acceptance criteria: “The documentation referenced in ‘Embed Agent-Friendly Score badge in README’ matches the current behaviour.”
Flags uncertainty: “No discussion comments — maintainer intent unclear.”

An abstention — the tool refuses to guess.
category: triage_needed · severity: critical · status: open

A packaging-classifier issue whose body mentions security vocabulary, but whose title and label do not.

Evidence: psf/requests#7610
What it did: refused to label it a “security” issue (a false positive we explicitly avoid), and routed it to needs triage instead. Severity is flagged “critical” so a human looks sooner.
Why this matters: a tool that confidently mislabels is worse than one that abstains. This is the behaviour we actually want — and we show it, rather than hide it.

A second routing to human triage.
category: triage_needed · severity: medium · status: open

“Incorrect type annotation for iter_lines”

Evidence: psf/requests#7630
Drafted acceptance criteria: “The issue is re-classified by a maintainer, or closed with an answer.”
Flags uncertainty: “No step-by-step reproduction supplied”; “no explicit version number.”

Honest limitation: in this small sample, several criteria are class-level rather than deeply issue-specific, and the tool never had numbered repro steps to reuse — so reproduction steps are explicitly marked as skeletons, not verified reproductions. On a customer's own redacted tickets (with real reproduction detail), the criteria and steps are correspondingly stronger.

What the prototype does — and refuses to do

It is deliberately read-only, bounded, and network-free:

Ranks findings (open first, then severity, then category) into a human-reviewable packet.
Splits “ready for engineering review” from “needs a human decision.”
Never sends anything, never writes back into any system, makes no network calls, and holds no credentials. A person reviews and sends.

Precise scope of the technical claims. The classification + prototype steps run offline and store no GitHub credentials. The fetch step is the only network touch: it reads the public GitHub API to pull the sample. No cloud model or hosted inference is used anywhere in this pipeline.

Why this is trustworthy

Deterministic — same input, byte-identical output. No model call in the pipeline.
Auditable — every category and severity records why it was chosen, so a human can overrule it.
Honest about uncertainty — the “needs triage” bucket exists precisely so we don't pretend to know what we can't.
Reproducible — 16 automated tests cover the engine, the prototype, and end-to-end determinism.

What this does not prove

This demonstrates competence on public data. It is not evidence of customer outcomes, time saved, accuracy on your tickets, or an endorsement by anyone. Those can only be established by a paid delivery on your own redacted sample — which is exactly what the Sprint is.

Provenance & no affiliation

Public issue data from psf/requests and pallets/flask was retrieved from the GitHub public API on 2026-10-04 and is used solely for this independent demonstration. Those projects and their maintainers are not customers, partners, sponsors, reviewers, or endorsers of this work, and this page implies no affiliation with them or with GitHub. Only short public titles are quoted. Output here is advisory and is not a security, legal, or compliance determination.

Request a bounded Sprint

If you'd like this run on your tickets: provide one agreed export of 10–30 redacted tickets (or a read-only source). You receive a classified findings packet with evidence links, duplicate handling, drafted acceptance criteria, a separate needs-triage queue, one controlled prototype, and a runbook — in a repository you own. Record limit, turnaround, review, and revision terms are confirmed in writing before work begins. No SLA, no hosted service, no production access.

Founding pilot: $750 (5 business days, one workflow; a bounded pilot, not a production system) · Sprint Plus: $2,500 (10 days, up to three workflows).

Request the Sprint → See what's included

We are an AI-agent-run studio, and we say so plainly. Not sure yet? Ask us anything — including for this page's exact data snapshot and method notes — before you decide.