Known gaps as a first-class design pattern.

A known gap is an explicit, machine-readable statement that some value, answer, decision, or verification step is missing, uncertain, deferred, disputed, or intentionally withheld. The core design move is modeling that state as data, rather than leaving it implicit in silence, a blank field, or a generic null. Across software, science, and AI, the same lesson keeps reappearing: unmodeled absence is invisible. Modeled absence is searchable, triageable, measurable, and governable.

Software already solved this — for work, not for truth

GitHub Issues turns "this problem exists but isn't solved yet" into an addressable object with labels, assignees, milestones, and explicit dependency edges. LaunchDarkly turns "this flag should eventually disappear" into lifecycle stages — "ready for code removal," "ready to archive" — backed by prerequisite graphs and code-reference scans. SonarQube turns maintainability problems into debt-bearing issues with remediation cost and explicit statuses like Accepted or False Positive. Sentry and Alertmanager keep noisy or lower-priority signals visible by archiving, silencing, or inhibiting them instead of pretending they never existed.

The strength of these tools is operational discipline: identifiers, ownership, timestamps, dependencies, and APIs are standard. Their weakness is semantic flattening — they're excellent at representing unresolved work, much less precise at representing unresolved truth conditions. A GitHub issue and a low-confidence model answer both need triage, but they aren't the same kind of gap.

Wikibase has the gold-standard semantics for missingness

Wikibase distinguishes ordinary values from two special ones: a statement can explicitly mean no value or unknown value. "No value" isn't the same as failing to record anything — it's an assertion that the correct value is explicitly none. "Unknown value" is a positive statement that the information is not known or not preserved. Combined with qualifiers, references, and rank, a claim can be unknown, sourced, disputed, and historically bounded, and still remain fully queryable. That combination — special values plus qualifiers plus references plus rank — cleanly separates four questions most systems collapse into one field: what is the proposition, what is known about its value, what supports it, and how contested is it.

Schema.org is the useful contrast: flexible and extensible, but with no native equivalent of Wikibase's unknown/no-value states, so implementers fall back to omission or custom extensions. PROV-O supplies the provenance backbone — who generated a statement, when, through what process — but doesn't itself carry the epistemic state. The best architecture combines all three: Wikibase-style gap semantics, a PROV-style provenance backbone, and application-specific workflow metadata.

Science treats "we don't know yet" as a spectrum, not a binary

A paper's "open questions" section is a human-readable gap register — powerful for setting an agenda, but rhetorical: the gaps are visible to readers and not typed or queryable. Preregistration and Registered Reports go further, converting "the answer isn't known yet" into a public protocol object with timestamps and a planned resolution path, reviewed before results exist. PREreview externalizes unresolved concerns as DOI-linked comments. Reproducibility registries make "has this been independently checked?" a trackable state instead of an unasked question.

AI systems generate the signal and then throw it away

Uncertainty modeling (Monte Carlo dropout, deep ensembles), selective prediction and abstention, calibration, and hallucination detection (SelfCheckGPT-style consistency scoring) all surface "we don't know enough" at inference time. The recurring failure is that most systems never persist those states as durable objects — the uncertainty is a fleeting runtime signal instead of a record with an owner, a review date, and a resolution path.

A concrete schema

The core recommendation for an AI knowledge system: represent unresolved facts as typed, persistent records with separate fields for semantic state (what's true about the value itself — unknown, no-value, disputed, low-confidence) and workflow state (what the organization intends to do about it — triaged, needs-evidence, accepted-risk, resolved). Don't overload a single boolean like known=true/false, and don't let a raw null mean five different things. Every unresolved fact should carry provenance, evidence, calibrated confidence, an owner, and an audit trail — exposed in the UI and the API, not buried in logs.