Workflows & TES

A workflow bundle needs a stable identity/version, declared inputs and outputs, validation rules, execution requirements, and a testable failure contract. Keep orchestration separate from the tool image and preserve enough run context to reproduce a result.

Before changing a bundle, identify affected services and compatibility boundaries, test the smallest representative case, and document rollback. Do not treat the frozen ML tutorial tree as the workflow runtime contract. SIF/Apptainer is configured in the inspected stack but operational support requires a successful pinned execution record; do not promise it without that evidence.

Workflow development

Workflow bundles live in omnibioai-workflow-bundles, discovered from each domain/workflow directory's manifest.json and README.md. The Workflow Catalog indexes every registered, documented workflow directly from that source — currently several hundred registered of a somewhat larger set of candidates found in source, both counts re-derived on every regeneration, never hard-coded.

Registration and documentation are not execution evidence. A workflow appearing in the catalog means its manifest was discovered, parsed, and indexed — it does not mean the workflow has been executed against sample data or a real backend. Only a small number of workflows in the current catalog have any located execution-lifecycle test evidence (see Testing & Quality); most do not, and this page does not imply otherwise for any workflow just because it's listed.

TES development

Tool and backend definitions live in omnibioai-tes (configs/tools/**/*.yaml for tools, backend configuration separately). The generated Tool Catalog and interactive Tool Explorer index every configured tool — currently in the tens of thousands, re-derived on every regeneration.

A tool's own source may tag its command as unverified_command. This is source metadata the tool definition declares about itself, preserved verbatim by the catalog generator — it is a fact about the tool's own declared state, entirely separate from this site's documentation verification state (CONFIGURED, meaning "successfully parsed into the catalog"). A large share of currently configured tools carry this tag; the catalog states this per tool rather than hiding it.

Catalog generation is not tool execution. Regenerating the TES catalog parses tool-definition YAML; it never runs any tool. A tool's full searchable presence in the catalog (human discoverability) is a documentation property, not evidence that tool executes correctly — do not run any of the catalog's tools as a way of "verifying documentation," and do not treat the catalog's completeness as proof of execution correctness for any individual tool.

Execution-backend adapter code (local, Slurm, Kubernetes, cloud batch) has its own unit test suite in omnibioai-tes, exercising the adapter logic — not each individual tool's command, and not a real scheduler or cloud account unless you have explicitly configured and are entitled to use one.

Execution artifacts

Use Tool Image Lifecycle to connect image metadata and verified runtime availability to TES, and Model Registry Lifecycle for model registration, verification and use.