Sequence as the top-level: pipeline composer interfaces

Most control planes that execute in sequence are edited as if they were a junk drawer.

CDN redirects live on one page. Cache rules on another. Transform rules somewhere else. SSL and proxy toggles sit in DNS. Origin behavior is documented in a second vendor’s settings. Each surface is locally coherent. Together they form a machine nobody can see — until two rules disagree and the browser reports a redirect loop.

That failure mode is not exotic. It is what happens when sequentiality is real in the runtime and fragmented in the UI.

The claim

If a system applies transformations, policies, or handlers in a defined order, the primary interface should be a processing map: one composition where every step is visible, ordered, and editable in place.

Call the pattern a pipeline composer.

• Sequence as the top-level organization.
• Parallel work is not a competing metaphor at the root. It nests inside a step or sub-step.
• Users insert steps between neighbors — but only steps whose rule type is valid at that socket.
• The map is the product representation of the actual pipeline, not a dashboard of unrelated cards that happen to affect the same request.

This claim is scoped to the processing-map surface — the composer where an ordered runtime is edited — not to every pixel of a product shell. Real admin UIs still wrap that surface in navigation, hero copy, billing chrome, and unrelated settings. Sequence as the top-level means the spine inside the pipeline composer matches the spine the engine runs. It does not mean the login screen, sidebar, and invoice page are secretly one pipeline.

This is how many of us already visualize these systems. The industry usually refuses to put that mental model on screen.

Why sequence wins the top slot

Not everything is a pipeline. Graphs, canvases, and spatial layouts earn their place when the domain is genuinely multi-parent or freeform.

But a surprising amount of infrastructure and product logic is ordered:

• Request and response middleware
• DNS → proxy → edge rules → origin
• CI jobs and deploy gates
• Mail filters and moderation queues
• Compiler passes and linters
• Shell pipelines and structured data pipelines
• Form wizards and checkout flows
• Accessibility trees walked in document order

Human planning machinery is good at sequences and goals. Progressive disclosure is already procedural planning made visual: show the next honest step, deepen on demand. A processing map makes that honesty structural — the order you see is the order that runs.

Parallelism still matters. Fan-out, race, join, and “all of these must pass” are real. Express them as typed composite steps inside the sequence: a step named Parallel checks that expands into sibling sub-steps, then joins before the next top-level stage. Sequence stays the spine; composition fills the vertebrae.

Fragmented sequentiality is a product lie

When execution order is split across tabs, the product is lying about what counts.

Power users cope by maintaining a private diagram in their head (or a Notion page). Everyone else discovers order only through outages. That is the same class of bug as filters that exist in the API but not in the UI: capability without representation.

A classic collision looks like this:

1. Vendor A redirects apex → www (configured as a “redirect rule”).
2. Vendor B redirects www → apex (configured as “primary custom domain”).
3. A proxy toggle puts Vendor A in front of Vendor B, so both rules finally meet in one request path.
4. The browser loops. No screen ever showed A then B as one pipeline.

The fix people reach for — “read three docs and hold the order in working memory” — is exactly the cognitive tax HCI should refuse.

Anatomy of a pipeline composer

1. The map

A single visual plane: stages in order, left-to-right or top-to-bottom. Each stage is a step with a name, a type, a short summary of its effect, and an expand affordance for configuration. Empty sockets between steps invite insertion. There is no separate “list of rules elsewhere” that silently participates.

2. Typed sockets

Not every rule can sit everywhere. A TLS termination step is not a cache key rewrite. The insert palette is filtered by socket type: what the previous stage emits, what the next stage consumes, and what the platform allows at that phase.

Typing prevents nonsense compositions and teaches the domain. It is progressive disclosure for experts and guardrails for everyone else.

3. Nested composition

Inside a step you may find:

• A linear sub-pipeline
• A parallel group with a join policy
• A conditional branch that rejoins
• A reference to a reusable mini-pipeline

The root remains a sequence so the question “what happens first?” always has an answer.

4. One evaluation story

The UI should be able to narrate a sample input walking the map: which step matched, which transformed, which short-circuited. If the runtime can evaluate it, the composer should replay it. Debugging becomes reading the map, not grepping four admin UIs.

What this is not

• Not BPMN cosplay. The goal is a legible product surface, not enterprise diagram theater.
• Not “everything is a node graph.” Freeform graphs bury order. Use graphs when the domain is a graph; default to a spine when the domain is a spine.
• Not a replacement for code. Pipelines as config still need export, diff, and review. The composer is the honest face of that config — the same heirloom obligation as any other settings GUI that claims to represent a file.

Design rules (short)

1. One map for one runtime order. If it runs in the path, it appears on the path.
2. Sequence at the root; nest parallelism.
3. Insert between, with types. Palette = valid rule kinds for that socket.
4. Summaries before forms. Steps show effect in one line; expand for knobs.
5. Replay beats folklore. Sample evaluation on the map > tribal knowledge of “how Cloudflare really works.”
6. Export is sacred. The map serializes to the same artifact the engine loads.

Why this pattern is rare

Vendors ship features as SKUs. Each SKU gets a settings page. Navigation mirrors the org chart and the billing catalog — not the request path. Sequential truth is an implementation detail; the UI sells modules.

HCI Nerdz takes the opposite bet: product representation follows execution, not package packaging. If minds plan in sequences, sequential systems should be composed as sequences.

Prototype

We are building this as an open UI experiment in pipeline-composer: a typed processing-map component and a live demo that models edge/request pipelines (including the apex/www redirect trap) as one editable spine.

• Demo: hci-nerdz.github.io/pipeline-composer
• Docs note: Processing maps

The first demo is intentionally narrow: prove that typed insertion, nested parallel groups, and path replay make conflicting rules obvious before the browser does.

Architecture note

The prototype follows the HCI Nerdz strategy template: core IR, headless controller, DOM renderer first, thin host wrappers — share meaning and behavior, not auto-exported pixels. See Share the IR, not the pixels and Fundamental contexts for portable UI.

Sibling boundaries

• HCI Nerdz — graphical pipeline composers, processing maps, product representation of ordered systems
• OpenShellOrg — shell and CLI pipelines, structured pipelines in the terminal
• DevCentr — environment and toolchain orchestration that should eventually show the same honesty about order

Same obligation, different surfaces: do not make people assemble a machine in their head that the product already knows how to run.