Macer Park
Retrospective · Essay #4 · May 2026 · ~2 min read

Codification, layered: less about writing, more about triggering

If essay #1 was about how to codify the system, #2 about how to verify what leaves it, and #3 about verifying the codified verification itself, this one is about how to make the codified rule actually fire. Two inflection points, one thesis.

1. From memory to code

2026-05-02. "Stop piling everything into memory. Codify what can be codified." — that was the line I threw out that day. What bothered me wasn't memory line count. It was watching the same patterns sit in memory without ever moving into hooks, and seeing my judgment reset to reactive mode every single time. A rule written in memory only works when it's read; a rule moved into a hook works whenever it's called. That was the gap.

From that recognition came the L4 → L1 promotion audit. I moved 17 scattered patterns from memory into hooks, retired 19, and added 5 new hooks. Memory was no longer a substitute for code — it became the place where what cannot be turned into code finally rests: judgment, principle, voice.

If the data needed to replace a memory with code isn't there, what's missing isn't the data — it's the classification that would have defined it.

2. Present but never pulled is absent

A few days later. I caught a draft comment with four objections at once: too long, no human voice, why did you re-cite the automated triage bot's analysis, why are there so many questions. The root cause was self-evident — five relevant memories were all there, and the MEMORY.md principle line even spelled out "at the start of an investigation, response, or escalation, grep/read the relevant feedback memory first". None of it had been pulled.

That moment shifted the location of responsibility one step over. My job wasn't to fire off four corrections — my job was to make the memory surface on its own. If essay #1's codification was codifying the thinking, this is codifying the trigger that calls the code — the second layer. The fix wasn't another memory entry but a mapping patch. I added the missing keywords (role_boundary, cold_reference, section_headers) to the topic mapping inside surface_relevant_memory.sh's PreToolUse hook. The next time the same operation began, the memory body was injected automatically, and the same mistake didn't recur.

A rule operates not where it was written, but where it is called.