Update deploy containerized workloads with Topo

Author: muchzill4

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

@@ -1,17 +1,17 @@
 ---
 title: Deploy containerized workloads to Arm-based Linux targets with Topo
 
-description: Use Topo to detect Arm processor capabilities on a target device, select a compatible container template, and deploy containerized workloads to Arm-based Linux targets over SSH using the CLI or VS Code extension.
+description: Use Topo to detect Arm processor capabilities on a target device, select a compatible Topo Project, and deploy containerized workloads to Arm-based Linux targets over SSH using the CLI or VS Code extension.
 
 minutes_to_complete: 30
 
 who_is_this_for: This is an introductory topic for embedded, edge, and cloud software developers who want to deploy containerized workloads to Arm-based Linux targets using Topo.
 
 learning_objectives:
     - Install Topo and verify that the host and target environments are ready for deployment
-    - Run health checks and generate a target description to identify compatible Arm processor features and templates
-    - Clone a Topo template and deploy a containerized workload to an Arm-based Linux target
-    - (Optional) Use the Topo VS Code extension to run the same target, template, and deployment workflow from Visual Studio Code
+    - Run health checks and list compatible projects for your target
+    - Clone a Topo Project and deploy a containerized workload to an Arm-based Linux target
+    - (Optional) Use the Topo VS Code extension to run the same target, project, and deployment workflow from Visual Studio Code
     - (Optional) Deploy firmware and applications to heterogeneous Cortex-A + Cortex-M devices using remoteproc-runtime
 
 prerequisites:
@@ -39,9 +39,8 @@ generated_summary_faq:
   summary: >-
     You'll use Topo to deploy containerized workloads to Arm-based Linux targets
     over SSH. You'll install Topo on a host machine, run a health check to validate host and target
-    readiness, and generate a target description so Topo can detect Arm CPU features such as Neon
-    and SVE and match compatible templates. You'll then clone a starter template using an
-    LLM chatbot example, accept default build prompts, and deploy. Topo builds the container image
+    readiness, and list projects compatible with the target's Arm CPU features and hardware capabilities.
+    You'll then clone a starter project using an LLM chat example and deploy. Topo builds the container image
     on the host, transfers it to the target, and starts the services on the target; it can also
     build directly on the target. You'll also see how to run the same workflow using
     the Topo Visual Studio Code extension.
@@ -55,16 +54,14 @@ generated_summary_faq:
     answer: >-
       Pass `--target` to the Topo command or set `TOPO_TARGET` in your environment. The health check
       output prompts you when a target is not specified.
-  - question: How does Topo determine if a template is compatible with my Arm target?
+  - question: How does Topo determine if a project is compatible with my Arm target?
     answer: >-
       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?
+      SVE, and uses them to identify compatible projects when you run `topo projects --target`.
+  - question: What should I expect when cloning the example project and responding to prompts?
     answer: >-
-      Clone the LLM chatbot template with `topo clone` and press Enter to accept the default build
-      arguments. The default configuration uses the `bartowski/Qwen_Qwen3.5-0.8B-GGUF` model and
-      builds with Neon optimizations.
+      Clone the LLM chat project with `topo clone`. The default configuration uses the
+      `unsloth/SmolLM2-135M-Instruct-GGUF` model and can be deployed immediately.
   - question: Where are images built and what happens after deployment starts?
     answer: >-
       Topo builds container images on the host, transfers them to the target over SSH, and starts
@@ -108,8 +105,8 @@ further_reading:
         link: https://github.com/arm/topo
         type: documentation
     - resource:
-        title: Topo template format
-        link: https://github.com/arm/topo-template-format
+        title: Topo Project specification
+        link: https://github.com/arm/topo/tree/main/docs/project-specification
         type: documentation
     - resource:
         title: Topo releases

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

@@ -132,99 +132,70 @@ topo install remoteproc-runtime --target user@my-target
 Run the health command again to verify installation. Topo uses `remoteproc-runtime` internally when deploying to heterogeneous devices.
 
 
-## Generate a target description
+## Understand target compatibility
 
-Ask Topo to probe your target and output a description of the hardware in your terminal. 
+Topo probes the target during health checks and project listing. It uses target details such as the CPU architecture, Arm CPU features, memory, and remote processor support to determine which Topo Projects are compatible.
 
-On your host device, run:
+The hardware feature list mirrors CPU feature flags reported by the Linux kernel. Key flags include `fp` (hardware floating-point), `asimd` (Neon Advanced SIMD — 128-bit vector acceleration), and `aes` (hardware AES encryption). Topo uses this information to determine which projects are compatible with your target.
 
-```bash
-topo describe --target user@my-target
-```
-
-The output captures details such as CPU architecture features, which Topo uses to select compatible templates.
-
-The following is an example snippet from an AWS Graviton-based instance, showing the main processor and its features, an absence of any remote or auxiliary processors, and the total memory:
-
-```output
-host:
-    - model: Neoverse-V1
-      cores: 4
-      features:
-        - fp
-        - asimd
-        - evtstrm
-        - aes
-        ...
-remoteprocs: []
-totalmemory_kb: 16044280
-```
-
-The `features` list mirrors the CPU feature flags reported by the Linux kernel. Key flags include `fp` (hardware floating-point), `asimd` (Neon Advanced SIMD — 128-bit vector acceleration), and `aes` (hardware AES encryption). Topo uses this feature list to determine which templates are compatible with your target.
+## List projects compatible with your target
 
-## List templates compatible with your target
+Because Topo can identify the capabilities of your target device, it can also advise on the compatibility of projects.
 
-Because Topo can identify the capabilities of your target device, it can also advise on the compatibility of templates.
-
-Use the following command on your host device to list compatible templates:
+Use the following command on your host device to list compatible projects:
 
 ```bash
-topo templates --target user@my-target
+topo projects --target user@my-target
 ```
 
 The following is an example output for an AWS Graviton-based instance:
 
 ```output
-✅ topo-welcome | https://github.com/Arm-Examples/topo-welcome.git | main
+Hello World
+  Clone:
+    topo clone https://github.com/Arm-Examples/topo-welcome.git#main
+
   A minimal "Hello, World" web app for validating a Topo setup and deployment.
   It runs a single service that exposes a web page on the target,
   with the greeting text customizable via the GREETING_NAME parameter.
 
-❌ topo-lightbulb-moment | https://github.com/Arm-Examples/topo-lightbulb-moment.git | main
-  Features: remoteproc-runtime
+Lightbulb Moment
+  Clone:
+    topo clone https://github.com/Arm-Examples/topo-lightbulb-moment.git#main
+  Features:
+    remoteproc-runtime
+
   Reads a switch over GPIO pins on an M class cpu, reports switch state over
   Remoteproc Message, then a web application on the A class reads this and
   displays a lightbulb in either the on or off state. The lightbulb state is
   described by an LLM in any user-specified style.
 
-✅ topo-cpu-ai-chat | https://github.com/Arm-Examples/topo-cpu-ai-chat.git | main
-  Features: SVE, NEON
-  Complete LLM chat application optimized for Arm CPU inference.
+Topo llama.cpp WebUI Chat
+  Clone:
+    topo clone https://github.com/Arm-Examples/topo-llama-web-ui.git#main
 
-  This project demonstrates running large language models on CPU
-  using llama.cpp compiled with Arm baseline optimizations and
-  accelerated using NEON SIMD and SVE (when supported and enabled).
+  LLM chat application with Arm CPU inference provided by llama.cpp.
 
-  The stack includes:
-  - llama.cpp server with Arm NEON optimizations (SVE optional)
-  - Quantized Qwen2.5-1.5B-Instruct model bundled in the image (~1.12 GB)
-  - Simple web-based chat interface
-  - No GPU required - pure CPU inference
+  This project demonstrates running large language models on CPU
+  with inference provided by the llama.cpp server.
 
-  Perfect for demos and testing! The bundled Qwen2.5-1.5B model allows the
-  project to run immediately without downloading additional models.
+  The upstream Linux Arm64 image includes architecture-specific CPU
+  backend variants for Armv8.0 baseline, Armv8.2 dot product/FP16/SVE,
+  Armv8.6 int8 matrix multiply/SVE2, and Armv9.2 SME-capable CPUs.
 
-  Ideal for testing LLM workloads on Arm hardware without GPU dependencies,
-  showcasing how far you can push NEON acceleration. Rebuild with SVE enabled
-  when wider vectors are available.
+SIMD Visual Benchmark
+  Clone:
+    topo clone https://github.com/Arm-Examples/topo-simd-visual-benchmark.git#main
+  Features:
+    SVE
 
-✅ topo-simd-visual-benchmark | https://github.com/Arm-Examples/topo-simd-visual-benchmark.git | main
-  Features: NEON, SVE
   Visual demonstration of SIMD performance benefits on Arm processors.
   Compare scalar (no SIMD), NEON (128-bit), and SVE (scalable vector)
   implementations running identical image processing workloads side-by-side.
-
-  This demo shows real hardware acceleration through three C++ services
-  compiled with different architecture flags, processing the same box blur
-  algorithm on images. Performance differences are measured in real-time
-  and displayed in an interactive web dashboard.
-
-  Perfect for demonstrating to non-technical audiences the concrete benefits
-  of SIMD optimizations, with visual results and quantified speedups.
 ```
 
-In this example, `topo-lightbulb-moment` is marked as incompatible, because it requires an SoC with both a Cortex-A and a Cortex-M. The instance contains Arm Neoverse cores only. All other templates are marked as compatible. You might see different results depending on the target hardware you use.
+When you provide `--target`, Topo marks each project according to compatibility with your target. For example, `topo-lightbulb-moment` requires `remoteproc-runtime`, so it is incompatible with targets that don't provide a supported remote processor environment. You might see different results depending on the target hardware you use.
 
 ## What you've accomplished and what's next
 
-You have now verified your host and target environments, resolved any missing dependencies, and optionally enabled heterogeneous deployment. You also generated a description of your target's hardware features and identified compatible templates. Next, you'll choose a template containerized workload and deploy it to your target.
+You have now verified your host and target environments, resolved any missing dependencies, and optionally enabled heterogeneous deployment. You also identified compatible projects for your target. Next, you'll choose a containerized workload project and deploy it to your target.