In 2015 I lost an account. The reason came back in two words: too expensive.
That’s not a reason. That’s a shrug with a price tag stapled to it. Too expensive compared to what? On which line items? Too expensive for who?
Nobody asked me for a memo. I wrote one anyway, to my manager, dated May 22, 2015. That’s just how I’m wired.
The number wasn’t one number. We were about 20% more expensive across the board, and up to 80% more on a few specific line items. Two different problems wearing the same complaint. So the fix wasn’t “drop the price.” It was: charge more for what buyers already expect to pay a premium for, ask for less on what they’re less familiar with, and restructure the playbook around how the market actually budgets.
Fourteen months later, in July 2016, the firm was building a deck with a slide for two alternate recommended models, meant to set up the pricing discussion. Did my memo cause that slide? I don’t know. Both documents exist, and both are dated. That’s exactly as far as the record lets me go, and I’m leaving it there on purpose.
What I can say is why there’s anything to check at all, eleven years later. I wrote the reasons down, with a date, while they were fresh. That’s what I’d now call provenance engineering. I just didn’t have the name yet. AI didn’t create this behavior. It made it possible to do it at a different scale.
Here’s the progression, in three steps. Prompt engineering shapes the instruction. Context engineering shapes what an intelligence, human or artificial, can understand right now. Provenance engineering is context engineering across time: what gets left behind so the next mind doesn’t start from zero.
The practice isn’t new. Records managers have done it for decades. Decision journals do it. A good case file does it. I’m not claiming an invention, just giving an old habit a name that fits the tools I work with now.
In RosenOS, the system I run my work through, I’ve started closing work sessions with what I call a finishing note. It isn’t a summary. What happened can usually be recovered from the work itself. A finishing note holds the three things the work won’t tell you on its own: why this path won over the ones right next to it, what got rejected and why it lost, and what should make someone reopen the work instead of starting over.
Sometimes that’s a page. Sometimes it’s one sentence: a warning that a future rollback could bring an old page back, dated and addressed to whoever touches the site next.
It also has to refuse things, on purpose. I’ve written that knowledge accumulates, wisdom compresses, and behavior compounds. A finishing note that tried to keep everything would just be a pile with a nicer name. So the rule stays narrow: keep the source evidence when someone reinterpreting it later could change a real decision. Otherwise, summarize it and let it go.
The hypothesis
A finishing note that records why, what got rejected, and what should trigger a second look lets the next person, or the next agent, pick the work back up without reconstructing it first.
Here’s how we’ll know. On September 18 I closed a working session with a finishing note. The next time that work resumes, whoever picks it up reads the note first, before opening anything else, and writes down what they believe the state is. Then we check that belief against what was actually true, and log which files they still had to dig up.
If the next mind still has to reconstruct the reasoning the note was supposed to carry, or the notes keep getting longer while re-entry stays just as slow, that changes my mind. A finishing note that doesn’t save the next mind any work isn’t a finishing note. It’s a diary.
We’ll report back after that next resume.
A finishing note is context you leave for someone you may never meet: the next person, the next agent, or you in six months. That’s the gift. Let’s see whether it saves them the digging.