← Module 2 · Policy Engineering

Lecture 2.8

Contradiction and Conflict

A decomposition can be complete and still be incoherent. This lecture covers the failure modes that appear only once a policy is expressed as structure — the conflicts prose was able to conceal — and treats their detection as a required step before any artifact is issued.

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

Learning objectives

After this lesson, the reader should understand:

  • 01Name the recurring classes of conflict in a decomposed policy.
  • 02Explain why prose conceals conflicts that structure exposes.
  • 03Resolve a conflict by amendment rather than by silent precedence.

Concept framework

Five classes of conflict

  1. 01Threshold conflict — two rules set different limits on the same field
  2. 02Role conflict — two provisions assign one decision to different holders
  3. 03Ghost term — a rule depends on a definition the instrument never provides
  4. 04Rule collision — two rules match the same facts and produce different outcomes
  5. 05Layer divergence — a local instrument contradicts the one it sits under

Case study

The two limits

A delegation schedule sets a manager's approval limit at $2,500,000. A procurement annexe, drafted two years later, refers to "the standard managerial limit of $2,000,000". Both are in force. What does the artifact encode?

It cannot encode both, and that is the value of the exercise. As prose, the two figures sat in separate documents and never met; the institution operated for two years without anyone holding both sentences in mind at once. Structure forces the meeting. The resolution is not for the engineer to take the lower figure as a safe default — that would be a new rule, authored by whoever happened to be compiling, with no mandate behind it. It is to escalate the conflict to whoever holds the authority to amend, record what they decide, and issue the artifact only once one of the two figures has been withdrawn. In the NOMOS reference implementation this scan is a deterministic pre-issue gate rather than a review someone remembers to run[1]. It compares every pair of rules that touch the same field using interval arithmetic and reports the classes it can establish without judgement: threshold conflicts (two limits on one field, as here), rule collisions (two rules matching the same facts with different outcomes), ghost terms (a rule leaning on a term the instrument never defines), and layer divergences (a local rule contradicting the one it sits under). The compiler does not seal an artifact while an unresolved threshold conflict stands in it. The strongest objection is that law solved this centuries ago. The interpretive canons — the later provision prevails, the specific prevails over the general, the higher prevails over the lower[2] — exist precisely to resolve conflicting norms without anyone having to amend anything. Why not apply them mechanically? Apply them here and see. Lex posterior picks the annexe, because it is two years younger, and silently cuts every manager's authority by half a million dollars. Lex specialis might pick the annexe too, as the more specific instrument — or the delegation schedule, as the instrument specifically about limits. The canons do not remove the decision; they presuppose one[3]: that the drafters meant the two provisions to conflict, which is later, which is more specific. Here the likeliest truth is that nobody meant anything — the annexe's drafter copied an old figure. That is a defect to correct, not a conflict to resolve by canon[4]. The detector has limits of its own, and they bound what its silence means. Its deterministic checks compare rules that read the same field. Two provisions that govern the same thing under different names — 'approval_limit' in one instrument, 'delegated_authority_ceiling' in another — never meet in those checks. The reference implementation adds a model-based pass that looks for exactly such cross-vocabulary conflicts, but that pass is advisory: it is probabilistic, it can miss, and it is deliberately not a seal gate. A clean deterministic scan therefore means no structural conflict among the fields as named, not no conflict in the policy. The work of Module 2's lecture on definitions is what makes this scan worth trusting.

Discussion questions

  • Who resolves a conflict discovered during decomposition?
  • Is a conflict that has stood for years a defect, or a de facto rule?
  • Should an artifact be issuable while a known conflict stands unresolved?
  • How should precedence between two instruments be recorded?
  • When is a conflict genuinely a conflict of norms, to be resolved by canon, and when is it a drafting defect, to be corrected by amendment?

Discussion (0)

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

Start the course to join the discussion.

Exercise

Run a conflict scan on one instrument.

  1. 01List every rule with its field, operator, and threshold.
  2. 02Flag any field carrying more than one threshold.
  3. 03List every term the rules use, and mark those the instrument never defines.
  4. 04Identify any two rules that could match the same set of facts.
  5. 05For each conflict found, name the person with authority to resolve it.
  6. 06List any two fields with different names that may govern the same thing, and check them against each other by hand.

Footnotes

  1. ^1NOMOS reference implementation — a deterministic contradiction detector: interval-arithmetic threshold conflicts, rule collisions, ghost terms, layer divergences; regression-tested and run as a seal gate.
  2. ^2Legal theory — lex specialis, lex posterior, and conflict of norms.
  3. ^3Carlos E. Alchourrón & Eugenio Bulygin, Normative Systems (Springer, 1971) — completeness and consistency as formal properties of a body of norms.
  4. ^4Bashar Nuseibeh, Steve Easterbrook & Alessandra Russo, "Leveraging Inconsistency in Software Development," IEEE Computer 33, no. 4 (2000): 24–29 — inconsistency as information to manage, not only an error to remove.

Further reading

  • Formal verification — consistency checking and satisfiability.
  • Knowledge representation — defeasible reasoning and rule priority.
  • Requirements engineering — inconsistency management.