Building the Desk
Order of operations: how our Desk checks an idea, a change, and a failure
Before the Desk looks at a price, it confirms who said what and which ticker it really supports. It checks that each change works in practice, not just in code, and it leaves failed research on the record instead of rerunning it.
Most of the work on a research desk happens before anyone looks at a price. This week we tightened how DePappa Capital's Desk handles that early work, and we want to explain the thinking in plain terms: what comes first, how we check that a change actually works, and what happens to a round of research that fails.
DePappa Capital trades only its own capital. Nothing here is investment advice, a recommendation, or an offer of any kind. This is a look at process, not results.
Step one: find out what an idea is actually about
Research ideas often start as posts: someone we follow shares a thesis about a stock, a crypto asset, or a prediction-market question. Before the Desk can test that idea, it has to answer two basic questions. Who said it, and can we point back to it? And which specific ticker, if any, does it really support?
Those questions don't need live market data. They're about the source, not the price. So we now treat them as their own stage. The Desk gathers the posts it can attribute, works out which ticker the evidence genuinely supports, and only then moves to the later stage that needs current market data.
Why separate them? Because mixing the two lets a market-data problem masquerade as a source problem, or the reverse. If a price feed is slow, that shouldn't erase the record of what was said and who said it. And if a post doesn't clearly support any ticker, there's no reason to spend time or money pulling market data for it. Doing things in order keeps each failure honest about where it happened.
Step two: check the code and the real operation separately
A change to the Desk isn't "done" when the code looks right. We check two different things, and we keep them apart.
First, the code: automated checks run against the exact version being shipped, and the change is reviewed before it goes out. Second, the real operation: once it's deployed, we confirm the running system behaves as expected, including that existing permissions and historical records survived the change and that the live research workspace still opens and works.
Passing the first doesn't prove the second. Code can pass every test and still be deployed wrong. And a system that runs fine today hasn't necessarily been checked against the change that was supposed to go out. Keeping these as separate checks means we don't confuse "it should work" with "it does work."
One practical result from today's update: new research requests no longer pass through an older, unnecessary paid data queue. The controls that matter stayed in place: which sources are allowed, the time window a request covers, who is allowed to do what, and protections against the same request running twice.
Step three: a failed round stays on the record
Earlier, one round of research failed. We didn't quietly rerun it or rewrite it. That round stayed stopped, and its original deadline, the reason it was refused, and its history were all kept as they were. No old research, trades, or posts were replayed to fill the gap.
The same rule applied this morning. Our scheduled morning checks overlapped a short engineering pause. Those slots aren't counted as successful scans, and we're not backfilling them after the fact. A visible gap is more useful than a result that looks complete but wasn't produced the normal way.
Future work runs under the corrected process. Past work stays exactly as it happened. That separation is what makes the record worth reading.
What this does not mean
To be clear about the limits: these are engineering and restoration facts. They are not proof of new research results, a trading plan, simulated fills, or profit. Several pieces are still open, including inspecting charts directly inside the Desk, tying a method to a specific decision in a reusable way, carrying a plan through to a simulated entry and exit, and showing reliability and cost over a sustained period.
Real-money trading by the Desk is off. Automatic publishing is off. Every post and article, including this one, is approved by a person before it goes out.
The takeaway
Good research is mostly sequencing and bookkeeping. Confirm what an idea is about before you price it. Check that a change works in practice, not just on paper. And when something fails, leave the failure where people can see it. We'd rather show a gap than paper over one.