Paragraph "What Shapes the Converted Application" added

Author: jmotow

docs/user-guide/dev_guide/convert_app.md

@@ -25,6 +25,67 @@ The prompt orchestrates the conversion process using a sequence of well-defined
 | Document the conversion               | Generate a detailed README and documentation for the converted application.                   |
 | Final compliance audit                | Perform a final audit to ensure all requirements and deliverables are met.                    |
 
+## What Shapes the Converted Application
+
+The form and structure of the converted application are not fixed — they emerge
+from the interplay of several factors that the workflow analyses and resolves
+automatically. Understanding these factors helps set realistic expectations
+before starting a conversion.
+
+### AI model and its context
+
+The choice of AI model is one of the most influential factors:
+
+- **Model architecture** (SSD, YOLO, ResNet, …) determines which DL Streamer
+  inference elements are used (`gvadetect`, `gvaclassify`) and how the
+  pipeline stages are chained.
+- **Inference mode** (`full-frame` vs `roi-list`) affects whether a
+  single-pass or cascaded detection approach is used — this choice is made
+  per-model based on object scale and density.
+- **Precision** (FP16 / FP32 / INT8) influences runtime performance and
+  the target inference device selection.
+- **Training domain** of the model (e.g. barrier/toll-booth vs. open-road
+  surveillance) determines whether a direct model reuse is valid or a
+  domain-matching substitute must be found.
+- **Character set / language** for OCR and text-recognition models constrains
+  which model is selected (e.g. Latin-alphabet vs. CJK character sets).
+
+### Architecture of the source application
+
+The source app's pipeline structure is preserved 1-to-1 in the conversion:
+
+- **Number and order of inference stages** (PGIE, SGIE, secondary
+  classifiers) maps directly to the number of DL Streamer elements.
+- **Presence of object tracking** determines whether `gvatrack` is included
+  and which tracking mode is selected.
+- **Visualization and metadata output** requirements determine the rendering
+  and publishing elements (`gvawatermark`, `gvametaconvert`,
+  `gvametapublish`).
+
+### Target execution environment
+
+Runtime characteristics of the deployment machine affect the output:
+
+- **Available inference device** (Intel iGPU / dGPU / CPU / NPU) determines
+  the `device=` parameter and whether hardware video encoding is available.
+- **Display availability** (headless vs. GUI) determines whether
+  `autovideosink`, `filesink`, or `fakesink` is used as the output sink.
+- **Operating system and driver stack** may require environment workarounds
+  (e.g. GStreamer registry cache rebuild, Python plugin compatibility).
+
+### Input and output format requirements
+
+- **Input source type** (local file, USB camera, RTSP stream) selects the
+  appropriate GStreamer source element.
+- **Required output format** (annotated video, JSON metadata, CSV log)
+  determines the metadata publishing and sink configuration.
+
+> **In short:** the converted application is a direct function of the source
+> app's pipeline, the models available for the target platform, and the
+> execution environment. The workflow resolves all these factors automatically
+> and documents every decision in the generated README under
+> **Conversion Notes**.
+
 ## Example Usage
 
 While the prompt is primarily designed for use with an agent or automation, a typical conversion workflow may be initiated as follows (pseudo-command):