First draft corrections

src/content/docs/apis/nerdgraph/examples/nerdgraph-api-secret-management-service.mdx

@@ -1,4 +1,4 @@
----
+ ---
 title: "NerdGraph tutorial: Secrets management service"
 metaDescription: "Learn how to use the Secrets management service to securely store and manage your secrets."
 freshnessValidatedDate: never
@@ -23,15 +23,15 @@ To access and use a secret across multiple accounts, you can store it at the org
 
 * **Controlled deletion and recovery of secrets**: The service allows recoverable deletion of secrets. Users without the Purge permission can soft-delete secrets. Permanent deletion is restricted to users with the Purge permission.
 
-* **Access control**: Admins can define who can access the secrets by setting custom roles and permissions, and specifying the scope of permissions. The scope can range from <dnt>**View**</dnt> to <dnt>**Purge**</dnt> permissions. For secrets requiring stricter access control, you can use sharable secrets with fine-grained access.
+* **Standard secrets with role-based access**: Standard secrets are accessible to all users with permissions in the account or organization. Admins control access by assigning custom roles with permission levels ranging from <dnt>**View**</dnt> to <dnt>**Purge**</dnt>.
 
-* **Sharable secrets with fine-grained access control**: Beyond standard secrets accessible to all users in an account or organization, you can create sharable secrets that are private by default. With sharable secrets, you control exactly who can read, update, or delete each secret by granting access to specific users, groups, or system identities.
+* **Sharable secrets with fine-grained access**: Sharable secrets are private by default to the creator, who can grant specific permissions (read, update, delete) to individual users, groups, or system identities. Organization admins retain full access to all sharable secrets for oversight and management.
 
 ## Secrets management services billing [#secrets-management-services-billing]
 
 The <dnt>Secrets management service</dnt> is an Advanced Compute Product feature offered as an [add-on](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/add-on-billing) or as a part of the Compute pricing model. Advanced [CCUs](/docs/licenses/license-information/product-definitions/new-relic-one-pricing-definitions/#compute-capacity-unit) are consumed when NerdGraph queries are executed to store, retrieve, or manage secrets.
 
-## Access control[#security-and-access-control]
+## Standard secrets access control[#security-and-access-control]
 
 Users with [standard roles](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts/#standard-roles) can access the <dnt>Secrets management service</dnt> specific to the accounts they have access to, with the following permissions.
 
@@ -56,38 +56,22 @@ Setup and configure the users, roles, permissions, and access to the <dnt>Secret
 
 ## Sharable secrets with fine-grained access [#sharable-secrets]
 
-When you store secrets at the account or organization level using standard secrets, all users with access to that account or organization can access and manage those secrets. For enterprise customers, this is a security concern because within an enterprise, multiple teams work on different projects. Each team or individual has secrets specific to their tasks. Exposing these secrets to a wider audience is not advisable and might lead to a security risk.
-
-Sharable secrets solve this problem by giving you precise control over who can access your sensitive data within your account or organization. With sharable secrets, you create private secrets that only authorized users, groups, or system identities can access.
-
-### How it works
-
-**Privacy by default**
-
-When you create a sharable secret using the `secretsManagementCreateSharableSecret` mutation, the secret is private by default. No one else in the account or organization can access it until you explicitly grant permission.
-
-**Automatic ownership**
-
-The user who creates the sharable secret automatically becomes the secret owner. This ownership is recorded as an explicit grant in the backend. As the owner, you have full control to read, update, delete the secret, and grant or revoke permissions for other entities.
-
-**Granular access control**
-
-The owner can grant access to a grantee, which can be a user, group, system identity, or system identity group. You can assign specific functional permissions:
-
-* **Read**: Allows the grantee to retrieve the secret value
-* **Update**: Allows the grantee to change the secret value
-* **Delete**: Allows the grantee to remove the secret
+While standard secrets are accessible to all users with permissions in an account or organization, enterprises with multiple teams often need to restrict secrets to specific individuals. Sharable secrets address this need.
+
+When you create a sharable secret, you automatically become its owner with full control. You can grant access to users, groups, or system identities by assigning individual permissions or by using roles that bundle multiple permissions together.
 
-You can also use standard roles to simplify access:
+**Individual permissions:**
 
-* **Secret Owner**: Grants full control (read, update, delete, grant/revoke)
-* **Secret Reader**: Grants read-only access
+* **Read**: Retrieve the secret value
+* **Update**: Change the secret value
+* **Delete**: Remove the secret
 
-Additionally, you can define custom roles to assign limited access based on responsibility.
+**Predefined roles:**
 
-**Scope and admin access**
+* **Secret Owner**: Full control (read, update, delete, grant/revoke)
+* **Secret Reader**: Read-only access
 
-Sharable secrets can be created at either the account level or the organization level. Organization admins retain full access to all sharable secrets within their scope for necessary oversight and management.
+You can also [create custom roles]((/docs/accounts/accounts-billing/new-relic-one-user-management/account-user-mgmt-tutorial/#roles)) that combine specific permissions based on your needs. Organization admins retain full access to all sharable secrets for oversight.
 
 ## Pre-requisites [#prerequisites]
 
@@ -468,7 +452,7 @@ mutation {
 
 <Collapser
   id="create-sharable-secret"
-  title="Create a sharable secret">
+  title="Store a sharable secret">
 
 Use the `secretsManagementCreateSharableSecret` mutation to create a private secret with fine-grained access control. When you create a sharable secret, you automatically become the owner with full control over who can access it.