Final corrections

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/cca-trustee/_index.md

@@ -7,11 +7,11 @@ who_is_this_for: This Learning Path is for software developers who want to run a
 
 learning_objectives:
   - Describe how you can use attestation with Arm's Confidential Computing Architecture (CCA) and Trustee services
-  - Launch a CCA realm and run a sample workload on an Armv9-A AEM Base Fixed Virtual Platform (FVP) with Realm Management Extension (RME) support
+  - Deploy a simple workload in a CCA realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) that has support for RME extensions
   - Connect the workload with Trustee services to create an end-to-end example that uses attestation to unlock the confidential processing of data
 
 prerequisites:
-  - An AArch64 or x86_64 computer running Linux or macOS. You can use cloud instances; see this list of [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/)
+  - An AArch64 or x86_64 computer running Linux or macOS; you can use cloud instances - see the [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/)
   - Completion of the [Get started with CCA attestation and Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison) Learning Path
   - Completion of the [Run an end-to-end attestation flow with Arm CCA](/learning-paths/servers-and-cloud-computing/cca-essentials/) Learning Path
 

content/learning-paths/servers-and-cloud-computing/cca-trustee/cca-trustee.md

@@ -1,6 +1,6 @@
 ---
 # User change
-title: "Overview of the software architecture"
+title: "Architecture overview for Arm CCA Attestation with Trustee"
 
 weight: 2 # 1 is first, 2 is second, etc.
 
@@ -10,32 +10,24 @@ layout: "learningpathall"
 
 ## The role of attestation
 
-In this Learning Path, you will learn how attestation controls the release of confidential data into a confidential Linux realm for processing.
-
-The role of attestation is to assess whether the target compute environment
-offers a provable level of confidential isolation. In this Learning Path,
-the target compute environment is a Linux realm. The assessment of a provable
-level of confidential isolation must occur before the realm can be trusted
-to receive confidential data or algorithms. This use of attestation to judge
-the trustworthiness of a compute environment, before allowing it to do any
-processing, is a common practice in confidential computing.
+In this Learning Path, you will learn how attestation controls the release of confidential data into a confidential Linux realm for processing. The role of attestation is to assess whether the target compute environment offers a provable level of confidential isolation. In this Learning Path,
+the target compute environment is a Linux realm. The assessment of a provable level of confidential isolation must occur before the realm can be trusted to receive confidential data or algorithms. This use of attestation to judge the trustworthiness of a compute environment, before allowing it to do any processing, is a common practice in confidential computing.
 
 ## Key software components
 
 This Learning Path is similar to
-[Run an end-to-end Attestation Flow with Arm CCA](/learning-paths/servers-and-cloud-computing/cca-essentials/).
-
-The main difference is that, instead of the KBS from the [Veraison](https://github.com/veraison) project, you will use components implemented in the [Confidential Containers (CoCo) Project](https://github.com/confidential-containers) to support the [IETF RATS model](https://datatracker.ietf.org/doc/rfc9334/) (Remote ATtestation procedureS). These components include the Attestation Service (AS), Key Broker Service (KBS), Reference Value Provider Service (RVPS), Attestation Agent (AA), and Confidential Data Hub (CDH).
+[Run an end-to-end Attestation Flow with Arm CCA](/learning-paths/servers-and-cloud-computing/cca-essentials/). The main difference is that, instead of the KBS from the [Veraison](https://github.com/veraison) project, you will use components implemented in the [Confidential Containers (CoCo) Project](https://github.com/confidential-containers) to support the [IETF RATS model](https://datatracker.ietf.org/doc/rfc9334/) (Remote ATtestation procedureS). These components include the Attestation Service (AS), Key Broker Service (KBS), Reference Value Provider Service (RVPS), Attestation Agent (AA), and Confidential Data Hub (CDH).
 The AS, KBS, and RVPS components are part of the [Trustee project](https://github.com/confidential-containers/trustee),
 whereas the AA and CDH are part of the [Guest Components](https://github.com/confidential-containers/guest-components) project in CoCo.
 
 ## RATS roles
 
-This Learning Path uses the following RATS roles:
+This Learning Path focuses on the following key concepts:
 
-- **Attester** – Provides evidence that is evaluated to decide trustworthiness (for example, whether it is authorized to perform an action). Evidence can include configuration data, measurements, telemetry, or inferences.
-- **Verifier** – Evaluates the evidence from the Attester and produces attestation results that are sent to the Relying party. The Verifier vouches for the validity of those results.
-- **Relying party** – Depends on the validity of information from the Attester (either directly or through the Verifier) to make an access or policy decision.
+- **Attester** – provides evidence that is evaluated to decide **Trustworthiness** (for example, whether it is authorized to perform an action). 
+- **Evidence** can include configuration data, measurements, telemetry, or inferences.
+- **Verifier** – evaluates the evidence from the Attester and produces attestation results that are sent to the Relying party. The Verifier vouches for the validity of those results.
+- **Relying party** – depends on the validity of information from the Attester (either directly or through the Verifier) to make an access or policy decision.
 
 ## Trustee components
 
@@ -55,8 +47,8 @@ The following diagram shows the AS components:
 
 The AS performs this verification flow:
 
-1. **Verify format and origin of evidence** – For example, verify the evidence signature. This is handled by a platform-specific Verifier driver.
-2. **Evaluate claims** – For example, validate that measurements match expected values. This is handled by the Policy engine, with RVPS support.
+- **Verify format and origin of evidence** – for example, verify the evidence signature. This is handled by a platform-specific Verifier driver.
+- **Evaluate claims** – for example, validate that measurements match expected values. This is handled by the Policy engine, with RVPS support.
 
 ## Verifier driver
 

content/learning-paths/servers-and-cloud-computing/cca-trustee/flow.md

@@ -12,7 +12,7 @@ In this section you’ll run the **Trustee services** (AS, KBS, RVPS), launch a
 
 ## Install dependencies
 
-Install Docker. On Ubuntu 24.04 LTS, set up Docker’s APT repository:
+Start by installing Docker. On Ubuntu 24.04 LTS, set up Docker’s APT repository:
 
 ```bash
 # Add Docker's official GPG key:
@@ -35,7 +35,7 @@ Install Git and Docker packages:
 sudo apt-get install -y git docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
 ```
 
-Add your user name to the docker group (open a new shell after this so the change takes effect):
+Add your user name to the Docker group (open a new shell after this so the change takes effect):
 ``` bash
 sudo usermod -aG docker $USER
 newgrp docker
@@ -56,13 +56,13 @@ Additional Learning Path–specific changes include:
 
 - Attestation policy with CCA rules
 
-- An “affirming” resource policy
+- An *affirming* resource policy
 
 - A demo secret message
 
 - A shared Docker network for all containers in this demo
 
-Go into the `cca-trustee` directory and start the Trustee services docker containers (as detached services):
+Go into the `cca-trustee` directory and start the Trustee services Docker containers (as detached services):
 ``` bash { output_lines = "3-9" }
 cd cca-trustee
 docker compose up -d
@@ -85,7 +85,7 @@ Where `service` is either `as`,`kbs` or `rvps`.
 
 With the Trustee Services running in one terminal, open up a new terminal in which you will run CCA attestations.
 
-Pull the docker image with the pre-built FVP, and then run the container connected to the same docker network:
+Pull the Docker image with the pre-built FVP, and then run the container connected to the same Docker network:
 
 ```bash
 docker pull armswdev/cca-learning-path:cca-simulation-v2
@@ -148,7 +148,8 @@ Run the attestation command and save the EAT Attestation Result (EAR) message in
 
 Request the demo secret with that EAR:
 
-```bash./kbs-client --url http://kbs:8080 get-resource \
+```bash
+  ./kbs-client --url http://kbs:8080 get-resource \
   --tee-key-file realm.key --attestation-token ear.jwt \
   --path "cca-trustee/demo-message/message.txt"
 ```  
@@ -213,7 +214,7 @@ Storage Opaque [none]: no claim being made
 Sourced Data [none]: no claim being made
 ```
 
-This part of the output shows how the attestation service has compared the attestation token against its expectations of a trustworthy system. These comparisons are known as *trustworthiness vectors"*. It also shows the conclusions that were drawn from that comparison.
+This part of the output shows how the attestation service has compared the attestation token against its expectations of a trustworthy system. These comparisons are known as *trustworthiness vectors*. It also shows the conclusions that were drawn from that comparison.
 
 Note these two trustworthiness vectors in the result:
 - __Hardware [affirming]__. Evidence in the attestation token shows a good match against the expectations of CCA platform.