Skip to main content

Research a technical ticket

Investigate only far enough to choose a credible direction or identify the decision and dependency that prevents one. Stop when you can plan, not when every related question is answered.

Approved AI tools and MCP-backed agents may inspect code, designs, and related tickets to surface scope, reuse, dangers, and decision candidates: data adds or changes, and upstream or downstream contract impact. They find most of those impacts. The research owner verifies the conclusion and does not treat an agent list as an accepted decision. See Responsible AI use and the LogicBee AI coding guide.

Prerequisites​

  • A detailed ticket with visible current behavior, expected behavior, and known dependencies.
  • Access to the relevant code, runtime evidence, designs, or documentation.

Define the question​

Start with the uncertainty that blocks planning. Examples include:

  • Which component owns the behavior?
  • Is the failure caused by data, configuration, an interface, or application logic?
  • Can an existing capability be reused?
  • Does the change require design, infrastructure, Builder work, migration, security, or compatibility work?
  • What can go wrong for users, data, or operations if this ships?
  • What would this add, change, or leave unchanged in data and in upstream or downstream contracts?

Inspect the relevant code, runtime evidence, designs, documentation, and related tickets. Time-box open-ended exploration to the next planning decision. Stop when you can recommend an approach, or when the remaining question has a named owner. Reassess instead of continuing once more research is unlikely to change the plan.

Record the conclusion​

Write the result, not a chronological investigation diary:

Research:
  Found:
  Dangers:
  Decision candidates:
  Recommend:

Add an open question only when it still blocks planning. Carry decision candidates into planning; they become accepted decisions only when the planning owner records what was chosen and what was rejected. Update the detailing section with dependencies discovered during research. Create and link separate tickets for independently owned work; use an RFC or design review when a consequential decision needs structured agreement.

Expected result​

The ticket has enough technical understanding to select an approach. Decision candidates for data, additions, changes, and upstream or downstream impact are visible. Any remaining blocking decision has a named owner, deliverable, and unblock condition.

If research cannot choose a direction​

Do not hide the gap inside a speculative plan. Either:

  • return to detailing with the new dependency or unclear outcome;
  • assign the blocking decision to a named owner, with an unblock condition; or
  • open an RFC or design review for a consequential choice.

Next: Plan the ticket.