DSAIL Quickstarts Guides Compare REST MCP tools Errors

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

{"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:

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

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