Insights · 6 min read

Linked Data for AI Training: Code, Tickets and Chat Together

Code says what was done. Tickets say what was asked. Chat says why. Linked together, they teach more than the sum.

Bearish AI · October 21, 2026

Most companies hold their work in separate places: code in one tool, tasks in another, conversations in a third, designs in a fourth. Each is useful alone. For AI training, the value jumps when the pieces are connected, because a connected record shows a piece of work from request to result.

One change, four records

Take a single ordinary change. Someone reports that exported invoices show the wrong total. A ticket is opened. Two people discuss the cause in chat. A developer writes a fix and a test. A reviewer asks for a change. The fix ships. That is five kinds of record about one event. Separately, each is a fragment. Together they form a complete lesson: a problem statement, a reasoning trail, a solution, a check and a judgment.

What the research and the market show

The standard benchmark for coding agents, SWE-bench, exists because of a link: each of its 2,294 tasks pairs a real GitHub issue with the pull request that resolved it. Without that connection there is no task, only code.

The commercial market points the same way. A buyer quoted in reporting on the resale of startup data said one company’s team-chat history can be worth more than another’s chat, email and calendars combined, and the report adds that varied, deep conversations are what raise value. Depth is easiest to see when conversations connect to work.

A worked example of the chain

Say a support case reports that a scheduled export silently skips records. The case ID goes into a ticket. In chat, an engineer and a product owner argue about whether the export should fail loudly or retry. The ticket is assigned, a branch is named after it, and a pull request fixes the bug, adds a test and gets two review comments about error handling. A later deploy event marks when the fix reached customers.

From the unlinked pieces you might get a bug fix with no reason, a debate with no outcome and a test with no story. From the linked chain you get a full episode: a symptom as users described it, a diagnosis, a design argument, a solution, a check and a review. That is the difference between a snippet and a lesson, and it is why a linked episode can support several kinds of task, from fixing the bug to explaining the trade-off to writing the test.

Which links matter most

Even small bits of data, like a ticket ID or a timestamp, do the joining. Low-text sources such as deploy logs and event records are worth keeping for exactly this reason: they say little themselves, but they connect the sources that say a lot.

What breaks links

• Tool changes. Moving from one ticket system to another often drops old IDs unless you export a mapping.
• Deleted channels. Chat retention settings can erase the very discussion a ticket refers to.
• Inconsistent names. If the same person appears under three spellings, the record of who decided what falls apart.
• Partial exports. An export that leaves out attachments, comments or edit history breaks the thread.
• Careless privacy scrubbing. Replace each person with the same stand-in everywhere, or the links disappear along with the names.

The privacy catch

Linking raises a fair concern. In the Spirit Airlines data sale, a flight attendants’ union argued that because links between datasets would be preserved, information about individuals or small groups could be reconstructed even after de-identification. That objection shows why linked data needs careful privacy review, not less linking. Consistent stand-ins keep the structure of the work while hiding who the people are, and a separate review of rights and confidentiality is still needed. Not legal advice; ask a lawyer who handles data licensing.

A ten-minute test of your own links

Pick twenty recent commits at random and note how many mention a ticket or pull request number. Open five of those tickets and check whether the discussion about them can still be found in your chat export. Look at five chat threads about bugs and see whether anyone posted a link to the fix. If most of these connect, your data is in good shape. If very few do, the cheapest improvement is usually to keep your exports and ID mappings safe before any tool is retired.

Honest limits

Linking costs effort, and partial linking still helps: a quarter of your tickets tied to code is better than none. Linking also does not rescue weak sources. Chat that is mostly small talk, or tickets with no description, adds little however well connected.

In the free estimate at /estimate, holding several kinds of source is treated as a sign of a richer record, and code together with chat or tickets is flagged as especially useful. Preparing the data so the sources actually connect is the work that lifts a figure from the conservative range. For the single-source view, see /insights/why-version-history-worth-more-than-code-snapshot.