> For the complete documentation index, see [llms.txt](https://docs.deepomatic.com/platform-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.deepomatic.com/platform-documentation/deepomatic-drive/configuring-visual-automation-applications/assembling-workflows/workflow-implementation/write-the-specs.md).

# Write the specs

The `specs.yaml` file is a crucial component that serves as the blueprint for your entire workflow. This YAML file, written in a human-readable format, contains essential information that defines how your workflow should function, what task-groups it will analyse, and what tasks to output.

{% hint style="info" %}
For now, please create the specs.yaml file in a folder named ***workflow\_v2***.
{% endhint %}

Here are the key elements that are to be specified in a `specs.yaml` file:

1. **Models:** You will be able, under the key *models,* to list all the models that you will use in your workflow. The specified name will later be used to reference that model. The id, is the **model version id**, as can be found on Studio.<br>

   ```yaml
   models:
     - name: image_classifier_1
       id: 67890
     - name: object_detector_1
       id: 12345
   ```

2. **Task-group definitions:**  Under the key *task\_groups ,* you will be able to define the inputs and outputs of an analysis on that specific task-group.\
   **First, the required entries (names and types) are to be listed**. The listed entries are not optional and will be required to do the analysis.\
   **Then, the tasks,** that an analysis on that task-group will have to retur&#x6E;**, are to be listed.** For each task, you have to specify its name and the type of its value. You can also add a *regions* key, and set its value to true,  if you want to link regions (bouding boxes on the image) to it.\
   The ***context\_validation*** key, is an optional key that can be added between the *entries* and *tasks* ones. It is used to give a special status to a specific task. The name of the task specified as context\_validation will necessarily return a boolean and if its value is False, it will stop the execution at that point. \
   For some specific cases, you might want to return a value for a task, even if it wasn't executed. Therefore, you can add the ***default\_value*****&#x20;** key to your task definition, and with it the value you want to return by default.

{% hint style="info" %}

```
As you may know, there are plans to switch the context_validation step to the data_conformity. 
As a first step towards this objective, this gives a special status to the context validation task while leaving it as a task.
```

{% endhint %}

<pre class="language-yaml"><code class="lang-yaml">- name: closing_read  
    entries:
      - name: image_input
<strong>        type: image # Entries types can be: str/int/float/bool/image/file
</strong>    context_validation:
      name: closing_read_context
    tasks:
      - name: closing_read_serial_number_value
        type: str # Tasks types can be: str/int/float/bool
        regions: true
      - name: closing_read_serial_number_valid
        type: bool
        default_value: False #Here if this task raises a TaskConformityError, it will still return the default value.
      - name: closing_read_meter_read_value
        type: str
        regions: true
      - name: closing_read_meter_read_valid
        type: bool
</code></pre>

3. **Work-order types:** Under the key *work\_order\_types,* you can specify the list of task-groups and tasks for each work-order-type.&#x20;

```yaml
work_order_types:  
  indoor: # First defined work order type
    closing_read: # Task-group 1 key
      - closing_read
      - closing_read_serial_number_value
      - closing_read_serial_number_valid
      - closing_read_meter_read_value
      - closing_read_meter_read_valid
    post_install: # Task-group 2 key
      - post_install
      - post_install_corners_visible
  outdoor: # Second work order type
    closing_read:
      - closing_read
    post_install:
      - post_install
```

{% hint style="info" %}
Try to do it completely for a task-group before generating your project,\
to avoid having to handle some merge conflicts at each generation.
{% endhint %}

{% hint style="info" %}
Here is a specs.yaml [example](https://github.com/Deepomatic/missions/blob/circet_workflow_v2/circet-ireland/smart-meters/workflow_v2/specs.yaml):
{% endhint %}