Module Contract Lab: INPUT → PROCESS → CHECKPOINT → RETURN

One of the main sources of chaos in a large workflow is not knowing where one responsibility ends and the next begins. LAB 03 forces that boundary to become explicit on the canvas.

After the exercise, you should be able to take any Hansen branch and state what it receives, what it does, where its result is verified, and what it officially returns to the Master Workflow.

• Keep LoadImage outside MODULE_01_INVERT: it is the upstream / Master Input.
• Place ImageInvert inside the MODULE_01_INVERT group.
• Place the first PreviewImage inside the group and label it CHECKPOINT · MODULE RESULT.
• Keep the second PreviewImage outside and label it MASTER DOWNSTREAM / OUTPUT.
• Connect the single IMAGE output of ImageInvert to both the local checkpoint and downstream output.

MODULE_01_INVERT has one responsibility: receive IMAGE and return an inverted IMAGE. Nothing more. It does not load the file, save the delivery result, choose a route or control other groups.

If a module description requires a long sentence containing several independent tasks, the boundary is probably poorly drawn.

Run the workflow and inspect only the LOCAL CHECKPOINT first. Do not judge MASTER OUTPUT until the local result is proven.

This simple rule saves hours later in PPL, masks and main FLUX: a local branch should be able to prove its own result independently of whatever happens after return.

In LAB 03, the return point is the IMAGE link that crosses the right boundary of MODULE_01_INVERT and continues to MASTER OUTPUT. A separate Return node is not required; what matters is an unambiguous interface.

In a large production graph, return points are worth marking with a reroute/label/note, especially if the module may later be extracted as a standalone JSON.

Create a second group, MODULE_02_PASS_THROUGH. Its job is to return the original IMAGE unchanged. Then place a selector after the two module outputs and switch between MODULE_01_INVERT and MODULE_02_PASS_THROUGH.

If downstream continues to receive the same IMAGE contract, the modules are interface-compatible even though their internal behavior is completely different.

Add another external control or source inside MODULE_01, but do not include it in the contract. Now imagine extracting the group into a standalone workflow. The problem becomes obvious: the branch is no longer autonomous.

Then fix the contract: either add the dependency as an explicit module input or move the required control inside the module. This is exactly the audit needed when extracting Hansen branches.

• You write the responsibility and contracts before selecting nodes.
• You distinguish a local checkpoint from the final Master output.
• You can point to the exact return point on the canvas.
• You can identify incoming links that cross the module boundary.
• You understand why two very different modules can be interchangeable when they share the same contract.
• You can explain why a hidden dependency breaks standalone extraction.