architecture-coupling-and-quantalisted

# Architecture Coupling and Quanta ## Purpose and scope Make a coupling claim checkable: what depends on what, for which change or workflow, and what evidence supports the boundary. Use a focused edge review for a small task; use an estate map only when the question needs it. One team can own several tightly coupled deployables; team count is not an activation threshold. An architecture quantum is a practitioner model involving independent deployment, functional cohesion, static dependencies and synchronous runtime coupling. These are different questions, not interchangeable proof. This skill produces a qualified map, not a universal graph formula or a split/merge recommendation. Read [Coupling vocabulary](references/coupling-vocabulary.md) when defining quantum boundaries or distinguishing connascence forms. ## Workflow 1. **Fix the claim and scope.** Name the environment, observation window, relevant operation/ success criterion and change class (for example additive API evolution versus removing a shared column). Inventory independently addressable deployment/rollback targets and their artifacts. One pipeline can ship several targets; a target can use several pipelines. Published libraries and shared platforms enter as dependencies, not extra service deployments. 2. **Collect enough evidence for the claim.** For release independence, inspect manifests, dependency versions, migration ownership, API/event contracts and deployment/rollback records. For