A rebalance recommendation needs to identify what changed before you can judge whether it belongs in your account. If the system cannot name the changed input, constraint, or objective, treat the new allocation as an unverified proposal and do not approve it.
At 8:12 AM, the brokerage app shows a different mix of holdings. There is no alert saying volatility rose, two assets became more correlated, a price threshold broke, or your maximum position size changed. The recommendation is simply there, dressed as the latest answer.
That is a decision without an audit trail.
In 1999, NASA lost the Mars Climate Orbiter while it approached Mars. The spacecraft had been launched the previous year, and its navigation depended on data passed between teams. NASA’s investigation, chaired by Arthur G. Stephenson, found that one system used imperial pound-seconds while another expected metric newton-seconds. The mismatch affected trajectory calculations. Commands sent to correct the spacecraft did not recover it.
The issue was not that engineers lacked data. A critical assumption moved through the process without being made visible and checked at the point of use.
A portfolio rebalance has lower stakes, but the operational lesson is the same. A changed output requires a traceable changed input.
A new allocation is not an explanation
A recommendation can look reasonable and still be impossible to evaluate. “Reduce tech exposure” may sound prudent. What caused it?
Maybe the model detected higher correlation between your technology holdings. Maybe implied volatility increased. Maybe a holding crossed a position-size limit after a price move. Maybe the system’s target changed from growth to capital preservation. Those are different claims, and each calls for different scrutiny.
Without the reason, you cannot tell whether the recommendation reflects your plan or a hidden change in the model.
This matters most when the allocation shift is large. Cutting a position from 12% to 4% has consequences for risk, taxes, liquidity, and your original thesis. A screen that shows only the proposed percentage asks you to accept the conclusion before you have seen the work.
The Mars Climate Orbiter failure is a harsh reminder that outputs can appear internally consistent while carrying an unexamined mismatch. In trading, the mismatch may be simpler: the model is optimizing for lower volatility while you think it is following a trend strategy. Both can produce trades. They do not serve the same objective.
The four changes worth demanding by name
Before approving a rebalance, look for a plain-language record of what changed. Four categories cover most meaningful moves:
- Market inputs: price, realized volatility, volume, correlation, or other data used by the strategy.
- Portfolio constraints: a position exceeded its cap, sector concentration rose, available cash changed, or a drawdown rule became active.
- Model assumptions: the lookback period, signal threshold, forecast method, or risk target changed.
- Objective: the system is now prioritizing a different outcome, such as reducing drawdown, maintaining exposure, or limiting turnover.
A useful explanation names both the trigger and the consequence. “Correlation between these two holdings increased, so the combined exposure now exceeds your portfolio concentration limit” is reviewable. “Portfolio optimization suggests rebalancing” is not.
You also need to know what did not change. If price, volatility, correlation, constraints, and objective are all unchanged, ask why the recommendation differs from yesterday’s. It may be a recalculation artifact, delayed data, an implementation change, or a model behavior you have not been shown.
That question is especially important after a backtest. A backtest can produce a clean allocation history while hiding the assumptions that generated each shift. What happens when the same backtest produces different broker results? examines why execution details can change an apparently stable result.
Approval is where discipline becomes visible
An approval gate has value only when the person approving can see enough evidence to disagree intelligently.
For each queued rebalance, review the previous allocation, the proposed allocation, the stated trigger, and the risk effect. Then compare it with the rules you set before the market moved. If the proposal reduces a position, ask whether it is enforcing a pre-set limit or reacting to discomfort. If it increases a position, ask what defined-risk rule still limits the downside.
A concise decision log can be enough:
“Rejected. No changed variable was identified. Keep current allocation until the system shows the trigger and the affected constraint.”
“Approved. Correlation increased and the combined exposure breached the portfolio limit set on July 1.”
These notes are useful later, particularly during a drawdown, when memory tends to rewrite the reason a trade was approved. A trading journal should preserve the evidence available at the time, not produce a cleaner explanation afterward.
Build a review standard before the next alert
Set a minimum standard now: no allocation change gets approved unless it names the input that changed, the rule it activated, and the expected effect on portfolio risk. If any one of those is missing, leave the order queued or reject it.
NASA’s 1999 investigation did not describe a mysterious failure of intelligence. It identified a missing interface check between systems using different assumptions. Your review process needs the equivalent check between a model’s recommendation and your own risk plan.
The next time an app offers a new allocation at 8:12 AM, pause before comparing percentages. Find the changed variable first.
Educational content, not financial advice.
Comments
No comments yet.