Analysis Job Flow

This sequence documents the asynchronous analysis path implemented by the Web App and Model Server. It applies when the Web App sends one or more pending jobs to the Model Server's /api/analyze/enqueue-batch endpoint.

Boundaries and Responsibilities

• The Web App owns AnalysisJob records and moves accepted jobs from pending to enqueued.
• The Model Server validates the batch payload, chooses the processor from its requested gateway and model, and queues the work in Redis.
• The RQ analysis worker processes the selected job. The tasks queue handles the unified analysis endpoint; the deployment also provides separate workers for tanbih_tasks, notifications, and data_collection_tasks.
• Shared data is the file boundary: the input path in the job payload identifies the dataset, and generated data is written back for the Web App to serve.
• The notification worker performs the Model Server's HTTP PATCH callback to the Web App. The Web App persists updates and sends a completion email for completed jobs.

Provider Branches

The selected gateway determines the worker processor. The current implementation supports ml_server models (including Marsad and Tanbih), openrouter, and open_source. A provider call therefore occurs only for paths that require an external or selected provider; it is not a guaranteed step for every analysis job.

Exact payload fields, status semantics, shared file paths, callback authentication, and compatibility rules belong in Cross-Repository Contracts.