Before defenders can move together, they need operational language that can describe adversary behavior, preserve meaning across handoffs, and turn scattered observations into systems people can use.
I keep finding myself in the same place: inside systems that are breaking, trying to make the failure legible.
Sometimes the system is a network. Sometimes it is a production environment. Sometimes it is an incident. Sometimes it is compliance. Sometimes it is fraud moving across accounts, merchants, identities, infrastructure, and institutions faster than any one team can describe it.
The domain changes. The pattern does not.
The behavior is real. The harm is real. The people closest to it usually know something is happening before the system knows how to say it. They can feel the shape of the problem. They can see the repetition. They can point to the fragments. They know the story is bigger than the case, the alert, the control failure, or the transaction in front of them.
But the language is behind the event.
When language lags
When language lags, defenders lose time. They argue over categories. They translate between teams. They describe the same pattern five different ways. They miss the connection between one fraud case, one security incident, one merchant abuse pattern, one infrastructure cluster, and one adversary operating model.
That gap is where adversaries live.
The bottleneck is not always detection. Often, it is description.
Most teams have alerts. They have dashboards. They have tickets, case notes, logs, indicators, reports, policies, rules, reviews, exceptions, and after-action summaries.
What they often lack is a shared operating language: a consistent way to describe adversary behavior that can move across teams, systems, institutions, and time without losing meaning.
The problem is rarely the absence of data. It is the absence of language durable enough to move across teams without being reinterpreted, flattened, or lost.
When a team cannot name what it is seeing, the knowledge stays local. It lives in an analyst's notes. It sits in a case queue. It gets explained in one meeting and re-explained in the next. It does not become a detection. It does not inform a policy decision. It does not become automation. It does not become institutional memory. It does not help another team recognize the same thing earlier next time.
The adversary, meanwhile, is not waiting for the vocabulary to catch up. They reuse infrastructure. They change tactics. They test controls. They move between systems, organizations, and jurisdictions. They exploit the seams between teams that see different parts of the same operation and call it by different names.
The lesson that carried across every domain
Years before I was working on fraud frameworks, I was working on a different version of the same problem.
In infrastructure and compliance, the challenge was not that people lacked requirements. They had standards, controls, policies, hardening guides, audit language, and remediation expectations.
The problem was translation.
A control written in one place had to become something a team could actually apply somewhere else. A requirement had to become a configuration. A best practice had to become a check. A check had to become remediation. Remediation had to become repeatable enough that it could move from one system to many.
That taught me something I have carried into every domain since: a system does not become safer because someone wrote down what should happen. It becomes safer when the language of what should happen can survive contact with the environment where work actually happens.
The same lesson kept showing up.
In incident response, the issue was not just whether a team had enough data. It was whether the data could become a coherent account of what happened, what mattered, what changed, and what needed to happen next.
In cyber intelligence, the issue was not just whether a team had indicators. It was whether those indicators could be connected to behavior, infrastructure, intent, and decision.
In fraud, the problem became even more obvious because the word itself carries too much. “Fraud” can mean a transaction, an account, a merchant, a card, an identity, a mule network, a scam, a policy violation, a breach, an abuse pattern, or a coordinated adversary campaign.
Those are not the same thing.
When they are treated as the same thing, teams lose precision. When teams lose precision, they lose leverage.
What good language makes possible
A case manager may see one part of the pattern. An investigator may see another. An engineer may see a signal that could support detection. A policy team may see abuse that requires a control change. A partner institution may be seeing the same behavior under a different name.
Without shared language, each team is working from its own map. And sometimes the maps do not connect until the damage is already large enough to be undeniable.
Good language creates leverage.
A team that can describe adversary behavior consistently can move from observation to detection, from detection to response, from response to policy, from policy to automation, from infrastructure to evidence, from evidence to disruption.
The language has to travel as fast as the threat.
A consistent way to describe adversary behavior so meaning can move across teams, systems, institutions, and time.
Insight that remains trapped in notes, queues, meetings, or individual memory because it has not been translated into a reusable form.
The ability to turn description into detection, response, policy, automation, evidence, and disruption.
Where the work is going
A taxonomy that sits on a shelf does not change outcomes. A framework that never enters the workflow does not help the person making a decision under pressure. A shared vocabulary only matters if it helps defenders move faster, coordinate better, preserve context, and act with more confidence.
The next step is making these systems more operational. Moving beyond simply naming a behavior, but connecting it. Not just documenting patterns, but reasoning across them. Not just producing language, but building systems that can carry that language into detection, investigation, automation, prosecution, and disruption.
That is where the work is going. It is also where it has always been going.
Compliance was never just compliance. Incident response was never just incident response. Fraud intelligence was never just fraud intelligence.
The work has always been the work beneath the work: turning adversarial chaos into operational language, and turning that language into systems people can use.
Before defenders can automate, they have to describe. Before they can disrupt, they have to connect. Before they can prosecute, they have to preserve meaning. Before they can move together, they have to speak in a way that survives the handoff.
The language is not decoration.
It is infrastructure.