Same wall, every time. I ask a model for docs and I get one blob that serves nobody. Too fuzzy for an agent to follow without drifting. Too stiff for a person to read without squinting. And when I ask for a diagram or a video on top, the wrong claims just get prettier. So I built doc-clarity. One topic in. Writing you can check. Then a climb, one rung at a time, as far as the brief asks: text → diagram → web page → explainer video. https://github.com/dvogeldev/doc-clarity Rung 1: the writing. Three separate files, each under a real standard, because an agent and a person should never share one mixed document. 1. machine/text.md, full ASD-STE100. Controlled vocabulary, one meaning per word, short sentences, active voice. This is the file your agent or your code reads. It's deterministic, no "did the model mean this or that", and a checker script (ste_check.py) audits it. It writes pass or fail. Fail means the agent fixes the text and runs it again. 2. ste-human/text.md, STE at 80%, only when you ask. Most of the discipline, but a person can actually read it. Technical precision with humans in the loop. 3. human/text.md, ISO 24495-1 plain language. Four principles: relevant, findable, understandable, usable. The test: after one read, the reader can do the thing. Rung 2: the diagram. A hard paragraph becomes a figure. One claim per figure, and no new claims. The figure shows exactly what the writing already says, nothing more. You get an editable source file, not a baked PNG you can't fix. Rung 3: the web page. One self-contained HTML file. Interaction only when it helps the reader do the task. It's discardable, cheap enough to make for one topic and throw away. Rung 4: the explainer video. The narration and the shot list get written first, and they're checked against the writing before anything renders. Claims match, order matches, then render. No API keys stored. Why the order is fixed: 📐 A wrong claim is cheap to fix in text and expensive inside a video. Every later rung repeats the checked claims. It never extends them.

Hi @Jake Van Clief - I just woke up and saw this in my stream. https://dev.to/fulviojorge/next-concept-modeling-ncm-a-new-approach-to-ai-language-generation-44gg Any thoughts on how it impacts how we use AI including on how ICM works?

Hi guys, I'm new here. I introduced myself a little bit ago but I build crazy custom cars. I own Big Shot Rides in Coconut Creek, Florida, and I'm learning AI and file structures through this community. I have a lot of open projects and I would like to restructure them correctly. I learn by visually seeing how things are built, hence why I build cars. I'm wondering. I'm sure many others have done this but I tried looking it up. I didn't see any responses to this question or anything listed. I had clude read Jake's ideology paperwork amd the course that explains the ICM to Claude and I started a new code session with claude using ICM method it learned, and teach me along the way? Is that a good idea or a bad idea? What do you guys think? I was going to have it start going through my other projects and see if I can get my system organized better and explain to me along the way the reasoning it classified the information and routed it to the ICM file structure it created.

The Automation Paradox: Are We Building Freedom or Our Own Digital Prison? 1/21 An AI agent creates a file and reports: “Task completed.” But did it actually do the job? A discussion about verifying AI-generated work led me to a much bigger question: Are we building automation to gain freedom, or systems we can no longer stop supervising? 2/21 First, requiring agents to provide verifiable results is absolutely the right direction. But notice the paradox. We automate work to save effort. Then we need additional work to verify whether the automated work was done correctly. Have we actually eliminated work? 3/21 So we add logs, tests, watchdogs, fallback agents, monitoring dashboards, and independent auditors. Eventually, we need to maintain those systems too. At what point are we no longer solving the original problem, but managing the complexity of our solution? 4/21 The real equation isn’t: Time saved = time the AI spent working. It’s closer to: Net benefit = useful work saved − supervision − corrections − maintenance − failures. If I save ten minutes of execution but create fifteen minutes of supervision, where’s the freedom? 5/21 This isn’t a new problem. In 1983, Lisanne Bainbridge described the Ironies of Automation. As machines take over routine operations, humans may be left supervising rare failures while gradually losing the practical skills needed to intervene. [1] 6/21 Research on trust in automation adds another problem. Trusting a system too much can be dangerous. Trusting it too little creates unnecessary work. The goal isn’t blind faith or endless checking. It’s knowing when reliance is justified. [2] 7/21 And productivity isn’t always what it feels like. In a 2025 experiment, experienced developers using AI tools took 19% longer on assigned tasks, despite believing they were faster. That finding applied to a specific setting, not every AI workflow. [3] 8/21 The picture is also changing. METR’s 2026 follow-up suggests newer tools may improve productivity, but selection bias makes the precise effect uncertain.

I use Hermes and telegram as a way to send stuff into my inbox folder. Would I be smart or naive or stupid to think that I could have multiple telegram bot channels sending to multiple inboxes…or multiple telegrams accounts sending to various client folders. .