Introducing Brekfuz: Map the Knowledge Your Team Actually Runs On

We have been working on Brekfuz for most of 2024, and this is the first time we are talking about it publicly. The short version: we are building an organizational knowledge graph that surfaces where your team's knowledge actually lives, who depends on whom, and which critical processes are vulnerable because only one person understands them end to end.

The longer version starts with why we decided to build this in the first place.

The Pattern We Kept Seeing

Before Brekfuz, I spent several years building enterprise data products and working closely with engineering and operations teams at growing organizations. The specific companies do not matter for this story. What matters is the pattern that appeared in almost every team I worked with closely enough to see beneath the surface.

It looked like this: someone important goes on leave. Or a senior engineer gives notice. Or a team reorganizes and two groups that used to sit next to each other now report to different parts of the org. And suddenly, something that was running fine is not running anymore. Not because capacity is insufficient. Not because the systems broke. Because the knowledge needed to keep things going was concentrated in one person's head, and that person is no longer accessible.

The post-mortems from these situations almost always reached the same conclusion: we need better documentation. We need knowledge transfer processes. We need runbooks. And those conclusions are not wrong. But they also do not solve the underlying problem, because they address the symptom without addressing the root cause: the team did not know where its knowledge dependencies were concentrated until the concentration became a crisis.

You cannot transfer knowledge you have not identified. You cannot cross-train for risks you have not measured. The documentation mandate fails not because documentation is a bad idea but because it gets applied without a map of where it is most urgently needed.

Why Existing Tools Do Not Solve This

The enterprise knowledge management category is not small. Teams use Confluence, Notion, Guru, SharePoint, and combinations of all of them. They invest in internal wikis, documentation-as-code initiatives, structured onboarding programs. None of that is useless. We use some of it ourselves.

The gap is visibility into the dependency structure itself. Wikis store what people chose to write down. They do not show you who knows what, or who the team actually turns to when something breaks, or which processes have exactly one qualified person to execute them. You cannot read a Confluence space and come away with a clear picture of where the knowledge risk is concentrated in an organization. The information is not in the documents. It is in the patterns of how people work.

That gap is what Brekfuz is designed to address. We read the behavioral signals from the tools your team already uses, construct a knowledge ownership graph from those signals, and surface the dependency concentrations that represent genuine operational risk. The graph does not require anyone to fill out a survey or write a new document. It is inferred from the work already being done.

What Brekfuz Actually Does

Brekfuz connects to the communication, documentation, and project management tools your team uses: Slack, Confluence, Jira, GitHub, Notion, Linear. From those connections, we derive a knowledge graph where nodes represent people and knowledge domains, and edges represent ownership and dependency relationships.

The graph answers questions that are difficult or impossible to answer from an org chart or a wiki inventory. Who are the secondary experts for your payment integration if the primary owner is unavailable? Which processes have only one qualified executor? Which systems have ownership that has organically migrated away from the formal owner to someone who is not officially responsible for them? What would the risk exposure look like if a specific person went on leave next month?

We also run a continuous dependency risk scoring layer on top of the graph. Each knowledge node gets scored based on concentration (how many people show real ownership signals), criticality (how many downstream processes depend on it), and coverage depth (how well the knowledge has been externalized in forms others can actually use). That scoring produces a ranked list of single-person dependencies sorted by severity, which gives teams a clear starting point for cross-training and documentation investment.

The third piece is the onboarding path generator. For a new hire in a specific role, the knowledge graph can show which knowledge domains they need to develop, which people and systems they will depend on, and in what order exposure to different areas makes sense given their role and their existing background. That path is generated from the team's actual knowledge structure, not from a generic onboarding template.

Who We Are Building This For

The teams that feel this problem most acutely tend to be in a specific growth stage: past the point where everyone knows everything and everyone has seen everything, but not yet large enough to have built robust institutional knowledge transfer infrastructure. Somewhere between 20 and 300 people, where the team is moving fast enough that knowledge is constantly being created and shifting, but formal processes for managing that knowledge have not kept pace.

Engineering and operations teams tend to feel it more sharply than product or design teams, because the knowledge they depend on is more likely to be embedded in technical systems that are difficult to document and hard to transfer without direct experience. The institutional knowledge about why an architecture was designed a certain way, or what sequence of operational steps to follow in a specific failure mode, or which edge cases a particular integration does not handle correctly, tends to be hard-coded into a small number of people who have built up that context over time.

We are starting with Bengaluru-based and India-headquartered engineering organizations, because that is the community we are closest to and can support most directly. But the problem is structural in growing tech teams everywhere.

What We Are Looking For Now

We are in early access. We are working closely with a small number of organizations to refine the graph construction, the dependency scoring, and the interface through which teams interact with their knowledge map. If you are leading an engineering or operations team and the problem described here sounds familiar, we would like to talk with you.

We are not claiming to have solved knowledge management. The problem is real and hard, and we are still learning a great deal about what the most useful version of this tool looks like. What we are confident about is that the measurement layer, the ability to see where knowledge is concentrated and where coverage is thin, is the foundational piece that has been missing from most teams' approach to this problem. That is what we are building.

If you want to follow along as we develop it, this blog is where we will be writing about the things we are learning: about knowledge graphs, dependency risk, onboarding, operational continuity, and the structural dynamics of how knowledge moves through growing engineering teams. We hope some of it is useful regardless of whether you end up using Brekfuz.