Markdown for LLMs
Presumptions and rebuttal
The source Markdown for this article. Copy it into your assistant or download it as a text file.
# Presumptions and rebuttal
On the last page the archive recognised a letter as received by fiction:
the act said "counts" — and there was nothing to object with. More often
a norm adds: "counts as received unless proven otherwise". That is
a presumption — a conclusion that stands by itself until someone
establishes the named rebuttal. The corpus holds 236 presumptions in 47
packages (measured 05.09.2026); 197 of their provisos derive the
opposite, 51 only remove the conclusion, and the difference between these
two forms is the page's main lesson.
Legally a presumption does not establish a fact but allocates the
burden: nobody saw the receipt, yet it is clear who must prove what to
change the conclusion. A rebuttal is an established fact, not silence.
"The service did not confirm delivery" and "the service reported
non-delivery" are different things, and only the second changes anything.
The archive sends a researcher a notice to return a document at the
registry address. Next: what counts as received, who rebuts it with what,
and what follows from a received notice.
```law
language "law.core" version "0.2";
package tutorial.archive version "0.10.0";
namespace "urn:law:tutorial:archive";
entity Person;
relation return_notice_sent_to_registered_address(p: Person) kind empirical;
relation delivery_failure_reported(p: Person) kind empirical;
relation non_residence_proven(p: Person) kind empirical;
relation address_change_unreported(p: Person) kind empirical;
relation return_notice_received(p: Person) kind institutional;
relation non_return_recorded(p: Person) kind empirical;
relation extension_granted(p: Person) kind institutional;
relation borrowing_suspended(p: Person) kind institutional;
```
## A presumption and its three provisos
A notice sent to the registry address counts as received. The reader may
prove she did not reside at that address — then the notice was not
received. But if she herself did not tell the archive about the address
change, the risk of non-receipt lies with her, and the notice counts as
received again. And a delivery-service report of non-delivery removes the
presumption while asserting nothing in return.
```law
presumption ReturnNoticeReceipt {
for p: Person;
when return_notice_sent_to_registered_address(p);
presume return_notice_received(p);
unless non_residence_proven(p) then not return_notice_received(p);
unless return_notice_sent_to_registered_address(p) and address_change_unreported(p) then return_notice_received(p);
unless delivery_failure_reported(p);
}
```
`presume` is the presumed head, `when` the premise, `unless` the provisos
in two forms: with `then` and without. There is no new mechanism behind
the word `presumption`: it is sugar over rules and priorities, and the
compiler shows the expansion via its expand command. Here it is
compressed to names, strength, and head:
```text
$ lawc expand 12-presumptions.law.md --symbol ReturnNoticeReceipt
presumption ReturnNoticeReceipt (12-presumptions.law.md:7:24)
порождено узлов CLIR: 6
rule …#ReturnNoticeReceipt/R1 defeasible return_notice_received(p)
rule …#ReturnNoticeReceipt/R2 defeasible not return_notice_received(p)
rule …#ReturnNoticeReceipt/R3 defeasible return_notice_received(p)
priority_rule …#ReturnNoticeReceipt/R3/priority/0 R3 над R2
rule …#ReturnNoticeReceipt/R4 defeater return_notice_received(p)
priority_rule …#ReturnNoticeReceipt/priority R2 над R1
```
The command names the page file; on this page run it with the `.en.law.md` filename (the "CLIR nodes produced" line counts the generated nodes, "over" marks the priority direction).
The premise became the defeasible rule `R1`. The proviso with `then
not` is the defeasible rule `R2` with the opposite head and a direct
priority over `R1`. The proviso with `then` but no `not` is rule
`R3` with priority over the previous link, `R2`. The bare proviso
is the defeater `R4`, with priority over nothing: it removes support
rather than arguing with it. All these are the tools of [the defeat
tutorial](/tutorials/defeaters/); a presumption merely assembles them
into a form matching the act's vocabulary.
## Without rebuttal
| Facts | `return_notice_received` |
|---|---|
| notice sent | `TRUE_ONLY` |
The test from this page, byte for byte:
```law
test "уведомление направлено по адресу из реестра — считается полученным" {
given {
context {
decision_time @2026-04-01T09:00:00+05:00;
knowledge_time @2026-04-01T09:00:00+05:00;
legal_time @2026-04-01;
timezone "Asia/Almaty";
}
assert return_notice_sent_to_registered_address(entity_ref("urn:tutorial:ivanova")) {
id "assert-sent";
origin case_input;
}
}
evaluate truth(return_notice_received(entity_ref("urn:tutorial:ivanova")));
expect truth_status == TRUE_ONLY;
expect evaluation_status == COMPUTED;
}
```
The test name reads: "A notice sent to the registry address counts as received."
`TRUE_ONLY` here is the support of a defeasible rule, not an established
fact. The difference shows not in the answer but in what can be done
with it: a strict support is defeated by nobody, while any of the
three provisos removes the presumptive one. The compiler rejects a strict
rule reading a presumed head (`LDC-E4103`): presumption consumers
are written defeasible.
## Block or rebut
Two provisos, two different answers.
| Facts | `return_notice_received` |
|---|---|
| sent, service reported non-delivery | `NEITHER` |
| sent, non-residence at the address proven | `FALSE_ONLY` |
The non-delivery report is the bare proviso, the `R4` defeater. It
removes the support of `R1` but does not prove non-receipt: the
answer is `NEITHER`, and the archive must look into it, not count. Proven
non-residence is the proviso with `then not`: rule `R2` derives the
opposite, the `R2`-over-`R1` priority settles the dispute, the answer is
`FALSE_ONLY`, and the archive must proceed on the notice not being
received.
The choice of form is the act author's legal decision, not a stylistic
one. The question is the same as when choosing between a defeater and
a priority: **must the authority proceed from the opposite — or must it
look into it?** Writing `then not` where the act merely removes the
presumption attributes to the act a conclusion it lacks; writing a bare
proviso where the act rebuts leaves the case at `NEITHER` when the
answer already exists.
## An exception to the exception
| Facts | `return_notice_received` |
|---|---|
| sent, non-residence proven, address change unreported | `TRUE_ONLY` |
The reader proved she did not reside at the address — but herself failed
to tell the archive about the move. The third proviso returns the
conclusion: `R3` prevails over `R2`, and the notice counts as received.
This is the proviso chain: each proviso with `then` takes priority over
the **previous link**, not over the presumption at large. The record
order is the chain order.
Hence the produced contrary rule is `defeasible`, not `strict`.
Were `R2` strict, no priority could beat it, and an exception to the
exception would make no sense. An author needing a truly irrebuttable
"not received" writes a separate strict rule with a `not` head — and then
it is no longer a presumption proviso.
## Each proviso has its own body
The second proviso repeats the presumption premise:
`return_notice_sent_to_registered_address(p) and
address_change_unreported(p)`. The repetition is no accident. A produced
rule's body is the proviso's own condition; the `when` premise is **not**
carried into it. The natural reading of the norm says the
opposite — "since this is an exception to the presumption, its conditions
are already present" — which is exactly why the rule is written out
explicitly in the specification.
| Facts | `return_notice_received` |
|---|---|
| nothing sent, address change unreported | `NEITHER` |
| nothing sent, non-residence proven | `FALSE_ONLY` |
Remove the premise repetition and the first row becomes `TRUE_ONLY`: a
reader who did not report her address would "receive" a notice nobody
sent. With the repetition cut out the answer becomes exactly this: the
lesson of the spare conclusion holds just like the lesson of the
needed one.
The second row shows the first proviso's premise is deliberately not
repeated: proven non-residence yields "not received" even without
a notice, and that is correct — an unsent notice was not received. The
rule is simple: look at each proviso as a separate norm with its own
body, and ask what it will derive when the presumption premise is not
established.
## A bare proviso strikes at the literal
| Facts | `return_notice_received` |
|---|---|
| sent, non-delivery, non-residence proven | `FALSE_ONLY` |
| sent, non-delivery, address change unreported | `NEITHER` |
The `R4` defeater removes support from **any** defeasible rule with the
same head and no declared priority over it: from both `R1` and
`R3`. In the second row the exception to the exception fired — and was
removed by the non-delivery report, because a bare proviso is no chain
link and knows no priorities. In the first row the report did not touch
`R2`: it has a different head.
Hence the record rule: a bare proviso goes **last**. Put it first and the
next proviso with `then not` takes priority over the defeater rather than
over the presumption; with proven non-residence the answer becomes `BOTH`.
The compiler accepts such an order silently: the proviso chain is acyclic,
and only the author knows it linked the wrong links. If blocking must
yield to the exception to the exception, it is written as a separate
defeater with a priority declared over it by an ordinary `priority`
declaration.
## A presumed fact feeds ordinary norms
A received notice is no end in itself: if the document was still not
returned after it, home issue is suspended — except when the term was
extended.
```law
rule SuspensionAfterNotice defeasible {
for p: Person;
when return_notice_received(p) and non_return_recorded(p);
then borrowing_suspended(p);
unless extension_granted(p);
}
```
| Facts beyond the sent notice | `borrowing_suspended` |
|---|---|
| non-return recorded | `TRUE_ONLY` |
| non-return recorded, service reported non-delivery | `NEITHER` |
| non-return recorded, non-residence proven | `NEITHER` |
| non-return recorded, term extended | `NEITHER` |
A bare premise reads as `established`: a removed presumption and
a refuted one alike leave the norm without support. Non-return here is
a control record, not silence about return, as in [the duty
tutorial](/tutorials/duty/). And `unless` on an ordinary rule is the same
machine: `SuspensionAfterNotice/unless/0` is a defeater against
`borrowing_suspended`.
## A presumption from a real act
Article 912 of the Civil Code of Kazakhstan: one who announced a reward
may withdraw the promise, except in three cases — the announcement
provided withdrawal is barred, a term for action was given, someone
already performed the action. In the corpus the three bars are three
strict rules with one head `withdrawal_barred`, and the right to withdraw
is a presumption with a `then not` proviso. Here one of the three rules
and the presumption itself, as they stand in the `public-reward` package.
```law
entity Announcement;
relation public_reward_announced(announcement: Announcement, promisor: Person) kind institutional;
relation responder_already_performed_before_withdrawal(announcement: Announcement, person: Person) kind empirical;
relation withdrawal_barred(announcement: Announcement) kind institutional;
relation promisor_may_withdraw_the_promise(announcement: Announcement, person: Person) kind institutional;
rule PerformanceBeforeWithdrawalBarsIt strict {
for announcement: Announcement;
for responder: Person;
when responder_already_performed_before_withdrawal(announcement, responder);
then withdrawal_barred(announcement);
}
presumption PromisorMayWithdrawUnlessOneOfTheThreeBarsApplies {
for announcement: Announcement;
for promisor: Person;
when public_reward_announced(announcement, promisor);
presume promisor_may_withdraw_the_promise(announcement, promisor);
unless public_reward_announced(announcement, promisor)
and withdrawal_barred(announcement)
then not promisor_may_withdraw_the_promise(announcement, promisor);
}
```
The archive director publicly promised a reward for returning a lost
file; Ivanova returned it.
| Facts | `promisor_may_withdraw_the_promise` |
|---|---|
| reward announced | `TRUE_ONLY` |
| announced, Ivanova performed the action before withdrawal | `FALSE_ONLY` |
The proviso repeats `public_reward_announced(announcement, promisor)` for
the same reason: the `R2` head names the promisor, while
`withdrawal_barred` knows only the announcement. Remove the repetition
and `promisor` in the head stays unbound.
## The same scheme via an expansion profile
A presumption has a second record form — the `rebuttable_presumption`
definition from the expansion library (reasoning-scheme
catalogue R01). An instance names cases by name and tells the two
rebuttal contracts apart explicitly:
```text
expand rebuttable_presumption ReturnNoticeReceipt {
label ru-KZ unofficial "Уведомление, направленное по адресу из реестра, считается полученным";
bind subject = p: Person;
conditions = [return_notice_sent_to_registered_address];
presumed = return_notice_received;
case blocked DeliveryFailure {
label ru-KZ unofficial "Служба доставки сообщила о невручении";
premises = [delivery_failure_reported];
}
case contrary NonResidence {
label ru-KZ unofficial "Читатель доказал, что не проживал по адресу";
premises = [non_residence_proven];
}
}
```
The labels read: "A notice sent to the registry address counts as received"; "The delivery service reported non-delivery"; "The reader proved non-residence at the address".
`blocked` is a defeater, `contrary` a contrary rule with priority over
the presumption; the CLIR nodes are byte-equal to the hand record, only
the case names are structural (`…/blocked/DeliveryFailure`), not ordinal.
What the profile does not do: proviso chains — cases are independent, and an
exception to an exception is written alongside as an ordinary rule with
priority. What it gives in return: a label on each case and no way to mix
up the proviso order.
On this page the block is shown as text because expansion is a package
dependency: the definition is connected in `law.toml` under `[expansions]`
and pinned in `law.lock`, while a literate page has no manifest. Put
`expand` in a package without a manifest and the compiler refuses:
```text
error LDC-E1336: expand ReturnNoticeReceipt: определение
"rebuttable_presumption" не разрешается (§279.1.3)
```
The diagnostic reads: 'definition "rebuttable_presumption" does not resolve'.
## Compiler refusals
A proviso that failed to bind the head variable. Remove the article-912
presumption's `public_reward_announced` repetition and the produced rule
gets a head with an unbound `promisor`:
```text
error LDC-E4101: PromisorMayWithdrawUnlessOneOfTheThreeBarsApplies/R2: head
использует несвязанные переменные [promisor] — правило не range-restricted
(§190: связывание только позитивным established-конъюнктом конечного
источника)
```
The diagnostic reads: '…head uses unbound variables [promisor] — the rule is not range-restricted: a variable must be bound by a positive established conjunct of a finite source'.
The diagnostic is named after the produced node, `…/R2`, not after the
presumption: an expansion is rejected exactly where a hand-written
defeater with the same body would have been rejected.
A proviso on a strict rule. Make `SuspensionAfterNotice` strict, keeping
`unless`:
```text
error LDC-E4110: SuspensionAfterNotice: `unless` на strict-правиле (§149) —
сделайте правило defeasible либо внесите условие применимости в strict-тело
```
The diagnostic reads: "'SuspensionAfterNotice': `unless` on a strict rule — make the rule defeasible or move the applicability condition into the strict body".
The same mutation yields a second refusal, `LDC-E4103`: the now-strict
rule reads `return_notice_received`, produced by the defeasible `R1`. A
presumption consumer cannot be strict for both reasons at once.
Both refusals belong to the language. Exceptions are written with
`unless`. The compiler rejects an unknown presumption-body item with
`LDC-E0201` rather than silently skipping it.
## Next
Presumption, defeater, and priority exhaust what the core can say about
norm against norm. The next page returns to the source: [the pinned
edition](/tutorials/pinned-edition/) — how to place an article's bytes
next to the package and verify a fragment twice, by address and by
content.
The exercise for this page is [/tutorials/exercise-presumptions/](/tutorials/exercise-presumptions/).