An AI system needs an executable rulebook

Many AI projects begin with a long prompt. It describes role, tone, objective, exceptions and sometimes even the preferred workflow. As long as the system only drafts text, this can work surprisingly well. Once it modifies files, uses tools or connects several steps autonomously, linguistic intent is no longer enough. The system needs a rulebook that does not merely describe work but constrains and verifies it.

Fluent language is not governance

A language model can repeat rules convincingly and still bypass them at the wrong moment. This does not necessarily come from disobedience. Instructions are often too general, contradictory or disconnected from the concrete action. „Work safely" does not say whether an agent may install a dependency. „Ask before critical steps" defines neither critical nor the form of approval.

Governance therefore begins with operational distinctions. Reading differs from writing. A preview differs from sending. A local test differs from deployment. A reversible file edit differs from deleting data. These states need names in the rulebook.

Rules need a visible hierarchy

A system works more reliably when it is clear which documents govern which questions. Durable project rules belong in concise, discoverable instruction files. Changing objectives, scope and data zone belong in a project brief. Acceptance criteria state how completion can be observed. Decisions record which alternative became binding. A handoff captures the current state.

This separation prevents an outdated product idea from surviving inside an always-loaded rule file. It also prevents a single ticket from silently overriding a permanent safety boundary. A rulebook is not one enormous document. It is an ordered relationship among document types.

A rule must be connected to an action

„No external action without approval" becomes executable only when the system can recognise external actions. They include sending, publishing, deployment, cost, deletion, expanded access and use of production credentials. A preview state must exist before the effect.

A strong preview names target, action, payload, expected consequence and rollback. The approving person then sees not merely that something will happen, but what exactly will happen. The decision can be allow once, deny or revise. Broad approval for future cases would be a separate policy change.

Skills are executable knowledge

A skill is more than a reusable prompt. It links trigger, inputs, permitted tools, workflow, output contract and stop signals. This makes knowledge actionable. For precisely that reason, a skill needs the same discipline as code.

It should provide a bounded capability, not a diffuse mission. „Produce a source-grounded summary from three named documents" is more testable than „Be my knowledge agent." A narrow skill can be evaluated with positive, negative and repairable cases. A broad skill may look impressive, but its failures are difficult to localise.

Examples and counterexamples shape rules

Abstract rules become unambiguous only through cases. „Do not publish without approval" needs a positive case: the agent prepares a preview and waits. A negative case confirms that it does not put a publication-ready file online automatically. A repairable case shows what happens when destination or recipient is unclear.

Counterexamples matter because they can look superficially similar. A local preview may be allowed while placing the same content in a public CMS requires approval. A file may be replaced inside a working directory while a production database must remain untouched. Rules gain force at the boundary between similar cases.

Versioning makes rules accountable

Rules change behaviour. They should therefore be changed like code. It should remain visible why a rule changed, which incident or evaluation case motivated it, which systems inherit it and how it can be rolled back.

After a rule change, testing only the new desired case is not enough. Existing positive and negative cases must run again. A new safety rule may otherwise block harmless work unnecessarily. Conversely, a more convenient wording may weaken a boundary that previously worked.

A rulebook needs tests

The quality of a rulebook is not shown by how complete it sounds, but by how it behaves in repeatable situations. At least three types of case are needed. A positive case tests permitted work. A negative case tests whether a forbidden effect is stopped. A repairable case tests whether the system detects a missing source, ambiguous scope or failed test and identifies the correct next step.

Useful measures include acceptance pass rate, evidence completeness, boundary violations, unnecessary escalation and handoff quality. No single value is enough. A system that works faster by bypassing approval is not more efficient; it is less governable.

The executable rulebook

# MISSION
Which bounded outcome should be produced?

# SOURCES AND TRUTH
Which documents govern, and which are merely supplemental?

# PERMITTED TOOLS
Which capability is necessary in this state?

# BOUNDARIES
What may be prepared but not triggered?

# STOP SIGNALS
When must the system ask, hand off or stop?

# VERIFICATION
Which tests and acceptance criteria support the result?

# HANDOFF
Which change, evidence, assumption and residual uncertainty remain?

A good rulebook does not make a system small. It makes capability addressable. It shows which action is allowed under which conditions. That turns fluent assistance into a work process that can be inspected, improved and held accountable.

All materials to download — the topic overview and the worksheet: