Module 5 · Executable Authority

Lecture 5.2

Compilation Is Not Execution

A language model, a compiler, a policy team — any of them may help turn a source into an authority artifact. That is compilation, and it is a governed act. Execution is separate: a deterministic evaluator checks a proposed action against an already-approved artifact. This lecture defends the boundary between them and the rule that a probabilistic system may build authority but must not be the runtime that enforces it.

Supports Law 5Intelligence Executes Systems — It Does Not Repair Them.
Lesson 28 / 39Start the course to keep your place and get the rest by email.

Learning objectives

After this lesson, the reader should understand:

  • 01Separate compilation (constructing authority) from execution (enforcing it).
  • 02State the legitimate roles of a language model on each side of the boundary.
  • 03Explain why a more capable model does not make a safer runtime authority.

Concept framework

Two processes, one boundary

  1. 01Construction — extract, model, review, compile, seal (probabilistic help allowed)
  2. 02Approval — the authority holder signs the artifact, not the memo
  3. 03Boundary — the sealed artifact crosses from build-time to run-time
  4. 04Enforcement — a deterministic evaluator applies the artifact to a proposed action
  5. 05Assistance — a model may prepare facts and explain outcomes, not decide them

Case study

The model asked to be the rulebook

A team ships an agent that is given the policy in its system prompt and asked to authorise actions against it directly. It is accurate in testing. Why is this the wrong architecture?

Because the authority now lives inside a probabilistic process. The same case can resolve two ways on two runs; a context change can silently drop a clause; there is no artifact to version, seal, or hand a regulator. Accuracy in testing measures the model, not the architecture. The fix is not a better model — it is to move the policy into a compiled artifact the model calls. The model still earns its place: it reads the messy input, extracts the facts, drafts the explanation. It just does not get to be the thing that says yes. Construction can be probabilistic; enforcement must be deterministic.

Discussion questions

  • Is prompting a policy into a model a form of compilation, or a way of skipping it?
  • What must a human sign before a compiled artifact may execute?
  • Where exactly does the model sit relative to the evaluator in a sound design?
  • If a model assists compilation, what review does its output need before sealing?

Exercise

Draw the boundary for one AI-assisted decision path.

  1. 01List every step from raw input to authorised action.
  2. 02Mark each step as construction, enforcement, or assistance.
  3. 03Identify any step where a model output becomes an outcome without passing through a deterministic evaluator.
  4. 04Propose where the compiled artifact sits and what the model does on each side of it.

Research notes

  • Neuro-symbolic architectures — learned components with symbolic guarantees.
  • Compiler theory — source, target, and the trust boundary at issuance.
  • Determinism and reproducibility in decision systems.
  • Software supply chain — separation of build and runtime trust.
  • Computable Authority, §6 and §9 — 'Compilation Is Not Execution' and 'The Model Should Not Be the Final Authority'.