Concepts

A reference glossary for the terms Watari uses consistently across the product, docs, and notifications.

Mapped Bug

A Mapped Bug is a structured bug report that has passed two independent confidence gates: the extraction step produced a high-confidence structured bug from the ticket, and at least one code location in your repository was matched with high confidence. Only when both gates clear does the billing meter fire and the PR draft begin.

Full detail on the qualification logic and what happens at that moment: The Mapped Bug meter — when it fires and what qualifies.

AI confidence

At two points in the pipeline — extraction and code mapping — Watari's AI assigns a confidence score to its output. The score represents how certain the model is that its result is accurate given the input it saw.

Thresholds exist because acting on a low-confidence result produces worse outcomes than flagging it for human review. A low-confidence extraction might misclassify a billing question as a bug; a low-confidence mapping might point a PR at the wrong file. The specific threshold values are calibrated internally and subject to tuning as the model improves — the docs describe them qualitatively as "high confidence" rather than publishing a number that could mislead you about the margin.

When a result falls below the threshold, Watari marks the ticket or bug for human review and surfaces it in the dashboard with a reason. You can edit the result and re-trigger the next pipeline stage manually.

Code location

A code location is the output of the mapping stage for a single candidate: a file path, a function or method name, and an optional line range. Watari derives code locations by parsing your repository with tree-sitter (producing function-level chunks), embedding those chunks, and using semantic search followed by AI reranking to score relevance against the bug description.

A bug can have multiple code locations — for example, a frontend component and the API handler it calls, each in a separate repository. All locations above the confidence threshold are persisted on the bug record and are used together to scope the PR draft.

Ticket lifecycle

A ticket moves through the following states from arrival to RCA publish:

1. Pending — the ticket arrived via webhook and is queued for processing.
2. Extracting — the AI extraction step is running, reading the ticket body, conversation thread, and any attachments.
3. Mapping — extraction produced a high-confidence bug; the code mapping step is now running against your indexed repository.
4. Mapped — at least one high-confidence code location was found; the bug qualifies as a Mapped Bug, the meter fired, and the PR draft was requested.
5. PR drafted — a draft pull request is open in your repository and waiting for review.
6. PR merged — a human reviewer approved and merged the PR.
7. RCA published — a successful production deploy was confirmed, the RCA draft was approved, and Watari posted the customer-facing summary back to the original support ticket.

Tickets that never produce a high-confidence bug (billing questions, feature requests, ambiguous reports) stop at Pending with a classification reason. Tickets that extract a bug but fail to map code stop at Mapping and are flagged for manual review on the bug detail page.

Bug signature

A bug signature is a deterministic key Watari computes from a bug's extracted fields — title, description, affected feature, reproduction steps, and customer verbatim. Two bugs that share the same signature are recognized as reports of the same underlying issue, regardless of which ticket they came from or which support tool sent the webhook.

When a new ticket produces a bug whose signature matches an existing bug in your workspace, the new ticket is absorbed into the existing bug's cluster rather than creating a duplicate entry. The cluster's linked ticket count grows, and any published RCA for that bug can be updated to reflect the additional customer impact.

The signature is computed from the AI-extracted summary fields, not from raw ticket prose. This keeps the dedup logic consistent even when customers describe the same bug in very different language.

Cluster

A cluster is the group of tickets that share the same bug signature. The first ticket to produce that signature creates the canonical bug record; every subsequent ticket with the same signature joins the cluster.

Clusters drive two downstream behaviors:

• Recurring-issue counts. The "X customers affected" stat on the bug detail page counts tickets in the cluster, giving engineering a real signal of customer impact rather than a single data point.
• RCA publish triggers. When a cluster reaches a configurable size (the "cluster grew" threshold), Watari can auto-trigger an RCA draft, letting you communicate proactively about a known issue before the fix ships.

RCA (Root-Cause Analysis)

An RCA is the customer-facing summary Watari drafts after a bug fix deploys to production. It covers what happened, which customers or features were affected, what caused the issue, what was changed to fix it, and what safeguards are being added to prevent recurrence.

RCAs are drafted automatically but never auto-published. They sit in review until a team member approves them from the bug detail page. Once published, the RCA appears as a reply in the original support ticket thread — in Zendesk or Intercom, depending on where the ticket originated.

The full RCA authoring and publish flow is covered in Bug to RCA — drafting and publishing customer-facing root-cause analyses.

Billing meter

The billing meter fires once per Mapped Bug — the moment the bug and its code locations are persisted and both confidence gates have cleared. Everything that happens after that point (PR drafting, PR iteration, RCA generation, Slack and issue-tracker sync) is bundled into your plan and never metered separately.

The meter is idempotent: a retry or re-qualification of the same bug does not fire it a second time.

Full detail: The Mapped Bug meter — idempotency, bundled actions, and the billing event.

Next: Your first week — day 1 through week 1 accuracy expectations — what to expect in the days after setup.