The uncertain parts of a system do not disappear when the interface only offers yes and no.
Start with the kind of uncertainty
Missing information, conflicting evidence and an old observation are different problems. They may all prevent a confident answer, but they suggest different next steps.
Keeping those states distinct gives the rest of the system something useful to work with. A stale reading may need refreshing. A conflict may need inspection. Missing evidence may remain missing.
Carry context across boundaries
When one service hands a result to another, it is tempting to send only the value. But a value without provenance, freshness or a reason for abstaining can become misleading as it travels.
The contract should preserve the context that changes how the value can be used. That does not mean sending every detail everywhere; it means deciding which details are necessary for a responsible decision.
Make recovery legible
An interface should give people a way to understand what happened and what they can do next. Uncertainty is easier to live with when it has a name, a reason and a clear boundary.
A system does not need to know everything. It does need to avoid pretending that it does.