nit

Author: anupras-mohapatra-arm

content/learning-paths/automotive/openadkit2_safetyisolation/_index.md

@@ -16,11 +16,66 @@ prerequisites:
     - Completion of the [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) Learning Path
     - Basic familiarity with Docker
 
+# START generated_summary_faq
+generated_summary_faq:
+  template_version: summary-faq-v3
+  generated_at: '2026-06-24T15:35:59Z'
+  generator: ai
+  ai_assisted: true
+  ai_review_required: true
+  model: gpt-5
+  prompt_template: summary-faq-v3
+  source_hash: 92a6dac2b1674a44cd623a0c8c3189b38438124a6067ed7ca776999ff1d8b5bf
+  summary_generated_at: '2026-06-24T15:35:59Z'
+  summary_source_hash: 92a6dac2b1674a44cd623a0c8c3189b38438124a6067ed7ca776999ff1d8b5bf
+  faq_generated_at: '2026-06-24T15:35:59Z'
+  faq_source_hash: 92a6dac2b1674a44cd623a0c8c3189b38438124a6067ed7ca776999ff1d8b5bf
+  summary: >-
+    In this Learning Path, you'll prototype safety‑critical isolation for autonomous
+    driving workloads on Arm Neoverse by applying functional safety concepts, ISO 26262 and ASIL
+    guidance, and a safety-island architecture. You'll separate safety-critical control
+    logic from non-safety functions, then connect components using a publish‑subscribe model (DDS/ROS
+    2) within containerized deployments or across Arm‑based instances. You'll learn about lifecycle
+    practices aligned with the V‑model, including clear requirements, version control, impact
+    analysis, and regression testing. By the end, you'll organize simulation components into
+    isolated units with defined interfaces and documentation suitable for advancing ISO 26262-oriented
+    development on Arm Neoverse.
+  faqs:
+  - question: How do I decide which components belong on the safety island versus the general
+      ECU?
+    answer: >-
+      Place time‑critical, safety‑relevant control logic (for example, braking or steering) on
+      the safety island, and keep non‑critical features (such as infotainment) on the general
+      ECU. The goal is strong isolation, determinism, and minimized coupling for safety‑critical
+      paths.
+  - question: What should I verify to confirm the isolation boundaries are defined correctly?
+    answer: >-
+      Check that safety‑critical components run independently from non‑critical services and communicate
+      only through defined publish‑subscribe interfaces. Ensure data exchanged is minimal and
+      purpose‑specific so that safety logic is not impacted by unrelated functions.
+  - question: How do ISO 26262 ASIL levels influence my development workflow in this prototype?
+    answer: >-
+      Higher ASIL targets require more rigorous processes and evidence across the V‑model. For
+      example, ASIL‑D changes go through full impact analysis and regression testing to prevent
+      introducing new risks.
+  - question: Should I separate components using containers on one host or across multiple Arm
+      Neoverse instances?
+    answer: >-
+      Both approaches support prototyping: containers model software isolation on one system,
+      while multiple instances model stronger physical separation. Choose the option that best
+      matches the isolation assumptions you want to evaluate.
+  - question: What artifacts should I capture to support ISO 26262 traceability in this prototype?
+    answer: >-
+      Maintain clear safety requirements, rationale for the safety‑island split, defined DDS/ROS
+      2 interfaces, and mapped tests to requirements. Record versioned changes, impact analyses,
+      and verification results aligned to the V‑model stages.
+# END generated_summary_faq
+
 author: 
     - Odin Shen
     - Julien Jayat
 
-generate_summary_faq: true
+generate_summary_faq: false
 rerun_summary: false
 rerun_faqs: false
 

content/learning-paths/mobile-graphics-and-gaming/ams/malioc.md

@@ -26,8 +26,6 @@ The `--help` option returns usage instructions and the full list of available op
 On macOS, Mali Offline Compiler might not be recognized as an application from an identified developer. To enable Mali Offline Compiler, open **System Preferences > Security & Privacy**, and select **Allow Anyway** for the `malioc` item.
 {{% /notice %}}
 
-## Supported GPUs
-
 To see the full list of [supported GPUs](https://developer.arm.com/documentation/101863/latest/Platform-support/GPU-support) use:
 
 ```console

content/learning-paths/servers-and-cloud-computing/rafay-eks/nginx.md

@@ -1,16 +1,15 @@
 ---
-title: "Deploy NGINX and clean up"
+title: Deploy NGINX to the Amazon EKS cluster and clean up
+description: Deploy NGINX to an Amazon EKS cluster on AWS Graviton-based nodes, test in-cluster connectivity, and clean up the Kubernetes and cloud resources.
 weight: 4
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-With the cluster running, you can now validate it by deploying a workload. In this section, you deploy NGINX using a manifest that pins pods to `arm64` nodes, verify the pod reaches a `Running` state, and test connectivity from inside the cluster. You then clean up all provisioned resources.
+## Deploy NGINX 
 
-## Deploy NGINX
-
-With the EKS cluster running on Graviton nodes, deploy NGINX to confirm that arm64 workloads schedule and run correctly.
+With the Amazon EKS cluster running on Graviton-based nodes, deploy NGINX to confirm that `arm64` workloads schedule and run correctly.
 
 Create a file named `nginx-graviton.yaml` with the following content:
 
@@ -104,7 +103,9 @@ nginx-arm-svc   ClusterIP   10.100.42.137   <none>        80/TCP    30s
 
 ## Test NGINX connectivity
 
-The NGINX service is type `ClusterIP`, which means it has no external IP and is only reachable from within the cluster network. The cluster also has `publicAccess: false`, so there is no public Kubernetes API endpoint. Both constraints mean you cannot test connectivity from your laptop directly. Instead, run a one-off pod inside the cluster that sends a request to the service and then deletes itself:
+The NGINX service is type `ClusterIP`, which means it has no external IP and is reachable only from within the cluster network. The cluster also has `publicAccess: false`, so there's no public Kubernetes API endpoint. Both constraints mean you can't test connectivity from your local machine directly.
+
+Instead, run a one-off pod inside the cluster that sends a request to the service and then deletes itself:
 
 ```console
 kubectl run curl-test --rm -it --image=curlimages/curl --restart=Never -- curl http://nginx-arm-svc.nginx.svc
@@ -127,9 +128,9 @@ working. Further configuration is required.</p>
 pod "curl-test" deleted
 ```
 
-The NGINX welcome page confirms that the workload is running and reachable on your Graviton-backed EKS cluster.
+The NGINX welcome page confirms that the workload is running and reachable on your Graviton-based EKS cluster.
 
-## Clean up
+## Clean up resources
 
 Remove the NGINX workload and then delete the cluster to avoid ongoing AWS charges.
 
@@ -148,7 +149,7 @@ service "nginx-arm-svc" deleted
 ```
 
 {{< notice warning >}}
-Deleting the cluster through RCTL triggers the removal of the EKS control plane, managed node group, and associated CloudFormation stacks in your AWS account. If you do not run this command, AWS will continue to charge you for the running EC2 instances and EKS control plane.
+Deleting the cluster through RCTL triggers the removal of the EKS control plane, managed node group, and associated CloudFormation stacks in your AWS account. If you don't run this command, AWS will continue to charge you for the running EC2 instances and EKS control plane.
 {{< /notice >}}
 
 Delete the EKS cluster through Rafay:
@@ -157,13 +158,9 @@ Delete the EKS cluster through Rafay:
 rctl delete cluster demo-eks-graviton
 ```
 
-## Summary
+## What you've accomplished
 
-In this Learning Path you:
+You've now deployed NGINX using a manifest that pins pods to `arm64` nodes, verified the pod reaches a `Running` state, and tested connectivity from inside the cluster. You then cleaned up all provisioned resources.
 
-- Connected your AWS account to the Rafay platform using a cross-account IAM role and cloud credential.
-- Provisioned a private Amazon EKS cluster with a Graviton (`m7g.large`) node group using a declarative Rafay manifest and `rctl`.
-- Deployed NGINX with a `nodeSelector` that pins workloads to `arm64` nodes, confirming that Arm-native containers schedule and run correctly.
-- Tested in-cluster connectivity using a one-off curl pod, and cleaned up all AWS and Rafay resources.
+Rafay's control plane handles cluster access without requiring a public Kubernetes API endpoint, so you can use Rafay to run private, Graviton-based EKS clusters at scale.
 
-Rafay's control plane handles cluster access without requiring a public Kubernetes API endpoint, making it straightforward to run private, Graviton-backed EKS clusters at scale.