Update patterns/1-initial/centralised-repository-governance.md

Co-authored-by: Sebastian Spier <github@spier.hu>

Author: amburi

patterns/1-initial/centralised-repository-governance.md

@@ -30,6 +30,22 @@ The audit did not block teams. It made readiness visible and helped maintainers
 * An InnerSource Portal, source code inventory, or repository catalogue may already exist.
 * GitHub Actions, GitHub APIs, or similar automation tooling is available.
 
+### Use This Pattern When
+
+* You have many InnerSource repositories owned by different teams.
+* Contributors struggle to identify how to use or contribute to projects.
+* InnerSource Portal quality depends on repository metadata and project hygiene.
+* Manual readiness checks are too slow or incomplete.
+* You want transparent policy-as-code instead of undocumented central checks.
+* Poor contributor experience costs more than maintaining the governance process.
+
+### Don’t Use This Pattern When
+
+* Only a few InnerSource repositories exist and manual support is enough.
+* You need hard enforcement at merge time rather than periodic guidance.
+* You cannot maintain repository ownership or lifecycle metadata.
+* You cannot protect the governance repository and its credentials.
+* Most projects require unique contribution models that do not fit a small set of profiles.
 ## Forces
 
 * **Autonomy vs consistency:** Teams need local ownership; contributors need predictable project signals.