Rules

Decide which pull requests count and how production deployments are detected: PR exclusion rules, deployment rules, what Bilanc detects on its own, and the suggestions it makes

The Rules page (Admin tools → Rules) has four tabs:

• PR exclusions – pull requests to leave out of analytics: release-train merges, sync PRs, bot branches, noise.
• Deployments – overrides for how Bilanc detects production deployments per repository, used by the DORA metrics.
• Repositories – what Bilanc detected for every repository (branching model, production branches, deployment source) with the evidence, and an Override button.
• Suggested – rules Bilanc thinks you should add, with the evidence. Accept, edit or dismiss each one. Nothing is applied without your say-so.

Rules are per organisation and never delete data; disabling or deleting one restores the affected rows on the next hourly refresh.

PR exclusion rules

A rule describes the pull requests to throw away — a PR that matches an enabled rule is dropped from PR analytics. There’s no “keep only these” mode; to keep a narrow set, exclude everything that isn’t in it using the negated match types.

• Within a rule, the conditions (repositories, source branch, target branch, title) are AND-ed — a PR matches only if it satisfies all of them.
• Across rules, matching any enabled rule is enough to exclude a PR. Add more rules to exclude more things.

An excluded pull request is removed from Bilanc entirely, so it also stops being a deployment event. If you exclude promotion PRs (dev → main) in a gitflow repository, the pull requests they carried can no longer get a deploy time from them. For DORA, prefer leaving promotions in: they are flagged is_promotion_pr in Data Explorer and you can filter them out of throughput there.

Git terminology: source vs target

A PR always flows source → target.

Field	Git concept	Column	What it is
Source branches	head	branch_name	The branch merging from — the feature/topic branch.
Target branches	base	base_ref	The branch merging into — e.g. main, production.

base_ref is the target branch, not the source. In git PR terms, base is the branch you merge into. “Exclude PRs that go into production” is a Target branch condition.

The mapping is the same across GitHub, GitLab, Bitbucket, and Azure DevOps.

Conditions and match types

Repositories has no match type — listed repos scope the rule to those repos; empty means all repos. The other three fields take a list of values (comma- or newline-separated) plus a match type. Matching is always case-insensitive. Leaving a field blank ignores it.

Match type	Meaning
Equal	Field equals one of the listed values
Prefix	Field starts with one of the listed values
Not equal	Field equals none of the listed values
Not prefix	Field starts with none of the listed values

The negated types are how you express “keep only X”: exclude every PR whose target branch is not production keeps exactly the production-targeting PRs.

Example: keep only one target branch in one repo

Goal: in one repository, keep only PRs merging into production and exclude everything else, leaving all other repositories untouched.

Field	Value	Match type
Repositories	(the repo)	—
Target branches	production	Not equal

This excludes any PR in that repo whose target branch isn’t production. Because the repository is scoped, no other repo is affected.

Don’t use Equal here — that would drop the production PRs you want to keep. The negation (production + Not equal) is correct.

Common patterns

Each row is one rule. Conditions within a rule are AND-ed — to exclude on either of two conditions independently, create two rules.

Goal	Repositories	Source	Target	Title
Drop release-train merges into main	(all)	—	main Equal	release: Prefix
Exclude everything except work merging into main/master	(scoped)	—	main, master Not prefix	—
Drop bot/automation branches	(all)	dependabot/, renovate/ Prefix	—	—

Deployment rules

Bilanc works out how each repository ships on its own (see how Bilanc detects a production deployment and how Bilanc reads your branching model). Most repositories need no rule. Deployment rules are for the cases it cannot know: a production branch called k8s-main, a deploy pipeline called just CD, a repository that should not count at all.

Rule type	Values	Effect
Production branches	branch names	Merges into these branches are production. Under merge-to-default each is a deployment; with releases or deploy runs, these are the pull requests that ship with the next one. Replaces the inferred branches for the listed repositories (or the whole organisation when no repository is listed).
Deploy workflow: include	workflow names + match type, optional branches	These CI/CD workflows are production deploys even though their name does not say “prod”. With branches set, only runs from those branches count (a multi-environment pipeline that runs on develop and main: include it on main).
Deploy workflow: exclude	workflow names + match type	Never treat these workflows as production deploys, whatever they are called.
Deployment source	one of github_release, bitbucket_deployment, workflow_run, merge_to_default, ignore	Pin the listed repositories to one signal, force merge-to-default, or take them out of deployment tracking entirely (ignore: sandboxes, demos, docs, archived repositories). Requires at least one repository.

Repository-specific rules beat organisation-wide ones. Rules take effect on the next hourly refresh, and the Repositories tab shows configured as the branching model for repositories a production-branches rule covers.

Worked examples

Situation	Rule
Gitflow repo that promotes develop into main by merging locally, so Bilanc sees only develop	Production branches = main; the develop PRs then ship with the next release or deploy run
The team’s production branch is release	Production branches = release
Production deploys run from a GitHub Actions workflow called build-deploy on main (and on develop for staging)	Deploy workflow include = build-deploy, Equal, branches = main
Deploy Container to ECS (Prod) in one repo is actually a canary and never production	Deploy workflow exclude = Deploy Container to ECS (Prod) scoped to that repository
infra-sandbox and docs should not count as deployments	Deployment source = ignore, repositories = org/infra-sandbox, org/docs
A repository has both releases and a deploy workflow and you want the workflow to win	Deployment source = workflow_run, repositories = that repo

The Repositories tab

One row per repository with merged pull requests in the last year:

• Model: trunk, gitflow, release_branches, trunk_on_nondefault, mixed, insufficient_data, or configured when a rule applies. Hover for the plain-English meaning.
• Production and integration branches Bilanc is using.
• Confidence: high, medium or low. Low usually means Bilanc could not tell what production is; there is normally a suggestion waiting for it.
• Source: the deployment source in use over the last 180 days (github_release, workflow_run, bitbucket_deployment, merge_to_default) and when the last deployment was.
• Evidence: merge share per branch, promotion PRs found, branches releases and deploy runs were cut from.

Override opens a production-branches rule pre-filled for that repository.

Suggestions

After every data refresh Bilanc looks for rules it thinks you should add and lists them in the Suggested tab with the evidence and a confidence. It suggests, never applies:

Suggestion	When
Production branch	A mixed repository whose merges mostly land on one non-default branch (develop, staging, k8s-main) and nothing shows what production is.
Deploy workflow include	A deploy-looking workflow (build-deploy, CD, Deploy to AWS) runs on the repository’s production branch with a healthy success rate, the repository has no live deploy signal, and the name does not say “prod”.
Ignore repository	A repository whose name says sandbox, demo, hackathon, docs or archive is counting merges as production deployments.

Accept enables the rule. Edit lets you change it before accepting. Dismiss keeps it disabled and stops Bilanc suggesting it again. Suggestions the data no longer supports disappear on their own. PR exclusion suggestions use the same mechanism and will appear in the same tab.

Rules apply only to enabled rows and take effect on the next analytics refresh. They don’t modify underlying data.