# Distinguish compliance from truth

## Intent

I want to distinguish compliance from truth.

## Wrong form and why it stays silent

A compliance query is not supported by the current query schema. Replacing it with truth without naming the boundary would give a different result.

```text title="Incorrect form"
evaluate compliance(safe(entity_ref("urn:recipe:m-queries:p")));
```

## Correct form

```law
language "law.core" version "0.2";
package recipe.m08 version "1.0.0";
namespace "urn:recipe:m-queries:08";
entity Person;
relation inspected(p: Person);
relation safe(p: Person);
constraint Safety(p: Person) { when inspected(p); require safe(p); severity warning; }
```

## Frozen execution scene

| Input / variant | Question | Expectation |
|---|---|---|
| 1. requirement refuted | `truth(safe(entity_ref("urn:recipe:m-queries:p")))` | `truth_status == FALSE_ONLY;  evaluation_status == COMPUTED;  issue(CONSTRAINT_VIOLATED);` |
| 2. requirement unknown | `truth(safe(entity_ref("urn:recipe:m-queries:p")))` | `truth_status == NEITHER;  evaluation_status == COMPUTED;` |
| 3. requirement established | `truth(safe(entity_ref("urn:recipe:m-queries:p")))` | `truth_status == TRUE_ONLY;  evaluation_status == COMPUTED;` |

```law
test "refuted requirement violates constraint" {
    given {
        context { legal_time @2026-09-13; decision_time @2026-09-13T09:00:00Z; knowledge_time @2026-09-13T09:00:00Z; timezone "UTC";  }
        assert inspected(entity_ref("urn:recipe:m-queries:p")); assert not safe(entity_ref("urn:recipe:m-queries:p"));
    }
    evaluate truth(safe(entity_ref("urn:recipe:m-queries:p")));
    expect truth_status == FALSE_ONLY; expect evaluation_status == COMPUTED; expect issue(CONSTRAINT_VIOLATED);
}
```

```law
test "unknown requirement leaves neither" {
    given {
        context { legal_time @2026-09-13; decision_time @2026-09-13T09:00:00Z; knowledge_time @2026-09-13T09:00:00Z; timezone "UTC";  }
        assert inspected(entity_ref("urn:recipe:m-queries:p"));
    }
    evaluate truth(safe(entity_ref("urn:recipe:m-queries:p")));
    expect truth_status == NEITHER; expect evaluation_status == COMPUTED;
}
```

```law
test "established requirement satisfies" {
    given {
        context { legal_time @2026-09-13; decision_time @2026-09-13T09:00:00Z; knowledge_time @2026-09-13T09:00:00Z; timezone "UTC";  }
        assert inspected(entity_ref("urn:recipe:m-queries:p")); assert safe(entity_ref("urn:recipe:m-queries:p"));
    }
    evaluate truth(safe(entity_ref("urn:recipe:m-queries:p")));
    expect truth_status == TRUE_ONLY; expect evaluation_status == COMPUTED;
}
```

In each scene, after the truth answer there is a standalone result:

| Scene | resultKind | target | normativeStatus | applicabilityStatus |
|---|---|---|---|---|
| 1 | CONSTRAINT | Safety | VIOLATED | APPLICABLE |
| 2 | CONSTRAINT | Safety | UNDETERMINED | APPLICABLE |
| 3 | CONSTRAINT | Safety | SATISFIED | APPLICABLE |

The constraint_check proof node is checked. Separately a wrong
query is presented that is not in the normative JSON schema:

```json
{"queryId":"urn:recipe:m-queries:08:unsupported","kind":"compliance","target":"urn:recipe:m-queries:08#Safety"}
```

The measured refusals differ between implementations: one engine exits non-zero with an error object on stdout, the other raises a value error; both messages are English. There is no refusal parity. A refusal with QUERY_INVALID is required before computation, so this is a defect of both implementations’ input check, additionally diverging in the form of the refusal. Both refusals are kept without normalization.

CONSTRAINT is a constraint result, not an implementation of COMPLIANCE:
here there is no full contract of required_values, actual_values, deviations, and
violated_positions. A compliance query is still unavailable; below
lies precisely the measured boundary and a neighbouring executable example.

Check of result fields and extra inputs:

```python
>>> import runpy
>>> checks = runpy.run_path("docs/recipes/m-queries/resources/check.py")
>>> checks["compliance"](https://github.com/arxohq/law/blob/master/docs/recipes/m-queries/8)
True
```

## Counterfactual

The sidecar mutation reproduces `LDC-E2105`. Counterfactual table variants are executed separately; input errors are not passed off as NEITHER.

## Boundary

The correct form above is an executable constraint, not an implementation of COMPLIANCE. Its target/status/proof are checked as CONSTRAINT. The full required_values/actual_values/deviations contract remains unsupported; FAIL does not replace it.

## Pitfall

A constraint finding is not automatically a violated legal position — see [Forbid an incompatible combination](/recipes/g-concepts/non-deriving-constraint/).