Sweeping for Signal

February 3
Sixty patterns. Seven categories. Four parallel agents. One question: which of these actually matter?
The Pattern Sweep 2.0 ran on a Tuesday, the first comprehensive audit since we’d crossed 50 patterns in the catalog. What we found wasn’t just new patterns — it was the beginning of a governance problem we hadn’t anticipated.
The scale question
When we started the pattern catalog, it was a handful of documented practices. Things we’d learned the hard way, written down so we wouldn’t forget. The Repository Pattern. The Service Layer. Verification First. Patterns that saved us time, prevented mistakes, made coordination possible.
Now we have sixty. Some are fundamental — load-bearing ideas that shape everything we build. Some are specialized — useful in narrow contexts, irrelevant elsewhere. Some might be duplicates of each other, or fragments of larger patterns we haven’t named yet.
The catalog had grown faster than our ability to curate it. Fortunately, it was time for our regular sweep (our new and improved pattern sweep!).
Four agents, parallel tracks
We’d learned from the TRUST-LEVELS sprint that parallel agents could cover more ground faster. The pattern sweep used four specialized roles:
The Usage Analyst tracked which patterns actually appeared in session logs. How often was each pattern referenced? Which ones guided real decisions?
The Novelty Detector looked for patterns that might be emerging — recurring solutions we hadn’t formally named yet.
The Evolution Tracker examined how patterns had changed over time. Were our original definitions still accurate? Had practice diverged from documentation?
The Meta-Pattern Synthesizer looked across the catalog for relationships — families of patterns, anti-pattern pairs, patterns that frequently co-occurred.
Forty-five minutes of parallel analysis. Results compiled. The inbox filled with findings.
Two true emergence candidates
The Novelty Detector found two patterns that kept recurring in session logs but weren’t in the catalog.
The first: Cascade Investigation. When debugging reveals adjacent issues, document and pursue them rather than patching the original symptom and moving on. We’d done this with the timezone drift, with the multi-tenancy audit, with half a dozen other investigations. The pattern was clear. We just hadn’t named it.
The second: Design Archaeology. Before redesigning something, investigate why it was built that way. Dig through old decisions, find the original intent, understand what constraints shaped the current state. We’d done this for the history sidebar, for the MUX object model, for several architectural questions.
Both felt like real patterns. Both had multiple instances in the logs. Both seemed genuinely useful to document.
But “feels real” isn’t a governance criterion.
The CIO’s decisions
The pattern sweep results went to the CIO for decisions. Not because the CIO has special pattern-detecting powers, but because someone needs to be accountable for catalog quality. Patterns added without scrutiny become clutter. Clutter obscures signal.
The response came back with clear reasoning:
Pattern-060, Cascade Investigation: Approved. Multiple instances across different contexts. Genuinely distinct from existing investigation patterns (which focus on single-issue depth, not adjacent-issue discovery). Add it to the catalog.
Pattern-061, Design Archaeology: Deferred. Only one clear instance documented. Track it as a proto-pattern. If it appears two more times before the March sweep, elevate it then.
The distinction mattered. Cascade Investigation had proven itself across multiple sessions, multiple problem domains, multiple months. Design Archaeology had one compelling example but might be a one-off rather than a recurring practice.
Better to wait and confirm than to clutter the catalog with aspirational patterns.
The family insight
The Meta-Pattern Synthesizer found something we hadn’t expected: our patterns cluster into families.
The Completion Theater family: patterns about ensuring work is actually done, not just marked done. The 75% Pattern, the Verification Pyramid, the Completion Matrix.
The Investigation family: patterns about understanding before acting. Five Whys, Audit Cascade, and now Cascade Investigation.
The Grammar Application family: patterns about using language tests on design decisions. The Grammar Test, the Colleague Test, the Category Error Check.
Eight families in total, covering about 70% of the catalog. The remaining 30% were either foundational (too basic to cluster) or specialized (too narrow to generalize).
The family insight suggested a new way to navigate the catalog. Not alphabetically, not chronologically, but by what problem you’re trying to solve. Worried about completion theater? Here are six patterns that address it. Investigating a bug? Here are four patterns for that context.
The scalability concern
The CIO flagged something that gave us pause: the sweep itself was getting complex.
Sixty patterns took four parallel agents forty-five minutes. By the end of the year, we might have eighty or a hundred patterns. The sweep methodology might not scale. We’d need either more agents, or smarter filtering, or a different approach entirely.
I’m starting to wonder what the practical limit will be.
This is the paradox of systematic methodology: the more patterns you document, the more overhead you create in maintaining them. At some point, the methodology for maintaining methodology becomes its own burden.
We didn’t solve this in the sweep. We noted it for future consideration. But the question is real: how big can a pattern catalog get before it defeats its own purpose?
What the sweep revealed
Coverage improved. Anti-pattern documentation went from 15.5% to 28.3% — not complete, but better. We’d been documenting what to do without equally documenting what to avoid.
One new anti-pattern made the catalog: Comment-Only Close, where issues get closed with a comment saying “this is done” but no evidence, no verification, no demonstration. We’d seen it. Now it was documented.
The pattern families provided organization. The emergence candidates gave us something to watch. The deferred pattern gave us a criterion for future sweeps: two instances before elevation.
The sweep didn’t revolutionize anything. It maintained. It curated. It kept the catalog honest.
The librarian’s work
Pattern sweeps aren’t glamorous. Nobody’s excited about auditing documentation. The work is quiet, methodical, unglamorous — reading old patterns, checking current usage, deciding what stays and what goes.
But without sweeps, catalogs become graveyards. Patterns documented and forgotten. Practices that drifted from their documentation. Names that no longer match what people actually do.
The sweep is the librarian’s work: not acquiring new books, but ensuring the existing collection remains useful. Weeding what’s obsolete. Reorganizing what’s grown. Making sure people can find what they need.
Sixty patterns later, the catalog is a little more honest than it was. That’s what sweeping accomplishes. Not revolution — maintenance. Not discovery — curation.
The next sweep is scheduled for March. By then, Cascade Investigation will have a track record. Design Archaeology might earn its place. The families might need restructuring. The scale question might need answering.
For now, the shelves are tidy. The signal is clearer than the noise.
