Executable Authority

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.

After this lesson, the reader should understand:

• 01Describe the inputs and outputs of a compilation.
• 02Identify what must be signed off before issuance.
• 03Explain why compilation is repeatable and auditable.

Compiling a sanctions screening rule

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.

• Who is competent to sign a compiled artifact?
• Should compilation be reproducible from source by a third party?
• What is the status of an artifact whose source instrument changed?

Write the issuance checklist for one artifact.

1. 01List the inputs required for compilation.
2. 02Define the review steps and who performs them.
3. 03State the sign-off record.
4. 04Define what invalidates the artifact.

• Compiler theory — source, target, and semantic preservation.
• Software supply chain and signed releases.
• Administrative process design for instrument issuance.

Determinism is what makes an outcome auditable: the same artifact and the same facts must produce the same outcome on any conforming runtime, today and years from now.

After this lesson, the reader should understand:

• 01State the conditions required for deterministic evaluation.
• 02Identify sources of non-determinism in a governance pipeline.
• 03Distinguish a deterministic artifact from a probabilistic model.

The model that changed its mind

A language model applied the same policy to the same case twice and produced different outcomes. Where is the failure?

Not in the model — models are probabilistic by construction. The failure is architectural: the authority was carried inside the model instead of inside an artifact the model calls. When the artifact evaluates and the model only assists with fact extraction and presentation, the outcome becomes reproducible while the model remains useful for the parts that do not require determinism.

• Where should a model sit relative to the authority layer?
• Is determinism achievable when facts arrive from external systems?
• What tolerance, if any, is acceptable in a governance outcome?

Audit one automated decision path for non-determinism.

1. 01List every input, including implicit ones such as time.
2. 02Mark any input that can change between runs.
3. 03Mark any step whose output is not a function of its inputs.
4. 04Propose how to fix or record each source of variance.

• Reproducible builds and computation.
• Determinism in distributed systems.
• Hybrid neuro-symbolic architectures.

Verification is confirmation by a party who did not execute the decision. This lecture examines what must be recorded for verification to be possible without access to the executing system.

After this lesson, the reader should understand:

• 01Define the minimum verifiable record of a decision.
• 02Distinguish verification from audit and from explanation.
• 03Design a verification path for an external regulator.

A regulator re-runs a year of decisions

What would a regulator need in order to re-execute last year's decisions without your systems?

The artifact versions in force at each point in time, the recorded facts, and a conforming runtime. Nothing about your infrastructure, your model, or your staff. If re-execution requires your cooperation to interpret anything, the record is an explanation rather than a verification — and explanations do not survive disputes.

• Should verification be open to the decision subject as well as the regulator?
• What is disclosed and what is withheld in a verification record?
• Who certifies a conforming runtime?

Construct a verification record for one decision.

1. 01Assemble artifact version, facts, trace, and outcome.
2. 02Remove anything that depends on your systems to interpret.
3. 03Hand it to a colleague and ask them to reach the same outcome.
4. 04Record what they had to ask you.

• Audit theory and evidential sufficiency.
• Verifiable computation and proof-carrying results.
• Regulatory supervision of automated systems.

Every decision was made under some version of the rules. This lecture covers immutable issuance, effective dates, and replaying past decisions against past authority.

After this lesson, the reader should understand:

• 01Bind a decision to the artifact version in force at the time.
• 02Distinguish issuance date from effective date.
• 03Handle retrospective amendment correctly.

The retrospective amendment

A rule is amended with effect from a past date. What happens to decisions already made?

With versioned artifacts the question is answerable: identify every decision bound to the superseded version whose facts fall inside the amended window, re-execute against the new version, and report the delta. Without versioning, the institution can only estimate. Retrospectivity is a policy choice; the ability to compute its consequences is an engineering property.

• Should artifacts ever be amended in place?
• How long must superseded versions remain executable?
• Who decides that a change is material?

Design a version scheme for one instrument.

1. 01Define what constitutes a material change.
2. 02Define the identity and numbering rule.
3. 03Define the retention period for superseded versions.
4. 04Describe the replay procedure.

• Temporal databases and bitemporal modelling.
• Point-in-time consolidation of legislation.
• Semantic versioning and change classification.

If authority is executable, it must be callable. This lecture covers the interface through which systems request an authority evaluation and receive a bound, traceable outcome.

After this lesson, the reader should understand:

• 01Specify the request and response shape of an authority evaluation.
• 02Return outcomes that carry their own authority binding.
• 03Handle referral, unavailability, and expired authority.

Authority as a shared service

Six systems apply the same policy. Should each implement it?

No — six implementations are six interpretations, and they will diverge on the first amendment. A single evaluation service means one artifact, one version in force, and one record format across every calling system. The organisational difficulty is not technical: it is deciding which body owns the artifact when six teams previously owned six copies.

• Should evaluation be synchronous, and what happens when it is unavailable?
• Who owns the artifact when many systems depend on it?
• How are breaking changes to an artifact communicated?

Specify one governance endpoint.

1. 01Define the request payload and required facts.
2. 02Define the response, including trace and binding.
3. 03Define behaviour for referral and for missing facts.
4. 04Define behaviour when no version is in force.

• API design and contract versioning.
• Policy decision points in access-control architectures.
• Service governance in public-sector platforms.