nits

Author: anupras-mohapatra-arm

content/learning-paths/cross-platform/avh_cicd/_index.md

@@ -34,7 +34,7 @@ generated_summary_faq:
     project, generate a Personal Access Token with permission to update workflow files, and set
     up an AVH instance using the Arm Virtual Hardware install guide. Then, you'll enable GitHub
     Actions on the fork and add a self-hosted runner on an AWS host, selecting a Linux image
-    and x64 architecture to match the instance. By the end, the repository is configured to use
+    and x64 architecture to match the instance. By the end, you'll configure the repository to use
     an AVH-backed self-hosted runner so workflows can drive automated testing and validation for
     bare‑metal targets.
   faqs:
@@ -52,7 +52,7 @@ generated_summary_faq:
       in the steps.
   - question: How do I enable GitHub Actions on my fork?
     answer: >-
-      Open the Actions tab in your fork. If workflows are disabled, click **I understand my workflows,
+      Open the **Actions** tab in your fork. If workflows are disabled, click **I understand my workflows,
       go ahead and enable them**.
   - question: How do I verify that the self-hosted runner is available to the repository?
     answer: >-

content/learning-paths/cross-platform/aws-greengrass-pacbti-test/_index.md

@@ -46,7 +46,7 @@ generated_summary_faq:
   - question: How do I know each device is ready to receive a Greengrass deployment?
     answer: >-
       In AWS IoT Core, confirm the device is registered as a Greengrass core device and appears
-      in the thing group you plan to deploy to. If it is not in the group, add it before creating
+      in the thing group you plan to deploy to. If it isn't in the group, add it before creating
       the deployment.
   - question: What result should I expect from the PAC/BTI test on Raspberry Pi 5 versus Jetson
       Thor?

content/learning-paths/cross-platform/build-a-reachy-robot-app-on-pi/_index.md

@@ -57,7 +57,7 @@ generated_summary_faq:
     answer: >-
       Check that `assets/gesture_recognizer.task` exists as a real model file, not a tiny pointer
       file. If you cloned before enabling Git LFS, enable LFS and re-clone the repository.
-  - question: The dashboard loads but the MuJoCo simulation does not move—what should I check?
+  - question: The dashboard loads but the MuJoCo simulation doesn't move—what should I check?
     answer: >-
       Verify the MuJoCo simulation is running on your development machine and that the Pi can
       reach it over the network. Also review `main.py` because it contains the settings used for

content/learning-paths/cross-platform/cpp-loop-size-context/_index.md

@@ -52,13 +52,13 @@ generated_summary_faq:
   - question: Is rounding down to a multiple of four safe for every loop?
     answer: >-
       Use the multiple-of-four constraint only when you know it preserves the required work for
-      your algorithm. If all elements must be processed, this path does not list a remainder-handling
-      step, so do not drop iterations unless that is acceptable.
+      your algorithm. If all elements must be processed, this path doesn't list a remainder-handling
+      step, so don't drop iterations unless that's acceptable.
   - question: How do I know whether the compiler used the boundary information?
     answer: >-
       Run both versions with the same input and compare observed behavior, such as timing if the
       code reports it. A difference indicates the compiler recognized the constraint and produced
-      different code, though exact changes are not enumerated here.
+      different code, though exact changes aren't enumerated here.
   - question: What happens if the input size is less than four or not divisible by four?
     answer: >-
       The expression (max_loop_size/4)*4 truncates, so inputs less than four yield zero iterations

content/learning-paths/cross-platform/deploy-containerized-workloads-with-topo/_index.md

@@ -57,7 +57,7 @@ generated_summary_faq:
       output prompts you when a target is not specified.
   - question: How does Topo determine if a template is compatible with my Arm target?
     answer: >-
-      Topo detects hardware capabilities on the target, including Arm CPU features like Neon and
+      Topo detects hardware capabilities on the target, including Arm CPU features such as Neon and
       SVE, and uses them to identify compatible templates. Generating a target description helps
       guide template selection.
   - question: What should I expect when cloning the example template and responding to prompts?

content/learning-paths/cross-platform/docker-build-cloud/_index.md

@@ -36,7 +36,7 @@ generated_summary_faq:
     common approaches for multi-architecture builds and configure Docker Build Cloud as the builder
     to avoid relying on instruction emulation. Then, you'll create a GitHub repository,
     add a workflow that targets multiple architectures, and set required secrets so the workflow
-    can run unattended. You'll trigger a cloud-backed build and see logs that confirm
+    can run unattended. By triggering a cloud-backed build, you'll see logs that confirm
     Arm and x86 variants were produced through the configured pipeline.
   faqs:
   - question: Which option should I use to build multi-architecture images without relying on

content/learning-paths/cross-platform/docker/_index.md

@@ -52,7 +52,7 @@ generated_summary_faq:
   - question: 'Which option should I use to create a multi-architecture image: `docker buildx` or `docker manifest`?'
     answer: >-
       Use `docker buildx` to build multi-architecture images directly. Use `docker manifest` when you prefer
-      to build and test separate images per architecture first and combine them later; note that
+      to build and test separate images per architecture first and combine them later. Note that
       `docker manifest` is experimental and not recommended for production.
   - question: What should I do if building Arm images on my non-Arm machine is slow?
     answer: >-

content/learning-paths/cross-platform/eigen-linear-algebra-on-arm/_index.md

@@ -35,7 +35,7 @@ generated_summary_faq:
     iterations, and performing repeated 512×512 matrix multiplications that use fused multiply-add
     operations. After validating the Eigen examples on an Arm Linux system, you'll build TensorFlow
     with SVE enabled by following the documented build flow and required
-    dependencies. You'll compile and run Eigen-based workloads and complete an SVE-capable
+    dependencies. You'll then compile and run Eigen-based workloads and complete an SVE-capable
     TensorFlow build on Arm.
   faqs:
   - question: What result should I expect when I run the Eigen examples?
@@ -48,8 +48,8 @@ generated_summary_faq:
       or a higher `N` increase runtime.
   - question: Why does the matrix multiplication example mention fused multiply-add (FMA)?
     answer: >-
-      The example is structured so Eigen can use FMA on CPUs that support it. You do not need
-      to verify FMA usage to continue; a correct run still prints a single numeric norm.
+      The example is structured so Eigen can use FMA on CPUs that support it. You don't need
+      to verify FMA usage to continue. A correct run still prints a single numeric norm.
   - question: Which compiler should I use to build the examples?
     answer: >-
       Use a recent version of GCC or Clang on Linux as listed in the prerequisites. A successful

content/learning-paths/cross-platform/ernie_moe_v9/_index.md

@@ -40,7 +40,7 @@ generated_summary_faq:
   - question: What result should I expect when verifying the setup on the Armv9 board?
     answer: >-
       You should see successful model inference and multilingual output from the ERNIE-4.5 Thinking
-      variant. This confirms the llama.cpp build and runtime environment are working end to end.
+      variant. This confirms the `llama.cpp` build and runtime environment are working end to end.
   - question: Which ERNIE-4.5 variant should I use for the comparison step?
     answer: >-
       Use both PT and Thinking on the same task and with the same settings. This makes the differences

content/learning-paths/cross-platform/floating-point-behavior/_index.md

@@ -58,7 +58,7 @@ generated_summary_faq:
   - question: How can I validate that my ported code behaves the same on both architectures?
     answer: >-
       Run the same source and inputs on both Linux machines and compare outputs. For well-defined
-      operations, the values should match; if they do not, look for undefined cases or differences
+      operations, the values should match. If the values don't match, look for undefined cases or differences
       caused by expression ordering or FMA use.
   - question: When should I change my code to improve portability across Arm and x86?
     answer: >-