Computable·Authority
← Module 1 · The Policy Problem

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.

Supports Law 1 — Authority Must Be Explicit Before It Can Be Executed. →
Lesson 4 / 39Start 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

  1. 01The rule — conditions bound to an outcome
  2. 02The issuer — which institution stands behind it
  3. 03The delegation — who may act on it, and on whose behalf
  4. 04The version — which text governed this decision
  5. 05The evidence — what facts the outcome depended on
  6. 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. 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; 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. The authority relationship — issuer, delegation, version, evidence, boundary — is the second, and it is the one a challenge actually tests.

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?

Exercise

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

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

Research notes

  • Deontic logic — the gap between a norm and the power to apply it.
  • Administrative law — delegation, jurisdiction, and ultra vires.
  • Rules as code — what the encoded artifact does and does not carry.
  • OECD consultation on the Digital Provision of Law — Law as Code as the state-authorised provision of law in force.
  • Computable Authority, §2 — 'Rules Are Not Authority'.
All lectures in this moduleGlossary of terms