Just passed my security+ certification exam. Not the score I wanted but a win is a win! I'll take it!

🔥 @Don Roy took the top spot this week. ---- 🇺🇸 Quick note first. This post is a day late. We took yesterday off for Memorial Day to spend time with family and remember the people who made days like that possible. Thanks for your patience. ---- 🎁 What Don wins: He was already a VIP member, so we're converting his account. ✨ Free VIP for life. ✨ The Drawing Room. High Tea. Bespoke folder builds with Jake. All of it. Forever. No charge. ---- ⏰ The 7-day clock just reset. Next Monday we crown the next winner. Could be you. 🎯 How it works: - 📝 Post bad ass stuff - 💬 Help people in the comments - 🛠️ Share what you're building, what's working, what's breaking - ❤️ Engage with other members' posts The leaderboard tracks all of it. Whoever sits at #1 next Monday wins. 🎁 The prize, depending on where you're at: 🆓 Free member? You get lifetime Premium, free ⭐ Already Premium? We convert your Premium so you stop paying 👑 Already VIP? We convert your VIP so you stop paying Either way, you stop paying. Forever. ---- ⏳ One more thing. The Week 5 weekly comp winner gets announced later this evening. Stay tuned. 🏆

A few months ago, I had an idea for a build. Thanks to @Jake Van Clief 's folder architecture I succeeded. I built the thing! But then someone had a question about what I had built that turned out to matter more than I expected: are the things I built actually agents? I'd been calling them that out of habit. Then the question forced me to be precise, and being precise changed the design. Sharing the three things that came out of it, because I was being loose with the word, so I post as a cautionary tale based on all the hype around "agents" right now. 1. "Agent" in 2026 means an autonomous reasoner — establishes its own path, it adapts, it learns. But there's an older meaning: a thing that acts — that has a scope, runs different types of operations, produces different effects. My things are the second kind not the first. They can't learn, can't self-modify, can't pick their own goals. Once I admitted that out loud, I stopped saying "agent" unqualified and started saying bounded executor. That not a bad thing — it was me being honest about what I had designed. Here's the interesting thing, an autonomous agent can't be audited with certainty, because what I will do next isn't predetermined. A "bounded executor" can. I removed the autonomy feature, on purpose! If you're building "agents," ask yourself which of the two words you mean, the answer changes what you can promise about them. 2. Test for drift with identity, not observation. "Drift" changes quietly over time and is something most people try to monitor for: watch outputs, catch anomalies etc. I went the other way. Every component definition in my system is content addressed: it has a hash derived from its exact content. So, the drift test isn't statistical, it's binary. Same hash at time A and time B and BOOM! byte identical! Different hash > there's a recorded, authorized change I can point to. There is no third case. The idea here is to make drift unable to happen silently by fixing that thing's behavior to an inspectable definition.

https://www.skool.com/cliefnotes/icm-paper-published-to-pre-print-today?p=5d686529 I almost didn't write this one. I read the Interpretable Context Methodology paper last week. If you haven't already, it's worth your time. @Jake Van Clief and @David McDermott I hope you don't mind but I did what any interested, semi decent AI enthusiast would do, I ran the paper against my own markdown and .rs crate stack and here's the result... Folder structure as agent architecture, the filesystem instead of an orchestration framework — and my first instinct was just to comment "great paper" and move on. But it kept nagging at me, so here we are. What got me wasn't that it was new. It was the opposite. I've been heading down this verification-first build path for months now and the paper kept describing things I'd already built. The difference is except it framed them as good ideas to aim for, and I'd been treating them as rules the system isn't allowed to break. That's what I wanted to talk about. Three places it overlapped, and where I ended up going a step further, not because I'm clever, mostly because it felt natural to go down that route. The paper's big idea is observability: every intermediate state is a readable file, so the system was never opaque, so there's nothing to explain. I love that. But "readable" wasn't enough for me and it took me a while to realize why. Readable still means I have to read it, and at some point there's too much. So I leaned on formal proofs. I used a model checker for the core properties. Not "I looked and it seemed fine," but "this holds for every input, proven." Same instinct as ICM, just pushed until "looks right" isn't in the loop anymore. I resonated with the Cross-Stage Trace Verification portion of 6.2 (2). The paper's "Toward Semantic Debugging" section proposes that a workflow stage should get a "Verify" section, a check that its output lines up with earlier stages. Honestly that came from trying to articulate everything manually in the beginning. I'd review something carefully, signed off, and missed a case anyway when the implementation was completed.

For those who missed the first post or just joined: The Lyceum is a 12-week program we're building. Live instruction from Jake and the Eduba team. Small cohorts. Real projects. You build something from week one, not watch tutorials. At the end, a competition with real prizes. Eduba's first certification, backed by the same methodology we've used to train Fortune 500 teams. Now here's what we've locked in since then. The Structure Three 4-week sprints with a 1-week break between each. Not 12 straight weeks of grind. You build, you breathe, you come back sharper. - Sprint 1: Foundation — Core methodology. Everyone starts here. - Sprint 2: Application — You're building. Real project, real progress. - Sprint 3: Capstone — Finish what you started. Demo day prep. The breaks aren't fluff. They're built in so you can catch up, refine, or just live your life without falling behind. The Cohorts Same curriculum across all three. The difference is where your hours go. Technical — Developers, engineers, technical founders. You're building a tool or production system. 30% of your time goes to Claude Code and integrations. Another 30% to production systems and capstone. This is the builder track. Business — Ops, managers, founders, consultants. You're automating a process or designing a system spec. Heavy emphasis on workflow design (30%) and decision frameworks (25%). You direct the work without writing the code. Creator — Marketers, educators, solo operators. You're building a content production system. One person replaces the team. 25% on content pipelines, 20% on workflow design. This is how you scale yourself. Pick the track that matches how you work. The methodology transfers no matter which one you choose. A 4th Cohort? We're considering adding a team cohort if there's enough interest. This would be for companies that want to enroll multiple employees, or for people in the community who want to form their own team and build together. If that sounds like you, let us know in the comments.