Advanced mode: the workflow graph

Advanced mode is a workflow timeline you build once and run every shoot — not a generic dataflow canvas. Each node is a real operation: copy to these disks, verify those bytes, transcode a proxy, write a manifest, eject the card. Wire them together, branch in parallel, save the graph as a template, and let it run.

Tabs are projects

The tab bar above the canvas holds your projects — each tab a complete, independent workflow with its own graph, results and run state:

• Durable. Tabs persist across app restarts — graph, node configurations, disk selections, everything. Close the app mid-prep, reopen tomorrow, it's all there.
• Independent. Tabs run (and arm) independently and in parallel.
• Named. Double-click a tab to rename it. The tab title matters: with the default duplicate policy, it names the run folder at your destinations — call the tab Day 12 — A cam and that's the folder on the RAID.
• The workflow bar under the tabs shows the loaded template chip (with a dirty-dot and Save when you've diverged), and the three segments: Build (the canvas), Results (this tab's runs), Info (production metadata).

How the graph thinks

• Sources are roots. Every flow starts at one or more Source nodes; nothing connects into a Source, and Source cards stay anchored in place on the canvas.
• One output port, wire it anywhere. Every node has a single always-open output. Two cables from one node = a parallel branch. (There is no "split" node — fan-out is the split.)
• It's a schedule, not a pipe. A cable means "run this after that". Result-dependent nodes (Verify, PDF Report) additionally pick which upstream result they act on in their settings — the cable orders, the config chooses.
• Acyclic, validated live. Cycles and invalid kind-pairings simply can't be drawn; the connection preview only offers legal targets.
• Several flows per canvas. A tab can hold multiple independent flows (say, A-cam and audio). Run and Arm process the flows that are ready; incomplete ones wait calmly.

Working on the canvas

• Add nodes from the + on any free output port (the chooser lists what may legally follow) or by clicking empty canvas.
• Connect by dragging from an output port to a node's input side.
• Configure in the detail panel that opens on the right: disks, policies, algorithms, naming. Add-on chips (Verify / MHL riders on a Copy) open their own compact panel.
• Drag disks straight onto cards — a card onto a Source, a shuttle onto a Copy. Entry rows appear on the card itself; reorder them by their grip handle in the details.
• Move nodes freely — layout is cosmetic and never resets results. Zoom with the controls in the corner (0.5×–2×, one click back to 1:1).
• Delete a selected node or cable; deleting a node removes its cables but never cascades into downstream nodes. The last remaining Source can't be deleted.
• Everything is live. Unplug a disk and every node that references it flags itself immediately — no click-to-refresh anywhere.

Plan diagnostics: blocked vs. waiting

As you edit, a planner continuously validates the whole graph. Its findings appear as a diagnostics pill at the bottom of the canvas; open it and each row names the node, the problem, and jumps to it. The crucial distinction:

• Blocking — a real error inside an otherwise-ready flow: no destination on a Copy, Verify with nothing selected, a Convert whose sources can't produce its target, destination inside the source. These stop Run/Arm until fixed.
• Waiting (deferred) — a flow that simply isn't fed yet: a Source with no selection. These never block; they render as a calm waiting for source state — which is exactly what an armed station is. Starting a manual Run with waiting flows just asks to confirm skipping them.

Add-ons: verify & manifests fused into a copy

A Copy node can carry an inline Verify add-on and, on it, an MHL report — shown as rider chips on the card. These run fused with the copy: read-back overlaps the copying, the manifest is written from the confirmed hashes, one pass total. Use a standalone Verify node instead when verification is a separate scheduled step (or an audit of the source itself). Details: Verification & MHL.

Running, arming, pausing

• Run executes the graph: parallel branches genuinely in parallel, downstream steps as their dependencies finish, per-node progress on every card (with live read speeds on Sources and byte/s or frames/s on operations).
• Arm is the standing version — see Watch mode.
• Pause / resume. Advanced runs pause mid-flight — even mid-file — and resume where they left off: the same run folder is reused and already-copied files are skipped, not re-copied. If a pause interrupts verification, the affected verification restarts cleanly on resume so no file is ever marked verified without a complete check.
• Stop keeps everything already copied (never a rollback), removes only the in-flight partial file, archives the run as stopped — browsable.
• Failures stay local. A node failing red fails its flow-branch; independent parallel branches keep running. Whatever depends on the failed result won't run; everything else finishes. There's no silent auto-retry — the result browser shows exactly what happened, and a Skip-policy re-run picks up the remainder.

Templates

A template is the whole graph, bottled: nodes, cables, policies, verify settings, convert outputs, naming — everything except the specific disks.

• Save with ⌘S or the workflow-bar Save (first save asks for a name). The template chip shows which template the tab is based on and a dirty dot when you've edited past it.
• Built-in templates ship as immutable starting points — loading one gives you a fresh copy to edit; your own templates are yours to overwrite.
• Disks become placeholders. On load, Source and destination selections come back as placeholders — drag today's actual disks on and everything else is already configured. That's deliberate: yesterday's card is gone; the recipe isn't.
• File-naming templates are not carried into saved templates in v1 — re-add custom rename rules after loading if you use them (destination policies, verify, convert settings all persist).

The Info panel: production metadata

The workflow bar's Info segment holds free-form production fields — project name, production, crew, contact, location and more. They're not decoration:

• They're available as naming tokens in destination-subfolder and file-naming templates (an empty field simply omits its path component).
• They flow into PDF reports — the report's header cards bind to these fields.
• They're saved with templates, so a production's template carries its slate.

Fields lock read-only while a run is active.