Queries: corpus forms

Law

1. RK Civil Code art. 10 — `positions()` with a named expectation (exemplary, inspected)

Package kz.corpus.civilcode — Kazakh Civil Code (Kazakhstan), art. 10 scenario:

test "urn:query:kz-civil-code-art10-consumer-may-join-organisations" {
    given {
        context { decision_time @2026-09-12T09:00:00Z; knowledge_time @2026-09-12T09:00:00Z; legal_time @2026-09-12; timezone "UTC"; }
        assert "civil-art10-1": person_acts_as_consumer(entity_ref("urn:kz:civil:participant:art10-consumer-1")) { origin case_input; }
    }
    evaluate positions();
    expect position(ObjedinenieVObshchestvennyeOrganizatsiiPotrebiteley, ACTIVE);
}

Exemplary: the literalless kind is asked bare as positions(), while the expectation addresses a named position with a status — more pointed than result_kind alone. The same device in the art. 41, art. 133 and art. 109 scenarios of the same catalogue.

2. RK Civil Code art. 323 — canonical `truth` expectation triple (exemplary, inspected)

Package kz.corpus.civilcode — Kazakh Civil Code (Kazakhstan), art. 323 scenario:

    evaluate truth(successor_bears_all_pledgor_duties(entity_ref("urn:kz:civil:pledge:323-2")));
    expect result_kind == PROPOSITION;
    expect truth_status == TRUE_ONLY;
    expect evaluation_status == COMPUTED;

Exemplary: result kind, truth status and computation status — all three axes. The same triple in the art. 192, art. 160 and art. 163 scenarios. Missing any of the three axes is debatable: a computation refusal (REQUIRES_JUDGMENT, a term error) walks past a test checking one truth_status.

3. Uzbek Civil Code — positive/negative pair on one predicate (exemplary, inspected)

Package uz.civil_code — Uzbek Civil Code (Uzbekistan):

    evaluate truth(capacity_restricted(entity_ref("urn:uz:civil-code:test:p1")));
    expect result_kind == PROPOSITION;
    expect truth_status == TRUE_ONLY;
    expect evaluation_status == COMPUTED;

Nearby a second test with the same question minus the court fact: truth_status == NEITHER at COMPUTED. Exemplary: the pair’s sensitivity proves the positive is not vacuous — the same device as in research.queries.truth_why_not (cases 01/02).

4. RK Civil Code art. 9 item 4 — the answer side of `positions()`: a `duty` head (exemplary, inspected)

Package kz.corpus.civilcode — Kazakh Civil Code (Kazakhstan), art. 9 item 4:

    then duty VozmestitPolnyeUbytkiNarushennogoPrava {
        ...
        beneficiary claimant;
        achieve claim_full_loss_compensation(protection_case) during [@1995-03-01, infinity);
    };

Exemplary as the answer side: the compact achieve … during … target (the same form as in research.queries.collect_positions), carrier and beneficiary — the rule’s bound variables. Note: in the file the carrier is written in the capital form predating the lowercase-keyword requirement; new examples use only lowercase bearer.

Conformance scenarios

5. `why_not` with nine witnesses and a continuation cap (exemplary, inspected)

A conformance scenario with nine notice facts:

    evaluate why_not(contract_avoided(entity_ref("urn:law:vectors:e0254c#k")));

    expect result_kind == GRAPH;
    expect truth_status == NEITHER;
    expect evaluation_status == COMPUTED;

Exemplary: the expectations pin the root classification as with truth — GRAPH instead of PROPOSITION, but the same NEITHER/COMPUTED. Nine notice facts check the continuation cap (no more than eight per rule, truncated: true).

6. `collect` with a typed generator (exemplary, inspected)

A conformance scenario with a typed generator:

    evaluate collect v0: Text where presented_in_time(v0);

    expect result_kind == COLLECTION;
    expect evaluation_status == COMPUTED;

Exemplary: a bound variable with a type (v0: Text), the generator a positive literal. No truth_status expectations — COLLECTION has no such axis. The same skeleton with a binary relation (collect v0: Money where monthly_income(…)), with a count quantifier.

7. `positions()` with a judgment status (exemplary, inspected)

A conformance scenario with an open judge:

    evaluate positions();

    expect result_kind == NORM_POSITION;
    expect evaluation_status == REQUIRES_JUDGMENT;
    expect normative_status == PENDING;
    expect applicability_status == APPLICABLE;

Exemplary: four axes instead of three — the positional kind carries normative_status and applicability_status (NORM_POSITION). Paired with two companion scenarios (the same bare positions()).

8. The `QUERY_INVALID` refusal: wrong-arity question (exemplary, inspected)

A conformance scenario pinning the rule: a question literal whose predicate is declared with a DIFFERENT parameter count is rejected BEFORE computation with a QUERY_INVALID error object.

Exemplary as a form boundary: a question about a predicate of declared arity two asked with one argument is not NEITHER but a pre-computation refusal. Sibling scenarios cover kind-less literals, unknown polarity and literal values; one pins focused_truth in 0.2 as FOCUS_UNSUPPORTED_SEMANTICS without a result.

Corpus measurement 05.09.2026

Corpus-wide counts (508 packages): term-generator uses underlying the collect query kind:

Form	Occurrences	Packages	Usually what
`count(collect …)`	745	83	“at least two witnesses”
`sum(collect all …)`	71	23	share and sum roll-ups
`exists … in … where`	29	5	“at least one level exists”
`forall … satisfies`	2	2	“all permits registered”

Queries: corpus forms

Law

1. RK Civil Code art. 10 — positions() with a named expectation (exemplary, inspected)

2. RK Civil Code art. 323 — canonical truth expectation triple (exemplary, inspected)

3. Uzbek Civil Code — positive/negative pair on one predicate (exemplary, inspected)

4. RK Civil Code art. 9 item 4 — the answer side of positions(): a duty head (exemplary, inspected)

Conformance scenarios

5. why_not with nine witnesses and a continuation cap (exemplary, inspected)

6. collect with a typed generator (exemplary, inspected)

7. positions() with a judgment status (exemplary, inspected)

8. The QUERY_INVALID refusal: wrong-arity question (exemplary, inspected)