# 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/).