Read the manifests Studio generates

01Open the panel

Objective

Find the DSL view, and notice that it follows the scene.

Actions

1. Select Hydra DSL in the top bar.
2. Read the label at the top left of the panel.
3. Switch scenes and watch the label change.

Top bar → Hydra DSL

One button, two views. In Workflow configuration the panel shows a single file, workflow.yaml, marked synced when it matches the canvas. In Jobs configuration it shows the job, marked multi-section because a job is four files, not one.

YAML   synced          ← workflow scene
JOB    multi-section   ← job scene

02Read the workflow file

Objective

Match every node on the canvas with an entry under steps.

Actions

1. Stay in Workflow configuration.
2. Read name, trigger, then each step.
3. Compare each depends_on with an arrow on the canvas.

Workflow configuration → Hydra DSL

The file opens with what the workflow is — its name and its trigger — then lists the steps in the order the graph imposes. Each depends_on is an edge, written as a name rather than drawn as an arrow.

version: "1.0"
workflow:
  name: first-workflow
  trigger:
    type: manual
  steps:
    - name: job_1786220352457_0
      type: action
      action: webhook
    - name: job_1786220352458_1
      type: action
      action: webhook
      depends_on:
        - job_1786220352457_0
    - name: action_log_4
      type: action
      action: log
      params:
        message: "Workflow test "
      depends_on:
        - job_1786220352458_1

Three steps for three nodes, and the chain reads correctly: the second waits for the first, the log waits for the second. The Log step is exactly what you configured — its action and its message are there.

    - name: first-job
      type: job
      job: ./jobs/first-job

What you should see

One entry per node, in dependency order, and a depends_on for every arrow.

03Read a job, section by section

Objective

Walk the four tabs in the order a job runs.

Actions

1. Switch to Jobs configuration and open Hydra DSL.
2. Select Sources, and read the connector block.
3. Note the identifier on the first indented line.

Jobs configuration → Hydra DSL → Sources

A job is four files, and the panel gives one tab to each. Read them in order and the job explains itself: where the data comes from, what happens to it, where it goes, and how the three are wired.

version: '1.0'
sources:
  source_csv_lean:
    type: csv
    connection: {}
    extract:
      table: ../../output/orders_clean.csv
      batch_size: 1000

source_csv_lean is the identifier, not the file. It is what pipeline.yaml will point at. connection: {} is empty because a CSV needs no connection — the path alone is enough. batch_size was never typed by hand; it is a default Studio writes for you.

What you should see

Four tabs, and the source block matching the node you configured.

Sources  Transformations  Destinations  Pipeline

04Read what is missing

Objective

Use the panel for what it is best at — showing absence.

Actions

1. Select the Transformations tab.
2. Select the Destinations tab.
3. Compare both with what you intended to build.

Hydra DSL → Transformations · Destinations

This is where the panel earns its place. The canvas draws a node whether or not it is complete; the YAML writes exactly what that node holds, and nothing more.

version: '1.0'
transformations:
  steps: []

version: '1.0'
destinations:
  dest_csv_gion:
    type: csv
    connection: {}
    load:
      table: ''
      mode: replace

destinations.dest_csv_gion.load.table
  String should have at least 1 character
steps
  List should have at least 1 item after validation, not 0

05Read the wiring

Objective

Confirm the two ends of the job refer to the identifiers you just read.

Actions

1. Select the Pipeline tab.
2. Compare from with the identifier in Sources.
3. Compare to with the identifier in Destinations.

Hydra DSL → Pipeline

The shortest file of the four, and the one that ties the others together. It holds identifiers, never paths — which is what lets you repoint a source at another file without touching the wiring.

version: '1.0'
pipeline:
  name: first-workflow
  from: source_csv_lean
  to: dest_csv_gion

One from, one to — a job reads from one place and writes to one place. The name line is written by Studio for readability; the engine reads from and to and ignores the rest.

What you should see

Both identifiers resolving to blocks you have already read. If one does not, the job will fail before reading a single row.

from: source_csv_lean   → sources.source_csv_lean
to:   dest_csv_gion     → destinations.dest_csv_gion