Skip to content

One policy, projected into every tool's instruction file

Every provider the tool declares — an agent, an orchestrator that runs agents, any tool that reads AGENTS.md — gets the same rules from the same place, because their instruction files are generated from one policy and never written by hand; the providers are the table in docs/generated/providers.md.

status
feature status: stable

What it does

.ai/repo/policy.yaml names the projections: a provider and a target file for each. The templates ship with the tool and a repository may override one under its own layer; the Rust executable and the shell tool render the same bytes, stamp included, so both agree on every stamp. A bootstrap says how to find the policy and never what the policy is: it points at the layer and the rules, stays inside the line budget the policy sets, and carries no rule of its own, so a rule that exists for one provider and not another cannot happen.

Profiles set capability class, effort, verbosity, presentation, context toggles and verification as independent fields, and a task carries the profile it started with. Unknown keys anywhere are errors, so a typo fails loudly.

What it does not do

It never names a vendor model: capability classes are what the projection asks a worker to map onto the closest its environment offers. It does not edit a provider's own settings, and a hand edit of a generated file is detected and refused rather than merged.

Why it exists

Operational moments from the Why catalogue that name one of this feature's mechanisms. Nothing here was assigned: a moment appears because it names a rule, a command, a capability or a claim this feature also names.

Every moment it answers (20)

How it works

The objects it is made of

Kinds of the layer. Each is a schema, a source class and a file on disk; the number beside it is what this repository holds today, counted at build time.

  • policy1
  • profile4

Where it sits

domain
Governance — The rules are written once, in the repository, projected into every tool's instructions, and a blocking rule stops the command instead of advising it.
areas of work
governancecontext

Evidence

What is guaranteed

Each claim this feature names, with the status its row declares, the verdict the recorded runs support, and the test that settles it.

Executable use cases

The rules that hold it

The decisions behind it

Using it

The commands that run it

  • majordomus init setup

    Create the .ai/ layer in this repository, and refuse to overwrite an existing one.

  • majordomus update setup

    Regenerate every provider instruction file from the one policy, deterministically.

  • majordomus doctor inspect · read-only

    It checks governance only: is Majordomus itself healthy, and is every enforcement it declares actually wired here?

Where this page comes from

the file
.ai/repo/features/policy.md
the same answer
majordomus product show policy

Searches the titles and descriptions of every page this site publishes.