# Policy check when a value cannot be determined from the document

How to check a policy against a document that does not settle every fact — submit unknown, get UNKNOWN back, and never let a missing value read as a pass or a failure.

Real documents do not answer every question a policy asks. The receipt is missing; the closure date is not on the page; the vendor field is blank. A check that forces every fact to a value fabricates the ones it lacks. In DSAIL, unknown is an answer, not a guess.

## The integrity rule

The service states one rule to every extractor, in the prompt pack and in the
validation contract, verbatim:

> unknown is a first-class answer. If you cannot determine a claim's value from
> the evidence, submit the string "unknown" (or JSON null). Never guess, never
> substitute a type-correct placeholder to satisfy a validator, and never omit
> the claim. A guessed value produces a confident TRUE or FALSE about a
> situation that does not exist, which is worse than no answer; "unknown"
> produces an honest UNKNOWN.

A claim submitted as `"unknown"` is accepted by validation. A claim *omitted*
is a validation failure — the check needs to know you looked.

## What the check returns

```json
{"claims": {"bound": ["amount"], "unbound": ["has_receipt"]},
 "rules": [
   {"rule": "receipt_over_75", "assertions": [
     {"name": "receipt_over_75", "check": "UNKNOWN", "unknown_policy": "neutral"}]},
   {"rule": "within_cap", "assertions": [
     {"name": "within_cap", "check": "TRUE", "unknown_policy": "neutral"}]}]}
```

`within_cap` needed only the amount and answers `TRUE`. `receipt_over_75`
needed the receipt and answers `UNKNOWN`: not a pass, not a failure, a fact
the document did not settle. `claims.unbound` names exactly which values were
missing, so the follow-up — ask for the receipt — is obvious.

## Choosing how a rule treats the unknown

Each assertion may declare how an unknown resolves:

```text
assert receipt_over_75 [pessimistic] { Implies(amount > 75 "USD", has_receipt) };
```

- `neutral` (the default): the assertion answers `UNKNOWN`.
- `pessimistic`: a missing fact is taken the way least favourable to the
  assertion holding.
- `optimistic`: the reverse.

This is a policy decision, made in the ruleset where a person reviews and
approves it — not a default buried in an extractor.

## Unknown for a different reason: units

A rule comparing a claim in one unit against a literal in another answers
`UNKNOWN` when nothing bridges the pair — an exchange rate, say, which the
service ships without because a rate is not a constant. The response names the
missing converter per rule, and a converter with a factor a person supplied
makes the comparison resolve. The service never invents the factor.

## Why this matters for the same answer every time

A check that guesses is a check that changes with the guesser. Keeping
`UNKNOWN` distinct from `FALSE` is what lets the same facts give the same
answer every time, and what lets a person trust that a `FALSE` was a rule that
decided, with a counterexample, rather than a hole in the document.

## Try it

- [Quickstart: Codex](../quickstart/codex.md) — a retention check where one fact is unknown.
- [Which rule decided](which-rule-decided.md) — the four results and the counterexample.