The decision to use gRPC over REST for the internal service communication layer is documented somewhere in a Jira epic comment from early last year. The reason the legacy payments module is not being refactored is buried in a 47-comment thread on a ticket that was closed as "won't fix." The engineer who made the call on the database connection pooling configuration explained the reasoning in a sub-task comment - a explanation that has since been read by nobody new, because nobody new knows it exists.
These are not edge cases. They are the normal state of engineering knowledge in organizations that use Jira or Linear as their primary project management system. The ticket system was designed to track work - but it has become, incidentally, one of the richest sources of institutional context that most engineering teams have. And almost none of that context is accessible to engineers who were not present when the discussions happened.
Why Tickets Contain So Much Knowledge
The reason ticket systems accumulate so much institutional knowledge is that they are where engineering decisions happen in real time. A Jira ticket is not just a unit of work - it is a record of the conversation that happened around that work. The "why" of engineering decisions tends to surface in ticket discussions in ways it often does not in formal documentation.
This happens for a few reasons. Tickets have a natural context: the specific problem being worked on. When an engineer asks "should we use approach A or approach B?" in a ticket comment, the context is immediately clear - this is a decision about this specific piece of work, not an abstract architectural question. That context makes the discussion more specific and more anchored in concrete tradeoffs than documentation written after the fact.
Tickets also have a social dynamic that produces frank discussion. The people commenting on a ticket are typically the people actively working on the problem, and they are writing for each other - for teammates they know, who share their context. This produces a different kind of writing than documentation intended for future readers: more direct, more specific about what did not work, more revealing about the reasoning behind choices.
Finally, tickets capture decisions that never get promoted to documentation. The architectural decisions that make it into an ADR (Architectural Decision Record) are the ones someone had the bandwidth to document formally. The decisions that happen in ticket comments are the vast majority - the ones that seemed too small to document, or where the engineer moved on to the next problem before getting around to writing it up.
The Retrieval Problem
The challenge is that Jira search is even more limited for knowledge retrieval purposes than Confluence search. Jira search was designed to find issues by status, assignee, project, label, and full-text content. It was not designed to answer questions like "why was this architectural decision made?" or "what other systems are affected by this component?"
The full-text search in Jira will find tickets that contain specific words, but it cannot synthesize an answer from the relevant content distributed across multiple ticket comments. It returns issue lists, not answers. And ticket comments, being conversational in nature, use the kind of natural language that is difficult to search with keywords - the relevant context for a question about gRPC adoption might appear in a comment that uses the phrase "latency overhead" rather than "gRPC," depending on who wrote it and what they were focused on.
The result is that the knowledge in ticket comments is functionally inaccessible to engineers who were not present in the original discussion. It exists in the system, indexed and searchable in principle, but practically unreachable because nobody knows which ticket to look in, and the full-text search returns too many results to triage manually.
What Gets Lost
The practical consequences of inaccessible ticket context show up in a few specific patterns.
Architecture decisions get relitigated. A decision that was made, debated, and explicitly closed in a ticket two years ago comes up again in a team discussion because nobody remembers it was already settled. Engineers spend time re-examining tradeoffs that were already carefully examined, often arriving at the same conclusion with no connection to the original reasoning. Sometimes they arrive at a different conclusion - which might be correct, since context changes, but might also be a regression from a decision that was made for reasons that were never documented anywhere the new team can find.
Technical debt accumulates without explanation. The legacy payments module that is not being refactored is in that state for reasons that made sense when the decision was made. Those reasons are in a Jira ticket comment. Engineers who join the team and encounter the legacy module have no way to learn those reasons without asking someone who was present in the original discussion - and in many cases, that person has since left the company.
Incidents get worse. Effective incident response requires understanding not just what a system does but why it was designed the way it was - what constraints it was built under, what alternatives were rejected, what the known failure modes are. This context is disproportionately likely to be in ticket comments rather than in operational documentation. Engineers managing an incident without access to that context make decisions with less information than was available at the time the relevant choices were made.
Bringing Ticket Context Into the Knowledge Layer
The practical solution is to treat Jira (or Linear, or GitHub Issues) as a first-class knowledge source rather than a separate system that happens to store some documentation-adjacent content.
This means indexing ticket content - including comment threads, not just issue bodies - alongside Confluence pages and other documentation sources in a unified knowledge retrieval layer. It means giving the retrieval system enough understanding of ticket structure to treat a comment chain as a coherent discussion, not a list of independent documents. And it means providing engineers with a query interface that can search across all knowledge sources simultaneously, so that asking "why did we choose gRPC for internal service communication?" returns the relevant ticket discussion alongside any related Confluence documentation.
Teams that have done this describe a qualitative shift in how new engineers understand the codebase they are working in. The difference between having the answer to "why does this exist the way it does?" available on demand, versus having to either ask a senior colleague or accept not knowing, is the difference between an engineer who can work confidently in an unfamiliar part of the system and one who is constantly operating with uncertainty about whether their mental model is correct.
The answers were there all along. They were just buried in tickets that nobody knew to look in.