Every quantitative exposure policy gets overridden. That is not a governance failure, it is what the policy is for, because a rule that can never be departed from is a rule that will eventually force a position nobody in the room believes in. The failure is the undocumented override, and it announces itself at exactly the wrong moment, in a review, when the position is down and the honest answer to how the exposure got there is that somebody felt strongly in March and nobody wrote it down.
If your alt sleeve is driven by a composite band table, the override record is the part of the process that decides whether a bad quarter is a defensible outcome or a finding. Here is the record I would want to have in front of me, and the three fields that do almost all of the work.
Name the three overrides that actually happen
Overrides feel infinitely various when you are inside one and turn out to be three shapes when you look at a year of them. Naming them is the first step, because named shapes become rationale codes, and rationale codes become countable.
The first is the trade-through. The composite implies a band, the manager takes a different weight, and the reason is a view about something the composite does not measure. The second is the pre-empt. The manager acts on the band change the score has not made yet, usually because one visible input is moving hard and the blend has not caught up. The third is the freeze. The score changes band, the policy calls for a rebalance, and the manager declines to trade, most often for liquidity or operational reasons that have nothing to do with the market view.
These three fail differently and should be reviewed separately. A desk that pre-empts constantly has a timeframe problem in its policy. A desk that freezes constantly has a capacity problem it has not admitted. A desk that trades through constantly does not believe in the model and should say so in a mandate discussion rather than in twelve individual exceptions.
The fields, and why each one is there
Keep it to one screen. An override form that takes twenty minutes will be filled in retrospectively, and a retrospective override log is worse than none because it looks authoritative.
| Field | What goes in it | What it prevents |
|---|---|---|
| As-of reading | Composite, regime label, momentum label, timeframe, capture timestamp | Arguing later about what the score said at the time |
| Policy weight | The sleeve weight the band table implied | Measuring the override against zero instead of against the rule |
| Actual weight | What was held after the override | Vagueness about the size of the deviation |
| Rationale code | Trade-through, pre-empt or freeze | Every override reading as a unique special case |
| Contested input | Which of the 11 metrics the manager believes is misleading | Rationales that cannot be checked against anything |
| Dissent | Named objections, or an explicit none | Manufactured consensus in the minutes |
| Expiry | A date, not a condition | The override quietly becoming the policy |
| Review outcome | Filled at expiry, scored against the counterfactual | A log nobody ever reads back |
The contested input field deserves a note. The scorecard names its eleven metrics: BTC Dominance, USDT Dominance, Altcoin Volume Ratio, Funding Rates, Open Interest, Stablecoin Flows, Exchange Reserves, Large Transaction Volume, NVT Ratio, MVRV Z-Score and Realized Cap Changes. Requiring the manager to name which one they think is wrong, and why, converts a mood into a claim. Moods cannot be reviewed. Claims can, because in three months you can look at whether that metric did what the manager said it would do.
Expiry is the field that does the work
If I could keep only one field beyond the numbers, it would be this one. An override without an expiry date does not end. It stops being a deviation and becomes the state of the book, and eighteen months later the sleeve is at a weight no current process supports and no current employee chose.
Thirty days is a reasonable default, deliberately short. At expiry there are exactly two outcomes and no third. The override is re-approved, which requires the same form again with a fresh as-of reading, or it lapses and the sleeve returns to the band weight without further discussion. Making the lapse automatic is the point. It reverses the burden, so that inertia carries the book back to policy rather than away from it.
Use a date rather than a condition. Conditions sound more sophisticated and they are a trap, because "until the market normalises" is unfalsifiable and will still be technically true next spring. If the manager genuinely wants a condition, they can have one on top of the date, never instead of it.
Scoring overrides without cherry-picking
An override log that only records what happened is a diary. The version that changes behaviour scores each override against what the policy would have done, and it does so for every override, including the uncomfortable ones.
Three rules keep the scoring honest. Measure against the counterfactual policy weight over the override window, not against zero and not against a benchmark, because the question is whether the deviation added value, not whether the sleeve made money. Score every override, including the ones that were closed early and the ones where the manager was right for a reason they did not write down at the time, which should be scored as a miss on process even where the profit and loss was positive. And report the aggregate, not the highlights. The distribution of override outcomes across a year is a measurement of a specific manager skill, and it is one of the few genuinely clean skill measurements available inside a discretionary overlay.
What the log gives you in the meeting you are dreading
The scenario the whole apparatus is built for is this one. The alt sleeve is down materially, a board member asks how the position got to that size, and the honest history involves a judgement call that turned out badly.
With the record, that conversation is about process. Here was the reading, here was the band, here is the weight we took instead, here is the input we believed was misleading and why, here is who objected, here is the date it was due to lapse, and here is the review we wrote when it did. The call was still wrong. But wrong inside a process that was followed and documented is a different category of event from wrong in a way nobody can reconstruct, and every experienced allocator on the other side of the table knows the difference.
There is one more thing the log tells you, and it is the finding people least want to hear. If the same rationale code appears eight times in a year against the same contested input, you do not have a manager exercising judgement. You have a band table that is wrong, or a timeframe clause that binds to the wrong lens, and the correct response is to amend the policy at the next review rather than to keep granting exceptions to it.