Typed models of where things run and how they layer.

Deployment & tier topology

Intent — Typed models of where things run and how they layer (the managed-deployment topology, each service's tier class, and the agent-substrate's layer boundaries), so deploy scripts and layering lints reason about a declared topology, not scattered constants.

Motivation — the failure it kills

Deployment facts (which layer a service is in, its tier, what may depend on what) end up hardcoded in deploy scripts and import checks. Hardcoded, they drift from the real topology: a service moves tier, a layer boundary is quietly crossed, and the deploy or an architectural invariant breaks. And an agent reasoning about "can layer X import layer Y?" needs the boundary declared, not inferred.

Why it's not just "encode the topology in the deploy scripts"

Topology in the deploy scripts is a copy. It drifts from the real service set and from the layering the code actually has. These typed models declare the topology once (managed-deployment loader, tier classification, layer-boundary contracts), and parity lints check the declaration against reality (deploy phase tables, import-layer checks). One declared topology, validated against the running system, means a moved tier or a crossed boundary fails a lint at author time — the scattered constants had no such check, so they drifted until a deploy broke.

Mechanism

The Deployment-topology loader is the typed loader for the managed-deployment topology; the Service-tier registry classifies each service's tier; the Layer-boundary contracts declare the layer boundaries for the agent substrate. Deploy scripts and layering lints (the deploy-phase-table parity lint, the import-layer checks) read them and gate on divergence.

Prerequisites

• A typed topology + tier + layering schema.
• Deploy scripts + layering lints that read it rather than hardcoding.
• Parity lints against the real deploy tables and import graph.

Consequences & costs

• Topology changes are model edits — a moved tier or new layer boundary means a model edit or a parity failure.
• Layering contracts constrain the code — a declared boundary blocks a cross-layer import (deliberately; a real cost to expedient shortcuts).

Known uses

• The Deployment-topology loader · Service-tier registry · Layer-boundary contracts.
• The deploy-phase-table parity lint + the import-layer boundary lints.

Related mechanisms

• Bridge — agents reason about layering/tiers through these models (agent side) ◀──▶ they govern the real deployment + import structure of the codebase (product side).
• Enabler — feeds model-driven-codegen (deploy/env generation).
• Counterpart — drift-parity-gates: the deploy-parity + layer lints.