Why Does One Bug Filed as Two Tickets Get Fixed Twice?

Challenge: Can we prove one bug will not receive two repair authorizations?

If one bug appears in two tickets, can we prove before work starts that our people and AI agents will not repair the same outcome twice? Without that proof, the second authorization can repeat staff hours, AI calls, token and compute charges, review, and cleanup. It also weakens the delivery record our next customer or operating decision relies on.

We can put an inspectable coverage decision between the request and the authorization. Search the active tickets, read each plausible match, and record whether the requested outcome is fully covered, related, or distinct. This gives us a repeatable reason to remove a duplicate's dispatch authority and extend the canonical ticket, link a dependency, or authorize a new ticket.

Have a workflow that is costing time, money, or customer confidence? Just In Time AI can help you find the smallest valuable improvement, implement it as a secure, compliant AI system, and prove the business result before expanding. Explore AI Systems Setup and Coaching.

What: What should happen before we authorize another ticket?

Treat a ticket as a request for an outcome, not proof that the outcome is new. Different titles can still commission the same result. Our documented Ticket sweep before create starts with every active state that could already contain the request.

The session agent searches New, Ready, Active, and Blocked tickets across every target queue. It uses several terms from the symptom, component, and intended outcome without regard to case. The agent then reads every plausible match before making one of three decisions:

Similar titles never establish coverage by themselves. The intended outcome, acceptance criteria, evidence, dependencies, and current state determine the decision.

Use the coverage decision before the next authorization:

1. Require the sweep record: Confirm the target, request, searched states and terms, candidate readbacks, disposition, and rationale.
2. Remove duplicate authority: When a later duplicate already exists, preserve it, record its link to the canonical ticket, and verify that it can no longer dispatch independently.
3. Keep one accountable outcome: Add the new evidence to the canonical ticket and verify its resulting state before work begins.

What does an inspectable coverage record look like?

The following illustrative record shows the proof another operator should receive:

That record lets the next operator inspect what was searched, what was read, why the decision was made, how the duplicate's audit trail was preserved, and which ticket now holds dispatch authority. The paired technical walkthrough binds this record to before-and-after fixtures and verifies both affected tickets.

When does the coverage decision expire?

The decision expires when the requested outcome or a plausible ticket changes materially. A new match, reopened or superseded ticket, changed dependency, changed acceptance criteria, or new evidence also requires another sweep.

The session agent then searches the four active states again, rereads every plausible match, and replaces the stale decision before acting. The dispatch-time search is a final backstop for changes since intake; it is never the first check.

The public Ticket sweep before create contract shows the four-state search, exact evidence carrier, and extend-or-link actions. The Verify Before Claiming Missing or Broken rule explains why a search result becomes evidence only after someone reads the candidate record.

Artifacts

• Ticket sweep before create -- the current four-state search, full-read, carrier, and disposition contract.
• Verify Before Claiming Missing or Broken -- the current evidence-first search and inspection rule.

Why: Why is the coverage decision worth its cost?

A duplicate authorization can repeat implementation, review, testing, and cleanup. It can also create competing changes and leave two closed tickets claiming that two outcomes were delivered when only one repair survived. That weak record affects customer commitments, operating decisions, and later incident work.

Use your own incident count, time records, loaded labor rates, and AI bills to estimate the recurring exposure:

Estimated recurring duplicate-work exposure = repeat incidents per period x [(staff hours per incident x loaded staff hourly rate) + (input tokens per incident / billing unit x input-token rate) + (output tokens per incident / billing unit x output-token rate) + (compute or wall-clock units per incident x billed unit rate) + (review and cleanup hours per incident x loaded reviewer hourly rate)].

Do not count a token, compute, or service component twice when a bundled AI charge already includes it. This calculation produces a dollar estimate from your records. It does not claim a universal saving or duplicate rate.

The decision also protects trust. One surviving ticket connects the request, evidence, acceptance criteria, change, and readback. A teammate can see what the business authorized and what result remains accountable.

For the implementation walkthrough, read How Do I Catch Duplicate Tickets Before Dispatch?.

Bottom Line: What business value should one accountable ticket protect?

Require one accountable ticket for one intended outcome. The value compounds each time a duplicate authorization would otherwise repeat work the business already funded.

The policy reduces team frustration from reopening and reconciling the same repair. It lowers the risk that competing changes or a misleading delivery record reach a customer. Compliance credibility also decays when the authorization rule repeatedly permits two records to commission one outcome; people stop treating an unreliable rule as a rule.

Each recurrence consumes staff time and can trigger another round of AI calls, token or compute charges, review, and cleanup to re-derive or repeat an answer the business already paid to settle. A coverage decision backed by both ticket readbacks preserves that investment without claiming a universal duplicate rate or savings figure.

For more practical AI operating controls, subscribe to the DanStolts newsletter.

Frequently Asked Questions

How do I check whether a bug ticket already exists before creating one?

Search New, Ready, Active, and Blocked tickets across every target queue using several terms from the symptom, component, and intended outcome. Read every plausible ticket in full and preserve SWEEP_EVIDENCE="lanes=... kw=... found=#id(disposition)..." with the exact project, queue, request, rationale, candidate readbacks, and final decision. If that evidence is incomplete, leave the new ticket uncreated.

When should I extend an existing ticket instead of creating a new one?

Extend the existing ticket when its intended outcome already includes the complete requested result. If a later duplicate already exists, preserve its history, mark and link it to the canonical ticket, and verify that it cannot dispatch independently. Then add the new symptom, evidence, or acceptance detail to the canonical ticket and read it back. Create another ticket only when a distinct outcome remains after the full read.

What should I do when two tickets are related but not duplicates?

Keep both tickets when each requires a distinct outcome. Add the tracker's explicit dependency and record the shared evidence, required order, or acceptance constraint. Do not merge them merely because their titles use similar words.

When should I rerun a duplicate-ticket search?

Rerun it when the requested outcome, plausible ticket body, state, dependency, acceptance criteria, evidence, or available records change materially. Also run a focused recheck immediately before dispatch so a new or reopened ticket cannot bypass the intake decision.

How do I estimate the business cost of duplicate ticket work?

Use your own records: repeated staff hours multiplied by loaded labor cost, plus AI usage, compute, review, delay, and cleanup. Add any customer, compliance, or opportunity impact that you can support with evidence. Treat the result as a decision estimate and show the inputs; do not invent a universal savings percentage.

Update History

• 2026-09-14 - Reader path and implementation help: Added the property-specific Just In Time AI service callout within the first third of the article and verified the paired reader path. The lifecycle-authorized article is bound to its locked canonical route; deployment and anonymous readback remain pending.