Module ownership and migration
==============================

``manifests/module_ownership.json`` classifies every current top-level public module as
``retain``, ``narrow``, ``migrate``, ``deprecate`` or ``experimental``. A test
fails whenever a top-level module is added without a decision.

Classification is not deletion. A ``migrate`` decision identifies the future
owner while the current Core surface remains compatible. Removal requires a
published replacement, caller inventory, adapters, migration documentation,
and at least one governed release-window deprecation gate. ``narrow`` retains a
quantitative center while preventing new workflow ownership from accumulating.

The artifact is the machine-readable source; the maturity and API manifests
continue to gate what is actually public and supported in each release.