I Build Connections Between Ideas That Are Usually Kept Apart
I am a Research Scientist and Adjunct Assistant Professor with a recently completed Ph.D. in Engineering Management and Systems Engineering from Old Dominion University. My academic training began in Industrial Engineering, continued through Engineering Management, and evolved into Systems Engineering, giving me a perspective that moves naturally between quantitative analysis, technology, organizational decision-making, and complex systems. I also serve as an AI Research Analyst and Subject Matter Expert supporting Elsevier Physical Sciences and Engineering Journals, where I evaluate AI-generated scientific and engineering content for technical accuracy, methodological rigor, evidence quality, citation integrity, and research reliability.
I hold a B.S. in Industrial Engineering, an M.S. in Engineering Management, and a Ph.D. in Engineering Management and Systems Engineering.
Today, my work explores questions around artificial intelligence, causal inference, data-driven engineering, modeling and simulation, digital twins, predictive maintenance, system-of-systems resilience, and decision-making under uncertainty.
I also teach engineering students through four different subjects: Engineering Managerial Economics (ENMA 302), Statistical Concepts for Engineering Management (ENMA 420), Project Capstone (ENMA 605), and Systems Architectures (ENMA 660).
At first glance, these may look like separate parts of an academic career.
I do not see them that way.
They are different ways of asking the same fundamental question:
How do we make better decisions about systems we do not completely understand?
That question has become the thread connecting my research, teaching, and applied work.
The Problems I Find Interesting Are Usually the Ones Without a Clean Answer
Engineering is often presented as a discipline of solutions.
Define the problem.
Build the model.
Run the analysis.
Optimize the result.
But real systems rarely cooperate with that sequence.
The data may be incomplete.
The environment may change.
The variables may interact in ways we did not anticipate.
The model may be mathematically correct and still be wrong for the situation.
The observed failure may only be a symptom.
And the decision may have to be made before uncertainty disappears.
These are the problems I find most intellectually interesting.
They require more than technical proficiency.
They require the ability to move between perspectives.
A statistician may ask whether the evidence is significant.
A machine learning researcher may ask whether the model predicts accurately.
A systems engineer may ask how the behavior emerges from interactions among components.
A decision analyst may ask which action is justified.
A human factors researcher may ask how the decision maker will interpret the recommendation.
I am interested in the space where all of those questions meet.
My Doctoral Research Started With a Simple Frustration
A machine can tell you that something is wrong.
That does not mean it can tell you why.
This distinction became the foundation of my doctoral research.
My dissertation focused on causal inference for fault root-cause diagnosis in nonstationary industrial time series.
The challenge was not simply detecting abnormal behavior. It was determining how causal relationships could be used to reason about the origins of faults in systems whose behavior changes over time.
That required bringing together ideas from causal inference, Bayesian reasoning, time-series analysis, predictive maintenance, and systems engineering.
The deeper problem was one of reasoning.
When a system changes, how do we distinguish correlation from causation?
When several variables change simultaneously, which relationships actually matter?
When the system operates under different regimes, can a causal relationship remain meaningful?
And when a diagnostic system identifies a likely cause, how should an engineer decide what to do next?
These questions pushed my research beyond conventional fault detection.
I became interested in the transition from observation to explanation.
From explanation to intervention.
And from intervention to decision.
That progression continues to shape the way I think about intelligent engineering.
Prediction Is Useful. Understanding Is More Powerful.
Artificial intelligence has made prediction extraordinarily powerful.
But prediction is only one layer of intelligence.
Knowing that a component is likely to fail is valuable.
Knowing which variables are associated with that failure is more informative.
Understanding the mechanisms that contribute to the failure is more powerful.
Knowing which intervention could change the outcome is more useful still.
This is why I am particularly interested in the relationship between predictive intelligence and causal intelligence.
A predictive model asks:
What is likely to happen?
Causal reasoning asks:
Why is it happening?
Systems engineering asks:
What does that mean for the larger system?
Decision analysis asks:
What should we do?
I find the transition between these questions far more interesting than optimizing any one of them in isolation.
I Do Not Treat Disciplines as Silos
My academic path has crossed several fields, but I do not think of that as collecting disciplines.
I think of it as learning different languages for describing the same reality.
Industrial engineering taught me to think about efficiency, processes, optimization, and the relationship between resources and performance.
Engineering management taught me to consider technical decisions within economic, organizational, and strategic contexts.
Systems engineering taught me to look beyond individual components and reason about relationships, architecture, interfaces, constraints, and emergent behavior.
Statistics taught me to be careful about what data can actually support.
Causal inference taught me to question whether observed relationships explain anything at all.
Artificial intelligence introduced new ways of extracting structure from complex data.
Modeling and simulation provided a way to experiment with systems before experimenting with reality.
These perspectives do not compete.
They constrain and strengthen one another.
That is where I find intellectual depth.
I Think About Systems in Layers
When I encounter a complex engineering problem, I rarely begin with the algorithm.
I begin by asking what kind of problem I am actually looking at.
What is observable?
What is hidden?
What changes over time?
Which relationships are structural?
Which relationships are merely statistical?
Where does uncertainty enter?
Where does it propagate?
What does the system need to accomplish?
Who makes the decision?
What information reaches that person?
What happens after the decision?
And what happens if the model is wrong?
These questions create a different starting point.
Instead of asking immediately, “What model should we use?”, I ask:
“What kind of reasoning does this problem require?”
Sometimes the answer is statistical.
Sometimes it is causal.
Sometimes it requires simulation.
Sometimes it requires architecture.
Sometimes it requires human judgment.
Often, it requires several of them at once.
I Am Interested in What Happens Inside the Black Box
There is a recurring temptation in engineering to celebrate systems that produce accurate outputs without fully understanding how those outputs should be interpreted.
I find the opposite problem more interesting.
What happens inside the black box?
What assumptions make the model work?
Which relationships does it implicitly learn?
What happens when the operating environment changes?
What information does it ignore?
When should we trust it?
When should we challenge it?
And how should a human respond when the model and engineering intuition disagree?
These questions become increasingly important as AI moves from analysis into operational decision-making.
For me, trustworthy AI is therefore not simply a question of making algorithms more explainable.
It is a systems problem.
Trust depends on the model, the data, the environment, the interface, the human, the decision, and the consequences.
The intelligent component cannot be understood independently of the system around it.
A Digital Twin Should Do More Than Mirror Reality
I am particularly interested in digital twins and modeling and simulation because they create an opportunity to connect data, models, and decisions.
A digital representation of a physical system is useful.
But representation is only the beginning.
The more interesting possibility is to create an environment where engineers can ask questions that are difficult to ask in the physical world.
What if this component fails?
What if operating conditions change?
What if two faults occur simultaneously?
What intervention would improve resilience?
How does a local problem propagate through the larger system?
How much uncertainty should we attach to the prediction?
And which scenario should a decision maker investigate first?
In this sense, I see modeling and simulation not merely as computational tools.
I see them as laboratories for engineering thought.
I Care About the Decision at the End of the Pipeline
There is a danger in modern engineering research of stopping at the model.
A model performs well.
An accuracy metric improves.
A new architecture is proposed.
A simulation produces interesting results.
A dashboard displays the information.
Then what?
Someone still has to decide.
Someone has to allocate resources, change an operating condition, schedule maintenance, redesign a component, accept a risk, or intervene in the system.
That final step changes how I think about research.
A technically impressive method is not automatically a useful engineering contribution.
I want to know whether the method changes what someone can understand, anticipate, evaluate, or decide.
That is the standard I increasingly apply to my own work.
Teaching Is Where My Ideas Have to Become Clear
Research allows us to explore difficult questions.
Teaching forces us to explain them.
I teach Engineering Managerial Economics, Statistical Concepts for Engineering Management, and Systems Architectures.
The subjects are different, but each develops a different dimension of engineering judgment.
Economics asks students to determine whether an engineering alternative creates value.
Statistics asks them to determine what conclusions the evidence can justify.
Systems architecture asks them to determine how elements, relationships, interfaces, information, and constraints must be organized to accomplish a mission.
Together, they teach something larger.
An engineer is not simply someone who knows how to calculate.
An engineer must know what to calculate, why it matters, what assumptions support the calculation, how uncertainty affects the result, and what decision the result should inform.
That is the kind of engineering thinking I try to cultivate.
I want students to become comfortable with complexity rather than immediately trying to simplify it away.
Theory Matters. So Does Reality.
I enjoy theoretical problems because they expose assumptions.
I enjoy applied problems because reality exposes everything else.
My research experience includes applied, government-funded engineering projects, including work as a Co-PI on Military Sealift Command-funded research.
These environments reinforced an important lesson.
Real systems are rarely clean.
Requirements evolve.
Data are imperfect.
Stakeholders have different priorities.
Resources are constrained.
Operational environments change.
And the technically optimal solution may not be the most useful solution.
Applied research forces ideas to become accountable.
A method must work within constraints.
A model must represent something meaningful.
An analysis must support a real question.
And a research contribution must matter beyond the page on which it was published.
That tension between abstraction and reality is one of the reasons I enjoy engineering research.
I Am Drawn to the Boundaries
The most interesting questions often appear at boundaries.
Between prediction and explanation.
Between data and knowledge.
Between models and reality.
Between machines and people.
Between technical performance and economic value.
Between individual components and system behavior.
Between uncertainty and decision.
Between research and implementation.
I am comfortable working in those spaces because I do not expect complex problems to respect academic boundaries.
A system does not care whether the person analyzing it calls themselves a statistician, AI researcher, systems engineer, or decision scientist.
The system simply behaves.
Our job is to understand it.
What I Am Building Toward
My long-term research interests are moving toward intelligent engineering environments in which data, causal reasoning, simulation, AI, and human judgment are connected rather than isolated.
I am interested in systems that can observe their environment, reason about changing conditions, identify meaningful relationships, explore possible futures, communicate uncertainty, and support decisions.
Not autonomous systems for the sake of autonomy.
Not AI for the sake of AI.
Not digital twins because digital twins are fashionable.
The question is always:
What capability does this technology create that the engineer did not have before?
If the answer is better prediction, that matters.
If the answer is better diagnosis, that matters.
If the answer is better understanding of causality, that matters even more.
If the result is a better decision under uncertainty, then the technology has become part of engineering rather than simply another technical artifact.
That is the direction I want to pursue.
Beyond the Resume
My degrees explain where I have studied.
My publications show what I have investigated.
My teaching describes what I have chosen to explain.
My projects show where I have applied those ideas.
But none of these fully captures what motivates me.
I am curious about systems that behave differently than expected.
I am skeptical of explanations that are too convenient.
I like questions that become harder when you examine them closely.
I enjoy moving from a mathematical abstraction to a physical system, from a dataset to a causal hypothesis, from a model to a decision, and from a technical problem to the larger context that gives the problem meaning.
I am especially interested in the moment when two seemingly unrelated ideas suddenly become connected.
That moment is often where the real research begins.
The Question I Keep Coming Back To
There is a question underneath much of what I do:
What would it take for an engineered system to move beyond recognizing patterns and begin supporting genuine reasoning?
That question leads in many directions.
Toward causal inference.
Toward Bayesian reasoning.
Toward simulation.
Toward digital twins.
Toward human-centered AI.
Toward resilient system architectures.
Toward better engineering decisions.
Toward new ways of teaching engineers to think.
The individual technologies will continue to change.
The deeper challenge will remain.
We are building systems that can process more information than ever before.
The next challenge is to build systems that can help us make sense of it.
That is the kind of engineering problem I want to spend my career exploring.
Not simply making systems smarter.
Making our understanding of systems deeper.