Run your first pipeline

Goal

One workflow described, reviewed as a graph, dry-run, and committed. Done means a finished run whose outputs you can trace to evidence — and a versioned plan you can revisit, branch, and compare.

Image: Pipeline Studio with a freshly generated graph draft and the right-rail AI summary beside it.

Steps

1. Open Pipeline Studio and describe what you need in plain language. For example: "Summarize incoming orders by region each morning and flag unusual drops." You are authoring by intent, not drawing boxes.
2. Read what comes back as a package, not just a graph:
   • the graph draft itself — nodes for reading, transforming, and writing, connected by edges;
   • the explanation beside it — what the system thinks you asked for;
   • its assumptions — what it guessed and you did not say;
   • any missing capabilities — a source, skill, or reference it needs and you have not installed.

Image: annotated generated draft calling out nodes, explanation, assumptions, and one missing capability.

3. Challenge the assumptions first. Wrong guesses at this stage become wrong pipelines later. Reply in plain language and watch the draft update — refinement is proposed as graph edits with an explanation of what changed and what the validation impact is.
4. Resolve missing capabilities inline, without leaving Studio. If the draft needs a source you have not connected, install it from the proposal — the same catalog, preview, validate, commit flow as Connect data, launched from the graph that needs it.
5. Walk the graph in more than one view. The same plan projects differently per question:
   • Workflow: does the topology match the job — read, shape, write, in the right order with the right branches?
   • Data: do the interfaces line up — what flows across each edge, and is anything unstructured where you expected structure?
   • Permissions: what needs approval, and where are the runtime gates?
   • Health: is anything invalid, unconnected, or risky before you run?
   • Assets: where does everything land — destinations and ontology targets named explicitly?
   • AI: what is the system reasoning, assuming, and suggesting?

Image: same graph shown in workflow view versus permissions view.

6. Select nodes and edges and act on them. Clicking a node or an edge surfaces two kinds of actions: fixed actions (configure, inspect schema, attach policy, connect, remove) and AI-suggested actions (normalize here, add approval before this write, explain why this edge is invalid, complete the downstream flow). Prefer the suggestion that names the problem over the one that just adds machinery.
7. Set approvals where writes happen. Policy lives on the nodes, not in a separate app: require approval on the workflow, on a branch, or on the specific node that writes externally. Anything that changes the world outside Semogram should have a human gate you chose deliberately.
8. Dry-run and read the assist summary: what would run, which dependencies are still unresolved, and what outputs would be produced. Treat unresolved dependencies as blockers, not warnings.
9. Commit explicitly. The working draft becomes a version — with history, branches, and compare, so next week's change starts from a known-good state instead of a mystery.
10. Open the run and follow one output back through its evidence chain to the source. Trust the chain before relying on the result.

When the draft looks wrong

• Graph does not match the intent: the explanation or assumptions usually reveal the misread. Correct the reading, not individual nodes.
• Invalid edges: select the edge — the system explains why the interfaces are incompatible. Change one side's shape or insert the suggested normalization.
• Validation flags a node: read the flag as a question about your intent (wrong source? missing permission? ambiguous field?) and answer it in the graph.

What good looks like

• The proposal names real systems and data you recognize.
• Every external write has an approval you placed on purpose.
• Dry-run outputs match expectations before commit.
• You can explain the pipeline in one sentence and prove it from the run.

Next

• Structure what flows through it: Shape your first ontology.
• Deepen review and feedback habits: Operators.
• When a run misbehaves: Troubleshooting.