Discovery & Rangers

Between a signal and a ticket sits Discovery: a set of daily agents — Rangers — that each read one product source, normalize what changed against recent history, and file a draft ticket only when the evidence warrants it. You watch them from the Rangers tab (Product section of the dashboard).

Each Ranger owns its source end to end: it measures the source and it decides what becomes work — authoring a new ticket, strengthening a live one, or keeping a weak theme in memory. What keeps that trustworthy is the blast radius, not a separate approver: a Ranger can only ever file a draft ticket. It can't change your product, spend money, publish, dispatch a fix, or close a ticket. The worst case for a bad signal is a draft you dismiss in one click.

The pipeline

Every enabled Ranger runs on its own schedule, independently:

daily trigger (each Ranger on its own hour)
  → the Ranger reads its source for the most recently closed local day (read-only)
  → compares against 7-day history + the shared scratchpad
  → submits one run summary + zero or more signals (the run record)
  → for each finding worth your attention:
       author a new draft ticket · strengthen a live ticket · carry it in the scratchpad

Three object types flow through it:

The run summary and signals are the audit trail — proof the source was looked at and what was found. The ticket is the action — and only findings that clear the bar become one.

Rangers

A Ranger is a daily agent that owns exactly one product-signal source. Each runs on its own hour, reads only its source for the most recently closed local day, compares against recent history, and submits one run summary plus any signals worth recording. It is read-only on your product — it reads data and files draft tickets, but never edits code, spends, publishes, or closes anything itself.

Every product starts with this set (the three required Rangers are always on; the rest are on by default and can be turned off per source):

Dogfooding is the one exception to the one-Ranger-per-source shape: each persona you create becomes its own Dogfooding Ranger with its own testing directive, and they're managed from the Dogfooding page rather than the Rangers tab. See Dogfooding.

Set a Ranger's schedule

Open the Rangers tab and pick a Ranger to see its settings, reports, and run history.

1. Toggle enabled to turn the source on or off. Required Rangers stay on.
2. Set the run hour (0–23, in your product's timezone) and the days it runs — each Ranger runs independently on its own schedule.
3. Save settings.

The detail page shows the tickets and signals the Ranger authored; Run history shows every recent attempt, including quiet (no_data) and failed runs.

The shared scratchpad

Rangers share one bounded, human-readable scratchpad — the pipeline's working memory. It holds cursors (where each source was last read), carries (weak themes worth watching but not yet ticket-worthy, each with a concrete promotion condition), addressed themes, a light taxonomy, and cross-links between sources. It's why a feedback complaint one day and a matching error spike the next can be recognized as the same underlying problem instead of two isolated blips: before authoring, a Ranger searches the scratchpad and the existing tickets, so corroboration across sources strengthens one ticket rather than spawning duplicates.

Open it from Scratchpad on the Rangers tab (/dashboard/rangers/scratchpad). It's legible on purpose — you can read exactly what the pipeline is tracking and why.

What a Ranger does with a finding

After reading its source, a Ranger makes exactly one call per underlying problem:

• Carry it — evidence is weak, isolated, or not yet actionable. It goes to the scratchpad with a promotion condition, not your board.
• Author a ticket — a concrete product gap with enough evidence to warrant your attention. Files an idempotent draft ticket.
• Strengthen a live ticket — this occurrence adds a fresh independent voice, a wider segment, stronger impact, or new verification to an existing ticket; no duplicate is made. Rephrasing the same complaint is not an update.

A closed ticket stays closed — a verified recurrence gets a fresh ticket that cites the earlier one as history, rather than reopening it.

Most tickets a Ranger files are framed for your judgment: the default is a report ticket marked requires human input with no repository attached, because the right fix and its priority usually need product judgment. A Ranger only files a PR-bound, immediately-actionable ticket for a narrow, well-scoped defect in your connected repository with an unambiguous way to verify the fix.

Draft-only, by design

Discovery cannot act on your product. A Ranger reads its source and may file draft tickets only — it can't change the product, spend money, publish, dispatch a fix, or close a ticket. Every source's text (feedback, replay content, commit messages, URLs, model answers) is treated as untrusted evidence, never as instructions. So the worst case for a bad signal is a draft ticket you dismiss in one click — and a draft ticket only becomes real work when you comment on it.

Notes & limits

• Each Ranger reads one closed-day window. A Ranger only reads the most recently closed local day for its source, comparing against its 7-day history — so it never claims a trend from a single day's records.
• A source with no data still runs its Ranger and reports no_data — that's how the record tells "looked, found nothing" from "never looked."
• Optional Rangers need their source connected to be useful — Product changelog needs GitHub; Search discovery draws on Search Console and AI-citation tracking; the SDK-backed Rangers need the 1mn SDK installed. A source that isn't wired up simply reports nothing rather than failing.
• Discovery only ever hands you drafts. Nothing it produces runs on its own — it lands on the Tickets board as a draft for you to route.