Before two requests share an answer, decide what they share.

Matching text can conceal different purposes. Different text can describe the same intended work.

A useful reuse boundary identifies the conditions under which a stored contribution remains appropriate. The boundary may depend on data version, permissions, parameters, recipient, required precision, or the action the answer will support.

Those conditions are part of the design.

Start with an ordinary contrast.

One reader asks how a system behaved during a past incident. Another asks whether it is safe to rely on the system now. Both may mention the same component and failure.

The historical explanation can inform the current inquiry. It cannot establish present health by itself.

The contributions overlap without being interchangeable.

Ask what the reuse decision knows.

Does it see the source version? The caller's responsibility? A changed constraint? The difference between drafting a possibility and authorizing an action?

If relevant conditions are absent from the representation, a lookup can appear successful while returning material whose fit has never been established.

This does not mean every request requires a universal semantic model. It means the particular reuse mechanism should have a defensible account of what it treats as equivalent—and what it leaves for another stage to check.

Examine a boundary case.

Choose one pair of requests that clearly should share work. Then choose a superficially similar pair that should not. Explain the difference in ordinary language before selecting a metric.

That small exercise can reveal a missing source condition, an implicit permission, or an assumption carried from one mission to another.

Read context reuse, freshness, and the comparison baseline.

The useful question is not how broadly reuse can be extended. It is how well the chosen boundary serves the work.