What Belongs in Core vs. Not
The Core Question
Before writing a single line of code or policy, the enterprise must answer:
"If we removed this from the core tomorrow and every project team rebuilt it independently, what would happen?"
If the answer is "chaos, inconsistency, and security risk" → it belongs in core. If the answer is "they'd build something slightly different, but fine" → it probably doesn't.
Criteria for "Belongs in Core"
A capability belongs in the federation core if it satisfies 3 or more of the following:
| Criterion | Explanation |
|---|---|
| Cross-cutting concern | It affects every project regardless of domain (e.g., auth, logging) |
| Regulated / compliance-bound | External regulations mandate consistency (GDPR, SOC2, HIPAA) |
| High cost to rebuild | Significant engineering effort to re-create per project |
| Network-effect value | It becomes more valuable when all teams use the same version |
| Risk if inconsistent | Inconsistency creates security holes or data integrity issues |
| Strategic differentiator | It represents how the enterprise competes (e.g., proprietary AI models at Google) |
What Definitely Belongs in Core
Infrastructure Layer
- Identity & Access Management (IAM / SSO)
- Secrets management (Vault, KMS)
- Observability stack (logging, metrics, tracing standards)
- CI/CD pipeline templates and approval gates
- Container orchestration standards (K8s base configs, Helm charts)
- Cloud cost governance and tagging policies
Application Layer
- Authentication/Authorization SDKs (not just the service — the client SDK too)
- Common data contracts and schema registry
- API gateway and inter-service communication standards
- Event bus / message broker standards (topic naming, schema evolution rules)
- Error handling and retry conventions
Process / Governance Layer
- Security review checkpoints (mandatory, non-negotiable)
- Dependency vulnerability scanning policies
- Data classification and handling policies
- Architectural Decision Record (ADR) templates and review process
What Does NOT Belong in Core
This is equally important — an overloaded core becomes a bottleneck.
| Category | Why It Doesn't Belong in Core |
|---|---|
| Business domain logic | Specific to a project's problem — core cannot own what it doesn't understand |
| UI component libraries | Style varies by client/product — core can set a token system, not every button |
| Project-specific data models | Core should own the schema registry format, not every entity |
| Technology experiments / POCs | Core must be stable; experiments belong in project sandboxes |
| Client-mandated tools | If a client requires Jira over the core's Asana, that's a boundary the core cannot enforce |
| Operational runbooks | Too project-specific; core can provide templates, not the runbook itself |
The "Thin Core" Principle
The best enterprise federation layers follow a thin core principle:
Core provides the minimum viable set of constraints and capabilities that prevent the worst outcomes. Everything else is project team discretion.
Thick cores (that try to own everything) create:
- Single points of failure
- Core team becoming a bottleneck
- Project teams working around the core ("shadow IT inside the enterprise")
The Gradient — Not Binary
In practice, the decision is not binary. There's a spectrum:
MANDATORY (Core owns, enforces)
→ RECOMMENDED (Core provides, project teams should use)
→ AVAILABLE (Core built it, teams can optionally adopt)
→ DELEGATE (Core sets the principle, teams implement their own)
→ AUTONOMOUS (Pure project-team territory)
A mature federation layer is explicit about which tier each capability sits in.
A Useful Test: The "12 Projects" Test
Ask: "If 12 independent project teams were each solving this problem, how many different solutions would they produce, and would any of those solutions be dangerous?"
- If dangerous solutions are likely → Core must mandate
- If solutions would be redundant but harmless → Core should offer
- If solutions would naturally converge anyway → Core can ignore