The answer a rebalancing system needs is not the most accurate one available. It is one whose remaining error is far below the errors that are already in the pipeline around it.
Follow a set of target weights out of the optimizer and watch what happens to them. They get rounded to tradable quantities. Trades below some minimum size get suppressed. What survives goes to an execution algorithm that will fill somewhere near, but not at, the price you assumed. The tax consequence depends on which lots the accounting system picks, and on a cost basis that for transferred-in positions is sometimes an estimate. By the time the fills come back, the last several digits of the optimizer's answer have been overwritten by other parts of the system. And the inputs were never sharp to begin with: the expected returns and the covariance matrix that defined the problem are statistical estimates with real uncertainty attached.
Solving far past that point produces digits that the next stage destroys. Precision beyond the noise floor of your inputs is not accuracy. It is arithmetic.
Here is the part that surprises me every time. Almost nobody has chosen this number. The accuracy target in a production system is usually a default, inherited from whoever set the thing up or copied from an example in some documentation, and never revisited since. The latency target for the same system has an owner, a dashboard, and a postmortem process. The accuracy target has none of those, despite being a decision about how much money the firm leaves on the table and how much compute it buys to avoid doing so. That makes it a product decision, not a configuration detail.
The floor your answer lands on
Start by writing down the errors that are already present, before the optimizer runs at all.
Expected returns are the worst offender by a wide margin. Estimating a mean return well enough to distinguish two similar assets is one of the hardest problems in the field, and the standard error on those estimates dwarfs anything the optimizer contributes. The covariance matrix is better behaved but still an estimate, fitted on a finite sample, refreshed on a schedule, describing a market whose relationships shift. It is worth understanding how that risk model is actually shaped, because its structure tells you which parts of your answer are well determined and which are nearly arbitrary.
Then the operational errors. Prices in the optimization come from a close or a snapshot, and you trade later. Execution moves the price against you by an amount that varies by name and by day. Tax lot selection introduces ambiguity in the dollar consequence of a given trade. And the portfolio drifts: by tomorrow afternoon the weights you carefully computed have moved with the market, often by more than the difference between the two answers you were agonizing over.
The optimizer's remaining error should be compared against that floor, not against zero. If your answer differs from the theoretical optimum by one twentieth of the standard error on your return estimates, you have not made a modeling compromise. You have made a measurement below the resolution of the instrument.
One caveat, because a skeptical reader will raise it and they will be right: this holds for error that is unstructured. Systematic error does not average away. If a rounding rule always rounds the same direction, or an approximation consistently under-weights one sector, that bias compounds across accounts and across rebalances, and it can matter far below the noise floor. Random error an order of magnitude below your input noise is free. Biased error at the same size is not.
Choosing the number, in units a person can hold
The mistake that keeps this decision stuck in engineering is that the target gets expressed in solver units. A number in a config file governing an internal quantity nobody outside the team can interpret cannot be discussed by a portfolio manager, so it never is, so it never gets chosen.
Express the target in business units instead: basis points of tracking error, dollars of transaction cost, dollars of tax. Then work backward from what a decision-maker could distinguish. The procedure has five steps and takes an afternoon.
First, find where your pipeline already quantizes the answer. If you round to whole shares, or suppress any trade under $500, you have set a floor on meaningful precision downstream of the optimizer. On a $2M account, a $500 minimum trade is 2.5 basis points of portfolio weight. Any argument about accuracy below that is being settled by your minimum-trade rule, not by your optimizer, and you should know it before you spend a week tuning. Run the same arithmetic for your own account sizes: the floor moves with them, and it is usually higher than people assume on the small accounts, which are the ones you have most of.
Second, size the error sources above in the same units. Rough is fine. You are looking for orders of magnitude, not decimals.
Third, state the target as a business quantity with a threshold, in a sentence a person can approve: the answer must be within 2 basis points of predicted tracking error, and within $200 of expected transaction cost, of a reference answer computed at a very demanding setting.
Fourth, calibrate empirically. Take five or ten representative accounts, including the awkward ones. Solve each to a very demanding accuracy and keep that as the reference. Then solve at progressively looser targets and record the business quantities for each: tracking error of the difference, turnover cost, tax consequence. Plotted against the target, what you almost always see is a long flat stretch where the business quantities do not move at all, then a bend where they start to. Pick a point comfortably inside the flat stretch, which is usually far wider than anyone on the team expects.
Fifth, write it in the runbook with the reasoning, the date, and a name.
A worked illustration
Figures below are invented for the sake of a concrete example, not measured results.
Suppose a tax-managed separate account program: 400 accounts, average size $10M, tracked against a 1,000-name benchmark at a target of 60 basis points of annualized tracking error. Realized tracking error lands within roughly 15 basis points of predicted, which tells you the risk model's own resolution. Costs run about 8 basis points of traded notional, and annual two-way turnover is around 30%, so the account trades roughly $3M a year and pays roughly $2,400 in trading costs.
Now ask what a difference between two answers has to be worth before anyone acts on it. A portfolio manager here will not change a decision over 1 basis point of predicted tracking error, because the risk model cannot resolve it. Nor over $50 of transaction cost on an account paying $2,400 a year, because that is well inside the year-to-year variation in execution quality. So a defensible target is: difference under 2 basis points of predicted tracking error, under $100 of expected trading cost, and under $500 of tax consequence, per account. Everything tighter than that is invisible to every human and every report in the system.
Write that sentence down, get a portfolio manager to sign it, and a config default has become a product specification.
The measurement trap: never grade with a ratio of objectives
This is the section worth the price of admission, because I have watched careful people get burned by it and then quietly stop trusting their own quality numbers rather than fix the metric.
The natural way to measure how good an answer is: compare its objective value to the reference objective value, express the difference as a percentage of the reference. One line of code, and everyone recognizes it.
It breaks, and it breaks in the place where you need it most. Objective functions in portfolio work routinely pass close to zero. They are built by netting quantities against each other: an expected return term against a risk term against a transaction cost term against a tax term. The optimum is where those pressures balance, and the value there is a small difference of large numbers. For a tax-aware rebalance the objective can straddle zero by construction, positive on one account and negative on the next.
A ratio with a near-zero denominator does whatever it likes. Reference objective of -0.0002, your answer at -0.0008, and the report says a 300% gap on a solution whose weights differ from the reference by three parts in a hundred thousand in every single name. Nobody in the firm could tell those two portfolios apart. They would trade identically, book identical tax, and show identical risk. The number is arithmetically correct and completely uninformative.
The failure runs in the other direction too, which is worse. Take a problem where the objective is large: reference at 12,000.0, your answer at 12,000.6, a reassuring 0.005% gap. But the objective surface near an optimum is flat, and flat means a small objective difference can correspond to a large move in the decision variables. Those two answers might differ by 4% of the book in weight terms, which on a $10M account is $400,000 of turnover and a tax bill nobody approved. The gap said everything was fine. Everything was not fine.
So measure the thing the business holds. That is the weights.
Compute the difference vector between the two allocations and report two things about it. The root mean square difference across names catches diffuse drift, many small disagreements spread across the portfolio. The maximum absolute difference catches the case where one position blew out while everything else agreed. You need both, because either alone can look healthy while the other is alarming.
Then push that difference through the translators that make it mean something. Treat the difference vector as a portfolio in its own right, a long/short book that is exactly what separates the two answers, and run it through the same risk model you already own. Its predicted volatility is the honest answer to "how differently will these two portfolios behave." Then price the difference as a trade list: what it would cost in commission and slippage to move from one answer to the other, and what tax that would realize. Three numbers, all in units a portfolio manager uses daily, all stable, none of them capable of being flattered or wrecked by a denominator.
Two additions that cost nothing. Keep feasibility separate and binary: an answer that violates a mandate constraint is not a slightly worse answer, it is not an answer, and no gap figure rescues it. Averaging a constraint violation into a quality score is how a system ships an untradeable portfolio with a good scorecard. And report quality alongside speed in the same table, always, for the reason laid out in the benchmark methodology: a speed number without its quality gate is not a result.
The second trap: a reference that is not independent of the thing you are grading
The other way a quality metric fails is quieter. Your metric compares an answer to a reference. If that reference is contaminated by the system under test, the metric is partly measuring the pipeline agreeing with itself.
This happens through ordinary, well-meant engineering. The reference gets computed by the same code path at a tighter setting, so shared modeling errors cancel and go unmeasured. The reference inherits the same starting portfolio, so both answers stay near it and the distance between them looks small for reasons unrelated to quality. Sometimes the gap is computed against the input portfolio itself, in which case a system that changes nothing scores perfectly.
One diagnostic catches all of these and takes ten minutes. Ask what your quality metric would read if the system under test did nothing at all. Implement the null system: it takes the input and returns it unchanged. Score it with your metric exactly as written.
If the null system scores acceptably, the metric is broken. Not conservative, not noisy: broken, and it needs replacing rather than interpreting, because it is measuring the flatness of your problem instead of the quality of your answer. A metric that cannot separate a working system from one that does nothing will not tell you anything useful about the difference between two working systems either.
The stronger version, when the stakes justify it: compute the reference with a genuinely different implementation, ideally one your team did not write, and confirm the reference itself satisfies every constraint before you grade anything against it. Different families of method have different failure modes, and which family you are dealing with tells you what to check for. Agreement across two independent implementations is worth more than any single number from one of them.
What this is worth, and who should own it
The commercial consequence is plainer than it sounds. A target chosen this way is usually looser than the default it replaced, and the compute you stop spending on precision nobody can see becomes available for something a client can: more accounts reviewed, more often, with the awkward ones no longer skipped because they were expensive.
We hold our own reporting to the standards above. Where quality can be stated as a business outcome, it is: the full $238K harvestable tax budget captured on a $5M direct-indexing book on real US equity data, with the harness and result tables in the direct indexing evaluation repository. Where the claim is a matched-quality speed comparison, it reads as 3.4x to 126.7x faster than the best completing incumbent at certified-equal objectives on an operationally constrained real-data suite, with the methodology in the paper, the artifacts in the public evaluation repository, and the provenance of each headline figure on our research page. Rows without a completed reference are reported as feasibility, timing, memory and failure-status evidence rather than dropped or scored as an infinite speedup.
The organizational point is the one I would actually push on, and it is free.
Your accuracy target should be a written paragraph stating the threshold in business units, the reasoning behind it, the date it was set, and the name of a person on the business side who owns it. It should be reviewed on a schedule, the way a latency commitment is reviewed, and revisited when the inputs change: a new risk model, a different universe, a change in minimum trade size, a move into less liquid names where the noise floor is higher.
Almost no one does this. The number sits in a config file, set by someone who has probably left the firm, silently governing both how much compute the firm buys and how much precision it throws away downstream. Writing it down costs an afternoon and a signature, and turns an accident into a decision someone can defend.
Start with the null test. Run your quality metric against a system that does nothing, this week. Whatever it reads will tell you how much of the rest of this you need.
I write about optimization at production scale at Asymmetry Computing, where we build PRISM, an optimization engine that returns a feasible, auditable answer inside a hard deadline and reports its quality in units a portfolio manager can act on. This post first appeared on the Asymmetry Computing blog.