Concepts
Mapped Issue, confidence thresholds, ticket lifecycle, billing meter, RCA, the vocabulary you'll see across the product.
A reference glossary for the terms Watari uses consistently across the product, docs, and notifications.
Mapped Issue
A Mapped Issue is a structured bug report, or a code-actionable feature request, that has passed two independent confidence gates: the extraction step produced a high-confidence structured item 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.
A feature request counts as a Mapped Issue only when it is code-actionable: a specific change to code that already exists. An open-ended request, and any question, is never mapped and never billed. It is still filed to your issue tracker.
Full detail on the qualification logic and what happens at that moment: The Mapped Issue 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 parses your repository with tree-sitter, searches it for code related to the bug, and a rerank step scores each candidate 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.
The locations are ranked candidates, the place Watari starts from. Before drafting a fix it reads the code around them, so once a draft PR exists the Where it happens section also shows where the draft PR makes the change, above the ranked list. That is the most specific location for the issue.
Ticket lifecycle
A ticket moves through the following states from arrival to RCA publish:
- Pending: the ticket arrived via webhook and is queued for processing.
- Extracting: the AI extraction step is running, reading the ticket body, conversation thread, and any attachments.
- Mapping: extraction produced a high-confidence bug; the code mapping step is now running against your indexed repository.
- Mapped: at least one high-confidence code location was found; the bug qualifies as a Mapped Issue, the meter fired, and the PR draft was requested.
- PR drafted: a draft pull request is open in your repository and waiting for review.
- PR merged: a human reviewer approved and merged the PR.
- 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 issue page. When Watari finds likely code but is not confident in any of the locations, the issue's Where it happens section says Needs your review: the locations are shown, the issue does not count toward your plan, and it is not filed to an issue tracker set to mapped issues only. You can check the locations yourself, or add context and re-map.
Bug signature
A bug signature identifies the underlying problem a bug describes. Two bugs with the same signature are treated as reports of the same issue, even when customers describe it in different words or report it through different support tools.
When a new ticket describes a bug you already have, it 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.
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 issue 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, and nothing is posted until a team member approves the draft from the issue page. What happens after approval is your choice in the Customer updates settings. By default, Watari posts the approved RCA automatically once the fix is confirmed in production (or when the pull request merges, if you chose that). In manual mode, someone sends it from the issue page when ready.
Once published, the RCA is posted where the report came in: a reply on the Zendesk, Intercom or Freshdesk ticket, or a comment on the Jira, Linear, GitHub or Azure Boards issue Watari picked up, for your team to pass on. See Bug to RCA for when a tracker comment is withheld.
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 Issue: 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 Issue 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.
Quickstart
Sign up, name your workspace, then follow the three setup steps on Home. Connect where customer reports arrive, connect your code, and your first issue appears on its own.
Working in Watari day to day
Home shows what needs you and what Watari is working on. Issues sorts every report by whose move it is. Each issue page says the one next step and what to tell the customer. Codebase says whether Watari can search your code and where issues come from. Insights counts what Watari did each month.