Pattern Inventory Audit

Experienced architects are fast because they recognise that a new problem is an instance of an old one. The same mechanism produces their most confident errors, and those errors are invisible from the inside: the analogy that fires fastest feels like insight. Checking one pattern's preconditions against one situation catches the case in front of you. It does not tell you which analogy you reach for too often, because that is a property of your whole record rather than of any single decision.

A pattern inventory audit measures the frequency. Count the priors you argued from across your last twenty written decisions, and whichever appears in more than about a third of them is a candidate for over-application.

Why it matters

Over-application is systematic, not random. It concentrates in one dimension — write volume, team size, consistency requirement, whether an operator is awake at 3am — because the prior case had a particular shape and you keep meeting situations that differ in the same way. That makes the finding actionable: not "stop pattern-matching", but one named precondition to check in a specific class of decision.

Nobody else will tell you either: colleagues read your conclusions rather than your priors, and a confident analogy from the senior person in the room ends the discussion.

Implementation patterns

• Collect twenty written decisions you authored or strongly influenced - decision records, design documents, directive review comments - and for each write the one sentence naming the prior case you argued from. It is usually implicit: "this is the same shape as the ingestion pipeline at my last company". About 2 hours in total.
• Count the priors. Over 20 decisions, 7 or more occurrences of one prior is the threshold worth investigating.
• Write the three preconditions the original case satisfied — the properties that made the solution work there, not the symptoms it presented.
• Check each precondition against every application and count the misses. Seven uses with a precondition failing in three of them is your answer.
• Attach the preconditions to the pattern in your own notes, so recall drags the check along and the check costs ten seconds.
• Ask a peer "what do I always say?" It takes 5 minutes and colleagues answer accurately and instantly, and it covers what the written record misses.

Industry example

The best-documented false analogies are the ones where a published architecture was copied without its preconditions. Microservice decompositions modelled on organisations with hundreds of engineers and mature deployment automation have been reversed repeatedly by teams of fifteen, and the public write-ups of those reversals - including a widely discussed 2023 account of a video-monitoring pipeline consolidated back into one process for cost reasons - describe the same mechanism: the pattern was sound where it came from, and the precondition that made it sound was team and traffic scale. The architect who built three of those will not notice, because each felt like the obvious reading of the problem. The audit finds it, because the prior appears seven times in twenty records.

Failure scenarios

• The audit covers only big decisions. Written records hold what was important enough to write down; the high-frequency analogies live in standups, code review and corridors, and are absent. The peer question is not optional.
• Finding a fashionable answer instead of a specific one. "I over-index on scalability" is not a finding; "I apply an event-log pattern from a system with three producers and one consumer to situations with many consumers and no schema owner" is.
• Treating the result as a prohibition and abandoning a pattern that is right most of the time, which trades speed for nothing.

Trade-offs

The audit costs about 2 hours plus the discomfort of reading your own reasoning back, and buys one named check in one class of decision - cheap, because the error it finds is invisible until a design is built. The cost that matters is social: publishing the finding makes you more useful and spends a little of the authority fast pattern-matching earns.

When not to use it

With fewer than about ten written decisions there is nothing to count; the honest substitute is the peer question. In a domain you have just entered, over-application is not yet the risk — under-application is, and the time is better spent building the pattern library.

Interview question

Q: "Which architectural analogy do you reach for too often? Assume you do not already know, and tell me how you would find out."

What a strong answer covers: a procedure over their own artefacts rather than an opinion; an explicit frequency threshold; preconditions written as properties rather than symptoms; the audit's blind spot and the peer question that covers it; and attaching the check to the pattern rather than abandoning it.

Quick check

Quiz: How does this differ from checking a pattern's preconditions before applying it? The precondition check tests one pattern against the situation in front of you; the audit measures how often you invoke each prior across your whole record, which is the only way to find the one you over-apply.

Flashcard: What threshold marks a prior as over-applied? Appearing in more than about a third of your last twenty written decisions — 7 or more — with at least one precondition failing in several of those uses.