There's a question I've kept running into for over a decade—not because I set out to chase it, but because it kept reappearing in every system I worked on.
How does architecture determine what behaviors are possible?
More specifically: how do the structures we build—whether neural systems, software systems, or machine learning models—process information in ways that produce emergent behavior? What can we learn by studying these systems? What becomes possible when we understand them deeply enough to build new ones?
This isn't a question unique to neuroscience. It's a question I happened to study through neuroscience. And once you've seen this pattern play out across enough domains, you start recognizing it across very different kinds of systems.
Where It Started
I didn't go into neuroscience because I wanted to understand the brain specifically. I went in because the brain is the most capable information processing system we know—and understanding how it works seemed like it would reveal fundamental principles about perception, decision-making, and action.
My PhD focused on sensorimotor integration: how brains coordinate perception and action. How does the motor system use sensory feedback? How does context change processing? Why do errors in one domain affect performance in another?
These questions fascinated me because they revealed architecture. The brain isn't just a black box that produces outputs. It's structured. Hierarchical. Feedback loops everywhere. Parallel processing streams that integrate at specific stages. Time constants that differ by orders of magnitude—reflexes measured in milliseconds, memory consolidation happening over hours.
The architecture determines what the system can do.
But here's what I realized, probably around year three of my PhD: I didn't actually care about brains specifically.
I cared about the pattern. The question. How systems—any systems—process information to produce behavior.
Neuroscience was just one lens on that question. And it turned out there were others.
Proprio: The Same Question, Different Substrate
When I co-founded PlatformSTL and built Proprio—a wearable activity classification platform for stroke rehabilitation—I was ostensibly leaving neuroscience. No more MRI machines. No more brain imaging. Just Apple Watches and AWS Lambda functions.
But I was asking the exact same question.
Given this sensor architecture (6-axis IMU at 30Hz), what behavioral patterns can we extract?
We weren't studying brains anymore. We were studying time-series signals from accelerometers and gyroscopes. But the underlying challenge was identical: understand the processing pipeline well enough to recognize patterns that correspond to real-world behaviors.
The limits of what we could classify weren't about model choice—they were set upstream by sensor placement, sampling rate, and windowing assumptions. Because we were constrained to wrist-mounted sensors at 30Hz (battery life requirements), certain activities were inherently indistinguishable. "Typing" and "eating with utensils" produced similar wrist movement patterns in that frequency range.
The sensor architecture determined what processing was possible. The processing pipeline determined what behaviors we could recognize.
- Wrist orientation over time mapped to "brushing teeth" vs "eating with a fork" via FFT-derived features
- Sliding windows (1–3 seconds) captured enough temporal structure without too much latency
- Patient-specific models corrected for individual movement impairments
Same analytical lens. Different substrate.
And we had to build the entire infrastructure to answer these questions: real-time streaming from watch to cloud, ML pipeline for patient-specific model training, clinician dashboards to interpret results. The tools didn't exist, so we made them.
MR.Flow: When Architecture Blocks Processing
MR.Flow—the neuroimaging pipeline orchestration system—is where I saw the pattern from a different angle: how accidental architecture prevents processing from happening at all.
The field had world-class preprocessing tools: fMRIPrep, FreeSurfer, ANTs, SPM, AFNI. Each tool represented decades of neuroscience expertise. But the architecture of how researchers accessed these tools was a disaster.
The architecture: Each tool was a separate command-line program with its own configuration format, dependency requirements, and failure modes. No coordination between tools. No shared error handling. Manual job scheduling.
The processing that resulted: Researchers spent 2-3 weeks just getting pipelines to run. Docker environment configuration. Parameter files in different formats for each tool. Serial execution because parallelization required manual job scripting. When something failed (and it always did), you started over from scratch.
The behavior that emerged: Experiments that should have taken days took months. Questions went unasked because the overhead of testing them was too high. Grad students became sysadmins instead of scientists.
The problem wasn't the algorithms—it was the architecture they were embedded in.
When architecture makes execution expensive, exploration becomes rare.
MR.Flow changed the architecture: unified GUI, automated dependency management, hardware-optimized parallel execution, persistent job state with resume-on-failure. That architectural change enabled different processing: workflows that previously took weeks to configure now take 45 minutes. Parallel execution uses all available CPU/GPU resources automatically. Failures don't destroy hours of work.
Different architecture → different processing → different behavior. Researchers can now iterate on analysis approaches instead of fighting infrastructure.
Same analytical lens applied to infrastructure.
Epoche: Emergence in Machine Learning
Fast forward to Epoche—the ML workbench I built for neurophysiology research. On the surface, it's a tool for training classifiers on EEG data. Feature extraction, grid search, ensemble optimization, interpretability analysis.
But really, it's a platform for asking: What patterns emerge across different model architectures?
When you train 18 different classifier types on the same data, you're running an experiment on information processing systems. Each model has a different architecture (decision trees vs neural networks vs ensemble methods). Each processes the input differently. Each produces different feature importances.
Cross-model consensus lets you separate signal that survives architectural differences from patterns that exist only because a specific model makes them easy to express.
If Random Forest, XGBoost, and Logistic Regression all agree that frontal theta power is the most important feature for predicting attention state—that tells you something about the data. If only one model thinks a feature matters, that tells you something about the model's architectural biases.
Here's the explicit causal chain: Because different model architectures (tree-based vs linear vs kernel-based) process features differently (splits vs coefficients vs kernels), they weight features differently. When architectures agree despite processing differences, the signal is likely real. When they disagree, you're seeing architectural artifacts.
Epoche's hypothesis generator does exactly this: analyzes divergence patterns and produces testable claims. "Tree-based models weight this feature heavily but linear models don't → possible nonlinear interaction." "One model rates this feature much higher than others → verify this isn't spurious correlation."
This is experimental design for understanding information processing systems. The emergent behavior we care about is prediction accuracy, yes—but more importantly, it's understanding what patterns the models learned and why.
Same analytical lens. Different substrate.
MUSE: Building Systems to Study Emergence
Which brings me to MUSE.
On the surface, it's a simulation platform for interactive storytelling. 100K+ entities with biological needs, psychological states, social relationships. Emergent narrative. All true.
But that's not why I'm building it.
I'm building MUSE because it's the first system where I can test these questions directly, without domain constraints or inherited architectures.
Every entity is a bundle of systems: metabolism, memory, perception, decision-making, social cognition. Each system has an architecture (how it's structured) and processing rules (how it updates over time). Behavior emerges from the interaction of these systems with each other and the environment.
And crucially: it's deterministic and inspectable.
I can run the same scenario twice and get identical results. I can step through time. I can snapshot state. I can trace any behavior back through the causal chain that produced it. I can modify architectures and see what changes.
Here's a concrete example of the causal chain:
Architecture: Memory system with decay curves, consolidation during sleep, context-dependent recall.
Processing: Each entity stores experiences as time-stamped events. During sleep cycles, recent memories consolidate based on emotional salience. Recall probability decreases with time but increases with contextual similarity.
Emergent behavior: Characters remember significant events long-term but forget minor details. They have biased recall—remembering the same event differently based on current emotional state. Relationships develop history that shapes future interactions.
I didn't program "characters form grudges." I programmed a memory architecture with specific consolidation rules. Grudges emerged.
This is where I get to study the question most directly:
- Want to understand how memory consolidation affects decision-making? Modify the memory system architecture and run populations for simulated years.
- Want to know how social network structure influences information spread? Set up different graph topologies and measure emergence.
- Want to test if biological constraints (metabolism, sleep, aging) produce realistic behavioral patterns? Implement them and observe.
Same analytical lens. Different substrate.
The Throughline
Looking back, every project has been the same investigation:
Proprio: Sensor architecture → signal processing → behavioral classification MR.Flow: Toolchain architecture → workflow processing → researcher productivity Epoche: Model architecture → feature learning → prediction + interpretation MUSE: System architecture → entity processing → behavioral emergence
Different substrates. Same analytical lens.
And at every stage, I've built tools because the tools to answer these questions didn't exist.
- Neuroscience labs had infrastructure that blocked questions. I built research platforms.
- Startups needed real-time ML pipelines. I built Proprio.
- Researchers needed interpretable ML. I built Epoche.
- I needed a simulation platform to study emergence. I'm building MUSE.
Tool building is how I explore the question.
Why This Matters
I think this realization matters for anyone who feels constrained by the domain they trained in.
My PhD is in neuroscience. My CV says "computational neuroscience." But that's not what I do. It's one context where I studied the question I actually care about.
The questions are portable. Domains are just where you encounter them.
If you find yourself thinking "I'm interested in X, but X just happens to be how I encountered the deeper thing I care about"—pay attention to that. The deeper thing is probably where you should go.
For me:
- Neuroscience → systems thinking
- Brain imaging → information processing
- ML on EEG → architecture determines emergence
- Building tools → experimental design
The domain was never the point. The question was.
Where This Goes
This lens applies naturally to areas like AI systems research, computational biology, or any domain where structure, processing, and behavior interact. Studying how transformer architectures process information to produce capabilities. How gene regulatory networks produce phenotypes. How distributed systems scale behavior.
What I do know is this:
Wherever I work next, the pattern will be the same: design the structure, observe the processing, study the behavior, and build tools that make the system legible enough to learn from.
The same analytical lens applied cleanly across domains.
That's the transferable skill: seeing how architecture shapes processing, how processing produces behavior, and building systems that make the relationship legible.
This is part of a series on building systems, following questions, and why the throughline matters more than the trajectory.
If you're working on questions about information processing, emergence, or experimental design for complex systems—regardless of domain—I'd love to hear from you.