Hi community. I just Wondered whether anyone else has come across this issue: I created a complete repo using the ICM structure, it's an agency style business. I've attached a pic of generally what my repo looks like. For the first few weeks it was working really great. I was able to ask it to generate invoices and proposals and contracts and by and large it was deterministic in nature just following the instructions from the context.md files as expected. But then I started to notice a deterioration in the output. And what would happen is if I wanted to add a custom item for let's say a proposal or an invoice, it would then start updating the config files and changing the workflow. Previous templates that were set up as desired were subtly changing over time as I was making requests for particular clients or particular contracts to include particular clauses. And now I'm in a situation where I feel like I'm correcting things more than I should be and my productivity is getting impacted. It seems like the integrity of my framework has deteriorated. I'm obviously a little bit cautious and worried about having to rework my entire repo, but I'm wondering if anybody has experienced this issue themselves and what steps, if any, they have put in to create some guardrails around this. I also feel like over time it's probably helpful to have a workflow that just cleans house full of clutter and unwanted files that tend to materialize over time as I work on the business. Any ideas, thoughts, or input much appreciated. Thank you.

Same poll every month, hit a button below and leave a comment arguing for your favorite! Also be like @David Vogel and yell at me if I didn’t mention your fav 😅

The 60/30/10 rule, and why the 10 is the part that matters least in the mix! When I first learned how to actually think about an AI build I was not thinking ratios, ICM change that. Sixty percent infrastructure. Thirty percent orchestration. Ten percent AI. And I’ll be honest, when I first heard it, I assumed the AI would be the big number. That’s the part everybody’s chasing, right? It’s the smallest one on the list. Once that clicked for me, it changed how I look at everything I build. Here’s how I understand each piece. The 60% is infrastructure: This is the foundation. Your folder structure, where your information lives, how it moves, the plain deterministic scaffolding that holds the whole thing up. None of it is glamorous. It’s the part people want to rush past because it feels like setup instead of real building. But this is the building. Get this part wrong and nothing you stack on top of it stays standing. Almost every time something I’ve built keeps falling over, I trace it back here. The 30% is orchestration: This is how it all moves. The workflow logic, the order of the steps, where the gates are, where your quality checks happen, how one step hands off to the next. The if this then that. This is where your actual thinking lives. The infrastructure gives you the shape. The orchestration is what makes the shape do something. The 10% is AI: This is the piece everybody obsesses over, and it’s the smallest slice of the whole thing. It’s the generation, the analysis, the part that runs at the very end once everything underneath it is already solid. When the ninety percent below it is sound, the AI looks brilliant. When it isn’t, there is no prompt on earth that saves you. So which matters more, the 60 or the 30 I went back and forth on this for a while, trying to decide whether the structure or the logic carried more weight. I finally realized that’s the wrong question. The 60 and the 30 are both the real work. They’re the deterministic part, the stuff you actually have to sit down and think through. The honest divide isn’t 60 against 30. It’s the 90 against the 10.

The last post I made was about the "what" and "why" of ICM. This one will be the "how." Actual folder structures, actual contracts. (If you've been wanting to try this but didn't know where to start, this is your blueprint.) ⭐ I'm going to walk through a real use case: (➡️ Adapt this to your own SOP) (Client) You're an IT Manager at a life sciences company and you need to automate SOP (Standard Operating Procedure) change control. If you've worked in pharma, biotech, or medtech, you know this pain. A single SOP change touches document control, impact assessment, reviewer routing, training assignments, and compliance sign-off.(or its supposed too anyway 😅) It's manual, it's slow, and it generates audit findings constantly. 📝Note* Every audit finding costs real money and real time. A single finding can trigger a CAPA (Corrective and Preventive Action), which means someone has to investigate the root cause, document the fix, implement the fix, verify the fix worked, and then prove all of that to an auditor. That's hours of work per finding, across multiple people. 🥅 The goal of the workflow below is to take an SOP change request, from the moment someone submits it, all the way through to a revised document with the right reviewers assigned and the right people flagged for retraining, without a human having to manually route, classify, chase approvals, or figure out who needs to be retrained. We're going to build an ICM workspace that handles the intake-to-approval pipeline. And we're going to do it using the 60/30/10 ratio so you can see exactly how the layers map to real architecture. Now for the 👇 🗂️ The Folder Structure ( Your 60%) ← ✅ This is your deterministic (predictable) infrastructure. It doesn't change, it doesn't need AI, and it does most of the heavy lifting. sop-change-control/ ├── CLAUDE.md ├── CONTEXT.md ├── _config/ │ ├── compliance-rules.md │ ├── reviewer-matrix.md │ ├── sop-template.md │ └── training-requirements.md ├── references/

The past will tell you the future.