A system that always gives an answer can still be a system that has stopped telling you the truth.
An empty answer carries information
Imagine an attribution system following a chain of transfers. It can see where funds moved, but a missing link prevents it from supporting a claim about their original source. Returning a confident attribution would make the interface look complete. Returning unknown would describe the evidence more accurately.
Unknown is not the same as no. It is also not the same as a failure to run. Those distinctions deserve their own representation because the next action depends on which one occurred.
Keep the reason attached
An unknown result becomes useful when it carries a reason: missing input, stale evidence, conflicting observations, or a boundary the system cannot see across. The consumer can then decide whether to gather more data, ask a person, or leave the question open.
If that reason is collapsed into a false boolean or an unexplained null, the uncertainty has not gone away. It has just moved to a part of the system that has less context.
Make room in the contract
The interface should make it possible to return a supported answer, an unsupported answer, or a known error without confusing them. That is a data-modelling decision before it is a copywriting decision.
An honest boundary is a useful feature. It tells the next person where the system’s knowledge ends.