Product capability
Configuration ownership
Existing configuration deserves more than a naming convention.
The operational problem
Existing PBX objects can belong to another service or reflect deliberate administrator choices. Names and apparent similarity are not enough to justify changing them.
Configuration protection / four cases
A matching name
is not permission.
What matters is verified ownership and the actual configuration, not whether an object looks familiar.
Manage after verification
Ownership is recorded only after creation has been verified. Later changes require the current object to match the recorded evidence and the new configuration to remain provider-authorised.
A practical example
An existing trunk looks compatible
If its configuration exactly matches the required state, it may be reused without becoming owned. If it needs a change and is unowned, DOMAINTAINS must stop. A safe legacy adoption is a separate, reviewed administrator action, not an automatic migration.
Record verified creation
The ownership ledger records native FreePBX object identities and configuration fingerprints only after creation has been verified. Trunks, routes and number configuration outside that authority remain protected. Exactly matching unowned objects may be reused, but reuse does not confer ownership.
Reject drift
Reconciliation checks the current configuration against recorded ownership evidence. Unexpected administrator changes fail closed rather than being silently overwritten or adopted. A provider-authorised change can be applied when the existing owned object still matches its recorded fingerprint.
Adopt only after review
Safe legacy configuration can require explicit administrator-confirmed adoption. Conflicting or ambiguous objects cannot be adopted. Do not delete the ownership ledger or recreate trunks to bypass a conflict; preserve native identities and inspect the diagnostic first.