docs: Documentation updates (#62)

Signed-off-by: Isabella Gottardi <isabella.gottardi@arm.com>

Author: IsabellaARM

docs/README.md

@@ -41,10 +41,10 @@ The generated site will be written to `.mkdocs/site/`.
 
 The top-level `README.md` remains the main user guide for installation and CLI
 usage. This docs tree explains the core architecture, CLI, output shape, and
-backend-management model.
+backend management model.
 
 ## Relationship to plugins
 
-Plugin packages own the target-specific, backend-specific, and converter-specific
-detail. Keep that material in the plugin repos rather than copying it into the
-core repo.
+Plugin packages own the target-specific, backend-specific, and transformer or
+converter-specific detail. Keep that material in the plugin repos rather than
+copying it into the core repo.

docs/source/backends.md

@@ -7,7 +7,7 @@ SPDX-License-Identifier: Apache-2.0
 
 ## Overview
 
-The core `mlia` repository provides backend discovery and backend-management
+The core `mlia` repository provides backend discovery and backend management
 commands, while many backend implementations now live in split plugin
 repositories.
 

docs/source/cli.md

@@ -37,13 +37,6 @@ mlia backend list
 That gives you a quick picture of what the environment can actually do before
 you start copying example commands from documentation.
 
-## Legacy entry points
-
-The `mlia-target` and `mlia-backend` scripts remain available as compatibility
-wrappers. They print deprecation warnings and dispatch to the corresponding
-command group. Prefer `mlia target ...` and `mlia backend ...` in new commands,
-documentation, scripts, and examples.
-
 ## Common workflows
 
 Show top-level help:
@@ -118,7 +111,7 @@ assuming a plugin-specific example applies to your setup.
 ## Plugin relationship
 
 The core repo provides the commands and workflow orchestration. Plugin packages
-provide target plugins, backend plugins, and converter plugins that are
+provide target plugins, backend plugins, and transformer plugins that are
 installed into that experience.
 
 A useful mental model is:

docs/source/execution_flow.md

@@ -78,10 +78,10 @@ graph LR
     model --> collectors[Data collectors]
     profile --> advisor[Target advisor]
     advisor --> collectors
-    collectors --> maybeConvert{Converter needed?}
-    maybeConvert -->|yes| converter[Converter plugin]
-    converter --> intermediate[Converted/intermediate artifact]
-    maybeConvert -->|no| backendInput[Backend input artifact]
+    collectors --> maybeTransform{Transformation needed?}
+    maybeTransform -->|yes| transformer[Transformer plugin]
+    transformer --> intermediate[Converted/intermediate artifact]
+    maybeTransform -->|no| backendInput[Backend input artifact]
     intermediate --> backendInput
     backendInput --> backend[Backend tool or service]
     backend --> rawResults[Raw backend output]

docs/source/high_level_architecture.md

@@ -25,8 +25,6 @@ graph TD
     mainCli --> backendCli[mlia backend]
     mainCli --> targetCli[mlia target]
     mainCli --> cliPlugins[CLI plugin commands]
-    legacyBackend[mlia-backend compatibility wrapper] --> backendCli
-    legacyTarget[mlia-target compatibility wrapper] --> targetCli
     checkCommand --> api
 
     backendCli --> backendCommands[backend install/list/uninstall]
@@ -63,7 +61,7 @@ graph TD
 
 | Layer | Core modules | Responsibility |
 | --- | --- | --- |
-| CLI | `mlia.cli.main`, `mlia.cli.commands`, `mlia.cli.command_validators` | Parse the root `mlia` command, including `check`, `backend`, and `target` command groups; keep legacy `mlia-backend` and `mlia-target` wrappers available with deprecation warnings; create `ExecutionContext` only for commands that need analysis context; configure logging and output format; and call command functions. |
+| CLI | `mlia.cli.main`, `mlia.cli.commands`, `mlia.cli.command_validators` | Parse the root `mlia` command, including `check`, `backend`, and `target` command groups; create `ExecutionContext` only for commands that need analysis context; configure logging and output format; and call command functions. |
 | Public API | `mlia.api` | Validate inputs, resolve targets and backends, ensure required backends are installed, create advisors, optionally return standardized output. |
 | Registries | `mlia.target.registry`, `mlia.backend.registry`, `mlia.plugins.*` | Load plugin entry points once and expose registered target, backend, converter, and CLI capabilities. |
 | Backend management | `mlia.backend.manager`, `mlia.backend.install`, `mlia.backend.config` | Show backend status, install/uninstall backends, resolve dependencies, and provide backend configuration metadata. |
@@ -76,10 +74,10 @@ graph TD
 The core package should not need target-specific conditionals for every new
 hardware family or converter. Instead:
 
-- target plugins register target metadata and advisor factories
-- backend plugins register backend configuration and installation metadata
-- converter plugins register named converter callables
-- CLI plugins can append commands to the command list
+- Target plugins register target metadata and advisor factories.
+- Backend plugins register backend configuration and installation metadata.
+- Transformer plugins register named model transformation callables.
+- CLI plugins can append commands to the command list.
 
 This keeps core orchestration stable while allowing target, backend, and
-converter packages to evolve independently.
+transformer packages to evolve independently.

docs/source/overview.md

@@ -15,13 +15,13 @@ together, how JSON output is structured, or how plugins are discovered, this is
 the right package.
 
 If you are trying to understand the detailed behaviour of a specific target,
-backend family, or converter path, the owning plugin package is the right place
-to go next.
+backend family, or model transformation path, the owning plugin package is the
+right place to go next.
 
 ## What this documentation covers
 
 This documentation focuses on the shared MLIA experience: how to run the core
 workflows, how results are structured, and how plugins are discovered and used.
 
-For in-depth target-specific, backend-specific, or converter-specific detail,
+For in-depth target-specific, backend-specific, or transformer-specific detail,
 see the individual plugin packages.

docs/source/plugin_architecture.md

@@ -17,7 +17,6 @@ conversion stacks.
 The core `mlia` package provides:
 
 - The `mlia` CLI, including the `target` and `backend` command groups.
-- Legacy `mlia-target` and `mlia-backend` compatibility wrappers.
 - Plugin discovery and registration.
 - Shared workflow abstractions.
 - Common reporting and output schema logic.
@@ -29,11 +28,11 @@ Plugin packages provide one or more of:
 
 - Target plugins.
 - Backend plugins.
-- Converter plugins.
+- Transformer plugins.
 - Bundled target profiles and backend resources.
 
-Examples include target-focused plugins, backend-focused plugins, and converter
-plugins that extend the larger MLIA workflow.
+Examples include target-focused plugins, backend-focused plugins, and
+transformer plugins that extend the larger MLIA workflow.
 
 See the individual plugin packages for in-depth target-specific,
-backend-specific, and converter-specific documentation.
+backend-specific, and transformer-specific documentation.