As the technical documentation for "custom model specification" is currently under development for arduino-app-cli, we need to update the Understanding Bricks guide.

The goal is to formalize the Arduino Model as a standalone entity within the ecosystem, clarifying its relationship with AI Bricks and its lifecycle, ensuring a single source of truth and avoiding duplication in the app-cli internal docs.

Proposed Additions

1. The Arduino Model Entity

An Arduino Model is a self-contained resource (weights, configuration, metadata) decoupled from specific Apps. Within the Uno Q ecosystem, models are shared resources that provide the "intelligence" for AI Bricks, optimized for concurrent use and memory efficiency.

2. Relationship & Compatibility (N:N Mapping)

The ecosystem implements a Many-to-Many relationship between Bricks and Models:

• Model Versatility: A single model (e.g., Face Detection) can serve multiple Bricks (e.g., object_detection and video_analytics) if they share the same domain requirements.
• Brick Flexibility: A Brick can swap underlying models (e.g., switching for higher accuracy) without changes to the main.py Python API.
• Multi-tenancy: When multiple Bricks use the same model, they share the assets but execute within separate AI Runner (Docker) instances.

3. Model Classification

Models are categorized by their origin and persistence:

• System Models: Pre-installed, read-only models integrated into the core OS.
• Custom Models: User-added models (via Edge Impulse, AI Hub, or manual import) stored in a dedicated writable partition.

4. Custom Model Lifecycle

The system tracks the synchronization and availability of models through the following states:

• Available: Remote-only; present on the cloud provider but not yet downloaded.
• Installed: Assets and model.yaml are present on the board and ready for execution.
• Detached: Locally functional but disconnected from the remote provider (e.g., after logout or cloud project deletion). Updates are disabled in this state.