← Module 2 · Policy Engineering

Lecture 2.2

Definitions

Definitions decide outcomes more often than rules do. This lecture treats the definition as the primary object of policy engineering: scoped, versioned, and shared across rules.

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

Learning objectives

After this lesson, the reader should understand:

  • 01Explain why definition drift changes outcomes without changing rules.
  • 02Scope a definition to an instrument, a domain, or a jurisdiction.
  • 03Detect a term used with two meanings in one instrument.

Concept framework

Anatomy of a definition

  1. 01Term
  2. 02Scope of application
  3. 03Criteria
  4. 04Exclusions
  5. 05Source of authority
  6. 06Version

Case study

Who counts as an employee

One organisation, three definitions of 'employee'. What breaks?

Payroll, benefits eligibility, and security clearance each inherited a different definition from a different instrument. Every rule downstream is individually correct and collectively inconsistent. Expressed as artifacts, the divergence is visible before deployment because the definitions are named objects rather than repeated phrases — and the institution must decide, once, which one governs where. Make the divergence concrete. Payroll counts anyone paid through the payroll system, including fixed-term staff. Benefits counts permanent staff working at least twenty hours a week. Security counts anyone with access to internal systems, which includes agency contractors. Now take one person: a contractor, thirty hours a week, paid through an agency, holding a system login. For security she is an employee; for payroll and benefits she is not[1]. A fourth rule then says 'all employees must complete annual data-protection training'. It does not say which definition it means. Whether this contractor is required to train — the person with the most direct access to the data — depends on which document the rule's author happened to have open. The obvious objection is to adopt one canonical definition across the organisation. It sounds like hygiene and is usually a mistake. The three definitions differ for legitimate reasons: payroll follows tax law, benefits follows the pension scheme, security follows the threat model. Forcing one meaning breaks at least two domains. The requirement is not uniformity; it is that every rule names which definition it uses[2], so the training rule's choice is made deliberately rather than inherited by accident. A register does not end the regress. Definitions are built from terms — 'permanent', 'access', 'paid through' — and those terms have meanings too. At some depth every vocabulary rests on primitives that are fixed by convention and judgement rather than by further definition[3]. The discipline is to choose that depth deliberately and to record the primitives, not to pretend they do not exist.

Discussion questions

  • Should definitions be shared across instruments or duplicated deliberately?
  • What happens to decisions made under a superseded definition?
  • Can a definition be delegated to an external register?
  • When two definitions of one term differ for legitimate reasons, is the right response to merge them, rename them, or scope them?
  • At what depth should a definition register stop defining, and who decides?

Discussion (0)

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

Start the course to join the discussion.

Exercise

Build a definition register for one instrument.

  1. 01List every defined and quasi-defined term.
  2. 02Record criteria and exclusions for each.
  3. 03Mark terms that appear with more than one meaning.
  4. 04Propose the governing definition for each conflict.
  5. 05For one rule, find a real case that falls inside one definition and outside another, and state what the rule does to it.

Footnotes

  1. ^1Nicola Guarino & Christopher Welty, "Evaluating Ontological Decisions with OntoClean," Communications of the ACM 45, no. 2 (2002): 61–65 — identity criteria and why two things called by one name may not be one kind.
  2. ^2W3C, SKOS Simple Knowledge Organization System Reference, W3C Recommendation (2009) — scoped, versioned vocabularies with explicit mappings between schemes.
  3. ^3ISO 704:2022, Terminology Work — Principles and Methods — concepts, characteristics, and definitions as managed objects.

Further reading