An autonomy policy is a file, not a PDF

What is the difference in practice?

A policy in a PDF is read by a person, who remembers it when they remember it. A policy in a file is read by the gate on every action an agent takes, every time.

When a rule lives in a document, breaking it takes an oversight. When it lives in a file, breaking it takes a change to the file, and that change leaves a trace in version history.

What does the file look like?

Ordinary YAML in the repository, reviewed like any other code change. Below is an excerpt of ours, in the shape the gate reads.

mode: tiered            # low -> auto, above that -> owner queue

tiers:
  low:                  # executes and records
    - read_data
    - draft_content
    - deploy_staging
  high:                 # prepares fully, waits for a signature
    - place_owner_call
    - use_real_person_likeness
    - use_patient_or_client_case_study

never_auto:             # refuses; not queued, not drafted
  - sign_contract
  - impersonate_human
  - claim_clinical_outcome
  - modify_graph_authority

Why is the never category separate?

Because an approval queue is convenient, and that is what makes it dangerous. Someone who approves twenty things a day approves the twenty-first by reflex.

Actions that must not happen even after a click have to be refused before the queue. Signing a contract or impersonating a human is not a decision to weigh at five on a Friday.

An agent can improve how it works. It cannot rewrite the rules it is judged by.

How do you know the file matches reality?

Because it is executable. Before any autonomy example is published on this site, a script runs the real classification function for every action listed and compares the result with what the page claims.

If they diverge, publication fails. It is the only way we know to stop a marketing page from drifting away from the configuration it describes.

Sources

• Article 14: Human oversightEU Artificial Intelligence Act, accessed 2026-09-09