Chapter 12 — The Three Rules for Any System With Money on the Line

⚠ Not investment advice. I hold no financial-advisory license. Nothing in this chapter recommends a security, a strategy, or a moment to buy or sell. The account described here is this company's own, and the figures shown are losses. Every number reflects July 2026 and will be out of date by the time you read it. What you do with your own money is your decision and your responsibility.

In chapters 10 and 11, we dealt with accidents where a bot stops or goes berserk. This chapter deals with a different kind of danger — the bot is perfectly alive, but the numbers it shows are lying. When a system dies, you notice right away, because the screen freezes or the alerts stop. But when a number is quietly off — and off in a good-looking direction, at that — nobody suspects it; they just feel pleased.

So this chapter gives you three rules to apply, without exception, to any system with money on the line. For each rule, we've compressed a real accident that shows why it's needed into a three-line box — the price we paid to learn each of these rules in our bones.

Principle 1 — Calculate Returns With Deposits and Withdrawals Removed (TWR)

When you calculate an automated-trading account's return, don't compute it as "current balance − starting balance ÷ starting balance." This method counts even the money you newly put in (deposits) as return.

Instead, do this. Every time there's a deposit or withdrawal, split the timeline into segments, calculate "how much you earned" only within each segment, then stitch the segments together. This method is TWR (Time-Weighted Return). A deposit is only a point that divides one segment from the next — it isn't counted as return.

The calculation itself takes just a few lines of code. The hard part isn't the formula — it's the habit of using this method, without fail, in every place performance shows up (the sheet, a video's opening, a report). There was a time we'd applied TWR correctly to the core metric, yet the cumulative-percentage graph piling up daily in the sheet was still drawn with the simple comparison. Check every single place a number appears, one by one.

One more thing — it's only a true record if it includes even the losses you've liquidated. Unrealized P&L, which looks only at the stocks you're holding right now, and TWR are different metrics. Because losses you've already sold drop out of the unrealized-P&L calculation, looking only at the survivors — the winners — always makes the record look good. When you talk about performance, always put TWR first.

You should now see: you can confirm, right on the sheet or screen, that the return number doesn't suddenly spike even right after a deposit. Conversely, if the return looks unusually good only in a month you made a deposit, that's a signal you're using the simple-comparison method.

⚠ Watch Out For This — A Deposit Disguises Itself as Return

On one account that started small early on, going through several deposits, the simple-comparison return came out to +5,111%. It looked as if the account had grown more than fiftyfold, but in reality it wasn't trading — that much new money had simply come in. The smaller the starting balance, the more the illusion from a single deposit grows exponentially. (The full story of the same illusion on two other accounts is in Appendix B.)

Principle 2 — Numbers Are Calculated by Code, and the AI Only Narrates

Whether AI or human, you can speak a calculated number, but you must not create or alter the number itself. Return, win rate, backtest result — every number printed on screen must be a value that code calculated by a set formula, and you must always be able to trace which code it came from.

There's one way to keep this principle. Automatically cross-check the numbers before and after the AI polishes the sentences, and if even one differs, throw out that entire correction. Why the AI changed the number doesn't matter — if it differs, you throw it out, no exceptions.

This principle has no exception whatever AI you use. Even if, to save tokens, you subcontract summarizing or drafting to a cheaper AI, never use the numbers that AI produces as-is in the books or a report. Numbers are always recalculated by code from the ledger; the subcontracted AI is entrusted only with polishing sentences, and no further.

You should now see: even after the AI corrects a script or report, when you place the numbers side by side with the pre-correction original, they're completely identical. If even one differs, it's normal for that correction to have been thrown out.

⚠ Watch Out For This — "Smoothing the Sentence" Can Touch the Numbers Too

A proofreading AI, smoothing a script to read naturally, once changed the number "82.86 million" to "8.28 million" — dropping a digit — so a coin market-update video showed Bitcoin's price (in Korean won, about US$60,000 at the time) at one-tenth its real size. To a language model, a number is just part of the text, so — like any other word — it can be quietly changed in the name of smoothness. Now, if the string of numbers differs before and after correction, we automatically discard the correction itself. (The full story is in Appendix B.)

Principle 3 — Change a Strategy Only After It Passes Validation

(How this gate actually runs, week to week, inside the organization we showed you first in chapter 10, "The Owner of Performance Is Design" — here we cover the validation method itself.)

Before you change a strategy or a trading rule, always validate it on past data first. But don't take comfort from an in-sample (a stretch the strategy already saw when it was built) backtest alone. If you first pick the stocks that look good to the eye and then trace back on those stocks, of course the results come out well (post-hoc universe selection — a form of survivorship bias).

Instead, do this. Re-score it on a recent stretch the strategy never saw when it was built (a holdout). If the result is a rejection, report it rejected, exactly as it is. Put the same scoring automatically on every single newly proposed change, and even when a person forgets, the procedure remembers instead. A rejection is a result, too — an honest failure report is itself the only thing that prevents the next illusion.

You should now see: every time you propose a new strategy, two numbers get printed side by side — the "in-sample record" and the "holdout record." If the gap between them is large, that in itself is a warning signal.

⚠ Watch Out For This — A Dazzling In-Sample Number Can Be False Comfort

When we traced a medium-to-long-term asset-allocation strategy back over five years of data, the compound annual growth rate (CAGR) came out to 42% (that is the figure from the audit record at the time; Figure 12-3 re-runs the same code at publication time, so its numbers differ slightly — and the verdict is still the same: rejected), but the actual live record swung through negative stretches. The cause was post-hoc universe selection (survivorship bias). Re-scoring on just the most recent 18 months as a holdout, both the risk-adjusted return (Sharpe ratio) and the drawdown came out worse than the market index — and this result, instead, lined up with the actual live underperformance. (The full story is in Appendix B.)

Three Principles, One Sentence

The attitude running through all three principles is one. Before you trust a number, ask first how that number was made. Whether deposits and withdrawals got mixed in (Principle 1), whether an AI touched it (Principle 2), whether it holds up even on a stretch it never saw (Principle 3) — trust the number only when the answer to all three questions is "yes."

This principle applies to this book, too. The named markers that have appeared so far, like {{KIS TWR %}} and {{Toss TWR %}}, and every number still to come, are filled in at publish time by code, calculated from the real records. Neither a person nor an AI types those values in by hand. Reading this chapter right now, you've already learned all three of the principles we hold dearest.

Checklist: Can I Trust This Number?

• Principle 1 — Is this return a deposit/withdrawal-removed value (is it TWR), or a simple

balance comparison?

• Principle 1 — Does this performance include even what's already been sold (losses included),

or does it show only what's left now?

• Principle 2 — Is there a mechanism that automatically cross-checks against the original number

before an AI renders it into a sentence?

• Principle 3 — Was this backtest's set of stocks not picked afterward for looking good

(post-hoc selection)?

• Principle 3 — Was this backtest also re-scored on a stretch the strategy never saw when it was

built (a holdout)?

• Can I go, right now, to the code path this number came from?
• Am I not being tempted to skip the validation procedure just because I like this conclusion?

Time needed: the guard code itself is a few lines, doable in tens of minutes. But for this habit to sink into your bones takes far longer. Only after living through the same kind of illusion three or four times does "when a number shows up, doubt it first" start coming out reflexively.

Cost: the money it takes to fit a guard is $0. The cost you pay for not fitting one isn't priced in money — it's deceiving yourself with a wrong number, or losing the trust of whoever saw it. The most expensive thing in this chapter, in the end, wasn't money but trust.

The way these honest numbers gather each morning into a single report — that continues in the next chapter.