In December 2025 I had 18 frameworks. Today my operating system runs on 659 of them. The real number is well over 700 if you count the client work, the frameworks I built for other teams that aren't mine to publish, and the ones that haven't been catalogued yet.
I'm telling you this because I expected to plateau around 50.
The wrong assumption
When I started building frameworks systematically, I thought I was making a library. Pick a domain, document the methodology, file it under the right category, move on. Web design framework, check. Lead generation framework, check. Video production framework, check.
I figured I'd cover the major domains and be done. Maybe 50 frameworks total. Comprehensive enough to handle most of the work I do.
That's not what happened.
What actually happened
I built one video production framework. I thought that covered video. Then I started doing video work and realized the framework was the surface. Underneath it: audio-visual sync. Kinetic typography. Camera simulation. Color grading. Sound design. Mixing. Distribution format optimization. Quality gates between phases.
The single video framework became thirty.
The same thing happened with leads. I built one. Then I built fifty. Not because I padded the library. Because once I started actually working in lead generation at depth, every assumption I'd made at the surface revealed five more frameworks underneath it.
It happened with web design. With voice calibration. With federal contracting. Every domain I went deep on did the same thing. One framework became ten. Ten became thirty. The library kept growing because I kept finding work that needed to be named.
What compounding actually looks like
Compounding sounds abstract until you see what changes between version one and version thirty.
The first video framework produced silent animations with basic timing. That was it. You could make a clean visual sequence. No audio, no music, no transitions with intent. The output was professional but flat.
After thirty frameworks stacked together, the same starting brief produces something different. The voiceover gets recorded first, measured to the millisecond. Visual animations derive their timing from audio landmarks instead of guessing. Text doesn't just appear, it arrives with motion that encodes meaning. A word that drops carries weight. A word that scales carries revelation. Music ducks under voice automatically. Sound effects hit on the exact frame the visual transition fires. Color grading follows brand palette rules without being asked. The final export produces five distribution formats from one source.
Same brief. Different category of output. That's not because the model got smarter. That's because the system around the model got deeper.
And I still don't know how deep video goes. The deeper I go, the more I find.
Why standard research never finds this
Most people approaching a domain do standard research. What's the best practice? What are the tools? What does the workflow look like? That gives you a survey. A survey tells you what's visible.
The frameworks aren't in what's visible. They're in the gaps.
Standard research won't tell you that audio-first timeline construction is a separate framework from animation choreography. Both are obvious to a professional and invisible to the survey. Standard research won't tell you that lead qualification has fifteen distinct sub-protocols depending on channel, intent signal, and downstream handoff. Both are obvious in the work and invisible from the outside.
Gap analysis is different. Gap analysis asks: what should exist in this domain that doesn't? What's the AI getting wrong, and why is it getting it wrong? What does the practitioner know that the model doesn't?
Every gap is a framework waiting to be written down.
This is why the library kept growing past my expected ceiling. I wasn't running out of frameworks because I wasn't running out of gaps. The gaps were the work all along.
Every gap is a framework waiting to be written down.
Domains connect to other domains
Here's the part I didn't see coming.
Going deep in one domain doesn't just produce more frameworks for that domain. It opens doors to adjacent ones I wouldn't have reached otherwise.
Federal contracting led to compliance documentation, which led to AI governance frameworks, which connected to enterprise risk patterns I'd never have found by studying enterprise risk directly.
Web design led to lead generation, which led to email architecture, which led to voice calibration. None of those were planned. Each one revealed itself by going deep on the previous one.
It's not a list of domains I'm working through. It's a graph. Every node connects to others I can't see until I'm standing on it.
Peeling the onion
You have no idea how many layers there are until you start peeling.
That's the line I keep coming back to. Every domain I thought was small turned out to have ten more layers. Every layer I uncovered pointed at three more domains I hadn't considered. The framework count keeps growing because the territory keeps revealing itself.
I'm not running out of frameworks. I'm getting better at seeing where they are.
What this means
If you've ever wondered why your AI produces work that's competent but flat, this is the answer. The AI isn't the problem. The context around the AI is the problem. The frameworks are how you give it the context that's never been written down.
Most people stop at one framework per domain. That's the surface. The expert-level work lives ten frameworks deeper, in the gaps that standard research never finds.
The library is over 700 today. At this rate we could be past 2,000 within a year. But it's not really about the number. The number is almost beside the point. What I'm still trying to wrap my head around is that we had no idea it would get here this fast. That's why I'm writing this.
This library is mine. The methodology behind it isn't. The portable framework format I use, along with example frameworks and the tooling, lives in the open at github.com/framework-creator/framework-standard. The methodology for generating frameworks from your own expertise lives at howtoframework.com. Build your own.
Peeling the onion. That's the work.
Want to learn the methodology that built the library?
The systematic process for generating frameworks from your own expertise lives at HowToFramework. The portable file format and tooling are open source on GitHub.
Visit HowToFramework.com