The Building Inspector and the Electrician
Imagine two ways to check whether a building's electrical system is safe.
The first approach is direct.
The building inspector opens every panel.
Traces every wire.
Reads every circuit diagram.
They know exactly what the electrician built and exactly how it was built.
The inspection is thorough.
And then the electrician upgrades the internal wiring.
New conduit. Better routing. Improved cable management.
The building is safer than before.
But the inspector's notes are now wrong.
Every circuit reference. Every panel diagram. Every trace they documented.
All of it describes a wiring configuration that no longer exists.
The second approach is different.
The building inspector does not open the panels.
They plug into the test points.
The test point interface is fixed.
It does not change when the wiring changes.
The inspector reads voltage, continuity, and load capacity — through a stable interface that abstracts every internal detail.
The electrician can rewire the entire building.
The test point still returns the right answer.
The first inspector had deep knowledge of the implementation.
The second inspector had a stable interface to the outcome.
Most architecture fitness functions are written like the first inspector.
They probe the implementation directly.
They reference specific file structures. Package names. Dependency declarations. Internal API paths.
And the moment a delivery team refactors — the fitness function fails to compile.
Not because the architecture got worse.
Because the governance check was coupled to the implementation it was supposed to govern.
MCP is the test point layer.
Not because it was designed for governance.
Because its fundamental mechanical property — a stable interface contract between a consumer and a provider — is exactly what governance has always needed.
The AI industry discovered MCP first.
The architecture governance problem needed it longer.
Fitness Functions Were Right. The Implementation Was the Problem.
Architecture fitness functions were one of the most important governance ideas to emerge from evolutionary architecture thinking.
The principle is sound.
Define what your architecture must always be true of.
Encode that definition as an automated check.
Run it continuously.
If the architecture drifts, the check fails.
The principle works.
The implementation breaks.
Because fitness functions — as they are typically written — reach directly into the system they are governing.
They import packages. Parse codebases. Call internal endpoints. Read configuration files.
And delivery teams, doing exactly what delivery teams should do, refactor their internals.
They rename packages. Restructure modules. Extract services. Migrate configuration formats.
Each refactor is a valid architectural improvement.
Each one silently breaks a fitness function that was never designed to survive change.
Within months, three things happen.
The fitness function is commented out because it fails on every build.
Or the team spends more time maintaining the check than the architecture it was checking.
Or the governance tool is decommissioned because "it creates more work than it prevents."
The principle was not wrong.
The coupling was.
MCP Is Not an AI Protocol. Read What It Actually Does.
The AI industry labelled MCP the Model Context Protocol.
The label is accurate.
It is also the reason most architects have filed it under "AI tooling" and stopped reading.
That filing decision is the mistake.
Strip away the AI context entirely.
What MCP does mechanically is this.
It creates a stable interface contract between a consumer that wants to ask questions and a provider that holds the answers.
The consumer does not need to know how the provider stores its data.
The consumer does not need to know how the provider's internal structure is organised.
The consumer asks. The MCP server responds. The contract between them is fixed.
That contract does not care whether the consumer is an AI model or an architecture fitness function.
It does not care whether the question is "what documents do you have?" or "how many upstream dependencies does this service hold?"
The mechanism is identical.
The governance application has simply never been written down.
This is exactly the property that architecture fitness functions have been missing for years.
A fitness function that queries an MCP server does not care how the underlying system is built.
It cares about what the MCP server reports.
And the MCP server — controlled by the delivery team — is responsible for exposing the governance truth about their system through a stable interface.
The fitness function never needs to change.
The delivery team's implementation can change freely.
The test points stay the same.
Intent-Decoupled Governance (IDG)
Intent-Decoupled Governance (IDG) is a structured model for using MCP servers as the indirection layer between architecture governance intent and delivery implementation.
Its purpose is not to add a new governance process.
Its purpose is to decouple what architecture governance wants to know from how the system being governed is built.
IDG operates through three layers.
Each layer has a defined responsibility.
Each is separated from the others by a stable interface.
Layer 1: Governance Intent Layer
This is where the architect works.
The Governance Intent Layer contains the fitness functions — the definitions of what must always be true of the architecture.
Examples:
- No service may have more than three synchronous upstream dependencies
- All public APIs must return structured error schemas
- No domain module may import from another domain's internal package
- All data-at-rest must be encrypted at the storage layer
These are architecture truths.
They are expressed as queries against MCP servers.
They do not reference any implementation detail of the system being governed.
They ask. They do not inspect.
Layer 2: MCP Governance Server
This is the boundary layer.
The MCP Governance Server is owned and maintained by the delivery team.
It exposes a fixed set of governance endpoints — defined by the architecture team as part of the fitness function contract.
Examples of what a Governance MCP Server might expose:
get_upstream_dependency_count()→ returns integerget_api_error_schema_compliance()→ returns boolean and violation listget_cross_domain_import_violations()→ returns list of offending modulesget_data_encryption_status()→ returns compliance state per storage layer
The governance tool calls these endpoints.
The delivery team implements what sits behind them.
When the team refactors their internal structure, they update the MCP server implementation.
The governance endpoint stays identical.
The fitness function never breaks.
Layer 3: Implementation Layer
This is where the delivery team works.
The Implementation Layer contains everything the team builds, owns, and changes freely.
Package names. Internal modules. Dependency graphs. Configuration formats.
None of this is directly accessible to the governance layer.
It is all surfaced through the MCP server — which the team controls.
The team can refactor everything in this layer.
The governance layer asks the same questions and gets accurate answers.
The test points are stable.
The wiring can change.
The IDG Model
%% caption: The IDG model: governance intent stays fixed while the MCP server and implementation change beneath it
flowchart TD
A["🏛️ Governance Intent Layer\n(Architecture Team)\nFitness Functions as MCP Queries"]
B["🔌 MCP Governance Server\n(Delivery Team)\nStable Governance Interface"]
C["⚙️ Implementation Layer\n(Delivery Team)\nPackages · Modules · Services · Config"]
A -->|"Queries stable endpoints\n(never changes)"| B
B -->|"Reads internal state\n(implementation detail)"| C
C -->|"Team refactors freely\n(updates MCP impl)"| B
B -->|"Returns governance truth\n(same interface)"| A
The Two Governance Patterns
Most organisations operate one of two patterns today.
Neither is working.
| Pattern | How Fitness Functions Are Written | What Breaks |
|---|---|---|
| Direct Inspection | Fitness function reads codebase, parses files, calls internal endpoints | Every internal refactor breaks the check |
| Manual Review | Architecture standards reviewed in ARB sessions, not encoded as checks | Violations reach production undetected |
IDG introduces a third pattern.
| Pattern | How Fitness Functions Are Written | What Survives |
|---|---|---|
| Intent-Decoupled Governance (IDG) | Fitness function queries MCP server endpoints defined by contract | Implementation changes freely. Governance contract stays fixed. |
What the Two-Layer Architecture Looks Like in Practice
%% caption: Fitness functions query MCP server endpoints instead of reading the implementation directly
flowchart LR
subgraph GA["Governance Pipeline (Architecture Team)"]
F1["Fitness Function:\nmax_upstream_deps ≤ 3"]
F2["Fitness Function:\nAPI error schema compliant"]
F3["Fitness Function:\nNo cross-domain imports"]
end
subgraph MS["MCP Governance Server (Delivery Team)"]
E1["get_upstream_dependency_count()"]
E2["get_api_error_schema_compliance()"]
E3["get_cross_domain_import_violations()"]
end
subgraph IL["Implementation (Changes Freely)"]
I1["Service Internals\nPackages · Modules"]
I2["API Layer\nRoutes · Schemas"]
I3["Domain Structure\nBounded Contexts"]
end
F1 -->|query| E1
F2 -->|query| E2
F3 -->|query| E3
E1 -->|reads| I1
E2 -->|reads| I2
E3 -->|reads| I3
The fitness functions never change.
The MCP server endpoints never change.
The implementation changes constantly.
Governance survives.
What Breaks Without IDG
When fitness functions are coupled directly to implementation:
Governance becomes a maintenance burden.
Every team refactor triggers a fitness function failure.
The architecture team spends more time fixing governance checks than reviewing architecture decisions.
Fitness functions are deprioritised.
Then disabled.
Then removed.
Governance disappears — not through a decision to remove it, but through accumulated maintenance friction.
Standards become aspirational.
When automated checks break and nobody fixes them, the default fallback is manual review.
Manual review happens periodically.
Violations accumulate between reviews.
By the time an ARB session catches a coupling violation, the service has three other services depending on the non-compliant pattern.
Remediation costs ten times what early detection would have.
Teams learn that governance is fragile.
A delivery team that has broken three fitness functions by renaming a package learns a specific lesson.
Governance is brittle.
Governance is a constraint on their velocity.
Governance is not a property of the architecture — it is a property of the architecture team's bandwidth.
That lesson is difficult to unlearn.
When IDG is in place:
Refactors do not break governance checks.
Governance checks run on every deployment.
Standards are enforced continuously — not periodically.
Teams learn that governance is stable.
And stable governance builds trust.
What the Governance Contract Looks Like
The governance contract is the agreed interface between the architecture team and the delivery team.
It defines:
- Which MCP endpoints the delivery team must expose
- What each endpoint must return
- What constitutes a passing and failing response
Example governance contract for a service classified as Domain Service — Standard:
%% caption: Example governance contract: the endpoints a standard domain service exposes to fitness functions
classDiagram
class MCPGovernanceContract {
+get_upstream_dependency_count() int
+get_api_error_schema_compliance() ComplianceResult
+get_cross_domain_import_violations() List~Violation~
+get_data_encryption_status() EncryptionStatus
+get_deployment_ownership() OwnershipRecord
}
class ComplianceResult {
+compliant: boolean
+violations: List~string~
+checked_at: timestamp
}
class Violation {
+module: string
+imported_from: string
+severity: HIGH | MEDIUM | LOW
}
class EncryptionStatus {
+storage_layer: string
+encrypted: boolean
+algorithm: string
}
class OwnershipRecord {
+owning_team: string
+last_reviewed: timestamp
+adr_reference: string
}
MCPGovernanceContract --> ComplianceResult
MCPGovernanceContract --> Violation
MCPGovernanceContract --> EncryptionStatus
MCPGovernanceContract --> OwnershipRecord
The delivery team implements what is behind each endpoint.
The architecture team queries what comes out.
The contract between them does not change when either side evolves.
Implementation Guide (30–60 Days)
Introducing IDG requires a governance contract more than new technology.
MCP server infrastructure is already available in most delivery environments.
The missing piece is the discipline to define the interface before writing the checks.
Phase 1: Define the Governance Contract (Weeks 1–2)
Identify the five to eight fitness functions your organisation considers non-negotiable.
For each fitness function, define:
- What architectural property it is checking
- What question the fitness function needs to ask
- What a passing response looks like
- What a failing response must contain
Translate each fitness function into a named MCP endpoint specification.
Do not write implementation code yet.
Define the contract first.
Deliverable: Governance contract document — named MCP endpoints, return schemas, and pass/fail thresholds for each fitness function
Success Metric: At least five fitness functions expressed as MCP endpoint queries with no reference to implementation detail
Phase 2: Stand Up the MCP Governance Server (Weeks 3–4)
Select one bounded context as the pilot.
Work with the delivery team to stand up an MCP server that implements the governance contract endpoints.
The server reads from their actual implementation.
The governance contract endpoints return the agreed response schema.
Run the fitness functions against the MCP server.
Validate that the checks pass when the architecture is compliant and fail when it is not.
Deliverable: Running MCP Governance Server for pilot bounded context with all contract endpoints implemented and verified
Success Metric: All fitness functions return accurate compliance state against the pilot system's current architecture
Phase 3: Embed in Pipeline and Expand (Weeks 5–8)
Add the fitness function queries to the CI/CD pipeline for the pilot bounded context.
Fitness functions run on every deployment.
Failures block the deployment.
Validate one refactor cycle — the delivery team changes internal implementation and updates the MCP server without breaking any fitness function.
Expand to two additional bounded contexts.
Deliverable: Fitness functions running in CI/CD pipeline for three bounded contexts. One completed refactor cycle that did not break any governance check.
Success Metric: Zero fitness function breaks caused by internal implementation change across the pilot and two expansion contexts
Evidence from Practice
A FinTech company I worked with was adopting MCP to connect AI agents to internal systems. The engineering team saw it as a protocol integration. The security team saw it as a data exposure risk. Neither was wrong — but neither was asking the structural question: what does MCP mean for our governance architecture?
We analysed their MCP implementation through a governance lens: the protocol was not just transmitting data between agents and tools — it was creating a new layer where governance could be enforced uniformly. We defined governance contracts per bounded context, specifying what architectural invariants the MCP layer must enforce. Fitness functions validated these contracts in the deployment pipeline. The AI agents gained access to systems faster than before — but within governance boundaries that were enforceable and auditable.
The engagement was part of a broader AI operating model implementation: From 15 AI Pilots to 6 Prioritized Initiatives
Action Plan
This Week
Ask three questions:
- How many of your active fitness functions have been disabled or marked flaky in the past six months — and what caused each failure?
- When a delivery team refactors their internals, how many governance checks break that are unrelated to the architectural change?
- Can your fitness functions describe what they want to know without referencing how the system being governed is built?
If the first answer is more than two, implementation coupling has already eroded your governance layer.
Next 30 Days
Select one bounded context where fitness function failures are most frequent.
Map the five fitness functions that matter most for that context.
Express each as a question to an MCP server — not as an inspection of the codebase.
Define the governance contract.
Stand up the MCP server with the delivery team.
Run the fitness functions against it.
3–6 Months
Embed IDG as the standard for all new fitness functions.
Retire implementation-coupled fitness functions progressively — replacing each with an MCP-backed equivalent.
Establish the governance contract as a first-class deliverable in your architecture review process.
Every bounded context that passes architecture review should leave with a governance contract — not just a diagram.
Final Thought
The first building inspector knew everything about the wiring.
And every upgrade made their notes obsolete.
The second building inspector knew nothing about the wiring.
And every upgrade left their test points unchanged.
MCP was labelled an AI protocol.
The label is not wrong.
It is just not the most important thing MCP is.
MCP is a stable interface contract between a question and an answer.
Between what a consumer needs to know and what a provider chooses to expose.
Architecture governance has needed that contract for as long as fitness functions have existed.
The AI industry got there first.
That does not make it an AI tool.
It makes it a governance primitive that happened to ship with an AI label.
The test points do not move.
The wiring can change as often as it needs to.
Turn Your Fitness Functions Into Governance That Survives Delivery Change
If your fitness functions break every time a team refactors…
if governance checks are being disabled faster than they are being written…
or if your architecture standards exist in documents but not in your deployment pipeline —
the problem is not the standards.
It is the coupling between governance intent and implementation detail.
In a focused 30-minute IDG Diagnostic Session, we will:
- Identify which of your fitness functions are coupled to implementation and breaking silently
- Define the governance contract that your highest-risk bounded context should be exposing
- Introduce the MCP Governance Server model for your architecture practice
- Define a 30-day plan to decouple your governance layer from your delivery implementation
No new governance frameworks.
No fitness function rewrites from scratch.
No governance that breaks when your best team does their best work.
Just a stable interface between what architecture needs to know and how delivery chooses to build.
→ Book an MCP Governance Session
or
Governance that breaks on every refactor is not governance.
It is a suggestion with a build badge.
