skill-based edits

Author: anupras-mohapatra-arm

content/learning-paths/servers-and-cloud-computing/benchmark-nlp/_index.md

@@ -32,7 +32,7 @@ generated_summary_faq:
     You'll deploy Hugging Face Sentiment Analysis models
     with PyTorch on Arm servers and measure how they perform. Starting from a working Ubuntu
     22.04 Arm environment, you'll run three NLP models with the Sentiment Analysis
-    pipeline, record baseline results, and then enable BFloat16 fast math kernels to assess the
+    pipeline, record baseline results, and enable BFloat16 fast math kernels to assess the
     impact on inference performance. By
     the end, you'll compare before-and-after measurements to confirm the effect of BFloat16
     on this workload.
@@ -43,20 +43,19 @@ generated_summary_faq:
       AWS Graviton3 (c7g) instances.
   - question: What system resources should I provision before running the steps?
     answer: >-
-      Use an Arm server instance with at least four CPU cores and 8GB of RAM. This capacity supports
+      Use an Arm server instance with at least four CPU cores and 8 GB of RAM. This capacity supports
       running the three sentiment analysis models and collecting measurements.
-  - question: Which framework and model source are used in this path?
+  - question: Which framework and model source will I use in this Learning Path?
     answer: >-
-      The path uses PyTorch to run Natural Language Processing models sourced from Hugging Face.
-      The examples use the Sentiment Analysis pipeline.
+      You'll uses PyTorch to run NLP Sentiment Analysis models sourced from Hugging Face.
   - question: How should I measure the performance uplift from BFloat16 fast math kernels?
     answer: >-
       First, run the models to collect a baseline using the same Sentiment Analysis pipeline.
       Then enable BFloat16 fast math kernels on supported Arm Neoverse-based AWS Graviton3 processors,
       rerun the same workload, and compare measurements.
-  - question: Which models are evaluated and what should I have at the end?
+  - question: Which models will I evaluate and what should I have at the end?
     answer: >-
-      The path evaluates three NLP models with the Sentiment Analysis pipeline. By the end, you
+      You'll evaluate three NLP models with the Sentiment Analysis pipeline. By the end, you
       should have deployed the models on your Arm server and recorded baseline and BFloat16-enabled
       performance results for comparison.
 # END generated_summary_faq

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

@@ -40,13 +40,13 @@ generated_summary_faq:
   faqs:
   - question: Where should I place the code as I follow the steps?
     answer: >-
-      Use a single source file named bitvector_scan_benchmark.c. Add the bit vector type, helper
+      Use a single source file named `bitvector_scan_benchmark.c`. Add the bit vector type, helper
       functions, scalar scan routines, Neon and SVE implementations, and the benchmarking code
       into this file as directed.
-  - question: What must the bitmap data structure contain before I add the scan functions?
+  - question: What must the bitmap data structure contain before I can add the scan functions?
     answer: >-
-      It includes a byte array that holds the bits, the physical size in bytes, and the logical
-      size in bits. The same file also adds helpers to generate and analyze test bitmaps.
+      The data structure must include a byte array that holds the bits, the physical size in bytes, and the logical
+      size in bits. The same file must also add helpers to generate and analyze test bitmaps.
   - question: In what order should I implement and test the scanning approaches?
     answer: >-
       Start with the per-bit scalar baseline, then the optimized scalar version, followed by the

content/learning-paths/servers-and-cloud-computing/bolt-demo/_index.md

@@ -50,15 +50,15 @@ generated_summary_faq:
       prebuilt LLVM release instead (for example, LLVM 22.1.5) to match the required features.
   - question: Where do the example’s build and profiling outputs go?
     answer: >-
-      You'll find outputs into three directories: out for binaries, prof for profile data,
+      You'll find outputs in three directories: out for binaries, prof for profile data,
       and heatmap for visualization artifacts. Keeping these separate makes it easier to rerun
       steps and compare results.
   - question: How do I know if my program is a good candidate for BOLT?
     answer: >-
       Check a small set of Arm TopDown indicators related to instruction delivery and code locality.
       Programs that appear front-end bound, with inefficient instruction fetch and poor locality,
       are strong candidates for code layout optimization with BOLT.
-  - question: What should I use if my kernel does not meet the BRBE or SPE requirements?
+  - question: What should I use if my kernel doesn't meet the BRBE or SPE requirements?
     answer: >-
       If your kernel is older than the BRBE requirement, use SPE if the kernel meets the SPE version
       requirement. If neither is available, you can use instrumentation or PMU

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

@@ -33,8 +33,8 @@ generated_summary_faq:
     You'll use BOLT to post-link optimize an Arm Linux executable
     based on real execution profiles. First, you'll prepare a target system for profiling and optionally
     a separate build/BOLT system, then choose a profiling method — Perf samples, ETM, or SPE — to
-    collect runtime behavior into a perf.data file. You'll convert the profile for BOLT, and run BOLT to reorder code layout and emit a new optimized executable. By the end, you'll make an informed choice about how to collect profiles, produce the expected artifacts,
-    and run the optimization steps in sequence so the resulting binary can be compared against
+    collect runtime behavior into a `perf.data` file. You'll convert the profile for BOLT, and run BOLT to reorder code layout and emit a new optimized executable. By the end, you'll make an informed choice about how to collect profiles, produce the expected artifacts,
+    and run the optimization steps in sequence to compare the resulting binary against
     the original to observe improvements.
   faqs:
   - question: How should I choose between Perf samples, ETM, and SPE for profiling?
@@ -49,7 +49,7 @@ generated_summary_faq:
       profile files between systems as needed.
   - question: What file should exist after recording with Perf before converting for BOLT?
     answer: >-
-      Expect a perf.data file. Perf prints sample counts or data size when recording completes,
+      Expect a `perf.data` file. Perf prints sample counts or data size when recording completes,
       which indicates that profiling output was captured and is ready for conversion.
   - question: What version of Perf do I need for the SPE workflow?
     answer: >-

content/learning-paths/servers-and-cloud-computing/buildkite-gcp/_index.md

@@ -38,7 +38,7 @@ generated_summary_faq:
     Axion, install Docker, Docker Buildx, and the Buildkite agent, and connect the agent to a
     Buildkite queue. First, you'll create a small Flask application and Dockerfile in a GitHub repository,
     then configure a Buildkite pipeline that uses Buildx to build a multi-architecture container
-    image,and push it to Docker Hub. You'll use Ubuntu or SUSE on the VM
+    image, and push it to Docker Hub. You'll use Ubuntu or SUSE on the VM
     and validate that the agent is online. By the end, you'll have a published
     image and a running Flask service to confirm the build.
   faqs:

content/learning-paths/servers-and-cloud-computing/cassandra-on-gcp/_index.md

@@ -32,12 +32,12 @@ generated_summary_faq:
   faq_source_hash: b8268d4df3b62aeb9943b750b436a936134d47745fa71db6cc08db8c84eb37be
   summary: >-
     You'll deploy Apache Cassandra on Arm-based Google
-    Cloud Axion C4A virtual machines and validate a working baseline before running simple workload
+    Cloud Axion C4A virtual machines and validate a working baseline before running sample workload
     tests. First, you'll create a `c4a-standard-4` instance in the Google Cloud console and install Cassandra
     on Ubuntu or SUSE. Then, you'll start Cassandra as a background
     service, with logs tailed to confirm “Startup complete,” followed by nodetool status to verify
     the node state. By the end, you'll benchmark using the built-in `cassandra-stress` utility
-    to exercise write, read, and mixed operations on Arm64 to
+    to exercise write, read, and mixed operations on Arm to
     confirm Cassandra is operating correctly.
   faqs:
   - question: Which Google Cloud machine type should I choose for this setup?

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

@@ -31,9 +31,9 @@ generated_summary_faq:
   faq_source_hash: 649957b07b2bde05bc11047bd12bfc4f697c1a55eef1c3a25b5fafc95cda893d
   summary: >-
     You'll deploy a confidential container from an encrypted
-    image inside an Arm CCA Realm on an Armv9-A AEM Base Fixed Virtual Platform with RME support.
+    image inside an Arm CCA Realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) with Realm Management Extension (RME) support.
     First, you'll learn about the Confidential Containers design, understand which components run inside the
-    Trusted Execution Environment, and see how Trustee services (AS, KBS, RVPS) use Arm CCA
+    Trusted Execution Environment, and see how Trustee services use Arm CCA
     attestation to authorize decryption. Then, you'll start the Trustee services and a local Docker
     registry, publish an encrypted image, and launch the container on the FVP. By the end, you'll complete an end-to-end confidential execution workflow and confirm attestation, key release, and that the workload runs in a Realm only
     after authorization.

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

@@ -33,8 +33,8 @@ generated_summary_faq:
   summary: >-
     You'll complete an end-to-end confidential computing attestation
     flow on an Arm Fixed Virtual Platform using Arm Confidential Compute Architecture and Trustee
-    services. First, you'll start the Trustee components (AS, KBS, RVPS), launch a Linux realm on an
-    Armv9-A FVP with RME, and generate attestation evidence from the realm. After intentionally
+    services. First, you'll start the Trustee components, launch a Linux realm on an
+    Armv9-A FVP with Realm Management Extension (RME), and generate attestation evidence from the realm. After intentionally
     denying the first secret request to see how policy-based gating works, you'll endorse the
     realm initial measurement (RIM), repeat attestation, and retrieve the secret after the environment
     proves its isolation properties. By the end, you'll exercise and validate the complete path from evidence generation to

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

@@ -33,7 +33,7 @@ generated_summary_faq:
     in the RATS (RFC9334) model for Arm CCA attestation. After preparing an AWS account and authenticating,
     you'll create a Route53 domain and an HTTPS certificate so the Veraison REST APIs can be
     published on the internet. You'll deploy from the Veraison GitHub repository and
-    uses a bootstrap process to clone sources and set up the build environment. With the services running, you'll provision CCA
+    use a bootstrap process to clone sources and set up the build environment. With the services running, you'll provision CCA
     platform endorsements using the Linaro endorsement tool so Veraison can verify CCA attestation
     tokens.
   faqs:

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

@@ -1,5 +1,5 @@
 ---
-title: Get Started with CCA Attestation and Veraison
+title: Get started with CCA Attestation and Veraison
 description: Learn how to inspect and verify Arm CCA attestation tokens using command-line tools and the open-source Veraison attestation verification service.
 
 minutes_to_complete: 30
@@ -42,7 +42,7 @@ generated_summary_faq:
   - question: Should I remove an existing Go installation before setting up the tools?
     answer: >-
       Yes. The steps direct you to remove any existing Go installation before downloading and
-      extracting the specified Go release and updating your PATH.
+      extracting the specified Go release and updating your `PATH`.
   - question: What can I verify locally before using the online verification service?
     answer: >-
       You can inspect the example CCA attestation token with command-line workflows to review