Three Tables: What People See When They Look at Your Trading System
Notes on perspective, projection, and the layers of any automated investment system
A quant developer, a systems architect, and a discretionary trader sit around the same chart.
The developer sees: order flow latency, fill rates, position sizing algorithms.
The architect sees: throughput, fault tolerance, the system's behavior under load.
The trader sees: whether the setup is clean, whether they can hold it, whether it feels right.
They are all looking at the same thing. They are seeing entirely different systems.
This is not a failure of communication. This is the nature of complex systems — they have multiple valid layers simultaneously. And if you are building automated investment systems, understanding which table each person is reading from is not soft advice. It is a technical skill.
The Three Layers
Layer One: The Execution Layer (The Developer)
The quant developer is watching the machine.
She sees:
- Is the order routing logic sound?
- Are the fill expectations realistic given current market microstructure?
- Is the position sizing algorithm handling correlation correctly across multiple instruments?
Her mental model is: the system as a set of processes.
She thinks in execution. When something breaks, she looks for the process that broke. When something works, she wants to understand which process made it work.
Her blind spot: she can optimize the machine and miss whether the machine is solving the right problem. She is very good at making the wrong thing run faster.
Layer Two: The Integration Layer (The Architect)
The systems architect is watching the connections.
He sees:
- Are the components talking to each other correctly?
- Does the strategy module interface cleanly with the risk module?
- When the market regime shifts, does the system hold together, or does it fracture?
His mental model is: the system as a set of relationships.
He thinks in integration. When something breaks, he looks for the boundary between components. When something works, he wants to understand which integration made it robust.
His blind spot: he can make everything connect and miss whether the whole is greater than the sum of its parts. He is very good at building a system that does the wrong things perfectly.
Layer Three: The System Layer (The Trader)
The discretionary trader is watching the market meet the model.
She sees:
- Is this setup clean?
- Can I hold this through a drawdown without second-guessing?
- Does the system's behavior match my mental model of how the market works?
Her mental model is: the system as an extension of a market view.
She thinks in conviction. When something breaks, she questions the market thesis. When something works, she trusts the process even when it is uncomfortable.
Her blind spot: she can over-trust her intuition and miss when the system has evolved past her original thesis. She is very good at staying in a trade that stopped being right.
Why They All Sound Like They Are Right
In a healthy project, these three people will all give you feedback that sounds correct.
The developer says the execution layer is solid. The architect says the integration is clean. The trader says she can hold it.
And you think: great, we are done.
But here is the trap: they are not talking about the same system. They are each looking at a different cross-section. The project can be excellent at every layer and still fail — because the layers are not aligned. The execution solves a problem the integration does not need solved. The integration connects components that the trader does not trust. The trader holds a position the execution layer is slowly bleeding on.
This is why automated investment systems fail not with a bang but with a slow divergence. The pieces all work. The whole does not.
The Alignment Problem
The hardest problem in automated investing is not the algorithms. It is not the infrastructure. It is alignment across layers.
When the quant developer's model, the architect's system, and the trader's conviction point in the same direction, something unusual happens: the system behaves like it has inertia. It holds together under stress. Drawdowns feel manageable. The edges of the strategy are clear.
When they are not aligned, the system fights itself. The execution layer does exactly what the model says, and the trader cannot hold it because the drawdown pattern does not match her mental model. The integration layer routes orders correctly, but the quant developer built the position sizing around a correlation assumption the architect did not know was there.
This is not a technical failure. This is a coordination failure. And coordination failures do not show up in backtests. They show up in real-time, under stress, when it is too late to ask the right questions.
How to Read the Three Tables
Here is a practical question for anyone running an automated investment project:
When each of these three people speaks, which table are they reading from?
Most people do not know. They hear positive feedback from the developer and feel relief. They hear confidence from the trader and feel assurance. They never notice that the architect has quietly stopped objecting, not because the integration is right, but because she learned not to fight.
The actual skill is not building the system. The skill is maintaining coherent signals across all three layers simultaneously.
Ask the developer: what would break your confidence in execution?
Ask the architect: what integration are you most uncertain about?
Ask the trader: at what drawdown does your conviction start to waver?
If you get three different answers, you do not have a system. You have three systems that happen to share a name.
What This Has to Do With Code
Every serious code project has the same three tables.
There is the developer who sees the code as logic: does the function do what it says?
There is the architect who sees the code as structure: does this module belong here?
There is the user who sees the code as behavior: does this solve my actual problem?
Most code reviews only involve the first table. The review passes. The code is correct. And the system quietly accumulates architectural debt that will not surface until the load test, or the refactor, or the moment a new developer tries to understand it.
Or worse: the code is clean, the architecture is sound, and the users still do not trust it. Because they do not see their problem in it. The code solved a different problem correctly.
The Mirror Problem
When different people can all read your system — when the developer, the architect, and the trader all find something true in it — you have built something unusual.
You have also created a new vulnerability: they will project onto it.
The developer sees the system and thinks: this is a machine, and machines should be optimized.
The architect sees the system and thinks: this is a structure, and structures should be balanced.
The trader sees the system and thinks: this is a conviction, and conviction should be trusted.
None of them are wrong. But none of them are seeing the system. They are seeing their model of the system.
The next level of skill — the one nobody teaches — is being able to tell the difference between what the system is actually doing, and what each person's mental model is projecting onto it.
That clarity is not a nice-to-have. In automated investing, it is the thing that keeps you from over-optimizing at the wrong layer, over-trusting at the wrong moment, and over-holding when the thesis has quietly changed.
A Question Worth Sitting With
The next time you review your system — your trading system, your code base, your team — try this:
Ask each person the same question separately: what is the most uncertain part of this?
Do not ask for risks. Do not ask for concerns. Ask what they are most uncertain about.
Then notice: do the three answers come from the same layer, or from three different ones?
If they come from three different layers, you are not facing one uncertainty. You are facing three. And solving the wrong one will not make the others go away.
The system is only as strong as the least-aligned layer. Not the weakest link. The least-aligned.
Top comments (0)