Judgment channel: external judgment relation, REQUIRES_JUDGMENT, evaluative

In one sentence: these constructs answer “who decides when the law named a criterion but only an organ knows the answer”. The author takes them when a norm’s feature is evaluative (“proportionate”, “excessive”, “reasonable time”): instead of an invented threshold, a judgment relation with an organ is declared, and the engine awaits the answer and names the wait by name.

Evaluative criteria (“proportionate”, “reasonable”) are left to a named organ: the author declares a judgment relation with its authority, and the engine waits for the answer instead of inventing a threshold.

OverviewBoundariesCorpus formsPitfalls

1. When to take it and when not to

Instead	Selection rule
Judgment channel vs court fact	The answer not yet given, to be given by an organ — a judgment relation (REQUIRES_JUDGMENT, waiting). The answer already given and recorded — an ordinary case fact with origin case_input or adjudicated (three channels of the evaluative: judgment, court fact, reading). Unknown outcome ≠ absent fact
Judgment channel vs a reading group	The text is clear; what is unknown is the criterion’s application result (“is this measure proportionate”) — judgment. The text reads two ways — an interpretation with disputed status. The Turkish constitution records the choice right in a comment (see corpus-forms.md)
origin adjudicated vs origin case_input for the answer	An organ’s answer is an assertion with origin adjudicated; without a judgment object it is accepted as an assertion of the relation. A party’s allegation is case_input. Mix them up and you get either JUDGMENT_AUTHORITY_MISMATCH or a silent closure by another’s evaluation
An open judge vs a dead rule	A query is named only if the answer CAN change the outcome: the rule live on the goal’s substitution — no neighbour decided for certain. A neighbour refuted means the rule is dead, the answer is COMPUTED with no queries, whatever the judge says
One channel vs two judges	With several live branches the query lists every judge; the order is the canonical order_requests. Two relations are two queries, not one shared

2. Minimal example

Package research.judgment.open: a measure applied to a person; whether it is proportionate is for the court to decide.

Arxo Law

external judgment relation proportionate(m: Measure) {
    authority Court;
    label ru-KZ official "Мера соразмерна";
}
relation measure_applied(p: Person, m: Measure) kind empirical {
    label ru-KZ official "мера применена к лицу";
}
relation measure_upheld(m: Measure) kind institutional {
    label ru-KZ official "мера оставлена в силе";
}

rule UpholdProportionate(m: Measure, p: Person) strict {
    label ru-KZ official "Соразмерная мера оставляется в силе";
    when measure_applied(p, m) and proportionate(m);
    then measure_upheld(m);
}

Case 1: measure_applied only. Query: evaluate truth(measure_upheld(m)). Case 2: plus the court’s answer proportionate(m) with origin adjudicated.

The engine’s actual answer (installed law, semantics law.core/0.2):

Output

law test research.judgment.open: мир research.judgment.open
  ok   [research.judgment.open#authored] tests/01-open.lawtest / urn:query:research-judgment-01
  ok   [research.judgment.open#authored] tests/02-answered.lawtest / urn:query:research-judgment-02
итого: 2 проверено, 2 прошли, 0 не прошли, 0 не исполнены; код 0

law engine check — check OK, no warnings. Case 1 answers NEITHER with evaluation_status == REQUIRES_JUDGMENT (the law computed and silent FOR A REASON — a court named, not “not established”); case 2 is TRUE_ONLY. Sensitivity: the judge’s answer changes the outcome from NEITHER to TRUE_ONLY (files tests/01-open.lawtest, tests/02-answered.lawtest) — the example is not vacuous.

Nearest wrong outcome: the same case 1 in an earlier build answered NEITHER with COMPUTED — silence indistinguishable from missing facts. The channel exists precisely to tell these two silences apart.

Second package research.judgment.power — the same device in a valid_when carrier: valid_when (measure_fit(p)) reads a judgment relation; the power’s effect never materializes before the answer (a validity condition gives no support), but the document explains the missing effect with a status, not with silence:

Facts	Question	Answer	Why
application + issuance act, no court	permit_issued	NEITHER + REQUIRES_JUDGMENT	valid_when unresolved, reason named
same + measure_fit from adjudicated	permit_issued	TRUE_ONLY	the validity condition held, effect created

3. Example across domains

• Law: the Turkish Constitution (package tr.constitution, Türkiye) — four art. 13 judgment relations (see corpus-forms.md): the right’s essence, letter and spirit, democratic order, proportionality — all with authority Court.
• Standard/protocol: EU Regulation 261/2004 (package eu.transport.air_passenger_rights, European Union) — extraordinary_circumstances: “extraordinary circumstances” wholly left to the organ’s evaluation; the carrier_exempt_from_compensation head with no producer in the package — on purpose.
• Custom/ethics: the “Ochered” queue (package usus.corpus.ochered, customary practice) — absence_adjudged_excessive: the organ is the queue itself (authority TheQueue), next to a competing disputed-status interpretation reading: judgment vs reading in one file.
• Criminal law/teaching case: RK Criminal Code art. 102 (package kz.corpus.criminal_code, Kazakhstan): the court’s answer on the art. 32 channel closes the corpus delicti; the judgment_requests(0) expectation records that no judges are open. research.judgment.power — the same scheme in miniature.

4. How the engine answers

Table — actual runs of this directory’s examples (installed law, semantics law.core/0.2):

Facts	Question	Answer	Why
measure applied, no court	measure_upheld	NEITHER / REQUIRES_JUDGMENT	a live conjunct is a judgment relation
measure applied + adjudicated answer	measure_upheld	TRUE_ONLY	the judge closed the conjunct
application + act, no court	permit_issued	NEITHER / REQUIRES_JUDGMENT	valid_when is a channel carrier
application + act + adjudicated answer	permit_issued	TRUE_ONLY	effect materialized

• The result carries a typed JudgmentRequest in results[].judgmentRequests; the why_not root answers with the same status and the same query set as the same goal’s truth.
• A channel carrier is ANY status formula the program computes: a rule body, valid_when, a goal condition, a defeater condition, a transition guard/requires, a derived predicate over them, duty activation (PENDING + a query in positions), a conditional priority, a constraint require.
• A formula’s open judges: a literal open at NEITHER; status tests per the status-test table (not_known(J) at NEITHER gives no query); and/or by union of open members; the condition’s form irrelevant.
• A dead formula gives no query: a false neighbour (a refuted literal, a false comparison, false), a BOTH conflict, a defeater win with no priority, an immunity-locked effect.
• An organ’s answer without judgment is accepted as an assertion; with judgment, the organ (JUDGMENT_AUTHORITY_MISMATCH) and the form (JUDGMENT_PAYLOAD_MISMATCH) are checked; a rejected answer leaves REQUIRES_JUDGMENT.

Documented outcomes (earlier scenarios)

The rows below record earlier scenario content (given/ask/expect) as documented outcomes; no new example packages were created for them:

Case (given)	Question (ask)	Expectations (expect)	Scenario
licence_class(alpha, first) with origin case_input	truth(reliable(alpha))	NEITHER + REQUIRES_JUDGMENT	“judge did not answer”
contract_signed + penalty_notice	truth(penalty_imposed)	NEITHER + REQUIRES_JUDGMENT, not issue(POWER_INVALID_EXERCISE)	“judge in valid_when”
same + breach_material with origin adjudicated	truth(penalty_imposed)	TRUE_ONLY + COMPUTED	“adjudicated assertion closes valid_when”
contract_signed + penalty_notice + force_majeure (no court answer)	truth(penalty_imposed)	NEITHER + COMPUTED	“immunity silences the judge” (a locking immunity also silences the query)

5. Common mistakes

1. Expecting FALSE_ONLY instead of NEITHER — a silent judge does not mean “the condition is unmet”: neither ACTIVE nor achievement follows from it (pitfalls.md, item 1).
2. A court answer filed as case_input instead of adjudicated — the channel never closes; or the reverse: another’s evaluation filed as adjudicated (pitfalls.md, item 2).
3. A dead rule awaiting a judge — no: liveness reads before the query; a refuted neighbour kills the query (pitfalls.md, item 3).
4. A question without kind: "literal" is rejected QUERY_INVALID before computation, never answered COMPUTED (pitfalls.md, item 4).
5. An evaluative feature written as a number (“excessive = over 42 hours”) instead of a channel — an invented threshold for an organ; or the reverse: the countable given to the judge (pitfalls.md, item 5).
6. authority as a person’s name, not an institution: the identifier is checked by equality, needs no declaration, and a typo gives eternal waiting on the wrong organ (pitfalls.md, item 6).

6. References

• The evaluative takes three channels: judgment, court fact, reading.
• Sample: court-answer scenario tests in package kz.corpus.criminal_code (Kazakhstan, art. 102).
• The vocabulary-side syntax of the channel is the external_judgment_item production: authority, the optional request_schema, and labels — see vocabulary; the wait-and-answer semantics (REQUIRES_JUDGMENT, JudgmentRequest, liveness) is here, above.

7. Grammar: excerpt from the grammar

Show syntax reference

The body production of a judgment relation (the parent external_judgment_relation declares the header and binds the body; vocabulary lives on vocabulary):

Grammar

external_judgment_item  = "authority", identifier, ";"
                        | "request_schema", type_ref, ";"
                        | label_item ;

The body takes only the organ (authority is required; without it LDC-E0201, see pitfalls.md, item 10), an optional request schema and labels — checked word-for-word against the grammar.