Chapter 5: The Adapter Model
Executive Governance Series
The Adapter Model
The Federal Modernization Program adapter is the substrate’s mechanism for bringing tools and control planes into a canonical governance surface without absorbing their idiosyncrasies into canon. This chapter explains the dual-axis taxonomy that makes adapters governable, the two-registry model that keeps modernization separate from conformance, and the canon invariants that constrain every adapter regardless of vendor.
The dual-axis taxonomy
Per FMP_003, every adapter declares two attributes:
class:modernizationorconformance.- Modernization adapters are change-making. They mutate state in pursuit of a target architecture (e.g. moving identities from AD to Entra ID, reshaping the addressing plane).
- Conformance adapters are read-only. They observe state and emit canonical claims; they do not mutate.
mission-class: one ofidentity,telemetry,policy,enforcement, orintegration. Each adapter belongs to exactly one mission class — the canonical concern it primarily serves.
The cross-product yields a 2×5 matrix. Every adapter lands in exactly one cell. The taxonomy is canonical (declared in adapter-registry.yaml and modernization-registry.yaml) and validated in CI by adapter-conformance.yml.
Why two registries
The two registries are not bureaucratic. They reflect a substrate invariant: conformance adapters must not mutate state. A conformance entry in the wrong registry would silently violate the SSOT principle, so the canon enforces the separation by file, not by field.
The separation is enforced by file, not by field — so a reviewer can verify the invariant before reading a single line of adapter code.
Operationally:
- A vendor-supplied policy assessor (ScubaGear) ships as a
conformance / policyadapter. It observes M365 state and emits canonical claims. It cannot mutate the tenant. - A directory-migration adapter (bluecat-address-manager) ships as a
modernization / identityadapter. It is expected to mutate state; the modernization registry is the file that grants that authority.
A reviewer auditing a PR can check the file-level invariant before reading any code: a conformance adapter editing the modernization registry is a structural error.
At a glance — the two registries:
| Conformance adapter | Modernization adapter | |
|---|---|---|
| Example | ScubaGear (conformance / policy) |
bluecat-address-manager (modernization / identity) |
| Behavior | Observes state, emits canonical claims | Mutates state toward a target architecture |
| SSOT mutation | Never | Governed by canonical change records |
| Registry file | adapter-registry.yaml |
modernization-registry.yaml |
Canon invariants every adapter inherits
Every adapter, regardless of class, inherits four canon invariants:
| Invariant | Meaning |
|---|---|
gcc-boundary: gcc-moderate |
Adapter operates within the GCC-Moderate authorization boundary (or a named exception per the program decision) |
ssot-mutation: never (conformance) / governed (modernization) |
Conformance never mutates SSOT; modernization mutations are governed by canonical change records |
certificate-anchored: true |
mTLS-anchored emission of canonical claims |
object-identity-only: true |
Identity claims resolve to identity-plane objects, not to opaque strings |
These are not suggestions. They are schema-validated on every PR.
Microsoft Graph adapter convention
Adapters that read from Microsoft Graph resolve their endpoint via fmp.adapters._graph_clouds.resolve_graph_base rather than hardcoding hostnames. Accepted config keys:
cloud:commercial/gcc-high/dod(defaultcommercial, also serving GCC-Moderate per the program decision).graph_api_version: per-adapter default (betafor IntuneAdapter;v1.0for EntraAdapter, M365Adapter, EntraDynamicGroupsAdapter, EntraAdminUnitsAdapter, InBoundaryTelemetry).- An explicit URL override (
graph_endpointfor most adapters;api_base_urlfor the two Entra group/AU adapters that pre-dated the convention).
Unknown clouds fail closed at construction. The convention is what makes the substrate cloud-portable without per-adapter rewrites.
Adapter retirement (the program decision)
Adapters do not vanish; they retire. the program decision defines the retirement path: an adapter that is no longer maintained or whose target capability has been superseded transitions through deprecated → retired states with explicit canonical successor pointers. Substrate-walker findings catch references to retired adapters as DRIFT-PROVENANCE, ensuring no consumer silently keeps using them.
This is what allows the substrate to evolve without forcing a forklift upgrade: retirement is a substrate transition, not a removal.
Honest limits
- The taxonomy is opinionated. Tools that do not fit a single mission-class either decompose into multiple adapters or wait for a taxonomy ADR. There is no “miscellaneous” mission-class.
- Adapter authoring is engineering work. The substrate provides the contract and the registry; vendors and agencies provide the per-tool implementations.
- The two-registry separation does not preserve adapters that mutate conformance behavior at runtime. A conformance adapter that silently mutates is a substrate-level violation, caught by drift detection and resolved by an ADR.
Key takeaways
- Adapters are the substrate’s tool-integration mechanism.
- The dual-axis taxonomy (class × mission-class) is canonical and enforced.
- Two registries (conformance / modernization) reflect a substrate invariant about mutation authority.
- Four canon invariants apply to every adapter regardless of vendor.
- Retirement is a governed substrate transition, not a removal.
Next: Chapter 6 — Evidence over Attestation — why the substrate treats machine-verifiable evidence, not a human signature, as the primary artifact.