How I Work: Complex Systems in the Real World

I work on the model and the environment around it at the same time, because one without the other is not AI safety. A model does not operate in isolation. It operates inside a dynamic and evolving organization, supervised by people, shaped by incentives, and embedded in technical, institutional, and human systems. What happens in the real world, at the boundary between the model and that environment, is where the most consequential AI safety challenges persist. And this is where most safety efforts fail. What I have learned across twenty years of building mission-critical technical systems is that the software and the human environment around it are inseparable. They must be developed together, tested together, and hardened together, because that is the only way safety at scale actually holds.

My work always produces four categories of deliverable working together: technical systems, organizational design, policy and governance, and behavioral solutions. None of these work in isolation.

At Northrop Grumman and the Defense Manpower Data Center, I led technical teams building enterprise systems for DoD and VA programs within funding environments exceeding $100 billion, while simultaneously translating the outputs of those systems into frameworks that military leaders and members of Congress could use to make funding decisions worth hundreds of millions and billions of dollars. The software had to produce the right outputs. The human decision-making architecture had to be able to absorb and act on those outputs. I worked on both simultaneously, sitting in rooms with senior military officials and congressional staff in the morning and with my lead developer, database engineer, and QA engineers in the afternoon, making sure the technical system and the human system were developing together toward the same operational goal.

At NPS, I built the collaboration platform now known as Global ECCO: a live, still-operating system connecting defense and security professionals across more than 100 countries. The software architecture and the social architecture of how professionals from dozens of nations with competing interests could actually collaborate effectively had to be designed together. Neither worked without the other.

For AI safety, this is the central challenge. Safety at scale is not a software problem or an organizational problem. It is a sociotechnical system problem, and it requires a leader who can work on both sides of that problem at the same time.

Most analytical approaches examine components in isolation: how does this unit perform, how does this model behave, how does this team function. What they miss is how the components connect to each other, because connection is where the real behavior of a system lives.

Network structure reveals the leverage points where a small change produces a large system-wide effect. It reveals the structural vulnerabilities that make certain failures not just possible but inevitable under the right conditions. And it reveals how information, influence, and failure actually travel through a system, which is almost never the way the org chart or the architecture diagram says they should.

My master's research applied this lens to organizational resilience and critical infrastructure protection, mapping the structural interdependencies in complex organizations to identify where a failure would cascade before a disaster exposed it. That work, sponsored by the Department of Defense, produced real frameworks used by emergency planners and first responders, including the Organizational Network Game, a hands-on training tool I developed to teach network thinking and resilience to operational teams.

At NPS, I built the software for constructing authentic social networks from real survey data about real populations. The technical work and the human work were inseparable: I had to understand how military commanders actually made decisions, what information they needed, and how they would interpret simulation outputs before I could design the network construction and visualization systems that would make those outputs actionable. I developed research-backed visualization approaches specifically designed for non-technical operators, because a simulation that only experts can read is not a decision support tool. The technical output and the human interface were co-designed from the beginning.

At Northrop Grumman, leading integration of the Global Force Management Data Initiative meant synthesizing massive distributed datasets spanning the entire DoD enterprise and delivering real-time network visualizations to senior military leaders and congressional staff. The software had to integrate correctly. The visualizations had to make the right connections visible in the right form for the specific decisions being made. I worked on both continuously, in direct dialogue with the decision-makers I was serving and the technical teams I was leading.

For AI governance, network thinking changes what you look for and what you build. It is not enough to know whether a model is aligned. You need to know how alignment failures would travel through the organization deploying it, where the structural vulnerabilities are, and which technical and organizational interventions would actually hold under pressure versus which ones would create new failure modes while appearing to solve the original problem.

The most consequential risks in complex systems are almost never the ones on the risk register. They arise from interaction, scale, and context in ways that nobody anticipated during design, and they often emerge precisely from the interaction between the technical system and the human system surrounding it.

I have watched this play out across every domain I have worked in, and the pattern is consistent. The risk that matters is not the one you planned for. It is the one that emerges from components that each looked fine individually.

In my defense and security simulation work at NPS, I built tools specifically designed to surface these non-obvious dynamics for military commanders making real decisions. The core question was not what happens if we conduct this operation, but how that action ripples through the beliefs, relationships, and behaviors of the civilian population over the following weeks and months. Would raiding a compound increase cooperation or drive recruitment for violent extremist networks? Would building a school in a particular community shift support in the ways the mission required? The simulation work I led was used to inform exactly these decisions, in Iraq and Afghanistan, by commanders who needed to understand second and third-order effects before committing to a course of action. The software produced the analysis. The visualization and decision support architecture I built alongside it made that analysis legible and actionable for the humans who had to act on it.

In financial markets, I built and operated proprietary systems grounded in complexity science, and a significant portion of the technical work was specifically devoted to understanding how other traders and institutions would behave under specific market conditions. What pressures would lead them to place orders at predictable price levels? How would their automated systems respond to specific market events in ways that created self-reinforcing cascade dynamics? Understanding the human behavioral patterns encoded in the automated systems I was trading against was as important as understanding the market structure itself. March 2020, one of the most extreme and dislocating market events in a decade, was my best month on record precisely because the cascading dynamics between human traders and automated systems played out exactly as my framework predicted. Contract expirations bringing together large volumes of simultaneously expiring positions, central bank announcements with their immediate wild price swings, unexpected breaking news events against the grain of prevailing market sentiment: each created predictable cascading dynamics that were readable in advance to a system that understood the underlying human and technical interaction patterns.

For AI governance, emergent misalignment is the version of this that demands the most serious attention. A system that appears aligned under evaluation conditions can quietly drift as it becomes more capable, through a process that standard testing pipelines were not designed to detect because those pipelines examine the technical system in isolation rather than as part of the sociotechnical system it operates within. Treating emergence as the primary risk surface means building governance that monitors for that drift continuously, across the full sociotechnical environment, not governance that certifies safety at a point in time and considers the problem solved. Governing for what the system might become, not just what it currently is, is what I call emergence foresight, and it is the capacity that distinguishes genuine AI safety leadership from point-in-time compliance.

Cascading failures follow patterns. They are not random. The structural conditions that make a system vulnerable to cascading failure also make the cascade readable in advance, and that readability is operationally valuable if you have built the systems, technical and organizational, to act on it.

My master's research showed this in critical infrastructure: cascading failures in complex organizational networks during disasters follow structural patterns that can be identified before disaster strikes. That insight let emergency planners design interventions that interrupt cascades before they complete, rather than responding to damage after the fact.

In counterterrorism simulation work, the same principle applied at the level of social systems. Removing a key figure from a violent extremist network did not always reduce violence. Sometimes it fragmented the network in ways that produced more diffuse and harder-to-interdict activity. Sometimes it disrupted the information flows that were actually constraining civilian radicalization. The cascade dynamics of the social system were as important as the direct effect of the action, and reading those cascade dynamics as signals, not just as risks, was what made the simulation work operationally useful rather than merely analytically interesting. The software surfaced the signal. The decision support architecture I built alongside it helped commanders interpret what the signal meant for their specific operational context.

In financial markets, I built a methodology explicitly around cascade dynamics. A significant part of the technical work was developing tools that let me, as a human operator, make sense of the vast amounts of data about emergent market dynamics in real time: where the cascades were forming, how far they were likely to extend, when they were approaching exhaustion, and when the risk profile had shifted enough that the automated execution system needed to stand down. A core element of that design was the structural use of options contracts that created asymmetric exposure. The cascade dynamics I had modeled produced outsized returns when the prediction was correct and strictly bounded losses when it was not. This asymmetric approach to risk architecture in financial markets mirrors the same principle at work in counterterrorism operations and AI safety: design the system so that being wrong is survivable and being right is decisive. The human oversight system and the automated execution system were co-designed to work together, because neither was sufficient alone.

For AI governance, safety failures cascade through sociotechnical systems in the same way. A narrow technical intervention that reduces one visible risk while creating new failure modes elsewhere is not a safety improvement. It is a cascade in slow motion. Reading failure patterns as signals rather than isolated events, and building both the technical and organizational systems needed to act on those signals, is what allows governance to be genuinely adaptive rather than reactively compliant.

Before I deploy anything into an environment with real stakes, I understand how it behaves. Not how I hope it behaves. Not how it performed in a controlled test. How it actually behaves under real conditions, including conditions that were not anticipated during design, and including the conditions created by the human system that will actually be using it.

This is not caution for its own sake. It is the non-negotiable prerequisite for consequential action in complex systems.

The validation approach I developed for social simulation addressed this directly. Complex social systems have no controlled referent. You cannot run a randomized trial on a whole society. The solution was to run simulations forward from baseline population data, then compare the emergent dynamics against subsequent real-world survey data from the same populations. Real data as the benchmark, real human behavioral patterns as the validation standard. The simulation had to earn its use in real decision-making by demonstrating genuine predictive validity first, and the validation process itself required ongoing dialogue between the technical simulation work and the subject matter experts who could assess whether the outputs reflected how real communities actually behaved.

In financial markets, I ran three years of full-scale proprietary simulation before deploying a single dollar of real capital. A substantial portion of that simulation work was devoted specifically to understanding how my own decision-making and my own automated systems would behave under conditions I had not yet encountered: where my own biases would lead me astray, how my automation would respond to edge cases, and what the interaction between my human judgment and my automated execution would produce under extreme stress. Understanding the human element of my own system was as important as understanding the market dynamics. That discipline was the prerequisite for eight years of consistently profitable live trading, including exceptional results during the most extreme market event of the decade.

For AI governance, the equivalent is the gap between evaluated safety and deployed safety. This is the robustness gap: the distance between how a system performs under evaluation conditions and how it holds under the full pressure of real deployment, inside a real organization, with real humans, real incentives, and real consequences. A system can pass every benchmark and still fail under real deployment pressure because the evaluation environment did not capture the organizational context, the human behavioral patterns, or the emergent interaction between the model and the humans and institutions surrounding it. Closing that gap requires leadership that can work on the technical system and the human system simultaneously, insisting on genuine understanding of both before real human stakes are introduced. That is what safety at scale demands.

Human behavior is not a complication to route around. It is the most important design input in any sociotechnical system, and it can be modeled, measured, and built for, if the technical system and the human system are developed together from the beginning.

Most technical approaches treat human behavior as an afterthought: build the system, then figure out how humans will use it. My approach inverts this. Human behavior is a core design input from day one, because the system will only work as intended if it is designed for how people actually think and act, not how a simplified model assumes they do.

At NPS, I built simulation software that constructed synthetic populations from real survey data, representing each person's beliefs, values, and behavioral tendencies as a network of interdependent variables grounded in what real people in real communities actually think and do. Military commanders used the outputs to decide how to engage civilian populations in Iraq and Afghanistan: when to build infrastructure, how to design messaging, which communities were likely to shift their support under which conditions. The software produced those insights, but making them usable required co-designing the output formats and visualization approaches with the commanders and analysts who would act on them, in ongoing dialogue throughout development.

In financial markets, a substantial portion of my code was specifically devoted to modeling how other human traders, and the automated systems they built, would behave under specific market conditions. What institutional pressures would lead portfolio managers to place orders at predictable price levels? What behavioral patterns would lead algorithmic traders to configure their systems in ways that created predictable cascade dynamics? Understanding the human behavioral patterns encoded in the automated systems I was trading against was as important as understanding the market structure itself. The human and technical systems were inseparable, and my analysis of both was inseparable from the trading system I built to act on that analysis.

In my current AI alignment work, the central design challenge is making it genuinely easy for domain experts without technical backgrounds to contribute the ethical and safety knowledge that AI systems need. These experts possess irreplaceable real-world knowledge about human consequence, but they are not engineers. The interface between their expertise and the technical system that needs it must be designed with extraordinary care: low friction, natural, and structured in a way that produces exactly what the technical architecture requires, without the experts needing to understand any of that. Getting this right is as much a software design problem as it is a human factors problem, and solving it requires working on both simultaneously.

For AI governance, treating human behavior as a quantifiable design input means building systems that work with real human behavioral patterns rather than against them, and organizations that are designed for the humans who will actually operate them rather than for an idealized version of those humans that does not exist in practice.

In emergent complex systems, the most dangerous failure modes cannot be listed in advance. They arise from interaction and scale in ways that no design review can fully anticipate. Risk architecture built around a fixed list of known failure modes is therefore inadequate by design: it protects against the last failure, not the next one.

The right foundation for risk architecture in emergent systems is a deep understanding of the system's dynamics, both technical and human: how it behaves under pressure, how failures propagate once they begin, where the feedback loops are between the technical and human components that can amplify a small problem into a large one, and what conditions cause behavior to change qualitatively rather than just incrementally.

In financial trading, I built the entire system on this foundation. Rather than enumerating failure scenarios, I built continuous monitoring of the structural conditions under which the strategy was designed to operate, designed both the automated systems and my own oversight practices to recognize regime changes, and built automatic disengagement mechanisms that activated when those conditions shifted. The risk architecture was the foundation. Everything else was built on top of it.

My current work on AI alignment applies this principle in a fundamentally new way. Rather than trying to enumerate what an AI system should and should not do, I am developing a supervisory architecture that sits between the frontier AI system and the real world. The frontier model, which operates as a complex adaptive system where emergence and nonlinearity dominate, generates proposals freely. A purpose-built supervisory system, grounded in documented real-world cause and effect from human practice and expertise, evaluates every proposal against what actually happens to real people in real communities when interventions like these are implemented. Proposals that satisfy the supervisor reach the user. Proposals that would cause harm are stopped before they ever do.

The frontier model never interacts directly with the real world. Only the supervisor stands between the frontier model's emergent outputs and human consequence. This achieves genuine mechanistic interpretability of alignment, because we can understand precisely what the much smaller and more transparent supervisor is doing and why. It avoids the emergent misalignment and maladaptive behaviors that plague current approaches, because the frontier model's emergent capabilities are harnessed while being bounded by a supervisor grounded in real human consequence rather than abstract principles.

Critically, the design of this architecture required solving the human problem alongside the technical problem: how do you make it genuinely easy for domain experts without technical backgrounds to contribute the ethical knowledge the supervisor needs, in exactly the form the technical architecture requires, without friction that would compromise the quality or quantity of their contribution? That interface design challenge is as important as the neural architecture challenge, and neither can be solved without solving the other.

Safety at scale is not achievable without risk architecture that is designed for emergence, built for the full sociotechnical system, and developed in ongoing dialogue between the technical and human dimensions of the problem.

Automation raises the bar for human oversight. It does not lower it. And intelligent human oversight requires both the right technical architecture and the right human architecture, built together.

When a system executes faster than human cognition can track, the question is not whether a human is present. The question is whether the human present has the situational awareness, the information architecture, and the judgment to recognize what actually matters and act on it before the window closes. Building that capability requires working on the technical systems that surface the right information and the human and organizational systems that make it possible to act on that information, simultaneously.

My research at NPS examined how people visually understand complex network data under operational time pressure. Through controlled experiments with defense professionals from dozens of countries, I identified which visualization approaches enabled more accurate and faster recognition of the patterns that mattered for high-stakes decisions. That research directly informed the design of the decision support systems I built alongside the simulation software: the technical output and the human interface were co-designed from the beginning, because a simulation that only experts can interpret is not a decision support tool.

At Northrop Grumman, I led integration of the Global Force Management Data Initiative, turning massive distributed datasets spanning the entire DoD enterprise into real-time visualizations for senior military leaders and congressional staff making decisions worth hundreds of millions and billions of dollars. In meeting after meeting with top officials from every military service and with congressional staff responding to member requests, I translated what the technical systems were showing into language and frameworks that made the complexity actionable. That translation required deep fluency in both the technical systems and the decision-making processes of the humans I was serving, and the ongoing dialogue between those two domains shaped every development decision I made with my technical teams.

In financial trading, my execution was fully automated. Human oversight was not watching the trades. It was watching the conditions under which the automated system was designed to operate, and a substantial portion of the code I wrote was specifically designed to support that oversight function: tools for making the emergent dynamics of the market visible to me, in real time, in forms I could actually interpret and act on under pressure. The human oversight system and the automated execution system were co-designed, because neither was sufficient without the other.

For AI systems, intelligent human oversight requires the same co-design discipline at every level of the governance architecture. The technical systems must surface the right signals. The organizational systems must ensure the right people have the authority and the situational awareness to act on those signals. And the policy systems must make clear what action is required and who is responsible for taking it, before the cascade begins rather than after. Safety at scale requires all three, developed together.

Every domain I have worked in has been high-consequence from the beginning. The frameworks were not tested in these environments. They were built in them, shaped by the demands they imposed, and validated by outcomes that were real and measurable.

Disaster preparedness and critical infrastructure protection. My master's research, sponsored by the Department of Defense, produced network-based frameworks for organizational resilience, continuity of operations, and critical infrastructure protection used by emergency planners and first responders. I also developed the Organizational Network Game, a hands-on tool that teaches network thinking and resilience to operational teams, making technical concepts accessible and immediately actionable for non-technical professionals.

Defense, counterterrorism, and international security. At NPS, I simultaneously led two consequential programs. As Principal Investigator for the Combating Terrorism Fellowship Program platforms, I built what became Global ECCO: a live, still-operating global collaboration platform connecting defense and security professionals across more than 100 countries, recognized with an official letter of commendation from Undersecretary of Defense Michael G. Vickers for creating a ground-breaking tool that will benefit the U.S. government and our allies as we continue to combat terror. As lead CASS scientist, I built the simulation and modeling framework used by military commanders making real decisions in Iraq and Afghanistan, including decisions about when to build schools versus conduct operations, how to design messaging to reduce civilian support for violent extremist networks, and how different courses of action would ripple through local populations. At Northrop Grumman, I led programs within DoD and VA funding environments exceeding $100 billion, building enterprise systems and the decision support architectures around them simultaneously, translating complex technical outputs into actionable intelligence for military leaders and members of Congress.

Closing the digital divide. As President and Executive Director of a California technology nonprofit focused on digital inclusion and workforce development, I led the organization through a decade of sustained growth, building and sustaining strategy, governance, board leadership, fundraising, and operations with direct executive accountability throughout. The work was consequential in the most direct sense: families without computers, students whose schools did not provide devices, neighborhoods without internet infrastructure, adults without the digital skills required to compete in the modern workforce. Being left behind by the digital economy is itself a complex adaptive system problem, where poverty, institutional gaps, infrastructure deficits, and policy failures compound each other and leave entire communities behind by default. Providing technology and essential digital skills training at no cost to vulnerable populations is a real-world complex system intervention, and doing it effectively for a decade required exactly the kind of sociotechnical systems leadership that AI safety demands: understanding the technical, human, organizational, and policy dimensions of the problem simultaneously, and building solutions that work for the people they are designed to serve.

Complexity science applied to financial markets. From 2015 to early 2024, I designed, built, and operated proprietary systems applying complexity science to equity futures and options markets. Three years of full-scale simulation preceded the first live trade. Eight years of consistently profitable live trading followed, including exceptional results during March 2020, one of the most extreme and dislocating market events in a decade, when the cascading dynamics between human traders and automated systems played out exactly as my framework predicted. A substantial portion of the technical work involved modeling how other traders' behavioral patterns and institutional pressures would be encoded into their automated systems, producing predictable cascade dynamics that a complexity science framework could recognize and act on. The technical systems and the human oversight architecture were co-designed throughout.

AI safety and alignment. AI safety and alignment have been part of my work for nearly two decades, long before frontier AI became a public concern. Every intelligent system I have built required solving problems of safety, alignment, and human oversight in real operational environments with real consequences. The questions I was asking in 2008 about how to make intelligent systems behave safely in complex sociotechnical environments are the same questions the field is now grappling with at scale. Through 10²³AI and advanced doctoral research at the University of Southern California, I am extending that body of work directly into AI safety and alignment leadership, including presenting workshops and developing cutting-edge techniques at the intersection of complexity science, human systems, and AI governance. Every engagement I take is approached fresh, shaped by the specific organization, its specific challenges, and the specific sociotechnical system it is operating within. The methodology is proven. The application is always new.