Policy Engineering

Decomposition is the first unit operation of policy engineering: reading an instrument and separating it into the elements a machine will need. This lecture establishes the method and the discipline of not resolving ambiguity silently.

After this lesson, the reader should understand:

• 01Apply a repeatable decomposition pass to an instrument.
• 02Separate operative content from recital and explanation.
• 03Record ambiguity as a finding rather than a private assumption.

A twelve-page leave policy

How much of a typical HR policy is operative, and how much is context?

In practice the operative content is a small fraction of the text. Most of a policy is purpose, tone, and explanation — necessary for a reader, inert for a machine. Decomposition separates the two without discarding either, and the exercise routinely reveals that two operative rules in the same document contradict each other. That finding is the value of the pass, not a side effect of it.

• Who owns the resolution of a discovered contradiction?
• Should decomposition findings be published with the artifact?
• How much context should survive into the artifact?

Decompose one page of a real instrument.

1. 01Highlight operative sentences only.
2. 02Extract every defined term used.
3. 03Rewrite each rule as condition plus outcome.
4. 04Log every question you could not answer from the text.

• Legal informatics — structural markup of legislation.
• Requirements elicitation methods.
• Deontic logic — obligation, permission, prohibition.

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.

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.

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.

• 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?

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.

• Terminology science and controlled vocabularies.
• Ontology engineering — identity and subsumption.
• Statutory interpretation — defined terms and context.

A rule is an operative statement binding conditions to a normative outcome. This lecture covers rule form, modality, and the discipline of writing one rule per statement.

After this lesson, the reader should understand:

• 01Classify a rule by modality: obligation, permission, prohibition.
• 02Split compound prose into atomic rules.
• 03Attach each rule to the authority that issues it.

One sentence, four rules

A single compliance sentence carries four obligations. Why does that matter?

As prose, the sentence is evaluated as a unit and audited as a unit. As four atomic rules, each obligation can be tested, exempted, versioned, and reported on independently — and a partial failure is reportable as a partial failure rather than a blanket non-compliance. Atomicity is what makes remediation precise.

• When is a compound rule clearer than its atomic parts?
• How should conflicting rules of equal authority be resolved?
• Should a rule carry its own penalty, or reference one?

Atomise a compliance clause.

1. 01Split the clause into single-obligation statements.
2. 02Label each with its modality and subject.
3. 03State the condition set for each.
4. 04Identify any obligation with no stated consequence.

• Deontic and defeasible logic.
• Business rules management literature.
• Normative systems in multi-agent research.

Exceptions are where most policy failures live. This lecture treats the exception as a first-class object with its own conditions, authority, and expiry.

After this lesson, the reader should understand:

• 01Distinguish an exception from a condition and from a waiver.
• 02Express precedence between a rule and its exceptions.
• 03Handle exceptions granted by a different authority.

The standing emergency exemption

An exemption granted for an emergency is still in force four years later. Why?

Because nothing in the document expressed an expiry, and nothing in the process re-evaluated the trigger. As an artifact, the exception carries its own conditions and an expiry, and the runtime stops applying it when the conditions no longer hold. The failure was not the exemption — it was expressing a temporary displacement in a form with no notion of time.

• Should exceptions ever be permanent?
• Who audits the population of live exceptions?
• How do overlapping exceptions resolve?

Model one exception completely.

1. 01Name the rule it displaces.
2. 02State its trigger conditions precisely.
3. 03Name the granting authority and the expiry.
4. 04Describe what happens on expiry.

• Defeasible reasoning and priority orderings.
• Administrative law on waivers and derogations.
• Exception handling in safety-critical specification.

A condition is the point at which authority meets fact. This lecture examines evaluability: which conditions a machine can test, which require judgement, and how the boundary is declared.

After this lesson, the reader should understand:

• 01Classify conditions as evaluable, evidenced, or judgement-bound.
• 02Specify the fact source for each evaluable condition.
• 03Design a referral path for judgement-bound conditions.

'Reasonable steps'

How should an artifact handle a condition that requires reasonableness?

It should not pretend to evaluate it. The artifact marks the condition as judgement-bound, halts the automated path, and refers the case with the evaluated context attached. The value is not that the machine decided — it is that the boundary between machine and human judgement is now explicit, recorded, and auditable, instead of being absorbed silently by whoever happened to handle the case.

• Can a judgement-bound condition ever be proxied by a metric?
• Who owns the fact sources an artifact depends on?
• What should happen when a fact is unavailable?

Classify the conditions in one rule.

1. 01List each condition separately.
2. 02Assign a class to each.
3. 03Name the fact source or the referral route.
4. 04Note the behaviour when a fact is missing.

• Evidence law and standards of proof.
• Data provenance and attestation.
• Human-in-the-loop decision architecture.

Decision logic is the evaluable structure that turns facts into an outcome. This lecture covers ordering, completeness, and the requirement that every path terminate in a defined result.

After this lesson, the reader should understand:

• 01Construct a complete decision structure for a rule set.
• 02Test for unreachable paths and undefined outcomes.
• 03Produce a reasoning trace alongside an outcome.

The eligibility path with no 'no'

An eligibility policy defines who qualifies but never defines refusal. What does the machine do?

Nothing defensible. An incomplete decision structure produces silent defaults, and silent defaults are unlogged policy. Completeness testing surfaces the omission before deployment and forces the institution to state the refusal path explicitly — which is a policy decision the drafters never made in prose.

• Is a default outcome ever acceptable?
• Should evaluation order be part of the authority or an implementation detail?
• How much of the trace should be disclosed to the subject?

Draw and test a decision structure.

1. 01Map every branch from inputs to outcome.
2. 02Identify paths with no defined terminal.
3. 03Identify branches that can never be reached.
4. 04Write the trace a single case would produce.

• Decision tables and DMN.
• Model checking and coverage analysis.
• Explainability in automated decision systems.