Markdown for LLMs

Queries: corpus forms

The source Markdown for this article. Copy it into your assistant or download it as a text file.

# Queries: corpus forms

Analysis of real fragments: package identifier, act name, the key fragment, form rating
(exemplary / debatable / wrong-form choice) and why.

## 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:

```law
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:

```law
    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):

```law
    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:

```law
    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:

```law
    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:

```law
    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:

```law
    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" |