fixup

docs/reference/configuration/credentials-operator/README.mdx

@@ -46,9 +46,6 @@ The operator consults the label `credentials-operator.otterize.com/tls-secret-na
 When using SPIRE, once the operator has registered the pod with SPIRE, which happens automatically upon startup, the pod can use the SPIRE Workload API to generate credentials for the SVID `<servicename>.<namespace>`.
 
 ### Service name resolution and automatic pod labeling
-Service name resolution is performed one of two ways:
-1. If an `intents.otterize.com/service-name` annotation is present, that name is used (`intents.otterize.com/service-name` can be changed to a custom annotation name when installing the operator by setting the value of `global.serviceNameOverrideAnnotationName`.).
-2. If not, a recursive look up is performed for the Kubernetes resource owner for a Pod until the root is reached. For example, if you have a `Deployment` named `client`, which then creates and owns a `ReplicaSet`, which then creates and owns a `Pod`, then the service name for that pod is `client` - same as the name of the `Deployment`.
-
-The value resulting from this process forms the value of the label `credentials-operator.otterize.com/service-name`.
+The operator performs service name resolution for each pod. You can read more about the resolution algorithm [here](/reference/service-identities#kubernetes-service-identity-resolution).
+The value resulting from this resolution process forms the value of the label `credentials-operator.otterize.com/service-name`.
 

docs/reference/service-identities/README.mdx

@@ -8,11 +8,13 @@ Otterize uses universal service identities to refer to services, regardless of w
 ## Kubernetes service identity resolution
 How do Otterize operators decide what is the name of the service that runs within the pod? The algorithm is as follows:
 
-1. If the pod has an `intents.otterize.com/service-name` label, its value is used as the service name. This allows developers and
+1. If the pod has an `intents.otterize.com/service-name` annotation, its value is used as the service name. This allows developers and
    automations to explicitly name services, if needed. The value must not contain a period `.` as a period is used to separate service name and namespace, when the service is from a different namespace: `svcname.namespace`.
-2. If there is no `intents.otterize.com/service-name` label, a recursive look-up is performed for the Kubernetes resource owner of
+2. If there is no `intents.otterize.com/service-name` annotation, a recursive look-up is performed for the Kubernetes resource owner of
    the pod, until the root resource is reached, and its name is used as the service name. For example, if you have
    a `Deployment` named `checkoutservice`, which then creates and owns a `ReplicaSet`, which then creates and owns
    a `Pod`, then the service name for that pod is `checkoutservice` - same as the name of the `Deployment`. This is
    intended to capture the likely-more-meaningful "human name" of the service. If the resulting service name contains
-   a period `.`, it is replaced with an underscore `_`. Periods are used in service names to denote namespaces, e.g. `svcname.namespace`.
+   a period `.`, it is replaced with an underscore `_`. Periods are used in service names to denote namespaces, e.g. `svcname.namespace`.
+
+* Custom annotation can be set instead of `intents.otterize.com/service-name` (fo more information go to the [otterize helm chart documentation](/reference/configuration/otterize-chart#global-parameters)).