Write the specs

Defining the Blueprint of Your Workflow

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.

For now, please create the specs.yaml file in a folder named workflow_v2.

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.

   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 return, 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 key to your task definition, and with it the value you want to return by default.

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.

- name: closing_read  
    entries:
      - name: image_input
        type: image # Entries types can be: str/int/float/bool/image/file
    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

1. Work-order types: Under the key work_order_types, you can specify the list of task-groups and tasks for each work-order-type.

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

Try to do it completely for a task-group before generating your project, to avoid having to handle some merge conflicts at each generation.

Here is a specs.yaml example: