# From a bug report to a better decision

Case walkthrough — spoken transcript.

Assay metrics. From delivery evidence to better decisions.

For engineering leaders, a completed repair raises three different questions: where did work wait, how was the defect introduced, and did the repair help customers? Assay coordinates software delivery by agents under human governance. This video follows an illustrative duplicate-order checkout bug through the evidence Assay collects and the decisions it supports. You'll see how teams report and attribute bugs, where product data is needed, and how proposed machine-learning feedback could improve the process. No measured improvement is claimed.

Assay is an agent-operated delivery pipeline with human governance. Work starts in a brief: a bounded request with requirements and acceptance checks. Separate agents implement, review and verify it; people retain consequential decisions. The repair brief requires retries to create only one order. The pipeline ends at verification on main.

The repair leaves a history of status changes and linked pull requests. Statusgen is Assay’s command-line board and delivery-report generator. It reads those records to show completion time and waiting. If implementation finishes but review waits, that evidence points us toward the handoff before we add more workers.

Internal daily reports combine workflow and repository-hosting records, including review and verification outcomes. Each report has its own population and time window. A successful collection process can still return an unavailable measurement. For this repair, a missing review record cannot become evidence that review was frictionless.

To investigate the code, we use qualgen: Assay’s local command-line repository-quality analyzer. It mines Git history. With a supplied issue and pull-request snapshot, it can connect the checkout fix to a defect report and trace changed lines back to candidate introducing changes. Line ancestry gives us leads, not causal proof.

Now inspect the requirement. If retry safety was missing there, investigate the specification. If the requirement included it but the brief omitted it, investigate the brief. If both required it and the code violated it, investigate implementation. In our illustrative case, the original requirement included retry safety and its implementation brief dropped it. That directs investigation toward the brief. Discovery location doesn't determine origin.

An internal review catch and a customer report retain different discovery origins. The component owner triages the issue and links the fixing change. Our internal code workflow records the resolution claim in a reviewed pull request. Application teams own their support-to-tracker integration. Closing that record still doesn't establish a customer outcome.

After release, the application team needs the exposed version and checkout attempts, plus duplicate orders and support burden. Fewer complaints could mean fewer users. Compare outcomes for a defined exposed population. Statusgen describes delivery; qualgen helps investigate quality history. Neither automatically installs analytics in the product.

For future checkout changes, a risk estimate could help select extra review. Qualgen contains a learned change-risk library. It trains logistic regression on historical change features, using only defect labels known when the prediction would have been made. It compares later results with a heuristic and falls back when data is insufficient. That implementation doesn't establish that a trained predictor is deployed in every Assay project.

The broader feedback cycle is proposed: diagnose a problem, test extra review for selected checkout changes, have an independent assessor examine the result, and let an authorized owner decide whether to adopt it. Later observations support keeping or reversing the change. A model can prioritize attention; it doesn't approve changes or prove its own benefit.

Start with one repair in your own project. Keep its report, fixing change and acceptance evidence together. Define the users exposed to the release and the outcome you'll check. That gives your next decision an inspectable basis today. The companion article explains collection boundaries and the proposed learning cycle in depth.

For more Assay explainers, like and subscribe. You'll find the complete guide at Assay dot finance.