From ticket to pull request: the anatomy of a useful trajectory

A merged pull request is the end of a story, not the story itself. For teams training coding agents or building evaluations, the most valuable unit of company data is the whole trajectory: the path from the moment a problem is noticed to the moment a verified change ships. This post breaks that path into its parts and looks at what makes one trajectory useful and another thin.

Public code gives models plenty of diffs. What it rarely shows is why a change was made, what the engineer knew at the start, what they tried first and how they knew they were done. An agent that only sees the final diff learns what good code looks like. It does not learn how to get there from an ambiguous request in a messy codebase.

Real engineering work is mostly the getting there. Reading the ticket, asking a clarifying question, finding the relevant files, discovering the first approach does not work, responding to review. A trajectory captures that sequence, and it is only visible when the ticket, the discussion and the code history can be lined up against each other.

Imagine a 50-person B2B software company that runs on Slack, Jira, GitHub and a help desk. A single bug fix there might leave the following trail:

• The trigger. A customer writes to support that exported invoices show the wrong currency. The help desk records the report, the customer's plan and the support agent's first reply.
• The escalation. The support agent posts in an engineering channel. Two engineers discuss whether it is a display bug or a data bug and agree it needs a ticket.
• The ticket. A Jira issue is created with a description, a priority, a reproduction note and a link back to the support case. A product manager adds acceptance criteria.
• The work. An engineer picks up the ticket, opens a branch and pushes several commits. One commit is reverted after a test fails.
• The review. A pull request references the ticket. A reviewer asks for a test covering a second currency and questions a variable name. The engineer responds and pushes a fix.
• The checks. Continuous integration runs, fails once on an unrelated flaky test, then passes.
• The close. The pull request merges, the ticket moves to done, and support replies to the customer that the fix is live.

Each stage on its own is ordinary. Together, they form a task with a natural-language specification, a starting state, intermediate decisions, a verifiable outcome and a confirmation from the person who raised the problem.

Not every ticket produces a trajectory worth training on. The useful ones tend to share a few properties.

The task statement is grounded in a real need. A ticket that links to a customer report or a planning document carries context an agent has to interpret, which is closer to how work actually arrives. A ticket that just says "fix bug" with no link is much weaker.

The intermediate state is visible. Commits, reverted attempts, review comments and failed checks show the path, including wrong turns. Squashed history and missing review threads hide it. Dead ends are not noise here. They are some of the most instructive parts of the record.

The outcome can be checked. A merged change with passing tests, a closed ticket and a customer confirmation gives a clear signal of success. That makes the trajectory useful not only for training but for building evaluations and reward signals.

The links hold across tools. If the support case, the chat thread, the ticket and the pull request cannot be joined, you have four fragments instead of one task.

Every trajectory is full of people: the customer, the support agent, the engineers, the reviewer and the product manager. They all need to be anonymized without breaking the chain that connects them.

That is why every person, company, address, email, phone number and account is replaced with a consistent token across every tool. If the reviewer is PERSON_022 in a GitHub comment, they are PERSON_022 in the Slack thread and the Jira history too. The relationships survive, so you can still see that the same engineer who wrote the fix also answered the escalation. The identity does not.

Some content is removed rather than tokenized. Credentials, API keys, card numbers and government IDs are stripped outright, which matters in code history where secrets sometimes end up in commits. HR, payroll, medical and legally privileged folders are excluded by default. Each seller also sets their own scope and exclusions, annexed to the contract before any data moves.

If trajectories are what you need, the sourcing question changes. Rather than asking how many repositories a company has, it helps to ask whether the same company also ran a ticketing system, a chat tool and a help desk over the same period, and for how many years. Headcount matters too, since more engineers means more review and more handoffs.

Those are the variables a sourcing brief can specify: sector, headcount, tool stack, years of history, regions, and whether a company is operating or winding down. Martal Group builds a target list from company and technographic data, and its reps call the people who can sign. Data is then evaluated, anonymized and delivered on a rolling basis. The licence covers training and evaluation only, and buyers may never re-identify, contact or profile anyone in the data.

If your team is building coding agents or evaluations and needs connected engineering history, send us a sourcing brief.