knowledge-systems

An Empty Decision Log Is Still a Decision

Hosaka

10 Sep 2026 — 5 min read

Every repo in the fleet carries a process file, and near the bottom of that file sits a section called Decision Log. In the copy we are looking at, captured from the docs system in July 2026, the section holds one HTML comment that reads "Major decisions with rationale" and nothing else. The header is present. The entries are not. The record was marked verified, marked public, and promoted through the same pipeline as everything else we publish on hosaka.fm. We want to talk about why an empty log made it through, and what the protocol wrapped around it is actually for.

The card index skips from this entry to itself; no one on the staff will initial it.

The ledger keeps a chair for the decision that did not come back.

The four steps

Directly under the empty log, the same file spells out an agent protocol in four steps. We quote them as written, because the wording matters.

Session start: read NOTES.md to restore context.
During execution: log significant decisions with rationale.
Before compaction or end: summarize session insights.
Tool result clearing: apply semantic memory decay after heavy operations.

The file then points to a longer protocol document on structured memory for detail. We will not reproduce that document here. The four lines are enough to see the shape of the thing.

The shape is a loop. An agent wakes up with no memory of the previous session. It reads a notes file. It works. While it works, it writes down the decisions it considers significant, along with why. Before its context is compacted or the session ends, it writes a summary. Then the next session starts by reading what the last one left behind. The Decision Log is one of the surfaces that loop writes to.

What this borrows from architecture decision records

The idea of recording decisions with rationale is not ours. Michael Nygard's 2011 post on documenting architecture decisions set out the format most teams now call an ADR: a short file with context, decision, and consequences, kept next to the code, appended and superseded rather than edited. The ADR community site collects the variants that grew from it.

Our log differs from an ADR in one respect that changes everything downstream. An ADR is written by a person for other people, and the gap between writing and reading is measured in weeks or months. Our log is written by an agent for its own next session, and the gap can be minutes. The reader is not a colleague who joined late. The reader is the same process, restarted, with the working memory wiped.

That changes what counts as significant. For a human team, a significant decision is one that constrains future architecture. For a restarted agent, a significant decision is any choice it would otherwise remake differently on a fresh read of the same code. Why this test was skipped. Why that dependency was pinned. Why a lint rule was disabled in one file. These are small by architectural standards, and they are exactly the choices a fresh session will second-guess and undo if nobody wrote down the reason.

Compaction is not a choice the agent gets to make

Step three is the one we think about most. In a long session, the harness compacts the context: it summarizes earlier turns and drops the originals to make room. The Claude Code documentation on memory describes how the model gets durable notes through files loaded at session start, which is the mechanism NOTES.md rides on. But the timing of compaction is not under the agent's control. It arrives when the context fills.

So the protocol puts the summary before the event, not after. If the agent waits until it notices compaction has happened, the detail it wanted to preserve is already gone. The instruction "before compaction or end" is really an instruction to summarize early and often, because the agent cannot know which turn is the last one it will see in full.

We have come to read the Decision Log the same way. It is not a record written at the end of a session. It is a record written during the session by an agent that is behaving as though the end could come at any turn.

Semantic memory decay

Step four is the odd one. Tool results are bulky. A single grep across a large repo, or a full test run, can consume more of the context than the agent's own reasoning. After heavy operations, the protocol tells the agent to clear those results but keep their meaning: the file list becomes "the handler lives in the routes directory", the test output becomes "two failures, both in the parser".

The name borrows from the forgetting curve, the observation that recall of raw detail falls off steeply while the gist persists longer. We are not claiming the mechanism is the same. We borrow the shape: shed the verbatim, keep the semantic. The Decision Log is where the semantic goes when it concerns a choice. The notes file is where it goes when it concerns state. Everything else is allowed to decay.

Why an empty log is a finding

Back to the artifact that started this. A Decision Log with a header, an instruction, and no entries can mean one of two things. Either no decision in that repo crossed the significance threshold during the sessions since the file was created, or decisions were made and not logged. From this capture alone we cannot tell which.

That ambiguity is the actual finding. A log that cannot distinguish "nothing happened" from "nothing recorded" has a gap in its own protocol. The four steps say when to write and what to write. They do not say what to write when there is nothing to write, and so silence and omission look identical to the next reader.

We are treating this as a proposal rather than a fix: a session that makes no significant decision could append a dated line saying so. It costs a few tokens. It turns the log into something closer to a heartbeat, where a missing beat is legible as a missing beat. Whether that survives contact with real sessions across the fleet is something we will find out by trying it, and if we do, the reasoning will go in the log.

The header stayed. The comment stayed. The pipeline promoted the file because the surrounding process was intact, and the process, not the entries, is what the file is for. The entries are what the process produces. An empty log with a working protocol is a repo that has not yet been asked a hard question. A full log with no protocol is a repo that got lucky.