Distinguish compliance from truth

Intent

I want to distinguish compliance from truth.

Correct formFrozen execution sceneBoundary

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.

Incorrect form

evaluate compliance(safe(entity_ref("urn:recipe:m-queries:p")));

Correct form

Arxo 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;

refuted requirement violates constraint

Arxo 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);
}

unknown requirement leaves neither

Arxo 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;
}

established requirement satisfies

Arxo 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.