Markdown for LLMs

Classic problems of normative reasoning

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

# Classic problems of normative reasoning

Legal theory, deontic logic, and nonmonotonic reasoning have a short list of
problems that every serious rule system eventually meets: a default with an
exception, a duty that has already been breached, a permission that is only
silence, a term whose edge needs a judge. This page collects thirteen of
them. For each it gives the classic statement and its source, why it is hard
for rule systems, how Arxo expresses it, and which systems in this section
address the same problem with their own native forms.

**Status of this page.** The thirteen problems form a prepared bank. Each
problem has a small set of cases (two to five) whose expected outcomes are
derived from the problem text — or, where a current act anchors the norm,
from that act's text — never from any implementation. The cross-system runs
have not been performed. Nothing here is a result, and no system is ranked:
this page is a map of where the hard spots lie and who has machinery for
them, not a scoreboard.

## The machine-author question

Most of these problems are expressible in most serious systems; whether a
form exists is rarely the interesting question. Arxo assumes that models
write formalizations and people accept them, so each problem is framed for a
machine author: given only the problem text and a fixed documentation
budget, does a model write the form correctly once its work stops changing,
and does the system's stock check catch a planted error — a dropped
exception, a wrong quantifier, an evaluative term computed from case data —
before any case runs? The setup, budgets, and outcome classes are on the
[methodology](/comparisons/methodology/) page.

## How each entry reads

- **Classic statement** — the problem in a few sentences, with its original
  source.
- **Why it is hard** — the failure a naive rule encoding produces.
- **In Arxo** — the construct that carries the problem, linked to its
  language page.
- **Elsewhere in this section** — systems whose comparison pages record a
  native form for the same problem, and the systems the prepared protocol
  pairs it with. A system is named only when its page says so.

## Defaults, exceptions, and conflict

### 1. Tweety: the defeasible default

**Classic statement.** Birds fly; Tweety is a bird, so Tweety flies — until
we learn that Tweety is a penguin, and the conclusion is withdrawn. The
canonical illustration of a normal default with an exception comes from
Raymond Reiter, "A logic for default reasoning", *Artificial Intelligence*
13 (1980) ([doi:10.1016/0004-3702(80)90014-4](https://doi.org/10.1016/0004-3702(80)90014-4));
background in the Stanford Encyclopedia entry on
[defeasible reasoning](https://plato.stanford.edu/entries/reasoning-defeasible/).

**Why it is hard.** Classical logic is monotonic: adding a fact never
removes a conclusion. Encodings that fake the exception with "not penguin"
in the body tend to confuse "we know it is not a penguin" with "nobody said
it is a penguin", and two competing exceptions (a penguin that flies) are
often settled silently by rule order.

**In Arxo.** A [defeasible rule](/constructs/rule-defeasible-unless/) with an
`unless` clause or a separate defeater. Missing information about the
species leaves the default standing; the penguin fact defeats it, and the
defeat is visible in the proof. Two unordered exceptions stay a visible
conflict until a [priority](/constructs/priority/) is declared.

**Elsewhere in this section.** [Blawx](/comparisons/blawx/) studies a
published bird-flight toy act with chained defeats and a jetpack exception,
using section-defeats-section. [Catala](/comparisons/catala/) writes a
general definition plus an exception tree; [L4](/comparisons/l4/) writes
exceptions as rules guarded by negated exceptions;
[LegalRuleML](/comparisons/legalruleml/) marks rules strict, defeasible, or
defeater. The prepared protocol pairs Arxo with L4, [PROLEG](/comparisons/proleg/),
and an answer-set program.

### 2. The exception to an exception

**Classic statement.** A general rule applies; an exception removes it; an
exception to the exception restores the rule in a narrower case. The
structure goes back to the hierarchy of defaults in Reiter (1980). The norm
anchor here is the Criminal Code of Kazakhstan, Article 32 on necessary
defence: harm to an attacker within the limits of defence is not an offence,
excess of those limits restores liability, and an attack on life is a case
where excess does not arise at all.

**Why it is hard.** Three levels collapse easily into two. Dropping the
middle level makes every defence lawful; dropping the top level makes every
excess punishable. A missing fact about the nature of the attack must not be
read as the attack being on life.

**In Arxo.** An `unless` chain on a [defeasible rule](/constructs/rule-defeasible-unless/):
the language treats a carve-out from a carve-out as a first-class shape, and
a chain link stays alive in the proof. Where the levels come from separate
articles, a [priority](/constructs/priority/) with a stated reason links
them.

**Elsewhere in this section.** [Catala](/comparisons/catala/) builds exception
trees and offers an opt-in solver check for gaps and overlaps in them.
[PROLEG](/comparisons/proleg/) nests exceptions with the burden switching
side down the chain. [Blawx](/comparisons/blawx/) chains defeats between
sections. The prepared protocol pairs Arxo with PROLEG and Catala.

### 3. Rebutting versus undercutting defeat

**Classic statement.** A rebutting defeater gives a reason to believe the
opposite conclusion. An undercutting defeater gives a reason to doubt that
the premise supports the conclusion in these circumstances, without denying
either. The distinction is John Pollock's, "Defeasible Reasoning",
*Cognitive Science* 11 (1987); Phan Minh Dung's abstract argumentation
treats both as attacks between arguments: "On the acceptability of arguments
and its fundamental role in nonmonotonic reasoning, logic programming and
n-person games", *Artificial Intelligence* 77 (1995)
([doi:10.1016/0004-3702(94)00041-X](https://doi.org/10.1016/0004-3702(94)00041-X)).

**Why it is hard.** Most rule languages have one kind of exception. Writing
an undercut as a rebut produces a false negative conclusion where the right
answer is "not established"; writing a rebut as an undercut hides a genuine
conflict. An undercut of the undercut must restore the original conclusion.

**In Arxo.** Both kinds are separate forms on the
[defeasible-rules page](/constructs/rule-defeasible-unless/): a bare `unless`
or a separate defeater removes support without asserting anything (the
answer becomes "not established, not refuted"), while a contrary `unless … then not`
asserts the opposite. Two independent opposite rules without a declared
[priority](/constructs/priority/) are both preserved as a contradiction —
an answer, not an error. The [arguments and precedent](/constructs/argue-precedent/)
page covers reasoning from decided cases.

**Elsewhere in this section.** [LegalRuleML](/comparisons/legalruleml/) has a
separate defeater strength alongside strict and defeasible rules, plus
override relations. The prepared protocol pairs Arxo with an answer-set
program and a plain Python argumentation-graph script.

### 4. Conflicts between norms: specialis, superior, posterior

**Classic statement.** Three maxims settle collisions: the special norm
prevails over the general (lex specialis), the higher-ranked act over the
lower (lex superior), the later act of equal rank over the earlier (lex
posterior). They are doctrinal commonplaces without a single dated origin;
the norm anchor here is the Law of Kazakhstan "On Legal Acts" (2016), whose
articles on the hierarchy of acts and on resolving contradictions name rank
and later adoption as grounds.

**Why it is hard.** A single numeric priority flattens three different
grounds into one, and then cannot say why a norm won. Inferring "more
conditions, so more special" or "newer date, so it wins" without a stated
ground produces confident wrong answers, and two acts with the same date
need to stay visibly unresolved.

**In Arxo.** A [priority](/constructs/priority/) declaration carries an
explicit reason — specialis, posterior, and so on — and neither the number of
conditions nor a date decides anything by itself; act rank and date are
facts for a priority policy. Without an edge, incomparable candidates stay a
visible contradiction.

**Elsewhere in this section.** [LegalRuleML](/comparisons/legalruleml/)
encodes override relations between rules. [Catala](/comparisons/catala/)
expresses the special-over-general case as an exception to a general
definition, and [Blawx](/comparisons/blawx/) as one section defeating
another. Authorization languages settle conflicts by fixed combination
rules rather than by these maxims: in [Cedar](/comparisons/cedar/) a forbid
always wins. The prepared protocol pairs Arxo with PROLEG, L4, and a Python
rank-and-date script.

## Permissions and institutional facts

### 5. Weak and strong permission

**Classic statement.** Weak permission is the mere absence of a
prohibition; strong permission is an explicit norm that allows. Georg Henrik
von Wright drew the distinction in *Norm and Action* (1963), and Carlos
Alchourrón and Eugenio Bulygin developed it for whole normative systems in
*Normative Systems* (1971). See also the Stanford Encyclopedia entry on
[deontic logic](https://plato.stanford.edu/entries/logic-deontic/).

**Why it is hard.** Confusing the two gives wrong answers both ways: silence
read as permission where an explicit norm is required, and an explicit
permission ignored because a prohibition exists in another act the closure
never saw.

**In Arxo.** Strong permission is a [liberty](/constructs/liberty-immunity/):
a norm with a holder and a window that takes part in a priority conflict
with a prohibition. Weak permission is not a norm but a query result,
computed against an explicitly chosen universe, snapshot, and closure
policy; with no closure declared, absence of a prohibition stays
undetermined rather than becoming permission. See also
[prohibitions](/constructs/prohibition/) and
[negation and truth statuses](/constructs/negation-and-status/).

**Elsewhere in this section.** [Cedar](/comparisons/cedar/) denies by
default and allows only through explicit permit policies; its answer folds
"no permit" and "explicit forbid" into one Deny, told apart only by the
deciding policies. [OPA / Rego](/comparisons/opa/) treats a missing
attribute as an undefined value and closes complete rules with explicit
defaults. [Logical English](/comparisons/logical-english/) reads negation as
failure to prove. The prepared protocol pairs Arxo with L4 and Logical
English.

### 6. Counts-as: constitutive rules

**Classic statement.** Constitutive rules do not regulate existing
behaviour; they create institutional facts: X counts as Y in context C — a
signature counts as an offer, a raised gavel closes the session. John
Searle introduced the distinction in *Speech Acts* (1969); Andrew Jones and
Marek Sergot formalized it as "A formal characterisation of institutionalised
power", *Logic Journal of the IGPL* (1996).

**Why it is hard.** The brute action (the hand signed) and the institutional
fact (an offer exists) must stay apart: outside context C the first is true
and the second is not. A definition must not silently travel to another
institution, and a chain of counts-as steps must remain visible.

**In Arxo.** Three constructs share the work. A
[definition](/constructs/definition/) names a qualification ("who counts
as …") and explains its result "by definition"; a fiction on the
[presumptions and fictions](/constructs/presumption-fiction/) page orders
one thing to count as another; a [power](/constructs/power/) produces a
legal effect only when validly exercised, which is the Jones–Sergot reading
of counts-as.

**Elsewhere in this section.** [L4](/comparisons/l4/) separates
constitutive rules, declaring what counts as what, from regulative ones.
[Symboleo](/comparisons/symboleo/) gives powers that act through declared
functions such as suspend, resume, and terminate. The prepared protocol
pairs Arxo with L4 and Catala.

## Duties over time

### 7. Chisholm: contrary-to-duty obligations

**Classic statement.** Jones ought to go to help his neighbours; if he goes,
he ought to tell them he is coming; if he does not go, he ought not to tell
them; and he does not go. Roderick Chisholm showed that the standard
deontic logic turns these four natural sentences into a contradiction or
lets the breach make the primary duty disappear: "Contrary-to-duty
imperatives and deontic logic", *Analysis* (1963). The Stanford Encyclopedia
entry on [deontic logic](https://plato.stanford.edu/entries/logic-deontic/)
surveys the responses.

**Why it is hard.** A breach must remain a breach while a secondary duty —
to notify, to compensate — comes into force beside it. Encodings that derive
"there was no duty" from the fact of non-performance make the violation
vanish.

**In Arxo.** A [duty](/constructs/duty/) is a position with a holder, a goal,
and a window; its [lifecycle](/constructs/lifecycle-statuses/) records it as
violated, and a separate rule application derives the secondary duty from
that breach. The chain primary breach, compensatory duty, sanction is
explicit in the proof; the two statuses live side by side.

**Elsewhere in this section.** [LegalRuleML](/comparisons/legalruleml/)
carries deontic modalities with violation and reparation structure.
[Symboleo](/comparisons/symboleo/) tracks obligations through fulfilled,
violated, and further states over an event account, and its shared scenario
includes late-payment reparation. [L4](/comparisons/l4/) tracks fulfilment
and breach of typed duties over event streams. The prepared protocol pairs
Arxo with L4 and Symboleo.

### 8. A duty with a deadline

**Classic statement.** Remedy the breach within thirty days of receiving the
order. The duty has a holder, a required action, a triggering event, a
length, and a status: open, performed, or violated. This is a synthetic task
on the duty-and-deadline skeleton rather than a problem with a single
literature source; its difficulty is well known from contract-modelling
work.

**Why it is hard.** "The period is running", "the period has passed", and
"performed in time" are three different answers. Late performance must not
rewrite the breach after the fact; an unknown trigger date means the period
cannot be counted at all; and the boundary day depends on how the text
counts.

**In Arxo.** A [duty](/constructs/duty/) with an achievement goal and a
window; the [deadline and calendar](/constructs/deadline-calendar/) page
fixes how the period counts (same day or next day, calendar or business
days); the [lifecycle](/constructs/lifecycle-statuses/) separates
violated from undetermined when no ground for a breach is established.

**Elsewhere in this section.** [Symboleo](/comparisons/symboleo/) has
first-class deadlines as temporal predicates. [Stipula](/comparisons/stipula/)
makes deadlines first-class through non-cancellable timeout events.
[L4](/comparisons/l4/) binds parties within time windows.
[RegelRecht](/comparisons/regelrecht/) computes a Dutch objection deadline,
where the comparison predicts a one-day boundary divergence. The prepared
protocol pairs Arxo with Symboleo, Stipula, and a Python date script.

### 9. A duty to maintain a state

**Classic statement.** Keep the fencing in working order for the whole
period of works. The duty is breached at the first moment of
non-conformity inside the window, not at its end. Like the deadline case,
it is a synthetic task; a candidate anchor is the occupational-safety
chapter of the Labour Code of Kazakhstan.

**Why it is hard.** Achievement logic ("done by the deadline") gives the
wrong answer: being in order on average is no defence, a failure before the
window opens belongs to another norm, and a gap in the log is neither
compliance nor breach.

**In Arxo.** A [duty](/constructs/duty/) with a maintenance goal: it holds
over the whole window, and the [lifecycle](/constructs/lifecycle-statuses/)
records a breach only on an accepted counterexample, a recorded failure.
A [prohibition](/constructs/prohibition/) is the same shape for not doing
something.

**Elsewhere in this section.** No comparison page in this section
discusses a maintenance form specifically; the prepared protocol pairs Arxo with
[Symboleo](/comparisons/symboleo/) and [Stipula](/comparisons/stipula/),
whose lifecycle and timeout machinery are the closest neighbours.

## Time and change of law

### 10. Retroactivity

**Classic statement.** Law does not act retroactively — except a law that
mitigates or removes liability. H. L. A. Hart treated retrospective
legislation as a defect in guiding conduct in *The Concept of Law* (1961),
and Lon Fuller listed non-retroactivity among the requirements of law's
inner morality in *The Morality of Law* (1964). The norm anchor here is the
Code of Administrative Offences of Kazakhstan, Article 5: a mitigating law
reaches back until the penalty decision has been executed.

**Why it is hard.** Three dates meet: the act, the entry into force of the
new edition, and the execution of the decision. Choosing the edition by the
date of the question, or always by the date of the act, gets one of the
cases wrong; the lenient-law exception has its own boundary.

**In Arxo.** The [time](/constructs/time/) page carries both mechanisms:
rules switch on and off by legal time with `effective`, nodes are dated by
the edition of the act they come from, and retroactivity in the corpus is
written as a comparison of fact dates in the rule body.
[Sources](/constructs/sources/) pin the editions themselves.

**Elsewhere in this section.** Dated editions are native in
[OpenFisca](/comparisons/openfisca/) and
[PolicyEngine](/comparisons/policyengine/) (a parameter value per date, a
formula per period) and in [RegelRecht](/comparisons/regelrecht/)
(date-versioning by file); [Akoma Ntoso](/comparisons/akoma-ntoso/) marks up
editions with validity starts. The prepared protocol pairs Arxo with
Catala and a Python date script.

### 11. Transitional provisions

**Classic statement.** Permits issued before the cut-over date remain valid
until they expire; applications filed before it are decided under the old
rules. Continuing relationships, pending procedures, and open periods cross
the boundary between two regimes. The concern for change without traps for
the addressee is again Hart (1961) and Fuller (1964); a structural analogue
in force is the transitional chapter of the Law of Kazakhstan "On Legal
Acts".

**Why it is hard.** A pending application must not be decided by a mixture
of both editions, an old permit must stop protecting its holder exactly when
it expires, and a renewal is a new procedure under new rules.

**In Arxo.** Transitional rules are explicit boundary rules: `effective`
windows on the [time](/constructs/time/) page bound each regime, and a
[procedure](/constructs/procedure/) records where a pending application
stands, so the case can be tied to the regime under which it started.

**Elsewhere in this section.** The dated-edition systems listed under
retroactivity apply here as well. The prepared protocol pairs Arxo with
[Catala](/comparisons/catala/) and a Python date script.

## Judgment and proof

### 12. Open texture and evaluative terms

**Classic statement.** "No vehicles in the park": a car is clearly a
vehicle, but a bicycle or an electric scooter sits in the penumbra where
the rule needs a decision. H. L. A. Hart, *The Concept of Law* (1961),
chapter VII; the term "open texture" comes from Friedrich Waismann,
"Verifiability", *Proceedings of the Aristotelian Society*, supplementary
volume 19 (1945).

**Why it is hard.** A rule system wants a test it can compute. The tempting
shortcut — a scooter over twenty kilograms is a vehicle — invents a
threshold the law never set and makes the answer look settled when it is
not.

**In Arxo.** The [judgment channel](/constructs/judgment-channel/): the
evaluative feature is a judgment relation with a named organ. Until the
organ answers, the result is "requires judgment" with the waiting premise
named; once a decision is recorded, the proof shows it as adjudicated.
Where the text itself reads two ways, an
[interpretation](/constructs/interpretation/) group records the fork.

**Elsewhere in this section.** [Logical English](/comparisons/logical-english/)
leaves judged questions to a human or a scene rather than inventing them.
[docassemble](/comparisons/docassemble/) sends evaluative terms to a person
through interview branching. [PROLEG](/comparisons/proleg/) takes
plausibility inputs as judge decisions. The published
[L4](/comparisons/l4/) model studied here computes such words from case
data — a choice of that model, not of the language. The prepared protocol
pairs Arxo with L4 and Logical English.

### 13. Burden of proof and presumption

**Classic statement.** A fact is presumed; the opponent bears the burden of
rebutting it; if the question stays unresolved, the act states the default
outcome. The executable line comes from Ken Satoh and colleagues:
"Formalizing a Switch of Burden of Proof by Logic Programming" (JURISIN
2007) and "Translating the Japanese Presupposed Ultimate Fact Theory into
Logic Programming" (JURIX 2009), the basis of PROLEG. A norm anchor is the
evidence chapter of the Code of Administrative Offences of Kazakhstan.

**Why it is hard.** "Not proven" is not "proven false". Evidence that was
offered but not admitted proves nothing either way, and a burden left
unmet is a status of the burden, not a finding of fact — unless the act
says so.

**In Arxo.** A [presumption](/constructs/presumption-fiction/) expands into
a defeasible rule, a rebutting exception, and a priority, with a named
burden of rebuttal. [Facts and evidence](/constructs/facts-and-evidence/)
keep an assertion that was not accepted out of the inference, and
[negation and truth statuses](/constructs/negation-and-status/) keep
"not established" separate from "refuted". The outcome on silence is a
rule the act writes, not an engine default.

**Elsewhere in this section.** [PROLEG](/comparisons/proleg/) is built on
this problem: the burden is distributed per condition in advance, and an
unproven burden-side fact counts as false so reasoning proceeds.
[Logical English](/comparisons/logical-english/) studies a citizenship
article with a foundling presumption among its edits. The prepared protocol
pairs Arxo with PROLEG and an answer-set program.

## At a glance

| Problem | Arxo construct | Paired in the prepared protocol |
|---|---|---|
| Tweety default | [defeasible rules](/constructs/rule-defeasible-unless/) | L4, PROLEG, answer-set program |
| Exception to an exception | [defeasible rules](/constructs/rule-defeasible-unless/), [priority](/constructs/priority/) | PROLEG, Catala |
| Rebut versus undercut | [defeasible rules](/constructs/rule-defeasible-unless/) | answer-set program, Python |
| Specialis, superior, posterior | [priority](/constructs/priority/) | PROLEG, L4, Python |
| Weak and strong permission | [liberty](/constructs/liberty-immunity/) | L4, Logical English |
| Counts-as | [definition](/constructs/definition/), [fiction](/constructs/presumption-fiction/), [power](/constructs/power/) | L4, Catala |
| Contrary-to-duty | [duty](/constructs/duty/), [lifecycle](/constructs/lifecycle-statuses/) | L4, Symboleo |
| Duty with a deadline | [duty](/constructs/duty/), [deadlines](/constructs/deadline-calendar/) | Symboleo, Stipula, Python |
| Maintenance duty | [duty](/constructs/duty/), [lifecycle](/constructs/lifecycle-statuses/) | Symboleo, Stipula |
| Retroactivity | [time](/constructs/time/), [sources](/constructs/sources/) | Catala, Python |
| Transitional provision | [time](/constructs/time/), [procedures](/constructs/procedure/) | Catala, Python |
| Open texture | [judgment channel](/constructs/judgment-channel/) | L4, Logical English |
| Burden and presumption | [presumptions](/constructs/presumption-fiction/) | PROLEG, answer-set program |

## What comes next

Each problem has a frozen protocol: the arms, the documentation budget, the
hidden case bank, and the planted errors the stock check should catch.
When a run happens, its outcomes land on this page as a dated section next
to the problem, with the run attached and every case classified as match,
mismatch, not comparable, execution error, or not checked. Until then the
expected outcomes in the bank are predictions from the problem text, and the
"Elsewhere" notes are documentation readings, not observed behaviour.