Lecture 5.1
Compilation converts a decomposed policy into an executable authority artifact. This lecture treats compilation as a governed act with inputs, review, and issuance — not a file conversion — and places it within the full authority lifecycle, from source through seal, publication, and assignment.
Supports Law 4 — Authority Must Precede Automation. →Learning objectives
After this lesson, the reader should understand:
Concept framework
The compilation pipeline
Case study
What must be true before a compiled screening artifact is allowed to run?
The ambiguity register must be empty or explicitly accepted, the definitions must resolve to named sources, every condition must have a fact source, and the authority holder must have signed the artifact rather than the memo describing it. Compilation without sign-off produces working software with no authority behind it — the most dangerous artifact of all, because it looks legitimate. Take the rule as an institution would write it: 'No payment may be made to a sanctioned party.' Compiling it forces at least four decisions the sentence does not make. Which lists — one regulator's, several, all that apply to any currency the payment touches? How close must a name be to count as a match, given transliteration, aliases, and typos — and is the matching threshold a technical setting or a policy? Does 'party' include a company owned by a sanctioned person? United States guidance answers that one: an entity owned fifty per cent or more, in aggregate, by blocked persons is itself blocked, even if it appears on no list[1] — so the compiled rule needs ownership data the original sentence never mentioned. And what happens on a near-match: block, hold, or escalate? Each answer changes who gets paid. None of them is an engineering choice, which is why the ambiguity register has to be resolved by the authority holder before the artifact runs. The strongest objection is that sign-off is theatre. Authority holders cannot read a compiled artifact, so they will sign whatever the engineers put in front of them, and the signature adds a name without adding scrutiny. That happens, and the remedy is in what gets reviewed. An authority holder should not review the artifact's code, nor a memo about it, but two things derived from the artifact itself: a plain rendering of every rule with its source, and a set of concrete test cases — this payee, this ownership chain, this near-match — with the outcome the artifact will return. A director who cannot read a rule engine can still say 'no, that payment should have been held'. Conformance tests turn sign-off from a signature into a judgement[2]. Repeatability has a limit worth stating. If a language model helps extract rules from the source, two compilations of the same document can differ, and 'compile it again' no longer reproduces the artifact. The reference implementation addresses this by recording every model call made during extraction, so a compilation can be replayed byte-for-byte without calling the model again, and a replay that would need a call the record does not hold fails loudly rather than silently re-asking. It is the same discipline reproducible software builds apply to compilers[3] — and a reminder, as an old lesson about trusting compilers puts it, that a verified source is only as trustworthy as the toolchain that built from it[4].
Discussion questions
Discussion (0)
No responses yet. Be the first to answer one of the questions above.
Start the course to join the discussion.
Exercise
Write the issuance checklist for one artifact.