Overlay post-mortems almost never conclude that the indicator was wrong. They conclude that the desk saw the signal, agreed with it in principle, and then implemented it four days late at two thirds of the intended size because a meeting could not be convened and the market had already moved. The model was fine. The ninety minutes after the signal printed were not governed, and ungoverned minutes are where a systematic overlay quietly turns into a discretionary one with extra steps.
The override is where the overlay actually dies
The structural problem is that a liquidity signal fires at the least convenient possible moment. Almost by construction, a composite that turns down is turning down because conditions are deteriorating, which means the same week contains drawdowns in the book, client calls, and a plausible narrative for why this particular deterioration is different. Every input into a discretionary decision at that instant is correlated with the reason you built the overlay in the first place.
That correlation is what makes "we retain discretion at the signal" a null statement in practice. Discretion exercised under stress is not a second opinion, it is the first opinion re-weighted by discomfort. If you want the option to override, you have to specify in advance what an override requires, because the one thing you will not have at the moment of firing is the calm to define it.
The Global Liquidity Scorecard is a reasonable spine for this because its state is legible and small. At capture it read composite 85 on a 0 to 100 scale, regime RISK-ON, policy EASING, with component reads of LIQUIDITY NEUTRAL on net flows, FUNDING NEUTRAL on SOFR and IORB, and MARKETS NEUTRAL on asset momentum, plus a Liquidity Trade Signals panel covering six major assets scored bullish, bearish or neutral. That is a state vector you can write into a policy document and reproduce in a review. A vendor read that cannot be stated in one line cannot be pre-committed against.
What a pre-commitment has to specify before it counts as one
Most overlay policies specify the trigger and stop. A trigger alone is roughly a third of a policy. Six elements have to be written down or the document will not survive contact with a live signal.
The observation protocol. Which tab, which field, read at what time, in which base currency, by whom. The module carries a currency selector and a moving average window control in its header, and both of those change what you are looking at. A policy that does not pin the settings has not defined the observable.
The state-to-exposure map. Not "reduce risk" but a table from state to target weights, with the target expressed as a number the implementation desk can act on without interpretation. If two people can read the map and arrive at different books, it is not a map.
The tolerance band. Every map needs a no-trade region, or you will churn the book on a composite oscillating across a boundary. State the band in the same units as the trigger.
The clock. How long from signal to first execution, and how long to full target. This is the field most policies omit and the one that does most of the damage. A pre-commitment with no deadline is an intention.
The named approver and the named deputy. One person, one alternate, with authority to release the trade. A committee is not an approver.
The evidence to be retained. A screenshot of the state at the moment of firing, the timestamp, and the settings in effect. The module stamps its own refresh time in the header, and that stamp is what goes into the file.
An approval path with a running clock on it
Approval and discretion are not the same thing, and conflating them is what turns a governed overlay into a slow discretionary one. Approval verifies that the signal is real and that executing it does not breach a constraint. It does not re-litigate whether the signal is right.
Write the path as three checks, all answerable in minutes. Did the state genuinely cross the specified boundary, on the specified settings, on a refresh that reflects new data rather than a page reload. Does the target book breach any mandate, concentration, liquidity or counterparty limit. Is there a scheduled event inside the execution window that materially changes execution risk, such as a policy meeting or a month-end index event.
Any check failing produces a defined outcome, not a discussion. A boundary that was not genuinely crossed means no trade. A mandate breach means the trade is scaled to the nearest compliant book and the shortfall is documented. An event inside the window means execution is deferred by a stated interval, once, with the deferral logged and the clock restarted. Nothing in that path contains the word judgement, which is the point.
Logging the state you saw, not the state the vendor shows later
Attribution on a macro overlay is impossible without a vintage log, and almost nobody builds one until the first time a committee asks why a position was cut in a week that a chart now shows as benign.
Central bank balance sheet data, monetary aggregates and credit series are all revised. A composite recomputed on restated inputs will show a history that nobody traded. If your only record of the signal is the vendor's current chart, then in every review you will be defending a decision against evidence that did not exist when you made it. That is an argument you lose regardless of whether you were right.
The fix is unglamorous and cheap. On every signal event, capture the header state, the component reads, the per-asset tally, the refresh timestamp and the active settings, and store it immutably with the trade ticket. Do the same on a fixed weekly cadence whether or not anything fired, because a log that only contains signal days cannot tell you your false positive rate.
That archive is also the only honest input into any later question about whether the overlay adds value. A backtest run on restated data answers a question about a world you did not trade in.
The exceptions worth allowing, and the ones that are just discretion
A policy with no exception mechanism gets suspended entirely the first time it is inconvenient, so build a narrow one deliberately.
Allow exceptions grounded in things the composite structurally cannot see. It reads conditions, not valuations, and it carries no knowledge of your book. A liquidity read that says expand exposure while the specific instrument you would buy is already at a level that has discounted the easing is a valid case for expressing the change elsewhere. A pending capital flow that will change the base you are sizing against is another. A hard constraint that would be breached is a third. All three share a property: they are facts external to the signal, verifiable by a second person, and not restatements of the view.
Refuse exceptions whose content is a forecast. "We expect the composite to reverse next week" is the override that has to be blocked, because if you can forecast the composite then that forecast should be in the model, and if it is not in the model it is a feeling. The same goes for any exception whose stated reason is recent portfolio performance.
Then measure the exception rate as its own line in the review. A policy running at two exceptions a year is a policy. One running at two a quarter is a discretionary process wearing a document, and the correct response is either to fix the map so the exceptions stop being necessary or to stop describing the overlay as systematic in client materials.