A procurement office wants a guarantee that every time a solicitation document is written into the repository, a redaction linter runs against it. An analyst added a line to CLAUDE.md reading Always run the redaction linter after writing a solicitation file, and it works most of the time but has been skipped on several long sessions. The compliance lead needs it to be unconditional. What should the architect do?

The dividing line here is between context and configuration. Instructions the model reads, whether they live in project files, memory, or a skill, raise the probability of a behavior; mechanisms the harness executes determine it. A compliance requirement described as unconditional is a request for the second kind, and the intermittent skipping the procurement office is seeing on long sessions is the expected signature of a guarantee implemented as prose.

A hook configured in settings.json runs on a defined tool event and is executed by the harness rather than chosen by the model. The redaction linter then fires on every write of a solicitation document whether or not the model happened to be attending to that instruction, and because the hook is checked in it applies identically to every analyst's session.

Restating the instruction more forcefully or in more places does not change its nature, since it remains guidance competing for attention in a growing context; moving it into a skill makes it less reliable rather than more, because a skill loads only when selected and skills carry no priority over project context; and persistent memory reloads the sentence at the start of each session while still leaving execution to the model's mid-run judgment.

Exam caveat: a hook guarantees the linter runs, not that anyone acts on what it finds, and a hook that only logs leaves the compliance gap open. Operational check: write a solicitation file containing a deliberately unredacted field and confirm the hook both fires and blocks or flags the write rather than merely recording a message somewhere.