Strategy Advisor — what it measures, what it approximates, what it has not validated

Written for a reader who will test each number against the convention it is named for. Built from the model register, so it describes the engine that ships; the built-from stamp in this page's source is checked against the register in CI.

Against the CFA Institute Standards of Professional Conduct

Each line names the mechanism a reader can check. NOT YET is written where it is true.

Measured · proxy · unvalidated

Measured

• Concentration by name (aggregated across accounts), by sector with funds folded through their vendor weights, by industry from the vendor field, by currency — each with the share of the book it could not classify stated.
• Expected shortfall (CVaR 95%, one day) and value-at-risk from the book's own daily history, with coverage and window stated; three named crisis replays on stored closes. US-dollar holdings are converted to Canadian dollars at the same day's USD-to-CAD close before any return is taken; a US holding with no FX history is excluded and named.
• Time-weighted and money-weighted return against a named benchmark, alpha, and turnover on a stated convention. Nothing is annualised under a year of history, and a benchmark younger than the book is not compared.
• The tax consequence of every taxable trim or sell in dollars at the client's marginal rate, derived on every read from their province and income band on CRA's 2026 brackets, with registered-first allocation across an aggregate position and a superficial-loss denial check against the ledger.

Proxy

• Beta-multiplied stress scenarios are illustrative arithmetic, not a forecast; the beta coverage of the book is printed beside each.
• Expected return of a mix is FP Canada's 2026 projection assumptions, net of the book's fees when they are known (gross, and said so, when a fund's MER is not on file), and the basis (declared policy / proposed policy / current mix) is named wherever it is used.
• Fair-value "confidence" is cross-model agreement; the realized-accuracy calibration behind the label abstains until estimates mature, and the report says which.

Unvalidated

• The Deep Score's labels, their cut-offs, its valuation inputs and every BUY / SELL / TRIM verdict built on it: no forward-return evidence exists (Standard V.A). The pre-registered point-in-time population test of 2026-10-06 certified only the 85-point fundamentals core as a rank of later sector+size-relative returns, narrowly (t 3.10 against 3.0; model register deep_score 2.1.3). The forward track-record script declares itself UNCERTIFIED.
• Diversifier picks: logged since 2026-09-10 with entry price and distance from the 52-week high; none has matured; no hit rate is published.
• The written narrative is a language model under constraint — validated for tickers, share counts, verbs and reconciled figures — and its prose is not deterministic across model versions.

From the model register — limitations, monitoring, validation

Strategy Advisor — signal rule engine v1.3.0 · reviewed 2026-10-01

• 1.3.0 (2026-10-01): A HOLDING WITH NO PRICE IS NOT SIZED. value_cad joins GUARDED_INPUTS and every rule that reads a weight or a value declares it, so a holding the price feed could not value (no live price and no stored close) gets the not-assessed verdict instead of a size judgement. The ADD rules read its unknown weight as 0% and told the client it was 'only 0.0% of portfolio. High conviction warrants higher weight' (independent review, 2026-10-01). Enforced by tests/invariants/test_signal_aggregate_weight.py's rule-input sweep.
• 1.2.0 (2026-09-30): A POSITION IS SIZED AS A WHOLE. Every size judgement now uses the whole position - the same ticker summed across all accounts - not one account's slice; a trim is still sized in the account it happens in, and its text names that account. No ADD fires on a name whose whole position is at or above its ADD level: the client's declared single-name limit x 40/45 (the house limit 25% -> about 22.2%), the same headroom the house sector pair uses (ADDs stop at 40%, trims start above 45%). The mid-quality trim takes the whole position to 5% by taking the same share off every slice. Today's concentration card fires at the client's declared single-name limit, else the 25% house limit; it was a hard-coded 25%. Buy, sell, trim and add cards on Today now come only from this engine: the AI Tax & Structure Audit contributes structural moves only (MIGRATE, CONSOLIDATE, HARVEST), and every card names its source (audit 2026-09-30).
• Rules are point-in-time on a single holding plus portfolio aggregates; no rule sees correlation, liquidity or realised volatility.
• Concentration limits sit above private-bank policy norms by design (review B5); a client who wants a bank's limit must declare one (max_single_position_pct, max_sector_pct).
• A declared limit LOOSER than the house one is honoured, not refused: the report states the departure for every sector and name concerned but does not re-ask. It records no acknowledgement from the client beyond the declared number itself. The statement is in the report and on the web Strategy page; the signals list, the Android app and iOS do not carry it.
• The sector ceiling is only as good as the look-through beneath it: a fund the ETF scan has not described is unclassified and outside every sector's weight.
• No rule's forward outcome is recorded, so no TRIM or SELL has an out-of-sample hit rate.

monitoring: NOT MONITORED · metric: forward outcome of TRIM/SELL signals

validated by: tests/invariants/test_advisor_signal_invariants.py + test_advisor_absence_invariants.py — soft-reason tax guard, verdict never silence, tax always stated, one decider, unknown is never a number

Strategy Advisor — orchestration, suitability, tax allocation, AI validation v1.16.0 · reviewed 2026-10-06

• 1.6.0 (2026-09-24): ADVISORY SPLIT FROM RESEARCH - A SINGLE NAME IS NO LONGER SIZED AS ADVICE. Measured on production 2026-09-24: 66 stored reports -> 48 carrying diversifier recommendations -> 180 single-name recommendations -> 180 of 180 carried a suggested_weight. Not a sample: every single name this product has ever shown a client arrived with a position size, behind a rank with no graded forward return. A size is the sentence that turns research into advice - 'consider DLO' and 'put 3-5% into DLO' are different acts, and the second implies a basis that does not exist. The size is now stripped at the engine choke point and the recommendation states how much graded evidence stands behind the screen, INCLUDING none. AN ETF KEEPS ITS SIZE: allocation rests on a declared policy, a tax rule or an arithmetic identity, and this is a split rather than a retreat from advice the product can defend. ENFORCED BY THE ENGINE, not the prompt - the prompt already asked for this shape and produced 180 of 180 the other way. GUARDED IN BOTH RENDERERS TOO, because the 48 stored reports still carry a weight and are re-read long after they were written. No contract change: suggested_weight is absent from contract.py and neither mobile client has a diversifier surface.
• 1.7.0 (2026-09-24): "DIVERSIFIES" NOW SAYS WHAT IT RESTS ON (B2a), AND IS MEASURED WHERE THE HISTORY ALLOWS (B2b). The prompt instructed the model to write '<sector> - diversifies the overweight' while the engine handed it NO correlation input at all: a candidate carries ticker, name, sector, deep_score, the growth-pillar fields and valuation fields, and nothing about how the name moves with the book. The only basis the screen had was that the candidate sits OUTSIDE the overweight sectors. That is a real basis and a weak one - two different GICS sectors can move together closely, which is exactly why the Risk X-Ray measures effective BETS rather than counting names. Every single-name recommendation now states the basis, and where price history allows it carries the measured change in effective bets, computed through the SAME risk_data/risk_concentration pair api/risk_api.py uses so the report and the X-Ray cannot disagree about one book. A name that measurably does NOT diversify is disclosed as such; the recommendation still stands, and the contradiction is stated beside it.
• B2 COVERAGE IS A MINORITY AND THE DISCLOSURE NAMES ITS OWN: measured on production 2026-09-24, 10 distinct live diversifier candidates -> 4 carry the >=60 days of price history a correlation needs. The plan specified this 'on every candidate'; that premise failed on the data. The other 6 say 'NOT measured' explicitly rather than staying silent, because silence beside a diversification claim reads as assent.
• 1.7.0 also adds B6's SUSPENSION RULE, and the honest fact about it is that it CANNOT FIRE YET. advisor_pick_track_record.py grades logged picks against SPY and the name's own sector, but it is network-bound and not in CI, so no graded cohort verdict is stored anywhere the report can read. The rule therefore returns ACTIVE with an explicit basis ('no graded cohort yet' / 'cohorts have matured but none has been graded') rather than ACTIVE with an implied all-clear - a STATE, not a boolean, because 'not suspended' and 'not yet judgeable' are different facts and a boolean collapses them into the reassuring one. When it does fire it REMOVES single names from the report rather than relabelling them; ETF recommendations survive, because allocation rests on a declared policy, a tax rule and an arithmetic identity and is not what failed.
• _SLEEVE_SUSPEND_AFTER_LOSING_COHORTS = 3 is a DECISION, not a fitted number. With no matured cohort there is nothing to fit it to, and a threshold fitted later to the very data it judges would be circular. Three is slow enough that one bad quarter does not silence a screen and fast enough that a persistent loser does not run for years. REVISIT when the first cohorts mature (first grading 2027-01-15).
• WHAT THIS DOES NOT DO: it does not make the single-name screen validated. The pick log and the grader exist; no cohort has matured, and the report now says so with the date the first one will. Nothing here converts a rank into evidence.
• TERMS AND PRIVACY WERE DELIBERATELY NOT TOUCHED. The plan had this batch editing docs/terms.html and docs/privacy.html, which state what the product represents itself to BE. F2 (registerable advice) is parked pending securities counsel, so a drafted legal representation would be the one claim in this programme with no gate behind it and the only one with legal rather than financial consequences. OWED: counsel review, then the wording.
• Recommendations carry no out-of-sample evidence: no pick, TRIM or SELL has a graded forward return yet (CFA Standard V.A). Nothing may describe the output as validated until scripts/advisor_pick_track_record.py grades a matured cohort.
• Suitability is an analytics analogue, not a regulatory determination (CFA III.C): below the six-field minimum every action is review-only with no timing and the missing fields are named; on a complete profile the four declared constraints narrow the plan and never widen it. Measured 2026-09-22: 1 of 6 client books had the four constraint fields on file.
• The declared allocation policy is enforced (a breach leads the plan) for clients with an IPS on file — 2 of 7 users on 2026-09-22. For the rest the questionnaire's mix is shown as a PROPOSAL awaiting acceptance and drift is never measured against it.
• Goal feasibility uses FP Canada's 2026 Projection Assumption Guidelines NET of the book's fund MER and any declared advisory fee when every MER is on file (gross, and labelled with the reason, when not; Batch 5, 2026-10-06) and an i.i.d. normal draw; the basis mix (declared / proposed / currently held) is named on every figure, and the currently-held basis is the return of what the client owns, not of a suitable allocation.
• Sector look-through covers only funds the ETF scan has described (sector_weights on file); the remainder is reported as unclassified, never as a sector.
• The written narrative is an LLM under constraint (schema, ticker and share checks, figure reconciliation, temperature 0); its prose is not deterministic across model versions.
• 1.16.0 (2026-10-06): A LOW SCORE IS A REVIEW, AN UNKNOWN BETA IS NOT A NUMBER, A CDR IS ITS UNDERLYING (audit HIGH residuals P004, P001, P002). (a) PROMPT: the narrative prompt said 'SELL is only for genuine deterioration: AVOID-rated quality (score < 40)' and 'Any holding with score < 40: recommend SELL or TRIM', a sale on a percentile the engine refuses (avoid_fundamental_rank_only). Both now defer to the engine; every holding in the prompt carries engine_actions (the signal list is capped at 40 and a rank-only HOLD is the first thing it cuts); the model is told the Deep Score and its labels have NOT been tested against forward returns. _validate_narrative corrects a model SELL/TRIM of a name the engine held on its rank alone to HOLD, recorded in _validation. Gate: tests/invariants/test_ai_prompts_defer_sales.py reads the RENDERED prompt. (b) STRESS ROWS: the broad-bear and severe-recession rows applied the covered-average book beta to the WHOLE book, so a holding with no beta was shocked at the average. They now go through the page table's decider (_stress_population / _beta_shock_loss): a holding with no beta is excluded and named (stress_unmodelled, stress_unmodelled_note), the loss and loss % are over the modelled holdings, after_cad is not stated while any holding is unmodelled, and with no beta anywhere the row states no loss and no value after ('no betas on file — not stated'; a flat index drop until 2026-10-07). Betas are clamped to [0, 3] here too. The suitability drawdown conflict names the population its loss % is over. (c) LOADER: a CIBC CAD-hedged CDR on a US company carries its underlying's beta (cdr.BETA_FROM_UNDERLYING, 31 receipts checked against CIBC's CDR Directory, T2, retrieved 2026-10-06); on production every no-beta holding was such a receipt (2 of 6 users). Other receipts in the price map are not covered and stay without a beta. SIDE EFFECTS, measured on a test book through the real engine (tests/invariants/test_cdr_beta_side_effects.py): late_cycle_trim and deteriorating_outlook_trim now fire on a covered CDR in a registered account (they stood down for lack of a beta) and still stand down on a taxable winner; recession_risk_highbeta does not fire (it also needs a Deep Score, which a CDR lacks); an ADD of a covered CDR is now judged against a declared drawdown limit instead of listed as unjudged. (d) GOAL RISK: the Strategy report's callout no longer picks a worst case over market-wide rows whose value-after is not stated; it says the shortfall cannot be stated and names the holdings left out. (e) ONE RULE FOR AI TRADE VERBS: signal_engine.ai_action_shown — a model SELL, TRIM or ROTATE stands only when the engine raised a reduce for the ticker, and never as a stronger verb (an exit where the engine raised a trim is shown as the engine's TRIM; SELL vs ROTATE shows the engine's; the model's verb is kept as provenance); matched per (ticker, account) slice, since the engine raises a trim on the slice it allocates it to — a sale on another slice is a review naming where the engine acted; a model ADD/BUY of a name the engine is reducing is HOLD (buys are otherwise ungated: fund and idle-cash advice needs them); an all-cash book is cash_only on the report as on the page (one decider, _stress_basis); a ValueError inside the Tax audit is a 500 unless it is the builder's TaxAuditNoBook (the first version keyed on the rank-only HOLD's rule name, which summarise_signals can hide behind a stronger HOLD); the Tax audit prompt prints the signal engine's verbs, not auto_recommendation's, and labels an investor override as theirs.
• 1.15.0 (2026-10-06): WHAT THE FUNDS COST IS READ ONCE, IN PERCENT, AND EVERY PROJECTION DEDUCTS IT. book_fund_costs is the one MER reader: etf_fundamentals.expense_ratio is a FRACTION and the cost disclosure had published it as weighted_mer_pct unscaled (a 0.20% fund reached the prompt as 0.002) and weighted over fund value only; it is now a percent over the whole book with shares and cash at 0%, with a C$ estimate per holding and per account (MER only; the TER the dealer's NI 31-103 s.14.17 report adds is not included, and the report says so). Reach on production 2026-10-01: 2 of 6 users with holdings hold a fund with its MER on file. _policy_expected_return deducts the book fee (plus any declared advisory fee) via return_basis; the retirement lens carries the 90%-success spend, the fee basis and the FP Canada horizon.
• 1.14.0 (2026-09-30): FOUR FIGURES THE REPORT QUOTES WERE CORRECTED AT THEIR SOURCE (audit 2026-09-30). (a) STRESS TABLE (beta_shock_table): cash is carried unshocked and the loss is over the invested holdings only; each holding falls by its beta x the shock, beta clamped to [0, 3], each holding floored at zero; a holding with no beta takes the covered holdings' value-weighted average beta, never an assumed 1.0, and a book with no betas at all is labelled unadjusted. (b) CRISIS REPLAY AND CVaR (_historical_stress): US-dollar holdings are converted to Canadian dollars at the same day's USD->CAD close before any return is taken; a US holding with no FX history is excluded and named, never priced as if it were Canadian. (c) PERFORMANCE: under one year of history nothing is annualised (GIPS 2020, 2.A.12) and the prompt is given cumulative figures for the period instead; a benchmark whose first close is more than 7 days after the first transaction is not compared; the dollar gap treats the client's dividends as reinvested in the index from the day received, and it measures a gap, not skill. (d) MARGINAL RATE: the rate a taxable trim is estimated at is derived on every read from the client's province and income band, computed from CRA's 2026 brackets at the band midpoint, instead of a snapshot saved with the profile; a client near a bracket edge can differ from it.
• 1.13.0 (2026-09-29): A BREACH ALREADY SHOWN IS A QUESTION ABOUT THE POLICY. A declared policy breach led every report with the same REBALANCE, report after report, and nothing asked whether the policy still described what the client wanted. CFA Standard III(C), 'Updating an Investment Policy' (T0): an IPS is reviewed at least annually, and a client who holds an off-policy book is discussed with - the trade is made or the policy updated. _policy_review asks when (a) the book was outside THIS policy in the same class and direction in the report before, and every report back to breach_since, with the policy not saved since; or (b) the policy was last saved more than _POLICY_REVIEW_DAYS ago. Only reports stored after the policy was last saved count, so re-saving it starts the clock again; a report inside the band or with a failed lens ends the chain; an unknown save date triggers nothing; a failed history read is reported, not treated as no history. The question is appended to the breach action and printed in the policy panel of the report and the web Strategy page; it never suggests moving the policy to match the book. Also: a REBALANCE the model wrote itself is now REPLACED by the engine's, which carries the figures and every engine sentence; keeping the model's used to suppress them (0 of 4 stored breach reports were affected). Reach on production 2026-09-29: 7 users, 2 with a declared policy, 2 whose last two reports were both in breach; the owner re-saved his policy after his last report, so only one client's next report would ask.
• LIMITS OF THE POLICY REVIEW. (a) Reports are generated on demand, so 'already shown' means one earlier stored report, not a period of time. (b) Only the report asks; the Today card still shows the rebalance every day without the question, because its path must not read report history. (c) It does not record the client's answer: re-saving the policy is the only acknowledgement it can see.
• 1.12.0 (2026-09-29): A CLIENT CAN DECLARE A SECTOR LIMIT, AND A LOOSER LIMIT IS SAID. The house limits (45% in one sector, 25% in one name) had one client override, the single-name limit, and it was honoured even when looser than the house one, in silence, against the code's own comment that a client may only tighten. Now profile_max_sector is declared beside profile_max_position, and signal_engine.concentration_limit is the one reader of both: a declared limit replaces the house one, tighter or looser. A looser one is a departure from the house view (CFA Standard III(C), Addressing Unsolicited Trading Requests, T0: discuss, explain, record - neither refuse nor silently accept), so while the book sits above the house level the report states it, once per sector or name: the weight, the house limit and the declared one (concentration_departures, printed by the report and the web Strategy page). Not as a per-holding HOLD: summarise_signals keeps one HOLD per holding, and a quality HOLD (strength up to 72) would have hidden it, or it theirs. The overweight test, the fund-first insertion, the contribution plan's sector line and the contribution dependency follow the declared limit; the fund-breadth rule stays at the house level because it describes an instrument, not a client. Reach on production 2026-09-29: 7 users, 5 with an advisor report, 3 whose largest sector is above 40% of holdings, 2 above 45%; 1 with a looser single-name limit already honoured in silence (50 against 25). 0 with a declared sector limit, because the field did not exist.
• 1.11.0 (2026-09-29): A DECLARED CASH RESERVE IS OUTSIDE THE ALLOCATION POLICY. The allocation lens added every declared cash item to the cash class, so a savings account and an emergency fund counted as money the policy could deploy, and a cash-over breach proposed moving money out of them. Liquidity needs are the first client constraint a policy is written under (CFA Standard III(C), Standards of Practice Handbook, T0). The client now declares a reserve in dollars (profile_cash_reserve, read by assetmix.load_reserve and by nothing else); assetmix.compute_mix removes min(reserve, cash) from the cash class AND from the base every percentage is a share of, so drift, the policy trade, the contribution plan, the Today card and the entitlement preview follow without re-deciding. A reserve larger than the cash on file is reported as a shortfall and is never made up from a GIC or a holding; the contribution plan rebuilds a short reserve before it invests anything. With NO reserve declared nothing moves: the value is unknown, not zero, and where a cash-over breach draws on savings the client entered the engine says how much of the cash that is and where to declare a reserve. Reach on production 2026-09-29, before code: 7 users, 2 with a declared policy, 1 with declared cash items, 1 whose leading action moved money out of them. Moves no published number until a client declares a reserve; 0 of 7 had one on the day it shipped, because the field did not exist.
• LIMITS OF THE CASH RESERVE. (a) It is DECLARED, never inferred: not from an item named Emergency, and not from emergency_fund_months, which cannot be turned into dollars without an expense figure nothing collects. A client who declares nothing gets the old arithmetic and a question. (b) It is taken from the cash class as a whole, idle brokerage cash and declared items alike; the engine does not say WHICH account holds it. (c) [Fixed in 1.12.0: the years-to-policy figure used to assume the reserve-rebuilding year repeated; only year 1 rebuilds it now.] (d) The retirement pool and the per-ticker rebalance planner do not read the reserve: neither includes declared net-worth cash. (e) CORRECTION to 1.10.0 limit (e): the 40 and 45 sector figures are two levels by design (stop adding at 40, trim above 45, signal_engine.SECTOR_CEILING_PCT), not three thresholds that should be one number.
• 1.10.1 (2026-09-29): CORRECTION - FIGURES PUBLISHED ABOUT THE OWNER'S BOOK IN 1.9.0 AND 1.10.0 WERE WRONG, AND THE ENGINE WAS NOT. They were taken from a book assembled by hand rather than from the engine: it priced holdings from the stock table only, which missed his fund holdings, and read cash from a table that does not hold it. It came out at C$72,038, 100% equity and 80.0% Technology. The engine's own drift block says C$122,094 - equity C$86,557 (70.9%), nothing in fixed income, and C$35,537 (29.1%) in cash-class assets - with Technology at 71.0% of holdings. So the published statements that a year of contributions reaches his policy, and that his breach was equity over target, were false: his breach is CASH over target by 19.1 points, the trade that closes it moves C$23,327 out of cash and requires no sale, and contributions alone take 4 years. The entries above are corrected in place. No shipped function changed: each reads the engine's blocks, so what the product computes was right throughout. What was wrong was what was SAID about one book, in this register, in three docstrings and in advice given to its owner.
• A FINDING THE CORRECTION EXPOSED, NOT YET BUILT: the C$35,537 of cash-class assets is two declared net-worth items - a savings account of C$25,500 and one named 'Emergency Saving' of C$10,000. The allocation lens counts both as cash available to the policy, so the rebalancing trade proposes moving C$23,327 'out of cash' on a book whose only other cash is C$37. An emergency reserve is a liquidity constraint, not an allocation to be optimised (CFA Standard III(C) requires the client's constraints to be considered before a recommendation). Nothing in the engine separates reserved cash from deployable cash, and the profile's emergency_fund_months is read by the prompt but by no rule. Reported for the owner to order; not fixed in this change.
• 1.10.0 (2026-09-29): THE REPORT SAYS WHERE THE NEXT CONTRIBUTION GOES. For a client still saving, what they are about to add outweighs what they hold: on the owner's plan 91.2% of the projected pot at retirement (C$1,612,222 of C$1,768,621, on the engine's own holdings total) is contributions not yet made. The engine already said how LONG contributions take to dilute a concentration (_compute_contribution_dependency); nothing said WHERE the money should go. The premise this work started from - that contributions were absent from the advisor - was wrong and is corrected here: the dilution horizon existed, the allocation did not. REACH, measured on production: 7 users -> 6 with holdings -> 1 with an annual contribution on file -> 1 with a declared policy as well. This is capability for one book today and is stated that way.
• THE CONTRIBUTION SPLIT IS AN IDENTITY, NOT A MODEL. After a contribution C the book is T + C; each class's target in dollars is its policy weight times that; what a class needs is its shortfall to that figure, never negative; C is shared in proportion to need, and a class already above target gets nothing. The needs sum to exactly C when no class is above its new target. NO RETURN IS ASSUMED AND NONE IS CLAIMED: growth is ignored, which makes every horizon conservative. Nothing is sold. On the owner's book as the engine measures it (C$122,094: equity 70.9%, cash-class 29.1%; policy 80/10/10, C$60,000 a year) the split is C$45,871 to equity, C$14,129 to fixed income and nothing to cash; contributions alone take 4 years to reach the policy, because cash sits above its target; Technology is 50.3% of the whole book and would be 33.8% if the equity money holds none of it, or 35.7% through the first screened fund. No external convention is borrowed because none is needed - the hand calculations in the test file are the check.
• THE TRADE AND THE CONTRIBUTION ARE TWO ROUTES TO ONE POLICY, and the report stated only the one that sells. The engine-enforced breach action already said 'direct new contributions here first' - in words, with no amount and no horizon. It now states the contribution route beside the trade in the same figures: where a year of contributions reaches the policy it says so, and where it would take longer it says how many years and that the trade closes the rest, rather than offering a slow route as an alternative.
• LIMITS OF THE CONTRIBUTION PLAN. (a) It needs a declared policy; with none it allocates nothing and asks for one. (b) It answers the ASSET-CLASS question and the sector question; it does NOT say which ACCOUNT the money goes into - registered room is reported elsewhere in the same report and is not re-derived here. (c) The contribution is assumed level at the figure on file. (d) Where the policy holds a class at 0% that the client owns, no horizon is stated, because adding money never removes a holding. (e) THREE THRESHOLDS NOW DESCRIBE 'CONCENTRATED' and they are not the same number: _OVERWEIGHT_SECTOR_PCT is 40, while _compute_contribution_dependency's target and the prompt's trigger are 45. This change uses the first and leaves the other two where they were; they should be one number, and which one is a decision for the owner.
• 1.9.0 (2026-09-29): THE FUND HALF OF THE DIVERSIFIER MENU IS NOW SCREENED AND MEASURED. Single stocks have always come from a screen over the scored universe. Funds came from the prompt line 'ETFs may come from your general knowledge' - the model's memory - while 245 scanned funds sat in etf_fundamentals that the candidate screen never queried. Measured on production before any code: 67 stored reports -> 49 carrying diversifier recommendations -> 245 recommendations -> 185 single stocks and 60 funds; of the 60, 23 were VXUS and 16 were VUG, which are the tickers the prompt itself used as examples, and VUG is 57.75% Technology by its stored sector weights while being recommended to diversify technology. The owner's own latest report was 5 single stocks of 5 on a book 71.0% Technology by the engine's look-through. The prompt now names no fund ticker at all, and a gate enumerates that as a class.
• THE FUND SCREEN REUSES DECIDERS THAT ALREADY EXISTED RATHER THAN CHOOSING NUMBERS. Sector weights must be known (unknown is not offered as a diversifier). Asset class is assetmix.classify_holding, because the stored data gives bond funds equity-style sector weights. The quality floor is the fund score's own top tier. And the 40% at which this report calls a client's book concentrated is the same 40% above which a fund cannot be offered - in the client's overweight sector, or in ANY sector, since a single-sector fund swaps one concentration for another. On the live universe of 2026-09-29: 245 funds -> 63 with no sector weights -> 7 not equity -> 112 below the quality floor -> 14 concentrated in the overweight sector -> 7 narrow -> 42 eligible.
• TWO DESIGNS WERE MEASURED ON LIVE DATA AND DISCARDED, and both are recorded so neither is rebuilt. Ranking by the book's post-add effective number of sectors SATURATED: the top 25 funds all scored 1.80-1.81, so the order was noise and was led by covered-call utility funds. Ranking by weight in the overweight sector ALONE put XLE - 100% Energy - first, and the engine's own text called it a broad fund. The breadth rule above is what that second failure produced.
• _SAME_EXPOSURE_L1_PP = 5.0 is a DECISION, taken from a measurement and not fitted to any outcome. It shapes only which screened funds the prompt is shown. Trackers of one index sit 0.1-1.7 points apart in summed sector weight (IVV/VOO 0.1, XIC.TO/ZCN.TO 0.8, TTP.TO/XIC.TO 1.7); funds that are genuinely different sit at a median of 53.5 across all 861 eligible pairs. Without it the first broad menu was five trackers of the Canadian composite. The short menu is also split across account currencies, because the report tells the model to deploy an account's cash without converting it.
• WHERE A SECTOR EXCEEDS 40% AND NO SCREENED FUND WAS RECOMMENDED, THE ENGINE PLACES ONE FIRST. It is inserted after the model has written, because a prompt instruction is a request; it carries NO position size, because none was computed; and the model's own picks are kept behind it. Every fund recommendation, inserted or chosen, states its measured weight in the overweight sector, or that it was not measured, or that it is itself concentrated there and does not diversify it.
• LIMITS OF THE FUND SCREEN, stated rather than left to be found. (a) Coverage: sector weights are on file for 182 of 245 funds, so 63 cannot be offered however suitable. (b) The quality floor inherits the fund score's trailing-return component - 35 of 100 points, 50 for a growth objective - so the menu leans toward funds that have done well; it is a floor and not the ranking key, but it is not neutral. (c) The measure is HOLDINGS-BASED: it says what a fund owns, not how it moves with the book. Only 13 funds carry price history, so the return-based effective-bets measurement used for single stocks cannot run for them. (d) It addresses SECTOR concentration only: bond and cash funds are excluded by design, and the asset-class policy breach is the allocation lens's job. (e) NO FORWARD CLAIM is made - no return is stated or implied for any fund, and nothing here is validated (CFA Standard V.A).
• 1.8.0 (2026-09-26): THE ADVISOR NOW READS THE RETIREMENT INCOME PLAN, AND THE CLIENT CAN SWITCH IT OFF. advisor_engine imported retirement_sim (the goal Monte Carlo) and NEVER decumulation - zero references in the module. So the report could reason about reaching a target BALANCE and had nothing to say about the INCOME that balance must produce: sustainable spend, CPP/OAS timing, the RRIF minimum that forces withdrawals from 71, and the OAS recovery tax those withdrawals can trigger. The goal lens was answering a different question and standing in for this one. The lens reads api.retirement_api.plan_for_user - the SAME assembly GET /retirement/plan serves - so a retirement figure in the narrative cannot contradict the Retirement panel the client is reading; the route's own copy of the steps was extracted into that function and into retirement_ages in the same push, and a gate fails the build if advisor_engine ever calls build_plan directly.
• REACH, measured on production 2026-09-25 BEFORE building: 7 users -> 2 with birth_year (the plan cannot be dated without it) -> 2 who also have retirement_age -> 0 with ret_spend_target -> 5 who have ever generated an advisor report. HARM SET: 2 users have a plan AND read advisor reports. This adds a lens for 2 of 7 and MOVES NO PUBLISHED NUMBER - decumulation.py is byte-identical to the deployed commit and no existing payload key changes value.
• NOBODY HAS SET A SPENDING TARGET - 0 of 7 - so the gap analysis is dark for every user, and that fact shaped the design rather than being a footnote. With no target there is NO gap: gap_cad is null and never 0, spend_target is listed in missing_inputs, the prompt is forbidden to assume a spending level or to call anyone on track or behind, and both renderers say the target is absent instead of showing a verdict. A default would be the model telling a client they are on track against a number nobody chose (CLAUDE.md 9, unknown is never a number). Naming the missing input is also the only mechanism that ever gets it filled in.
• THE CLIENT CAN OPT OUT (owner request, 2026-09-26), and the switch is a DEDICATED setting rather than 'leave birth_year blank'. birth_year is in MINIMUM_SUITABILITY_FIELDS and sets years_to_retirement, which drives risk capacity for the WHOLE report - using it as the off switch would silently degrade every other piece of advice to buy silence on one lens. ret_in_advisory is read in exactly one place (advisory_includes_retirement), shared with the save route so a form that omits it cannot switch advice back on; it is checked BEFORE anything else, so an opt-out never surfaces as 'we need your birth year'; and it defaults to ON for everyone who predates it. It suppresses the ADVISORY lens only - GET /retirement/plan ignores it, because the panel is where the switch lives.
• THE PROJECTION IS NOT VALIDATED (CFA V.A). It is a projection under stated assumptions - pre-tax, in today's dollars, net of the book's fees when they are known (2026-10-06; the 2026 FP Canada Projection Assumption Guidelines state that management fees must be subtracted to obtain the net return) and labelled gross when not. It is not validated, not backtested and not predictive, and no part of the lens, the prompt or either renderer may describe it as such; a gate asserts those three words appear near the lens only inside the sentence that denies them.
• 1.7.1 (2026-09-25): THE DISCLOSURE'S OWN REASON WAS RESTATED, BECAUSE IT HAD BECOME FALSE. The Growth-pillar note said the pillar's sign was untestable because price history covered 88 of 1,023 scored names. The bounded universe backfill closed that gap (2,786 of 2,792 scored names; 988 of the 1,059 scored on 2026-06-08), so the remaining blocker is the 126-day window closing 2026-10-12, not absent data. A disclosure that keeps citing a resolved obstacle overstates the limitation as surely as omitting it would understate it.
• 1.2.0 (2026-09-24): TWO DEPENDENCES THE RECOMMENDATION RESTS ON ARE NOW DISCLOSED BY THE ENGINE RATHER THAN ASKED OF THE MODEL (CFA Standard V.B). (a) GROWTH-PILLAR DEPENDENCE: a recommended single name whose Deep Score owes the Growth pillar more than an evenly-scoring name would (above PILLAR_MAX['Growth'] / 100 = 25%) carries that share, in its own `why`, with the two findings that bear on it. Measured on the production scan of 2026-09-24 over 2,577 scored names: the Spearman between the shipped score and the score with the pillar removed is 0.9700, but 45 of the top 50 names are in that set only because of the pillar and 6 of the 8 the live screen surfaced were Growth-lifted, mean 20.6 of 25 against a universe mean of 12.5. (b) SINGLE-NAME CONCENTRATION: the share of the book held as individual securities rather than funds, against the 20% default budget, with its sources. NEITHER CHANGES A SCORE, A RANK, A PICK OR A SIZE - the same names are recommended in the same order at the same weights; what changed is that the report says what they rest on.
• The Growth pillar is disclosed, NOT re-weighted. Until 2026-09-25 the reason was missing data: price_history covered 127 tickers of which 53 were held, so a forward-return test was n=88 and selection-biased toward the book. The bounded universe backfill closed that gap — 2,786 of the 2,792 scored names now carry daily closes, and 988 of the 1,059 names scored on 2026-06-08 span that scan to today. The remaining blocker is TIME: that cohort's 126-day forward window closes 2026-10-12. Until it is graded, re-weighting the composite on the literature alone would substitute one unvalidated prior for another.
• The single-name budget is DISCLOSED, NOT ENFORCED. No trade is blocked, no recommendation is resized and no plan is rejected for breaching it; the report states the figure and says so explicitly.
• 1.3.0 (2026-09-24): A POLICY BREACH NOW NAMES BOTH SIDES OF ONE TRADE, IN DOLLARS, WITH WHAT FUNDS IT. _enforce_policy_first led with breaches[0] - the single worst class - and stated the action in percentage points with no amount, no funding source and no tax consequence. On a book 24.2pp over in cash and 20.0pp under in fixed income the client was told 'Reduce cash toward 5%' and never told where the money goes; the destination WAS the second breach. Measured on production 2026-09-24: 6 users carry settings, 2 have a declared policy, and 2 of those 2 are in breach - BOTH holding 0% fixed income against a 20% target while over on another class (neha equity 100.0% vs 75%, vishal cash 29.2% vs 5%). Every class now moves to its declared target so the legs balance by construction, and the funding split is reported: vishal's C$242,000 rebalance is funded entirely from cash and realises nothing, while neha's C$109,250 requires selling equity.
• THE TAX ON A REBALANCE IS NOT ESTIMATED, only the funding split. Which lots in which accounts are sold decides it, and _policy_rebalance_trade is handed neither, so it reports how much requires a disposition and stops there rather than inventing a plausible figure. Money the look-through could not classify is excluded from the trade and named, never absorbed into a class.
• VANGUARD'S 200bp-TRIGGER / 175bp-DESTINATION REBALANCING BAND WAS CONSIDERED AND DECLINED (CLAUDE.md 14, cargo-cult test). It is derived on target-date funds rebalanced at scale, where the question is when to trim a portfolio NEAR its targets. That precondition fails here: the declared band is 5pp and the measured breaches are 20-25pp, four to five times outside it, so tuning the trigger would move nothing on any live book. The band remains the one the client declared, and every leg targets the declared policy rather than a band edge.
• 1.4.0 (2026-09-24): CAPITAL-GAIN STAGING WAS COMPLETE, CORRECT AND DEAD. _annual_gain_budget_cad reads investor_profile['annual_gain_budget_cad'] and _gain_staging_note turns it into advice; both were tested. The key appeared in exactly two places in the repository - its reader and its reader's test - with NO writer in src/, web/, ios/, android/, JSON or HTML, so the note had never fired on any book and could not have. Three separate breaks, of which the saved plan named one: (a) no KYC field, so no client could state a budget; (b) no mapping from the stored setting profile_annual_gain_budget into the profile key the engine reads; (c) TWO of the four live callers of apply_tax_and_allocation passed no investor_profile - api/portfolio._bundle (web + mobile) and intel_agent (the AI chat) - so even a stated budget would have reached the Strategy report and not the other three surfaces showing the same signals. All three are closed and the call sites are now enforced as a CLASS by walking the call graph, so a new surface must pass the profile or fail the build.
• GAIN STAGING CHANGES NO PUBLISHED NUMBER TODAY, and that is the honest statement of what it is: measured on production 2026-09-24, 6 users -> 4 carry a positive unrealised gain in a capital-gains-taxable account (the registry's own capital_gains_taxable field decides which; C$19,300 / C$99,695 / C$24,756 / C$3,389,870) -> 0 have a budget on file. Until a client states one, _annual_gain_budget_cad returns None and stages nothing by design - an absent budget is UNKNOWN, never zero and never unlimited. This ships capability, not a recovered loss.
• The staging advice rests on CRA's own T4037 Capital Gains guide (2025 ed., retrieved 2026-09-24), which states a capital gain is reported in the calendar year of the disposition - which is what makes 'split it across two tax years' a real instruction rather than folklore. The cargo-cult precondition HOLDS here, unlike the rebalancing band declined in 1.3.0: four live books carry unrealised gains that a single-year realization would treat very differently from two.
• 1.5.0 (2026-09-24): THE PROPOSED POLICY NOW REACHES THE PANEL THAT ACCEPTS IT. The report told clients 'your questionnaire proposed X - accept it in Investment Policy', and GET /assetmix, which feeds that panel, did not carry X: the client arrived at an empty form defaulted to a house 80/15/5 and had to retype three numbers from memory. The route now returns `proposed` from the SAME decider the report uses (_proposed_policy_from_questionnaire), only while no policy is on file, and the panel prefills the editor from it - PREFILLED, NEVER APPLIED, so the policy on file is still one the client deliberately saved (CFA III.C). Measured on production 2026-09-24: 6 users -> 2 with a declared policy -> 1 with a proposal no surface could act on (holding 100% equity against a proposed Conservative 45/50/5) -> 3 who have answered nothing. assetmix is absent from contract.py and has no iOS/Android consumer, so the frozen mobile clients are untouched.
• THE ALLOCATION LENS STILL DOES NOT REACH MOST CLIENTS, and that is an adoption gap rather than an engine gap: of 6 users with settings on 2026-09-24, 2 have a declared policy, 1 (demouser) has a Conservative 45/50/5 mix PROPOSED by the questionnaire that has never been accepted while holding 100% equity, and 3 have answered no questionnaire at all. GET /assetmix does not carry the proposal, so the panel where a client would accept it cannot show it.

monitoring: LOGGING — picks recorded since 2026-09-10, none matured; not yet graded · metric: forward return of diversifier picks vs SPY, by cohort · log: advisor_picks

validated by: tests/invariants/test_advisor_*.py, test_fund_lookthrough_invariants.py, test_stress_replay_invariants.py, test_risk_questionnaire_reaches_the_advisor.py, test_growth_and_concentration_disclosure.py — absence never a number, registered-first allocation, AI figures reconciled to the engine, fund fold-through on both spellings of absence, and the two engine-enforced disclosures: the threshold is the pillar's own weight share, an unmeasured share is silence and never 0%, the candidate whitelist carries the measurement through to the report, and no disclosure makes a forward claim the score has not been validated for (CFA V.A), each proven red by 16 entries in tests/parity/test_gate_injections.py

CompoundWise internal · not investment advice · generated from data/model_register.json (register 2.0.0, 2026-09-23).