Views and versions
Studio views, modes, selections, actions, and draft versioning.
Pipeline Studio shows one plan many ways. Views answer different questions, modes change what you are doing, and versions keep every decision reviewable. Conceptual companion: Pipelines overview.
Views
| View | Answers | Reach for it when |
|---|---|---|
| Workflow | Is the topology right? | First read of any draft |
| Data | Do interfaces and schemas line up? | Edges look suspicious |
| Permissions | What needs approval, what is gated? | Before any commit with writes |
| Health | Anything invalid or risky? | Validation flags appear |
| Assets | Where does everything land? | Outputs and ontology targets matter |
| AI | What is the system reasoning? | Assumptions need challenging |
Each view can show its own panels (graph, inspector, AI rail, impact, history) and overlays (interfaces, policies, health, assets, suggestions) — same graph, different scrutiny.
Example: a draft that looks fine in workflow view shows a missing approval in permissions view. Example 2: health view surfacing an incompatible edge the topology hid.
Image: same graph in workflow view versus permissions view.
Modes
| Mode | You are… | Graph behaves as… |
|---|---|---|
| Authoring | Building and refining | Mutable draft with suggestions |
| Lineage | Tracing provenance | Read-only ancestry of data and decisions |
Selections and actions
| Selection scope | Meaning | Actions surface |
|---|---|---|
| Whole graph | The plan itself | Fixed: configure, validate, commit; AI: reshape larger parts |
| Node | One step | Fixed: configure, inspect schema, attach policy, connect; AI: normalize here, add approval, explain, complete downstream |
| Edge | One flow | Fixed: inspect, remove; AI: explain invalidity, suggest normalization |
Actions come in two kinds: fixed (always available for the selection) and AI-suggested (with rationale and, often, a prompt you can accept or edit). Context is selection plus view plus graph state — the same node offers different actions in permissions view than in data view.
{
"id": "suggest-approval-before-write",
"label": "Add approval before this write",
"kind": "ai-suggested",
"scope": "node",
"targetNodeId": "egress-warehouse",
"rationale": "External write without a human gate",
"suggestedPrompt": "Require node-level approval on egress-warehouse"
}Node policy block
| Field | Meaning |
|---|---|
| Write policy | Referenced rulebook governing the node's writes |
| Approval | Whether required, and at node, branch, or workflow level |
| Runtime gate | Enabled with a human-readable reason when runs must pause |
| Access | Which integrations, tools, and secret providers this node may touch |
| Sensitivity | Low / moderate / high classification of what flows through |
Graph-level policy aggregates node policies — the graph summarizes, the nodes decide.
Drafts and versions
| Concept | Meaning |
|---|---|
| Working draft | The uncommitted graph you edit, with undo/redo and local changes |
| Commit | Explicit save moment turning draft into history |
| Branches | Parallel lines of experimentation on one workflow |
| Compare | Draft versus committed, or version versus version |
| Selection + viewport | Where you are (selected node/edge, pan/zoom, pinned panels) — restored with the draft |
One active draft per open workflow. Compare before merging behavior back; branch what you might regret.
Choosing well
- Change views instead of guessing — each view exists because topology hides something.
- Accept AI suggestions that name the problem, not ones adding machinery.
- Put approvals at the level of the effect: node for writes, workflow for launches.