Tutorial: Local Fan-out

This tutorial is the smallest useful branching proof: every event goes to an all branch, while three events also pass an important filter.

Expected result

One-worker clone fan-out with eight events on the all branch and three on the important branch

finite files input (8)
  -> normalize/classify
  -> clone
       all       -> print-all       (8)
       important -> filter(true) -> print-important (3)

The expected important IDs are evt-002, evt-004, and evt-006. Loss and unexpected duplicates must both be zero.

Download and verify the fixture

sha256sum events.jsonl expected-summary.json

Expected SHA-256:

61e1b02f658f45a0d474747aa33d22a83054731f46d894dfe0e35d32f3aeb697  events.jsonl
7997e8faab01dcf9a29cba755bca3ae59e91e2ae38b2afaaf786e6a1c4df327a  expected-summary.json

Copy events.jsonl to a run-owned directory readable by the selected worker. Use a fresh path or reset file fingerprints before a second cycle.

Build the workflow in the UI

Create a workflow draft named with a unique prefix, for example tutorial-local-fan-out-01.
Add a finite Files source with JSON parsing and Stop reading after enabled. Bind it to the exact worker-visible fixture path.
Add any normalization/classification step needed to retain event_id and the boolean important field.
Add the built-in Fan Out primitive.
Add two output ports named all and important; choose clone dispatch.
Connect all to a Print/evidence sink.
Connect important to a filter whose predicate is exactly important == true, then to a second Print/evidence sink.
Inspect the manifest and confirm the dispatch expresses clone intent:
```
[steps.route.dispatch]
mode = "clone"
ports = ["all", "important"]
```
Validate and publish the immutable workflow version.

Plan and apply

Create a run-owned worker group containing exactly one serviceable worker.
Create a deployment from the published version.
Place every generated job in that group; worker-channel edges require co-location.
Plan and review the generated jobs, channel drivers, one-worker placement, replica count, fixture path, and absence of unrelated destructive changes.
Record workflow, group, deployment, and plan identities, then apply the fresh plan.

Prove the result

Wait for readiness, then correlate worker logs or captured evidence with the deployment and cycle:

Check	Expected
Input records	8
`all` branch records	8
`important` branch records	3
Unexplained loss	0
Unexpected duplicates	0

Check the three important IDs, not only the count. A healthy deployment with missing record evidence is not a pass.

Automate the same lifecycle with MCP

Use the MCP workflow lifecycle. Start read-only: inspect workflow_recommend, workflow_scaling_advice, and workflow_authoring_preview. In a separate write-tier session, upsert the unchanged preview, publish, preview/create the one-worker group, create the deployment, preview the plan, and apply only after review. Record the same identities and counts as the UI path.

Failure and recovery

Zero input: verify worker-visible path, glob, permissions, JSON parsing, and file fingerprint state.
all is 8 but important is not 3: inspect the boolean field after normalization and the branch filter.
Duplicate counts: check that only one source job/replica reads the fixture and that the second cycle started from a clean fingerprint namespace.
Jobs split across workers: re-plan with one group; a worker channel cannot bridge the split.

Tear down and repeat

Preserve the evidence, preview removal, and delete only the recorded deployment and run-owned group/workflow artifacts. Remove only the run-owned fixture copy. Re-list and verify zero residue. For cycle two, use a new unique prefix and a fresh fixture path; require the same counts.

Next, add validation, quarantine, and a durable archive in the Application Log Router.