Skip to content

Layer-Placement Fitness Check

Placement diagnostic — instantiates Layer-Appropriate Capability Placement

Scores each candidate layer against the requirement it would have to own — variety, expressiveness, security, lifecycle cost, governance — and names the layer that can carry the capability well.

A Layer-Placement Fitness Check is the sizing step that decides which layer should own a capability before anyone builds it in the wrong one. Given a capability and a stack of candidate layers — the narrow subsystem, the host beneath it, a shared service alongside — it scores each candidate against the demands the capability would place on its owner: how much requirement variety it must absorb, how expressively the layer can represent it, what it costs over the capability's lifecycle, and how it fares on security, latency, portability, and governance. Its defining move is refusing the default of "wherever it's convenient to write the code" and instead making placement an explicit, criteria-scored decision, so a capability lands in the layer that can express and govern it well rather than the one that happened to notice the need first.

Example

An engineering org keeps re-litigating where request rate-limiting should live. Three candidates: inside each microservice, in the shared service-mesh sidecar, or at the edge API gateway. The Fitness Check scores them against the capability's real demands. Requirement variety: limits differ per-tenant and per-endpoint, which the gateway expresses centrally but individual services would each reimplement — advantage gateway. Latency: a per-service check is closest to the work, but the gateway rejects abusive traffic before it costs anything downstream. Governance: security wants one auditable place to tighten limits under attack — strongly advantage gateway. Lifecycle cost: putting it in every service means N implementations drifting out of sync — the shadow-platform smell.

The scored result isn't unanimous, but it's legible: coarse abuse-limiting belongs at the gateway (which the ownership matrix now records as its owner), while fine-grained per-feature fairness stays in the services that understand their own semantics. The decision rests on written criteria the next team can revisit — not on whoever's sprint had room.

How it works

  • Map the candidate layers. Lay out the host–subsystem stack and enumerate which layers could own the capability, not just the one currently proposed.
  • Name the criteria. Fix the axes that matter for this capability — requirement variety, expressive surface, lifecycle cost, security/isolation, latency, portability, governance — before scoring, so the test isn't rigged toward a favourite.
  • Score each layer against each axis. Rate how well each candidate can actually carry the capability, surfacing where a narrow layer would have to imitate the host to comply.
  • Assign ownership. Record the winning layer in an ownership matrix, including any deliberate split (coarse here, fine there), so there is one authoritative answer to "whose job is this?"

Tuning parameters

  • Criteria weighting — which axes dominate. Weighting latency picks a different layer than weighting governance; making the weights explicit is what keeps the check honest.
  • Capability granularity — whether it's scored as one lump or split into sub-capabilities that may place differently. Finer splitting finds better fits but multiplies interfaces.
  • Candidate breadth — how many layers are seriously considered. Including "a new shared service" as a candidate can beat both the subsystem and the host, but widens the analysis.
  • Scoring rigor — a quick qualitative red/amber/green versus a weighted quantitative score. More rigor resists motivated reasoning but costs time and can lend false precision.
  • Re-check trigger — whether placement is decided once or revisited as requirement variety grows; a fit that was right at low variety can decay as demands accumulate.

When it helps, and when it misleads

Its strength is that it makes placement a decision with reasons attached, catching the two classic errors early — pushing a capability too low (a narrow layer forced to reconstruct host facilities) and hoisting it too high (the host burdened with concerns a leaf should own). It is a practical instrument of the end-to-end principle: put a function at the layer that can implement it completely and correctly, and no lower.[1]

Its weaknesses are those of any scoring model. The criteria and weights encode judgement, so a check can be quietly steered toward the answer someone already wanted, and a tidy score can lend false confidence to what is really a contested trade-off. The misuse to watch is running it backwards — assembling criteria to ratify a placement already chosen for convenience or team ownership. The discipline is to fix the criteria and weights before scoring, to include candidate layers the proposer didn't suggest, and to re-run the check as the capability's requirement variety grows rather than treating the first placement as permanent.

How it implements the components

The Fitness Check fills the decision side of the archetype — the components that turn "which layer?" into an authoritative answer:

  • host_subsystem_layer_map — laying out the candidate layers is the check's first artifact: an explicit map of who sits where in the stack.
  • layer_placement_criterion — the scored axes are the criterion; the check operationalizes "the right layer" into named, weighted tests.
  • capability_ownership_matrix — its output records which layer owns the capability, and any deliberate split, giving one authoritative source for placement.

It decides where a capability belongs but does not inventory what the host already offers (that's the sibling Capability Catalog), profile the incoming demand it scores against (that's Extension-Request Workflow), or build the interface once placement is set (that's Host-Service API Delegation).

Notes

The Fitness Check and the Shadow-Platform Audit apply the same standard at opposite ends of the lifecycle — the check decides correct placement before building; the audit later detects where a capability has drifted into the wrong layer anyway. A placement recorded here is also only a recommendation until an owner accepts it and it is captured in an Architecture Decision Record.

References

[1] The end-to-end principle (Saltzer, Reed & Clark, "End-to-End Arguments in System Design") argues that a function is best placed at the layer where it can be completely and correctly implemented, and is often redundant or harmful when pushed into lower layers that lack the necessary knowledge. It is the canonical statement of "place the capability at the right layer." ↩