📦 AND SOMETHING NEW: EVERY ENTRANT GETS A FEEDBACK FILE 📦 🔍 WHAT WE DID DIFFERENTLY THIS TIME Every submission was cloned at the exact commit that was public when we read it, and read file by file. The brief. The identity. The rules. The reference layer. The code. Where a repo made a claim we could check, we checked it. Arithmetic recomputed by hand. Sample photos opened and compared against the outputs that cited them. Files diffed. Self-tests traced. Thirty-two repos, read at the code/word level. And one lens over everything, because it's the lens this whole community is built on: does the build keep the human's judgment where it pays and put the deterministic work in code, where it can't hallucinate? 📦 THE FEEDBACK PACKAGE This is the new thing, and it's for everyone not just the podium. 📦 COMP #8: THE WILDCARD - The Vault Every entrant gets a markdown file. Three parts: 1️⃣ The read. What your build actually is, and the strongest thing in it cited to your own files. Rule numbers. Function names. Your own examples. 2️⃣ One push. The single change that most improves your build. Not a list. One. 3️⃣ An idea worth naming something original in YOUR build, credited to you, that the rest of the community is told to take from. Plus links to the builds your feedback points at. Nobody walks out of this comp empty-handed. Thirty-two builds, thirty-two named ideas. The roster alone is worth the download. 📍 The package + the full write-up (what held up, what was missed) live in the new Feedback module: 📦 COMP #8: THE WILDCARD - The Vault 📚 WHAT THE FIELD TAUGHT Three lines split thirty-two repos: ✅ Enforcement. A must in a markdown file is a request. A must in code is a constraint. (That line is from one of your repos. It's in the package. Go find whose.) ✅ Evidence. The builds that shipped receipts of a REAL run transcripts, dated logs, before-and-after fixes read differently every single time.

I was showing someone a folder agent I'd been working on, walking through the personas, and they pointed at one and asked "what does that one do?" My answer was "uh... it kind of helps with strategy?" That's the tell. If I can't answer that question in one clean sentence, I built something I didn't need. And I built it for the same dumb reason we all do: the tool was shiny and I wanted to use all of it. The variable problem Here's the thing about ICM that's easy to forget once you're a few builds in. The whole point of the folders and context files is to give the AI a roadmap. A CLAUDE.md, a routing table, a CONTEXT.md per workspace, that's you doing the thinking up front so the model doesn't have to guess mid-task. Less guessing, less wandering, less hallucinating. That's the deal. Every persona you add is a variable. Every extra role in the pipeline is another voice the model has to reconcile, another set of instructions it has to weigh against the others, another place where two contradictory pieces of context can collide and send it sideways. You're not adding capability for free. You're adding surface area for drift. And the more I build these things, the more I think the goal isn't "make it smarter." It's "make it repeatable." As close to deterministic as you can get an LLM, which, let's be honest, is never fully deterministic, but you're playing the odds. Fewer moving parts, better odds. A real example Say you're building a YouTube Shorts pipeline. Researcher pulls trending topics and source material. Script writer turns that into copy. A YouTube-platform-expert persona checks pacing, hooks, and format against what actually performs on Shorts. Three roles, three clear jobs, and each one maps to a distinct mental mode. That's exactly the "different workspace for different thinking" rule from the folder guide, found in the vault if you are a premium or VIP member. Makes sense. I'd build that. Now somebody adds a marketing persona on top. Why? "To make sure the branding's consistent." Okay, but the YouTube expert is already checking format and hook strength, and the script writer already knows the voice. What's the marketing persona actually doing that isn't covered? Usually the honest answer is nothing, it's just there because "marketing" sounds like it should be in the room.

Good day everyone. I just wanted to say that I am happy that my LinkedIn algorithm is updating and feeding me a lot better content because I have connected with other members of THIS community. If you want to connect on LinkedIn, why don't you drop a link to your profile below and I will be sure to follow you!

The context was not in the model. It was not in the tool. It was an asset I owned. Today I ran a test that I consider a real benchmark for the ICM methodology. I built a folder structure for Curiositas: one set of files designed to hold state, routing, identity, organizational knowledge, operating context, and the way we work. First, I asked Claude Code to pick up the work. Correct response. Right context. Correct identity. Current state of the work recognized. Then I opened Codex. I had never used it before. Zero setup. Same exact question. It read the right files by itself, understood the routing, and returned the same context: identity, state, open tasks, and direction of the work. Different words. Same content. Everything is documented in the video. Then I asked Claude to evaluate the result. The screenshot says: “solid result... this is basically a clean pass on the portability test.” And that is the point. This is real portability. This is real persistence. It means building something that does not belong to the platform, the model, or the AI tool I happen to open that day. It belongs to the structure underneath. It belongs to the asset I am building. I had already tried to solve this problem before finding ICM. I saw AI tools as fragmented by nature: a new tool every day, context scattered everywhere, work spread across different places, and nothing that truly remained mine. My answer had been to build my own framework. It taught me a lot. But in the end, it was becoming as fragmented as the problem it was trying to solve. I was working a lot, but the result kept moving further away. ICM is the layer I was missing. You are no longer designing inside the tool or inside the model. You are designing the structure that survives both. Jake Van Clief describes this as the future of how we will build software: a new way of communicating with machines. After this test, I understand why. I worked on this Curiositas lobby for half a day. From now on, I will improve it every day. I will make it more efficient and more tailored to me, to my way of working, to my processes, and to my company.

Here I go again - realizing that @Bas Rosario post today, about pointing an AI model at his own setup and asking it to make itself cheaper, unveiled insights I thought would be of value to those who read both (original post https://www.skool.com/cliefnotes/i-just-spent-the-last-few-hours-asking-fable-to-make-itself-cheaper?p=cc666986). Bss wrote "It found a file that reported its own size as 450 tokens. The file was 7,000." I ran the same thing on my own system and found my version of it. A status file that declares a 10KB limit in its own header while sitting at 39KB. I'd read past that number a hundred times. That's not the part I want to talk about, though. What his post really did was make me look at where verification lives in a system, and I think most people keep it in the wrong place. The common setup is to build something first. A workflow, a stack of tools, an integration. Then you add checking at the end. You generate, then you verify. Verification becomes the last step, the thing you bolt on when you're worried the output might be wrong. I built mine the other way around, and not on purpose. I had nothing to start with. No existing architecture, no integrations. I built through the method itself, one worker at a time, and the first thing each worker learned was when to refuse. Verification wasn't a step I added later. It was the floor everything else got built on. Here's why that ordering matters more than it sounds. When verification is the base, the model stops being the important part. The AI gives you access to skill. Think of it as a set of clubs. A professional golfer can put the ball where they want with a lesser club, because the skill is in the swing, not the gear. Enforced verification is the swing. It's what lets you reach for the cheap, fast model when the job is grunt work, and the expensive one only when the job actually needs it. The right club for the setting, instead of swinging your driver at every shot because it's the fanciest thing in the bag.