docs(pro): Asset Identity is a Feature Flags toggle, with how to turn it off

docs/content/admin/feature_flags/PRO__feature_flags.md

@@ -133,6 +133,7 @@ Features under **MCP** appear on the Feature Flags page beneath the MCP server s
 | **AI Threat Modeling** | Generate a STRIDE threat model, attacker profiles, attack paths and security requirements from a feature design with Sensei. | On | [Docs](/sensei/threat_modeling/) |
 | **Airgapped instance** | This instance has no route off its network, so it never contacts DefectDojo. The version check, external tools, announcements, threat intel downloads and error and performance diagnostics stop, and both support pages show the DefectDojo support address instead. Load threat intel bundles from a file. The DD_AIRGAPPED environment variable turns this on for the whole deployment. | Off | [Docs](/get_started/pro/onprem/airgapped/) |
 | **Asset Exposure** (BETA) | Compute whether an asset is reachable from outside, and whether a finding's code is actually deployed in production, from the evidence connectors already collect. Both feed prioritization; exposure can also drive the FedRAMP VDR SLA tiers. | Off | [Docs](/triage_findings/finding_scoring/asset_exposure/) |
+| **Asset Identity** | Let connectors find each Asset by the identifier its source uses instead of by name, and list every identifier it is known by on its Identity card. Records that are already mapped stay where they are. Turning this off goes back to matching by name; the identifiers are kept. | Off | [Docs](/asset_modelling/engagements_tests/pro__assets/#asset-identity-aliases) |
 | **Calendar** | Show the Calendar in the sidebar. The calendar plots engagements and tests on a month view. Turning this off removes the entry; it does not change any engagement or test dates. | On | [Docs](/navigation/pro__sidebar/) |
 | **Celery Status** | Expose background-task queue health in the UI. | Off | [Docs](/admin/pro__celery_status/) |
 | **Certification Control Catalogs** (BETA) | Assess a product against ISO/IEC 27001:2022 Annex A, the SOC 2 Trust Services Criteria and the NIS2 technical requirements, and see one body of evidence answer all three in the cross-framework view. Running the assessments also needs **EU Evidence Packs** and **Compliance**. | Off | [Docs](/federal_compliance/certification_catalogs/) |

docs/content/asset_modelling/engagements_tests/PRO__assets.md

@@ -305,9 +305,25 @@ again — to stop a Connector claiming an Asset, change its mapping rather than
 
 Adding and withdrawing an alias requires edit permission on the Asset.
 
-Aliases require `DD_V3_ASSET_ALIASES` to be enabled before they can be created, and the Asset
-Identity card and the **Type** field appear only when it is on; existing aliases stay readable
-whether it is on or off.
+### Turning Asset Identity on and off
+
+Aliases are controlled by the **Asset Identity** feature on the
+[Feature Flags](/admin/feature_flags/pro__feature_flags/) page. While it is off, Connectors map
+Records by name alone, you cannot add or withdraw aliases, and the Asset Identity card and the
+**Type** field are hidden. Existing aliases stay readable through the API either way.
+
+Turning it on changes nothing about Records that are already mapped. Each Connector records its
+own identifier for a Record whenever that Record's Mapping is created or changed, whether the
+feature is on or not, so a Record you remapped by hand while it was off stays on the Asset you
+chose once it is on. A change takes effect without a restart.
+
+To go back to matching by name, turn **Asset Identity** off, or run
+`python manage.py set_feature asset_aliases False` in a DefectDojo container. The aliases are
+kept, so turning it on again later is just as safe.
+
+Earlier releases switched this with the `DD_V3_ASSET_ALIASES` deployment setting. An instance
+that had it set to `True` keeps the feature on; otherwise the setting has no effect, apart from
+standing in for the stored value when DefectDojo starts without its database.
 
 ### Container image repositories (the `oci` namespace)
 
@@ -380,8 +396,8 @@ Identity card shows them.
 
 `--connector-config <id>` limits the run to one Connector configuration, and `--json` prints
 the report as JSON. The command never merges Assets or moves Records, and running it again
-only records what is still missing. It works whether or not `DD_V3_ASSET_ALIASES` is on, so you
-can run it before turning identity on.
+only records what is still missing. It works whether or not **Asset Identity** is on, so you
+can run it before turning it on.
 
 ## Asset Versions
 

docs/content/connectors/upstream/manage_records.md

@@ -62,10 +62,12 @@ step 1 (and, for other tools, step 2) answers from then on. A Record already kno
 identifier stays on its Asset even when its repository resolves elsewhere: DefectDojo shows
 that as a repository conflict on both Assets rather than moving its Findings.
 
-Steps 1 and 2 require the identity feature to be enabled (`DD_V3_ASSET_ALIASES`); until then,
-Auto-Mapping resolves by name alone, which is the historical behaviour. Enabling it changes
-nothing about existing Mappings: the first Discover after it is turned on records identifiers
-for the Records you already have, and later runs use them.
+Steps 1 and 2 require the **Asset Identity** feature (see
+[Turning Asset Identity on and off](/asset_modelling/engagements_tests/pro__assets/#turning-asset-identity-on-and-off));
+until it is on, Auto-Mapping resolves by name alone, which is the historical behaviour. The
+tool's identifier is still recorded whenever a Mapping is created or changed, so enabling it
+changes nothing about existing Mappings: Records keep the Asset they are on, and later runs follow
+the identifier.
 
 Because names are matched globally, two tools that each report something called `payments` map
 to the same Asset on first sight. Recording each tool's identifier separately is what stops
@@ -98,10 +100,12 @@ step 1 (and, for other tools, step 2) answers from then on. A Record already kno
 identifier stays on its Product even when its repository resolves elsewhere: DefectDojo shows
 that as a repository conflict on both Products rather than moving its Findings.
 
-Steps 1 and 2 require the identity feature to be enabled (`DD_V3_ASSET_ALIASES`); until then,
-Auto-Mapping resolves by name alone, which is the historical behaviour. Enabling it changes
-nothing about existing Mappings: the first Discover after it is turned on records identifiers
-for the Records you already have, and later runs use them.
+Steps 1 and 2 require the **Asset Identity** feature (see
+[Turning Asset Identity on and off](/asset_modelling/engagements_tests/pro__assets/#turning-asset-identity-on-and-off));
+until it is on, Auto-Mapping resolves by name alone, which is the historical behaviour. The
+tool's identifier is still recorded whenever a Mapping is created or changed, so enabling it
+changes nothing about existing Mappings: Records keep the Product they are on, and later runs follow
+the identifier.
 
 Because names are matched globally, two tools that each report something called `payments` map
 to the same Product on first sight. Recording each tool's identifier separately is what stops