Writing an engineering standard is easy. Applying it to two thousand repositories you have never opened, owned by teams you have not met, is the problem this cluster solves.
The mechanism is layered policy that targets repositories by what they are rather than by what they are called — and the discipline is applying it without becoming the department that says no.
Start with GitHub Enterprise CloudWhat this cluster answers
Section titled “What this cluster answers”The layering rule
Section titled “The layering rule”Everything here depends on one property.
A vertical chain: enterprise policy, organization policy, repository ruleset, the targeted branch tag or push, and the developer action that is permitted or refused.
Rules aggregate. They never relax. GitHub’s documentation states it directly: creating a new ruleset can make the rules targeting a branch or tag more restrictive, but never less restrictive. Every applicable ruleset applies, and the union is what a developer experiences.
Why that matters architecturally: a control applied at the enterprise cannot be undone by an organisation owner or a repository admin. You can reason about the floor without auditing what everybody below you has configured — which is the only thing that makes governance at this scale tractable.
The corollary developers feel: a repository admin cannot make their own repository less restricted, only more. That is correct and it is also the source of most governance friction, which is why the exception process matters as much as the rules.
Targeting by property, not by name
Section titled “Targeting by property, not by name”The shift that makes fleet-scale governance possible.
A list of repository names is wrong the day a new repository is created, and nobody notices, because nothing failed.
A filter on metadata is correct for repositories that do not exist yet. GitHub supports targeting a dynamic list of repositories by custom property — a filter such as visibility:private props.team:infra — at organisation level, and targeting organisations by name pattern or organisation custom property at enterprise level.
That is the difference between:
if repository == "payments-api"and:
if data_classification == "restricted"Custom properties is the load-bearing article in this cluster for that reason. Rulesets, repository policies and much of the fleet cluster all target properties, and a property schema nobody maintains makes all of them quietly ineffective.
Two different governance systems
Section titled “Two different governance systems”A distinction the product itself makes and the terminology obscures.
Rulesets govern code. What may be pushed, to which branches and tags, under what conditions. Required reviews, status checks, signed commits, linear history, push restrictions. Enterprise and organization rulesets.
Repository policies govern repository lifecycle. Who may create a repository, delete one, transfer one out of an organisation, what visibility it may have, and what it may be named. Repository policies.
They are not alternatives. A ruleset cannot stop somebody creating a public repository; a repository policy cannot require a signed commit.
A third mechanism still exists: traditional organisation member privilege settings. Older, coarser, and still the enforcement point for several things the newer systems do not cover.
Internal is not private
Section titled “Internal is not private”The visibility level people most often describe incorrectly.
GitHub’s documentation is unambiguous: organization members have read permissions to all internal repositories in an enterprise, including those in organizations they are not a member of.
Read that again. An internal repository is readable by every member of every organisation in the enterprise — not just the owning organisation. That is the feature, and it is what makes innersource possible.
It is also a security consequence. A team that marks a repository internal expecting “private but shared with a few people” has made it readable by the entire company. Internal repositories covers the model properly, and visibility and fork governance covers the controls.
Where this cluster differs from Pillar 3
Section titled “Where this cluster differs from Pillar 3”Pillar 3’s rulesets article explains what a ruleset is, what rules exist and how they layer within a repository. Read it first if rulesets are new to you.
This cluster starts where that ends: applying rulesets from the enterprise and organisation levels, targeting repositories you cannot enumerate, deciding what belongs at which layer, and rolling changes out without breaking two thousand builds on a Tuesday morning.
The same relationship holds for Pillar 5: that pillar covers what a control does and why it matters; this one covers applying it consistently to a fleet.
Where policy should live
Section titled “Where policy should live”A recurring question with a usable rule: put a control at the highest level where it is universally correct, and no higher.
Enterprise level for controls that are true everywhere and whose exceptions are genuinely exceptional. A rule wrong for one organisation is wrong on every repository in it, and there is no clean local override.
Organisation level for the bulk of governance. Most standards are correct for a business unit and not the whole company, and organisations are where delegated ownership actually sits.
Repository level for what a team decides for itself, above the floor set elsewhere.
The instinct to resist is applying everything at enterprise level because it is tidy. It produces rules whose exceptions cannot be expressed, which means either the rule is weakened for everybody or a bypass list grows until it is meaningless.
The opposite instinct — leaving everything to repositories — is what produces the fleet inconsistency this cluster exists to address.
The practical shape most organisations converge on: a small enterprise-level floor of security-critical rules, a substantial organisation-level layer reflecting each business unit’s standards, and repositories free to add whatever they want on top.
Learning objectives
Section titled “Learning objectives”By the end of this cluster you should be able to:
- Describe the enterprise, organisation, team and repository hierarchy, and decide how many organisations an enterprise should have
- Explain how rulesets layer and why a lower level cannot relax a higher one
- Target repositories dynamically by custom property rather than by name
- Distinguish rulesets, repository policies and member privilege settings, and say which governs what
- Explain who can read an internal repository, and design a fork policy that matches your risk
- Design a repository custom property schema somebody will actually maintain
- Use custom repository and organisation roles for delegated administration instead of granting
admin - Set repository lifecycle standards — creation, naming, ownership, archival — that scale
- Build an innersource model that is more than making everything internal
Enterprise use cases
Section titled “Enterprise use cases”A security standard that must hold everywhere. Signed commits on production repositories, no force-push to default branches, required review. The enterprise ruleset case.
An acquisition arriving. A new organisation with unknown configuration that must reach the corporate baseline without breaking its teams’ work.
A regulated subset. Forty repositories handling payment data needing stricter controls than the other nine hundred, identified by property rather than by list.
Delegated administration. Team leads who need to manage their own repositories’ settings without organisation-owner access.
An innersource programme. Making internal code discoverable and contributable across business units without abandoning ownership.
Repository sprawl. Anybody can create a repository, nobody archives one, and the estate has grown 40% a year with no naming or ownership convention.
Three categories of rule
Section titled “Three categories of rule”The framing that keeps governance from becoming obstruction, and it should be applied to every proposed control.
Mandatory policy. A security or compliance requirement that must hold, enforced so bypass is recorded. Keep this list short. Every item on it costs friction on every repository forever, and a long list of mandatory rules is one where nobody can remember which matter.
Golden default. A strong recommendation applied by default and deviable with a reason. A standard workflow, a template, a branching model. Deviation costs the team support rather than an argument with a platform team.
Team customisation. Genuinely local. How many approvals beyond the mandatory floor, directory conventions, review etiquette.
The test for whether something is mandatory: would you be comfortable with it blocking somebody at 2am during an incident? If not, it belongs in the second category with an exception path, or it belongs in a ruleset with a bypass actor who can be held accountable for using it.
The failure to avoid is a platform team that centrally configures every repository setting because it can. That produces a bottleneck, resentment, and — predictably — teams that route around governance entirely by creating repositories somewhere it does not apply.
Rolling policy out safely
Section titled “Rolling policy out safely”Nothing in this cluster should be applied to a thousand repositories on its first day.
The sequence that works, covered fully in policy rollout:
Inventory what exists, because you cannot assess impact against an unknown set.
Classify using custom properties, so the target set is describable.
Draft the rule against a small pilot.
Evaluate. Rulesets support an enforcement status of evaluate, which does not enforce but lets you monitor which actions would violate the rule. This is the single most valuable feature for enterprise rollout and the one most often skipped.
Measure the violations. A rule that would break 300 repositories is a project; one that would break three is a change.
Fix or exempt each existing violation deliberately.
Enforce, then monitor.
The step that gets skipped is evaluation, and skipping it is how a well-intentioned security rule stops every build in an organisation before lunch.