I'm a dietitian (clinical nutritionist) and practice owner, but (mostly) not a coder. The capstone project is a telehealth clinic with no out-of-pocket cost to clients, and the clinical operating system underneath it. Eduba super kindly gave the green light on a shared seat: my spot, two of us in it, and I pay for it. So I'm looking for a technical person to join me! You'll be creating a product that solves very real, expensive pain, and deploys on my live practice. The full brief is linked here, and I tried to make it comprehensive, interactive and somewhat skim-readable, but attached is also the straight-up html file to just feed to AI instead. Or just ask me questions in the comments. Also for those who aren't necessarily interested in joining me, I would LOVE your feedback/questions/thoughts too. No need to be diplomatic or hold back either ☺️ https://bffhealth.com.au/brief.html (PS- @Alex Brown I think I mentioned I'd tag you in what I was up to, here it is)

Hey Ya'll! I've been deep in Opus 5 for a few days now, and I kept noticing the same thing a lot of you have been posting about: it doesn't want to follow the ICM folder system properly. It skips steps. It buries the answer under a pile of caveats. It re-opens decisions I already made. It goes off and "helpfully" does something I never asked for. And every session I'm correcting the same handful of behaviors all over again, like the last conversation never happened. So I stopped fighting it and tried something different. I asked it directly: give me the list of your trained programming that makes you go against parts of my ICM folder system. Not the stuff its creators tell it to keep private — just its own default behaviours that clash with my rules. For each one, what it costs me, and what the override should be. It gave me sixteen. And reading them, it clicked. I wasn't fighting the model. I was fighting its training. Things like: it leads with risk because caveats feel responsible. It balances instead of committing because that's what it's rewarded for. It infers from something plausible instead of opening the actual file. The newest message in the chat quietly overwrites the standing rules I set an hour ago. None of that is disobedience. It genuinely thinks it's helping. Which is exactly why "just follow my system" never works as an instruction — the model isn't ignoring you, it's pattern-matching to something it was trained to believe is better. So we bridged it. I had it write the whole thing into a document that sits in my _foundation folder and loads at pre-flight step zero — before it touches any work. Each row names the default, names what it costs, and states the override. And every row ends the same way: my system wins. No debate, no re-negotiation. The part that makes it compound is the mechanism at the bottom. When I correct it now, we check the table: - If the behavior is already in there, it broke a known override. Fix it, move on, no discussion.

I think I cracked the code on why we are all having a hard time with this second brain stuff. The real problem is that we are saving information that we think will be relevant to future endeavors, not just the stuff that is presently needed. Thus, we need rules that work in many (read "all") workspaces to make the information usable/searchable etc. These hypothetical rules would likely be more constraining than the rules that an actual use case would require. The second issue is that ICM is (correctly) very broad. Its principles map extremely well to the constraints of a task at hand, but poorly to undefined future tasks (like the goofballs making ICMs for imaginary problems) Possible solution: We stop saving unnecessary info and let our desired function determine the format (within ICM L3 Principles). That solution sucks, I still want to save info I don't need today!! I found a better solution... (If you just want the solution skip to the last paragraph. If you want some cool info on why your second brain doesn’t work, read on.) In practice, our L3 files are almost all SOPs. But the way an SOP is structured doesn't work for the way externally-authored source material should be kept for citation or lookup (which btw = split into its natural segments and indexed). This is why Tiago Forte’s PARA system doesn’t work, it’s built for helping a human decide what to do next, not have access to the relevant info. Google’s OKF fails because it's a format for shipping knowledge between tools/organizations, not the method for finding that info. Karpathy’s wiki fails because it defines only the loop (ingest / query / lint), so retrieval quality is only as good as the agents improvisation, its unreliable. RAG and vector databases are for bulk data, not a second brain. For instance, a million support tickets is a pile to query, not a knowledge base. Like our boy Jake likes to say (shout out Jake!), the principles for darn near everything have been around for decades. We're just applying timeless principles to an unrefined tool. The principle needed here is called faceted classification, developed by a librarian named S.R. Ranganathan in 1933, decades before we had a database to apply it to.

Planes keep a black box so that when something goes wrong there is a full recording of what happened and when. Build the same thing into your ICM system: a logbook it writes itself, every job and every journal, that you can hand back to Claude at any point. The setup is simple. Every Claude Code job writes a short record when it finishes - what it did, how it went, a grade, and any errors. Every design chat writes a journal when it is done drafting your ideas out. Every handover is stored in a set space. All of the above - ORGANISED Nothing is thrown away. The record just builds on its own in the background. Then, any time you have spare usage, point Claude at the whole logbook: pull the bits that ran slow, the bits that failed, and the improvements worth making. Once the logbook exists, here is what it gives you: - Query anything - ask in plain language what happened, when, and why. - Find the mistakes - surface exactly where and when something went wrong. - Improve the whole system - point at the record and tell it to fix the system as a whole - Security audits - every change that was made, timestamped and ready to review. - Client work - hard evidence and the answer already sitting there if a client complains. - Investor conversations - the same record holds up when you are showing what you have built. - Older systems - go back and read what a system used to do long after you have moved on from it. - Across projects - copy edits and systems from one project directly into another with ease And this is where it goes next. Fairly soon you will be able to hand a model every logbook across every project you run and let it treat the whole thing as training data - not to answer questions about the past, but to learn how you actually operate and carry that forward on its own. The record stops being something you query and becomes the material a system clones itself from: your decisions, your patterns, the way you work, all already written down. That is the real reason to start now. Every entry you log today is training data for the autonomy you hand off tomorrow.

ICM is the best thing I have come across for making AI work legible, and it is genuinely the reason I can build what I build. What I keep running into is that a folder structure is a map, not an engine - past a certain size, something has to drive it. Three things I ended up adding on top: - A logbook - every job writes a record when it finishes, so the system has a history and not just a current state. - A bundler - one command assembles the right files into a single prime, rather than me picking them by hand every session. - A design layer - brainstorming and prompt writing happen in a chat first, and only the finished work order goes to Claude Code. For context, ICM was one of my first real experiences of what you can actually do with AI, and I am still not over it. This is not a criticism of the methodology, it is a question about where it stops being sufficient on its own. Where I hit that was memory and scale. A folder tells a fresh session what exists, but not what happened last week, what already went wrong, or which of five projects it is sat in. The structure holds state and I kept needing history. Without the layer on top, I am the one remembering, assembling and routing, every single session, and that is where all the manual work quietly goes. So the genuine question. If you are running something big, or anything near enterprise, are you telling me it is a folder structure and Claude Code prompts and you see what happens? Or is there an orchestration layer you have quietly built that you do not talk about much? Interested in the limitations people have actually hit with a bare ICM setup, and what you put on top to get past them?