Rung two built the window. Rung three is what survives it, open from today. There is something you have told the model three times this month. Nothing big. The client signs as Sam, never Samuel. We stopped saying "the portal" in June. It got it right every time and it forgot every time, and somewhere around the third time you stopped noticing you were the one doing the remembering. That is not the model being slow. That is a window closing, with nothing on the other side. 📚 What just opened Memory Engineering, seven posts, the whole rung at once. The Overview draws the line the rung stands on, this turn against what survives between turns, and the three classes carry one claim each: (1) Most memory fails by keeping too much (2) A memory you cannot find is worse than none (3) A memory is a belief, not a record Then the payoff, the whole series on one card, my perspective on rung three, and the closing post on where memory sits inside ICM. By the end you own a memory: one small file the room reads every time you open it, a drawer behind it for the rest, and a date in your calendar for the day you read it back. No system in it, and you will notice you never built one. 🪜 Where you are standing (Rung 1 & Rung 2 should be completed) If not, you can find them here they are in order and should be taken from series 1 to series 2 and so on: PROMPT ENGINEERING 📚 Series 1 Overview CONTEXT ENGINEERING 📚 Series 2 Overview Climbed rung two? Bring the room's file, the seven lines, because this rung decides what gets written into it, what stays out, and what gets crossed out the day it stops being true. The Overview asks one more thing before class one: the three things you type to the model in every fresh window. Three, not thirty. Not there yet? Rungs one and two are still open and still the order, the Start Here post is pinned. Honest word on this one: it is the rung people stop on, because nobody ever asked most of us to decide what should be kept. So the steps are smaller and every wrong version is shown in full. If you have never built anything that had to remember, that is who I wrote it for.

Something I keep tripping over and don't have a clean answer for. I have a scheduled job on my machine. The copy I edit lives with the project. The copy that actually runs lives wherever the scheduler expects it, so installing a change means copying the file over and reloading the schedule. Which is fine until I fix something, test it, forget the copy step, and what runs is last week's file. Nothing complains, because the job still finishes cleanly. I've lost more time to that than to any real bug in it. Three things I've considered. Point the running path at the project file so there is only one copy. Or keep the copy, but make the job print its own version so a stale run shows up in the output. Or stop editing in the project entirely and treat the installed path as the only one that exists. Anyone running anything on a schedule off their own machine has this somewhere. How do you keep the two from drifting?

I'm curious about something. Of everything you've gone through so far... What's the ONE idea you know you'll come back to? - Not necessarily the most impressive lesson. - Not the most complicated one. The thing that made you think: "I need to remember this." Drop it below and tell me why. Seeing what sticks with everyone is also going to help us understand which parts of these roadmaps are having the biggest impact. And remember: Don't skip the accountability posts. Writing down what you understood is part of the process. Let's see what everyone pulled out of The Vault. 👇

RPSOW, pronounced "repsow": Receiver, Pain, Solve, Outcome, Why. It's a five word frame for describing an idea, and I have been testing whether it holds up as a file structure, the ICM way. @Jake Van Clief outlined the sentence behind it: For [receiver], I want to turn [input] into [output] so they can get [outcome]. They would pay for it because [reason]. That is the sentence I started with, and the five blanks turned into those five words. Empty, it looks like this. Receiver and Why sit at the root, because they do not change once you pick an idea. Pain, Solve, and Out are the stages under that, in order. Outcome sits at the end as the check: did Out actually solve Pain, for this Receiver, for the reason in Why. Nothing is filled in. It is just the shape. ICM Receiver–Pain–Solve–Outcome–Why/ ├── claude.md → "Receiver. The one who is getting the help. │ Why lives in _why/, not here." ├── _why/ │ └── claude.md → "Why. The reason this is worth paying for, written as a │ falsifiable bar before Out exists — what has to be true │ for Outcome to say yes." ├── 01 -Pain/ │ └── claude.md → "Pain. What the receiver is currently stuck with — │ the problem, in their words, not a data format." ├── 02 - Solve/ │ ├── claude.md → "Solve. The mechanism that turns Pain into Out — │ │ broken into three steps: 2a, 2b, 2c." │ ├── 2a/ │ │ └── claude.md → "Solve, step one. [TODO: what happens at this step]" │ ├── 2b/ │ │ └── claude.md → "Solve, step two. [TODO: what happens at this step]" │ └── 2c/ │ └── claude.md → "Solve, step three. [TODO: what happens at this step]" ├── 03 - Out/ │ └── claude.md → "Out. The deliverable itself — the artifact Solve produces." └── _outcome/ └── claude.md → "Outcome. The check — reads _why and Out only, and is written by someone other than whoever produced Out.

I've been building my second brain for a a couple of weeks now. I'm trying to use it to help me be more organized in my business but I feel like I'm getting more distracted. Does anyone have some tips on this situation? I'm sure it's happened before to somebody else.