Actionable insights — Portfolio Update March 2026

1. Sort a portfolio by why it survives, not by sector

1. Take every holding and ask one question: what specifically stops software from doing this? Discard the sector label while you answer.
2. Sort the answers into durable categories. This issue uses four: demand that predates technology (food, medicine, status, entertainment), regulated human judgment (law requires it, and a person must sign), irreplaceable physical assets (permits, land, networks, decades of construction), and embedded niche software (encoded local rules the buyer cannot re-derive).
3. Check the balance across categories — a book concentrated in one bucket is one argument, not a portfolio.
4. Any holding you cannot place in a bucket has no articulated defence, which is itself the finding.

• A bucket rationale written after the purchase. The test only has value if a holding could fail it and be sold.

2. Instead of hiding from a technology, own what it consumes

1. Write down the physical inputs the technology cannot function without — power, land, permits, transport, specialised equipment.
2. Find the owners of those inputs, and check the barrier is time and permission rather than capital alone.
3. Confirm demand is already contracted rather than projected: look for signed offtake or supply agreements with the technology's own leaders.
4. Prefer this to buying the technology itself when the input is scarce and the technology's winners are unknown.

• Regulated returns. Where a utility regulator caps the price of the scarce input, the scarcity accrues to the customer, not to the owner.

3. Use cost-of-failure, not task complexity, to judge automation risk

1. Estimate what a single failure costs the buyer — in money, time, liability and reputation.
2. Compare that with the fee being paid. A large ratio means the buyer is purchasing reliability, not the task.
3. Ask separately whether a regulator requires a human or a physical procedure in the loop; that converts a preference into a rule.
4. Rate automation risk low only when both hold: severe failure cost and a physical or regulatory requirement.

• Regulatory modernisation — a rule change that permits synthetic control arms or decentralised trials shifts the second half of the test.

4. Price the flight to safety — the "obviously undisruptable" name is where the crowd is

1. Identify the businesses a prevailing fear designates as safe, then look only at their multiples.
2. Benchmark those multiples against the company at the centre of the fear itself. When safety costs more than the epicentre, the fear is fully priced.
3. Treat the resulting multiple as the risk: growth rates in the "safe" names are usually a fraction of what the multiple implies.
4. Fund positions in the derated side of the same fear out of the crowded side.

• The multiple gap closing from the wrong direction — the epicentre re-rating up rather than the safe names de-rating.

5. Compute an expected return from two disclosed numbers before comparing anything

1. Take the portfolio's (or the stock's) forward P/E and invert it to get the earnings yield: 100 ÷ forward P/E.
2. Add your estimate of annual EPS growth. Terry Smith's rule of thumb: expected return = EPS growth + earnings yield.
3. Run the same calculation on the index for a like-for-like comparison, and state both growth assumptions explicitly.
4. Sanity-check the result against a doubling time (72 ÷ return) before believing it.

• The growth assumption doing all the work. The earnings yield is observable; the EPS growth is a forecast, and the answer is only as good as it.

6. Track intrinsic value separately from price, and treat the gap as the position

1. Measure the growth in the portfolio's underlying economics — earnings, owner's earnings or free cash flow — on a fixed schedule, independent of the share prices.
2. Chart it against the price series. A rising value line with a falling price line is a widening opportunity, not a broken thesis.
3. List the market's stated fears explicitly, then judge each against the companies you actually hold rather than the market as a whole.
4. Act on the divergence by adding, but only where the value line is still rising.

• The value line flattening. The whole argument depends on it continuing to rise; a stalled value line makes the price right rather than wrong.

7. For embedded software, test the local-knowledge layer rather than the code

1. Ask what the software actually encodes beyond its functionality: jurisdiction-specific rules, workflows, and two decades of accumulated data.
2. Estimate the annual cost to the customer as a share of their budget, and the consequence of an outage. Cheap plus critical is the durable combination.
3. Check tenure — how long the average customer has run it — as the proxy for how much local knowledge is baked in.
4. Only then consider whether a general-purpose model could replicate it; usually the barrier is the knowledge, not the code.

• New-customer wins rather than retention. The installed base is defended by inertia; the growth case needs someone to still be choosing it.