I'm a scientist, first.
Not as background color, but as the qualification itself. Below: who I am, how I work, and the research the practice rests on.
I'm a scientist, which means I come in from the outside with no stake in the existing explanation, architecture, or proposed solution. My job is to determine what is actually happening.
I go all the way down into a problem, then come back up with a cohesive account your whole team can act on. The critical step is classification: identifying what kind of system or problem you're actually dealing with, which properties matter, and what established body of knowledge applies to it. A problem that is classified correctly becomes much easier to diagnose.
The second advantage is independence. I have nothing to sell downstream and nothing to gain from the answer being reassuring. I'm there to make the situation legible. Finding what's broken along the way is often just a byproduct.
What Kedion is.
Kedion is the contracting entity behind this work, the name that goes on the statement of work, the rate card, the invoice, and the tools. The practice is one person, and that is the asset, not something to hide.
So there is no "team," no "our engineers," no fabricated staff. When you engage Kedion, you get me, first person, first hand. Going all the way into a codebase is the sharpest version of the work, not the definition of it: the same descent applies to a boardroom briefing, a roadmap, an acquired stack, or how a team actually operates.
It's structural, not a matter of talent.
Any system an enterprise depends on, an application, a data pipeline, a model stack, a delivery process, a team's working dynamic, was built by many people across many years. Each person holds a fragment. Nobody was ever assigned the job of holding the whole thing, and everyone who might is themselves a fragment-holder with a stake in their own fragment.
So the cohesive account doesn't exist. Not because the organization is careless, but because accretion is how these things get made. The picture has to be assembled by someone from outside who can go all the way down and then come back up. Complexity science is the study of exactly this: systems whose behavior isn't legible from their parts. It's what the training is for.
Down into the mess, then up into a category.
I go all the way down into the system, the code, the documents, the decision history, the interviews, and extract the real causal chain: what actually happens, in what order, driven by what. Then I come back up, placing it in a class of system whose behavior is already understood, so its known properties become available to your team.
That round trip, down into the mess, then up into something executives and engineers can act on from the same page, is what the whole practice turns on.
Developed in the open.
The idea underneath the practice, that structure is the right level at which to understand complex systems, is something I develop in the open and publish with the same rigor I bring to a review. A framework is supposed to defend itself; putting it on Zenodo is how it earns the right to be used on your system.
Writing lives on my personal site, not here, this site stays focused on the practice. Follow the research and the essays at sean-mcclure.com.