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.