Lecture 1.4

Rules Are Not Authority

A machine-executable rule says what follows when its conditions are met. It does not say who is entitled to cause that outcome, under whose delegation, against which version, or on what evidence. This lecture draws the line the rest of the discipline is built on: encoding a rule and authorising an actor to act under it are different institutional functions^[1].

Supports Law 1 — Authority Must Be Explicit Before It Can Be Executed. →

Lesson 4 / 40Start the course to keep your place and get the rest by email.

Learning objectives

After this lesson, the reader should understand:

01Separate the content of a rule from the authority relationship that lets an actor invoke it.
02Name the elements an authority relationship carries that a bare rule does not.
03Explain why 'the machine has the rule' is not the same as 'the machine is authorised'.

Concept framework

Rule versus authority

01The rule — conditions bound to an outcome
02The issuer — which institution stands behind it
03The delegation — who may act on it, and on whose behalf
04The version — which text governed this decision
05The evidence — what facts the outcome depended on
06The boundary — what happens when authority cannot be established

Case study

The correctly encoded refusal

A benefits system encodes an eligibility rule perfectly: the conditions are complete, the logic terminates, the outcome is correct for every input. A claimant challenges a refusal. What can the institution actually show?

That the rule was applied — and almost nothing else^[2]. It cannot show, from the rule alone, that this system was the one authorised to refuse rather than to recommend; that the caseworker's delegated limit covered this decision^[3]; that the version applied was the one in force on the day; or that the two facts the refusal turned on are facts the institution accepts as evidence. Each of those is a separate question, and a rule engine answers none of them. Law as Code produces the first artifact^[4]. The authority relationship — issuer, delegation, version, evidence, boundary — is the second, and it is the one a challenge actually tests^[5]. The strongest objection is that this is already solved, outside the software. Administrative law has spent a century on exactly these questions — jurisdiction, delegation, ultra vires — and courts answer them on review. True, and that is the difficulty. Judicial review asks them after the decision, of a record assembled for the purpose; an automated system makes thousands of decisions before anyone asks. Scholarship on reviewing automated public-sector decisions has found that the record a court needs is often precisely what the system never kept^[6]. Computable authority does not replace the legal tests. It makes the facts those tests examine exist at the moment of decision. The limit runs in the same direction. Encoding a delegation does not make it lawful; an artifact can faithfully record a delegation the institution had no power to make. Whether an authority relationship is valid remains a legal question. What the artifact guarantees is only that the question can be asked of a specific, versioned claim rather than reconstructed from memory.

Discussion questions

Is a rule with no named issuer enforceable, or merely runnable?
When does an institution delegate authority, and when has it only shared a rulebook?
Can two systems apply the same rule and still differ in what they are authorised to do?
Where, in your organisation, does the authority relationship live if not in the policy document?
If judicial review can examine authority after the fact, what is gained by representing it before the decision is made?

Discussion (0)

No responses yet. Be the first to answer one of the questions above.

Start the course to join the discussion.

Exercise

Take one automated or semi-automated decision and separate its rule from its authority.

01Write the operative rule as conditions and an outcome.
02Name the institution that issues it and the instrument it derives from.
03State who is delegated to act on it, within what limit, and on whose behalf.
04State which version governed the last decision made under it, and how you know.
05List the facts the outcome depended on, and who is entitled to say they are established.

Footnotes

^1 Computable Authority, §2 — 'Rules Are Not Authority'.
^2Deontic logic — the gap between a norm and the power to apply it.
^3Administrative law — delegation, jurisdiction, and ultra vires.
^4Rules as code — what the encoded artifact does and does not carry.
^5OECD consultation on the Digital Provision of Law — Law as Code as the state-authorised provision of law in force.
^6 Jennifer Cobbe, "Administrative Law and the Machines of Government: Judicial Review of Automated Public-Sector Decision-Making," Legal Studies 39 (2019).