Disclosure: I’m Esteve Castells, the maker of DomScan.

Domain intelligence often enters an application as a simple question. Is this domain available? Does this DNS record exist? Is an email security control configured? Did a public identity signal appear on the website?

The easiest response model is a boolean. It is also frequently the wrong one.

Checks against public internet evidence can time out, return incomplete data, hit access restrictions, or encounter an unsupported input. If an application converts every inconclusive result into false, it creates confident answers that the evidence never supported.

The boolean trap

Imagine a domain availability check that returns no conclusive result. Mapping that response to available: false makes the domain look registered. Mapping it to available: true is worse because a user may act on it. The honest answer is that availability could not be determined from the evidence available at that time.

The same problem appears in security and identity workflows:

• A blocked reputation check does not prove a domain is safe.
• A missing public profile does not prove the profile does not exist.
• A failed DNS lookup does not prove the record is absent.
• An unavailable certificate source does not prove no certificate was issued.

These are not edge cases to hide. They are states the product must represent.

Model evidence separately from interpretation

A useful internal contract gives uncertainty its own vocabulary. For example:

type EvidenceState =
  | "observed"
  | "absent"
  | "unknown"
  | "not_requested"
  | "unsupported";

interface EvidenceResult<T> {
  state: EvidenceState;
  value: T | null;
  checkedAt: string;
  confidence?: "high" | "medium" | "low";
  caveats: string[];
}

This structure separates what the check observed from what the application decides to do next. A product can still define policy, such as requiring a high-confidence result before approving a workflow, without rewriting missing evidence as a factual absence.

It also prevents null from carrying five unrelated meanings. null alone cannot tell a caller whether a check failed, was skipped, is unsupported, or found authoritative evidence of absence.

Unknown states affect the whole system

Once uncertainty becomes part of the contract, several implementation decisions improve.

Retries become selective. An unknown caused by a timeout may be eligible for a bounded retry. An unsupported input is not.

Caching becomes safer. A conclusive observation and a temporary unknown can use different freshness policies. The original check time should remain attached to both.

Alerts become quieter. Monitoring can distinguish a real change from a failed observation. Losing visibility is important, but it is not the same event as proving that a record disappeared.

Scores become explainable. A risk score can report incomplete coverage instead of silently treating every unchecked signal as neutral.

User interfaces become more honest. Presenting “unknown” with a short caveat helps a user decide whether to retry, investigate manually, or continue with reduced confidence.

Documentation is part of the data model

An enum is not enough. Developers need to know what qualifies as observed or absent, when a result becomes unknown, which timestamps describe the evidence, and whether cached data was used.

That is why the DomScan documentation publishes operation inputs, outputs, costs, limits, and evidence boundaries. The goal is not to make external data look perfectly certain. It is to make its uncertainty usable.

The practical lesson

Building domain intelligence workflows changed how I think about API quality. A clean success response is useful, but a precise incomplete response can be more valuable than an unjustified answer.

Before adding another boolean to an integration, ask what happens when the evidence is blocked, stale, partial, unsupported, or never requested. If those cases collapse into the same value, the schema is hiding information your users may need.

Unknown is not a failure of the data model. Often, it is the most accurate result the system can return.