Your fastest answer in design reviews keeps coming from a technology you have not deployed since 2021. What test separates a skill that has become a foundation from one that has become a liability, and what does keeping a skill current actually cost?

What is being tested

Whether you treat your own expertise as an asset that can expire. Most advice on architectural learning is about acquisition: what to read, what to learn deeply. The harder half is deciding what to stop knowing, because currency is a recurring cost paid out of a fixed weekly budget, and an architect who never retires anything ends up shallow everywhere.

The test that separates the two

A foundation is an invariant. A liability is an interface.

Everything you learned from a technology falls into one of two piles. The first pile is behaviour that holds wherever the same physics applies: write amplification in a log-structured store, why a queue's latency goes vertical near full utilisation, what a replica does when the leader is partitioned but alive. That knowledge still predicts behaviour in systems you did not learn it on. The second pile is surface: flag names, operator semantics, console layouts, quota tables. It predicts nothing outside the product, and the product changed.

Two falsifiable checks, usable in an afternoon:

1. Transfer check. Take the last three times you used this knowledge. Was each conclusion still true if the vendor were swapped? If yes, it is a foundation. If the answer depended on the product's specific behaviour, it is interface knowledge and you are asserting something you last verified years ago.
2. Correction check. In the last three design reviews where you invoked it, did someone with current hands-on experience have to correct a detail? Two corrections out of three is the signal. The danger is not that the knowledge is stale; it is that it is still fast, so it arrives before the slower, correct answer and other people defer to it.

What currency costs, in hours

Currency in one technology means running it, reading its release notes and watching its issue tracker: roughly 2 hours a week, so on the order of 100 hours a year per area. On a realistic 5 to 6 hour weekly budget that supports about three deep areas plus shallow awareness of many. A claim to be current in eight is a claim to spend 800 hours a year.

The trade-off is explicit: each area you keep is an area you cannot add. The bill arrives as a wrong recalled number stated confidently in a meeting — a managed-service quota memorised in 2021 and quoted in 2026, a price per GB that moved twice, a limit the vendor raised. Nobody checks a number an expert says quickly.

The decision rule

Retire the interface, keep the invariant, and write the invariant down in your own words so recall does not drag the product detail along with it. Then replace the retired knowledge with a lookup habit: for anything versioned, priced or quota'd, the correct move is to open the current documentation in the meeting rather than answer from memory. Memory is for behaviour, documents are for numbers.

When this is the wrong answer

If you are the organisation's only operator of that technology in production, you do not get to deprecate it; the currency cost is part of the job until someone else owns it. A rarely used but high-consequence skill — reading a query plan, reasoning about durability settings — is worth keeping current even at a poor hours-to-use ratio, because the alternative is being unable to check someone else's claim.

Common weak answers

• "Keep learning everything; you never know what will be useful." This is the position that produces the shallow generalist. It ignores the fixed budget, and it is how 40 half-known technologies become indistinguishable from marketing knowledge.
• "Just learn fundamentals, not tools." Fundamentals without any current hands-on anchor drift into abstraction, and you lose the ability to tell whether a vendor's claim is plausible. The point is not to stop touching products; it is to stop claiming currency you are not paying for.