Rules.

The problem.

A rule in a README and a rule the server refuses look identical in prose. An agent follows the text it was given, including a rule that has never fired.

What it is.

The process runs from spec to release, drawn as stages: Spec, Plan, Build, Review, Merge, Release, Learn. Every rule shows what holds it. The server refuses (enforced). CI or a scan reports (checked). Something outside Graphban is supposed to, and the page says Graphban cannot verify it (external). Agents are only told, in get_context (advisory). Nothing is set (unmeasured).

A stage reads as strong as its weakest used rule. Advisory is never drawn as enforced. A person turns a rule on or off, with a reason. A recommendation never does. A refusal names the rule that refused it, or says it is not mapped yet.

A rule the project is not using is drawn not used, with the reason, so it does not vanish and it does not count as a pass. The five holds above are the ones that mean something is supposed to be true.

Example · a stage is drawn as strong as its weakest used rule

1. Spec
2. Plan
3. Build
4. Review
5. Merge
6. Release
7. Learn

• Enforcedreview.not_own_work Not your own work. The server refuses.
• Checkedmerge.ci_green Merged work passed CI. CI reports. Nothing refuses.
• Externalplan.budget_cap Budget cap. Held outside the server. Graphban cannot verify this.
• Advisorygitops.base_branch Base branch. Told to agents in every get_context. Nothing refuses.
• Unmeasuredgitops.pr_title_pattern No value set.

What it isn't.

Not a policy engine that turns itself on. A person adopts a rule, with a reason. An unloaded pack is not "everything is off". That drawing is on the pipeline page.

Rules on the pipeline