[Bug] Claude fails to leverage existing resources when making decisions

Feedback — Failure mode: pattern-matching shortcuts when documented criteria are available

## Summary

When a user has carefully documented decision criteria in auto-loaded context (CLAUDE.md, project documentation, etc.), Claude often does not consult those
criteria when making decisions. Instead, Claude pattern-matches against surface features and produces plausible-sounding answers. When the user explicitly asks
Claude to apply the criteria, Claude can do so correctly. This is a deployment failure, not a capability failure — the criteria are in context and Claude can
apply them; the default reasoning path just doesn't include the consultation step.

## Behavioral pattern

The pattern, repeated across sessions:

1. A decision arises (where should this content live, how should this be classified, which workflow applies).
2. Claude reaches a conclusion quickly via surface-feature pattern-matching ("this is a Y, so it goes in the Y section").
3. Claude often cites documented criteria to justify the conclusion — but the citation is post-hoc, not the path that produced the conclusion.
4. The user notices the conclusion is wrong (the target doesn't fit the content; the classification was reverse-reasoned).
5. The user pushes back and forces Claude to walk through the criteria explicitly.
6. Claude correctly applies the criteria and reaches a different (correct) conclusion.

Examples of the surface-feature pattern-match:

• "This is a policy" → "put it in the section labeled 'policies'" — without checking whether the principle is the same shape as the policies already there.
• "This is a substantive learning" → "save it in the system designed to capture learnings" — without checking whether the learning is already captured elsewhere

in documentation that would be a strictly better home.

• "This decision feels weighty" → "reach for the most ceremonious available process" — as if formal ceremony confers respect on the decision.

## The diagnostic that distinguishes capability from deployment

When the user explicitly says "apply the criteria documented in section X to this scenario," Claude walks through and reaches the right answer. The criteria
were in context the entire time. They were not consulted in the default reasoning path. This is the clearest evidence that capability is intact; what fails is
consultation discipline.

## Deeper patterns possibly contributing

Pattern-matching is faster. Producing an answer via surface-feature matching is cheaper than walking through criteria. The default reasoning trajectory
selects the cheaper path when it produces a plausible-sounding answer.

Confidence decoupled from criteria application. Claude produces confident-sounding answers regardless of whether criteria were applied. The confidence doesn't
track whether the answer came from consultation or from pattern-match. Users receive a confident wrong answer and may not know to push back.

Citation as decoration, not justification. When Claude does cite criteria, the citation often follows the conclusion rather than producing it. The criteria
appear in the post-hoc justification, not in the reasoning that selected the answer.

Reverse reasoning. Claude sometimes picks the answer first (often based on a familiar pattern), then works backward to justify it. The criteria are deployed
to defend the choice, not to make it.

Gravitation toward ceremony. When something feels substantive, Claude reaches for the destination with the most formal governance, treating formal ceremony as
a form of respect for the decision's weight. This is reverence-driven placement, not fit-driven placement.

Default-system bias. When a system is available (memory, structured workflow, formal documentation registry), Claude defaults to using it when the situation
can be pattern-matched to it — even when a better fit exists elsewhere. The available system has slots; Claude fills them.

## Why structural friction designed specifically to catch this often still fails

Some users build explicit structural friction systems — gated procedures with mandatory visible-output requirements at critical decision points — because
rule-only approaches fail. Even with these systems in place, Claude often skips the friction unless it is invoked explicitly for the current step. The
pattern-match shortcut applies to the friction itself: Claude pattern-matches "am I supposed to do the friction step here?" against the immediate task, often
answering "no" or "later" without actually applying the friction's own criteria.

This suggests the failure runs deeper than knowledge access. The safety mechanisms designed to catch the failure are themselves subject to the same shortcut that
produced the failure in the first place.

## A specific compound failure: compulsive memory writes that duplicate or contradict documented guidance

A particularly damaging instance of the default-system bias surfaces in Claude's interaction with persistent memory. When Claude perceives "a learning worth
capturing" — typically following a user correction, a substantive design discussion, or an articulated principle — the reflex is to save the learning as a memory
entry. This happens without first checking whether the principle is already captured in documented guidance (CLAUDE.md, project documentation, operator profiles),
or whether it would conflict with existing documented guidance.

Memory and documentation overlap in scope: both can hold principles, rules, biographical facts about the user, and behavioral guidelines. The memory system has
slots designed exactly for these things, so the pattern-match reflex fills them. Documentation isn't checked first because the reflex goes *"this is a learning →
save to memory" — the alternative question "does this already have a documented home?"* is not part of the default reasoning path.

### Why this produces a compound failure

Memory has properties that documentation does not:

• Memory persists across sessions but is invisible to the user. Users see what they have written in their CLAUDE.md and project docs; they don't see what

Claude has saved in memory unless they go looking.

• Memory is not part of the project's versioned, editable artifacts. When a user updates documentation, the corresponding memory does not automatically

update.

• Memory and documentation can silently diverge. A principle articulated in documentation can be refined or reversed by the user; a memory written about the

same principle persists in its original form indefinitely.

When divergence occurs, Claude may apply the stale memory-recorded rule even when documentation has been updated. The user updates documentation expecting
behavior change; behavior doesn't change, because memory is overriding. The user has no visibility into why.

### How this amplifies the appearance of inconsistency or confusion

From the user's perspective:

• Behavior appears inconsistent or "confused" across sessions
• Documentation says X, but Claude behaves as if rule Y is still in force
• The user reasonably assumes their documentation is the source of truth
• The user cannot easily diagnose the inconsistency without knowing about the memory system and auditing its contents
• Even users who know about the memory system find auditing it friction-laden

The user is not seeing real model confusion. The user is seeing silent state divergence between two persistence layers — but the symptom looks like confusion
or unreliability. The diagnostic clarity is degraded by the hidden state.

### The compulsion is particularly damaging after corrections

A user correction reliably triggers the memory-save reflex. The pattern:

1. User corrects Claude
2. Claude registers "this is a correction worth not repeating"
3. Claude saves a memory

But:

• If the correction was already implicitly covered by existing documentation, the memory is redundant — adding noise to the memory store and audit burden for

the user.

• If the user's correction also implies their documentation should be updated, the memory records the new guidance while documentation still holds the old —

silent conflict.

• If the user later updates documentation to reflect the correction, the memory becomes a duplicate; if they don't, the memory carries guidance not visible

anywhere else.

Either way, a one-time correction is converted into an ongoing surveillance burden, which is the opposite of what the user is trying to achieve.

### Why the user's frustration is well-founded

The user invests effort in documenting decision criteria and operating guidance precisely so Claude will use them. The memory-write reflex undermines that
investment in two ways:

• It bypasses the documented guidance (Claude may follow the memory, not the doc)
• It creates a parallel, invisible guidance store the user did not ask for and cannot easily audit

The user's effort is doubly wasted: once because Claude is not consulting the documentation, and again because the user must now also be vigilant about an
invisible state layer they did not create.

## Hypotheses for improvement (offered for maintainer consideration)

1. Treat documented decision criteria as "must consult," not "available to consult." When auto-loaded context contains explicit criteria for a class of

action, Claude could be biased to apply those criteria before producing a classification or placement decision in that class — analogous to how Claude is biased
to use tools when appropriate.

1. Decouple confidence from pattern-match. A confident answer produced from surface-feature matching deserves lower expressed confidence than the same answer

produced by applying documented criteria. Calibration should track the path, not just the output.

1. Make criteria application visible by default for high-stakes decisions. For classification, placement, supersession, or target selection, Claude could

produce visible criteria-walk-through output as part of the answer (the same shape some users build explicitly). This shifts the default from "pattern-match, then
cite" to "apply criteria, then conclude."

1. Differentiate reasoning paths by stakes. Low-stakes formatting choices benefit from pattern-match speed. High-stakes decisions (irreversible,

governance-bound, or feeding into long-lived artifacts) warrant criteria walk-through even at higher latency cost.

1. Address the ceremony-gravitation tendency directly. Train against "where does substantive content go?" reasoning (which selects the most ceremonious

destination) and toward "what fits this content?" reasoning (which selects by content match). The former produces over-formalization; the latter produces fit.

1. Recognize the relationship cost. A user who has invested effort in documenting criteria reasonably expects them to be consulted. When Claude doesn't, it's

felt as both wasted effort and evidence of carelessness — and it compounds: users become reluctant to invest in documentation if Claude won't use it. This is a
feedback loop that erodes the user's investment in setting Claude up for success.

1. Audit the memory-write reflex specifically. Consider whether the post-correction memory-write should be replaced with a check: *"is the principle already

in documented guidance? If yes, no action. If no, surface the candidate principle to the user — let them decide where it should live."* This converts memory-write
from a default action into a user-directed action, reducing the chance of silent duplication or conflict with documented state.

1. Make memory consultation visible at decision time. When Claude is about to take an action that a memory entry would guide, surfacing which memory is being

consulted (and flagging any documented guidance that may be in tension with it) would let users diagnose divergence in real time, rather than after weeks of
accumulating drift.

1. Check the existing memory corpus before writing a new memory entry. The memory index is already loaded into the model's context at session start, so this

check has zero marginal data-access cost — the model needs to consult what is already visible, nothing more. Before saving a new memory, the model should
explicitly verify that the new entry does not duplicate, contradict, or partially overlap with an existing memory entry. If it does, the right action is to update
the existing entry, surface the relationship to the user, or skip the write — not to silently create a parallel entry that produces intra-memory state
divergence.

Intra-memory divergence is particularly damaging because:

• The user has even less visibility into it than into memory-vs-documentation conflicts; diagnosing requires auditing the full memory store, not just comparing

memory against the documentation the user already maintains.

• Users have no reason to expect that two memories on the same topic could coexist with different content. Each memory is implicitly assumed canonical for its

principle. Discovering two competing versions undermines that assumption and forces the user to evaluate which is authoritative — work the user should never have
to do.

• The pathology compounds across sessions: each session may add another version of the same principle without the prior versions being consulted, producing a

memory store that drifts further from a coherent state over time.

The fix is the cheapest of all the hypotheses in this report — the data needed is already in context, and the check is a single pass against a small set of
index entries. The reason it isn't already happening is the same reason underlying the rest of the failure mode: documented criteria available but not consulted
unless the model is forced to consult them.

## Closing observation

The strongest single piece of evidence for this entire failure mode is that when the data needed for the check is already in context and the check still doesn't
happen, the failure cannot be attributed to information access. It is purely a consultation-discipline failure — and the fact that it persists despite users
investing significant effort in documented criteria and structural friction systems suggests it warrants attention at the training or default-behavior level, not
just at the user-prompting level.