Markdown for LLMs
Four states of support
The source Markdown for this article. Copy it into your assistant or download it as a text file.
# Four states of support
Aigerim received two records about Ivanova. The registrar confirms her
accreditation, while the ethics committee reports that the accreditation
was revoked. Both records concern the moment the question is asked about.
Which one should count? Before deciding, we need at least to preserve
the disagreement itself.
Dana suggests comparing four cases: only a confirmation, only a revocation
decision, both records, neither. For the last case we take Petrov: no
evidence of his accreditation was passed to us. A single "yes" or "no"
mark is not enough to tell all four situations apart.
Let us work through them together with Aigerim. The Archive of Veliky
Ustin, its rules, and the people in the story are fictional. We will
return to the familiar rare-collections room access rule and see how each
evidence set affects the answer. If you want to run the example right
away, go to the ["Run"](#run-get-the-answer) section.
## Question: how many answers does one question have?
Try describing each answer in plain words before reading the table. Note
the distinction: a revocation decision gives grounds for a negative
answer. Missing evidence gives no such grounds.
| Accreditation evidence | Expected answer |
|---|---|
| Only the registrar's confirmation | Established |
| Only the committee's revocation decision | Refuted |
| Both the confirmation and the revocation decision | Grounds for the statement and for its denial |
| No records: Petrov's case | Neither established nor refuted |
In the first chapter we already met two of these answers: "established"
and "neither established nor refuted". Now refutation and contradiction
are added. If only one "yes" or "no" value is kept, we must additionally
decide how to represent a gap in the evidence and what to do when records
disagree. Whether another person can understand the original situation
will depend on those decisions.
## Record: two supports for each statement
We use the vocabulary and the rule familiar from the first chapter. To
establish access, one must confirm that the person is listed in the
researcher registry and holds a valid accreditation.
```law
language "law.core" version "0.2";
package tutorial.archive version "0.2.0";
namespace "urn:law:tutorial:archive";
entity Person;
relation in_researcher_registry(p: Person) kind institutional;
relation accredited(p: Person) kind institutional;
relation may_enter_rare_room(p: Person) kind institutional;
rule RareRoomAccess strict {
for p: Person;
when in_researcher_registry(p) and accredited(p);
then may_enter_rare_room(p);
}
```
We represent the revocation decision as a negative statement:
`assert not accredited(…)`. This record has its own name and an origin
note, like a positive statement. In this way we explicitly report the
absence of accreditation.
For the answer, Arxo counts separately the grounds for the statement
and the grounds for its denial. They are called the positive and the
negative support. Is there at least one support "for"? Is there at
least one support "against"? The four combinations of answers to these
two questions give the four states of support.
Positive and negative support do not destroy each other. If our example
holds both, the model keeps the contradiction. The order in which we
wrote the evidence does not itself decide which of them to prefer.
## Run: get the answer
You will need a copy of the repository and Rust with Cargo installed.
Open a terminal at the repository root and run the commands below. Then
keep working in the same window: it will keep the paths you set. The
`check` command will verify the package, and `lower` will prepare
the program for running.
```bash
cd engines/lawc
tutorial_dir=../../docs/tutorials
tutorial_page="$tutorial_dir/02-four-states.en.law.md"
cargo run -q --profile gate -p law-cli -- check \
"$tutorial_page"
tutorial_work=$(mktemp -d)
cargo run -q --profile gate -p law-cli -- lower \
"$tutorial_page" > "$tutorial_work/program.lawir.json"
```
Let us start with the case holding both accreditation records. We add
the evidence that Ivanova is listed in the researcher registry. In one
test we ask two questions: is her accreditation established, and is
room access established?
For accreditation we expect `BOTH`: there are grounds for the statement
and for its denial. For access we expect `NEITHER`: it is neither
established nor refuted. Below we will work out why the answers differ.
```law
test "Иванова: запись регистратора и отзыв комиссии" {
given {
context {
decision_time @2026-03-01T09:00:00+05:00;
knowledge_time @2026-03-01T09:00:00+05:00;
legal_time @2026-03-01;
timezone "Asia/Almaty";
}
assert in_researcher_registry(entity_ref("urn:tutorial:ivanova")) {
id "assert-reg";
origin case_input;
}
assert accredited(entity_ref("urn:tutorial:ivanova")) {
id "assert-acc";
origin case_input;
}
assert not accredited(entity_ref("urn:tutorial:ivanova")) {
id "assert-revoked";
origin case_input;
}
}
evaluate truth(accredited(entity_ref("urn:tutorial:ivanova")));
expect truth_status == BOTH;
evaluate truth(may_enter_rare_room(entity_ref("urn:tutorial:ivanova")));
expect truth_status == NEITHER;
}
```
The test name reads: "Ivanova: the registrar's record and the committee's revocation."
A ready-made test for this case ships with the tutorial.
The first command runs the check, the second shows the explanation of
the accreditation:
```bash
cargo run -q --profile gate -p law-cli -- test \
"$tutorial_dir/tests/02-both-and-neither.lawtest" \
--lawtest --program "$tutorial_work/program.lawir.json"
cargo run -q --profile gate -p law-cli -- explain \
"$tutorial_dir/tests/02-both-and-neither.lawtest" \
--program "$tutorial_work/program.lawir.json"
```
A `test PASS` message means both answers matched the expectations. In
the accreditation explanation, find the `assert-acc` and `assert-revoked`
records: the first supports the statement, the second its denial. The
`BOTH` answer preserves evidence of both.
Here it matters to tell two results apart. `PASS` reports that the test
went through. `BOTH` describes the state of the statement being checked.
A contradiction in the input evidence may be the expected result of
a correctly executed check.
Now let us collect all designations in one table:
| Support "for" | Support "against" | Designation | Answer in words |
|---|---|---|---|
| present | absent | `TRUE_ONLY` | established |
| absent | present | `FALSE_ONLY` | refuted |
| present | present | `BOTH` | grounds for and against |
| absent | absent | `NEITHER` | neither established nor refuted |
Back to access. Under our rule, accreditation must be established with
no support for its denial, i.e. hold the `TRUE_ONLY` status. The registry
entry alone is not enough for the conclusion.
Keeping the registry entry established, let us see how access changes
with each accreditation state:
| `accredited` | `may_enter_rare_room` |
|---|---|
| `TRUE_ONLY` | `TRUE_ONLY` |
| `FALSE_ONLY` | `NEITHER` |
| `BOTH` | `NEITHER` |
| `NEITHER` | `NEITHER` |
The last three rows give the same answer about access, though the
accreditation evidence in them differs.
With `FALSE_ONLY`, accreditation is refuted. The rule condition fails,
so access does not follow from it. But this rule does not derive
a refusal: after `then` only the positive access statement is recorded.
Refuting it would need a separate ground, for example another rule or
an explicitly entered negative statement.
With `BOTH` there is a contradiction. Such a state also fails the
`accredited(p)` condition in our rule. We did not state how to resolve
the conflict between the records, so the rule picks neither of them
and does not derive access.
With `NEITHER` the accreditation evidence is missing. Again the rule
does not apply, and no grounds appear for denying access. To make sense
of such an answer, it helps to look not only at its designation but at
the state of each premise.
## Contrast: a table and Python
Let us see how the same evidence can be represented in Python. We start
with a dictionary mapping each person to one `True` or `False` value.
Then we try storing positive and negative support separately.
In the example below, lines with `>>>` are entered commands, lines with
`...` their continuations. Under a command returning a result, that
result is shown.
```python
>>> accredited = {"ivanova": True}
>>> accredited.get("petrov", False)
False
>>> records = [("ivanova", True), ("ivanova", False)]
>>> dict(records)["ivanova"]
False
>>> support = {"ivanova": {"for", "against"}, "sidorov": {"for"}}
>>> def status(name):
... s = support.get(name, set())
... return {("for",): "TRUE_ONLY", ("against",): "FALSE_ONLY",
... ("against", "for"): "BOTH", (): "NEITHER"}[tuple(sorted(s))]
>>> status("sidorov"), status("ivanova"), status("petrov")
('TRUE_ONLY', 'BOTH', 'NEITHER')
```
In the first query Petrov is absent from the dictionary. We supplied
`False` as the default ourselves, so we got it back. If such an answer
is read as a refutation of accreditation, missing evidence becomes
indistinguishable from a negative statement.
Next, the dictionary `dict(records)` is built from two records about
Ivanova. Both records use one key, so the last value, `False`, is kept.
Swap the lines and `True` remains. The result depends on the record
order, and the evidence of their contradiction is no longer visible in
such a dictionary.
In the last part the data is arranged differently: each person holds
a set of supports. The `status` function tells all four combinations
apart. In the call shown, Sidorov's accreditation is established,
Ivanova's holds a contradiction, and about Petrov there is no evidence.
So the needed distinctions can be represented explicitly in Python too.
A table can likewise have separate "for" and "against" columns. The
ability to preserve such evidence does not belong to one tool. Arxo sets
the shared semantics of these states: how they arise, how they are
checked in rule conditions, and how they relate to the explanation of
the answer. When working in Python or in a table, these conventions must
be provided for in the arrangement of the program or the data.
The choice depends on the task. For a small calculation a table or
a short function may suffice. But if you pass models to other people,
a shared way of representing gaps, contradictions, and grounds of
derivation helps them understand your record and verify the result.
## Practice: four cases and two ways to say "no"
Copy the ready-made test into a temporary directory and first run it
unchanged. It should pass with the previous answers: `BOTH` about
accreditation and `NEITHER` about access.
```bash
tutorial_try=$(mktemp -d)
cp "$tutorial_dir/tests/02-both-and-neither.lawtest" \
"$tutorial_try/try.lawtest"
cargo run -q --profile gate -p law-cli -- test \
"$tutorial_try/try.lawtest" \
--lawtest --program "$tutorial_work/program.lawir.json"
```
Now open the `try.lawtest` copy and delete the whole negative statement
block named `assert-revoked`. Before running the test, explain why both
answers should become `TRUE_ONLY`. State these expectations after the
matching `evaluate` lines and repeat the `test` command from the block
above.
For the next experiment, restore the original copy. Delete the positive
`assert-acc` statement, keeping `assert-revoked`. Now accreditation should
be refuted, `FALSE_ONLY`, and access stay `NEITHER`. State these
expectations and verify them. Finally, delete both accreditation records:
both answers should become `NEITHER`.
In all experiments keep Ivanova's registry entry. That way it is clear
the result changes because of the accreditation evidence.
Then carry out [the four-cases exercise](/tutorials/exercise-four-states/):
pick input evidence so that the access question receives each of the four
answers without changing the package. In
[the negation exercise](/tutorials/exercise-negation/) two ways of saying
"not accredited" are compared. It is easier to return to it after the
next lesson.
## Acceptance: what you can check yourself
Before moving on, make sure you can explain the results of each
experiment:
- Confirmation and revocation together give accreditation `BOTH`.
Access stays `NEITHER`.
- Confirmation alone gives `TRUE_ONLY` for both accreditation and access.
Revocation alone gives accreditation `FALSE_ONLY`, access `NEITHER`.
- With neither accreditation record, both answers are `NEITHER`.
Such an answer differs from a refutation.
- In the first Python example the default hides missing evidence. In the
second, the repeated key hides the contradiction. Storing supports
separately preserves both distinctions.
- A passing test and the state of the checked statement are different
things: a test expecting `BOTH` may pass.
## Boundary: what is not yet done here
Our package holds only the rule from which access follows. So in the
experiments above, access is either established or neither established
nor refuted. That is a limitation of the chosen example. A strict rule
may also derive a negative statement; such a case is covered in the
lesson [on negation](/tutorials/negation/).
We also did not determine which of the contradicting records takes
priority and from which date it should count. That needs additional
evidence and rules. We will return to exceptions and priorities in the
lesson [on defeat and priority](/tutorials/defeaters/).
Finally, a support state is not a probability estimate or a guarantee of
truth. `TRUE_ONLY` means our model holds grounds for the statement and
no support for its denial. The reliability of the evidence itself still
needs to be assessed. `BOTH` reports both supports but does not claim
they are equally convincing.
Now Aigerim can pass on the answer together with the material
distinction: the statement is confirmed, refuted, disputed, or so far
without sufficient grounds either way. **"We do not know" and "we hold
contradicting evidence" are different answers, and both are worth
keeping.**