Pipeline Engine — website section 3 ("Model Builder")
- Date: 2026-08-17
- Author:
- Status: Draft (in description — owner's section 3 description folded in; remaining gaps & open questions below; canvas tech: Svelte Flow proposed, awaiting owner confirmation)
- Related: section 3 in
2026-08-16-website-spec.md,../projects/hutfx.md
Method (same as the website spec): the owner describes what it is and what it must do first. Tech choices and the page layout are decided only after the description is locked.
What it is (in the owner's words)
A pipeline is a process that goes through several stages. We need to build a pipeline tool that allows us to:
- choose a dataset
- process it through different modules — cleaning data, making graphics, some calculation, and many, many other things you can think of to process some data
- see the outcome in a viewer where we see the result
- at the end, save it as:
- a module — to be used for insertion into another pipeline (e.g. in its second stage)
- a research — just saved as research
- an export to many different other services — e.g. ML, create LLM, or just to send a signal to the device (many things we don't clarify yet)
The idea is that this web page with the pipeline needs to be used and reused for our services and processes — so basically we want to build something like the Unreal Engine interface or Blender: an infinite canvas with dots, where you create boxes, and inside each box you have some action/function, a sandbox to write Python scripts, or a build-block schema with IF/else blocks.
Flow
choose / upload] --> ST1[Module: clean data] ST1 --> ST2[Module: calculate] ST2 --> ST3[Module: graph / visualize] ST3 --> V[Result viewer] V --> SM[(Save as module
insert into another pipeline)] V --> SR[(Save as research)] V --> EX[Export to services
ML / LLM, device signal, API, ...]
(The middle stages are any chain of modules — the diagram shows the shape of a pipeline, not a fixed sequence.)
The 4 parts
1. Choose dataset
All four load paths, confirmed by the owner in the section 3 description (website spec): "select data or upload or read real time from something or it might come from the Data Router":
- Select a dataset (from Data Exchange — website section 1)
- Upload a new file into the pipeline
- Read live / in real time from a source (daemon SW, 3rd-party APIs, …)
- Receive it routed from the Data Router (section 1 routes data via API / MCP)
2. Process through modules
An infinite canvas with a dot grid (Unreal Engine / Blender node-graph style). You create boxes (nodes) and connect them; data flows through the pipeline, stage by stage.
Inside a box, one of:
- a ready-made action / function (clean, filter, calculate, graph, …)
- a sandbox — write a script for this step (Python first; R, Julia, … also in scope)
- a build-block schema — IF / else blocks (logic)
Module catalogue (brainstorm — confirm / add / drop):
| Stage | Module | What it does |
|---|---|---|
| Input | Choose dataset | Pick a dataset from Data Exchange |
| Input | Upload | Bring a new file into the pipeline |
| Processing | Clean | Remove duplicates, fill / fix missing values |
| Processing | Filter | Keep rows / columns matching a condition |
| Processing | Transform | Rename, reshape, join, split |
| Processing | Calculate | Arithmetic / statistics on the data |
| Processing | Features | Build feature sets |
| Processing | Aggregate | Group / summarize |
| Visualization | Linear graph | Plot data |
| Visualization | Heatmap | (and other sub-tools) |
| Logic | IF / else | Branch on a condition |
| Logic | Merge / split | Combine or route data streams |
| Sandbox | Python script | Custom Python for this step |
| ML | Train model | Fit a model on the processed data |
| Output | Result viewer | Show the result of a stage / of the pipeline |
| Output | Save as module | Package the pipeline as a reusable box |
| Output | Save as research | Store as a research record |
| Output | Export to service | ML / LLM creation, device signal, API, … |
(…and "many, many other things you can think of to process some data" — keep adding here as they come up.)
Also confirmed by the owner in the section 3 description (website spec):
- Templates — predefined pipelines as templates, or a blank canvas for advanced users
- Custom modules — the user can create modules with actions defined by themselves
- Tuning — visual sliders for tunable params and hyperparams
- Natural language — instructions in natural language; the backend converts them into code + config files
- Config files — a module is a config file in the backend; experienced users can edit the config directly
- Market — modules will be sold on the Market (section 5)
3. View the result
- A viewer where we see the result
- The pipeline's results are sent to the Research dashboard (section 2) for comparing results from different iterations
- (Per stage? The whole pipeline? Where on the page? — to describe)
4. Save / export
- As a module — the pipeline becomes a single box that can be inserted into another pipeline (e.g. as its second stage). Pipelines compose.
- As a research — saved as a research record (website section 2, Data Analytics: research projects / case studies).
- Export to other services — not yet fully clarified; known examples:
- ML / create LLM
- send a signal to a device — context from the section 4 description: there may be device-to-device connections without a model in the middle, e.g. one sensor sends a specific value that triggers another sensor (or action)
- publish modules to the Market (section 5) — confirmed in the section 3 description
- (more — to describe)
Reuse across services
The pipeline page is a section of the website, but the engine itself is reused for hutfx's services and processes:
- our own services / processes run pipelines
- device-to-device communication — the canvas is meant to be used for device-to-device communication and relation (the owner's reason for the preferred name "pipeline builder" — see Naming & terminology below)
- marketplace (section 5) — sells modules (confirmed in the section 3 description); pipelines too? (to confirm)
(to describe with the owner.)
Naming & terminology (owner's notes)
- Preferred name for the section / tool: "pipeline builder" — not "model builder" — so the canvas can also be used for device-to-device communication and relation.
- Use the words "architect" and "constructor" in this context.
- Nested canvas — a module for training / explaining algorithms (incl. quantum algorithms) opens a new canvas of the same kind (currently called "model builder"); the algorithm / model is again constructed there by drag-and-drop of modules. Pipelines compose, and the canvas recurs.
Tech (decided after the description is locked — in progress)
The owner started the tech conversation (canvas approach) while the description is still being finished — the decision below is a proposal until the description is locked.
Canvas approach — Svelte Flow (proposed, awaiting owner confirmation)
Svelte Flow (@xyflow/svelte) — the official Svelte port of React Flow
by the xyflow team (same maintainers, node-based UIs since 2019):
- v1.6.3 stable line — MIT, ~224K weekly installs, maintained in the
xyflowmonorepo (packages/svelte);2.0.0-next.0on anexttag - Peer dep
svelte ^5.25.0— the current line is Svelte 5 only (runes) - Built in: infinite canvas with a dot-grid
Background, node dragging, pan / zoom / multi-select,<Handle>ports, animated edges,MiniMap,Controls— the Unreal / Blender node-graph shape the owner described - Subflows (nested graphs) out of the box — matches the owner's "nested canvas" note (train / quantum-algorithm modules open a canvas of the same kind)
- Plays well with Tailwind (our design system); nodes are plain Svelte components, so sliders, the sandbox editor, and IF/else build-blocks render inside a node
Stack impact: hutfx has no Svelte today (Laravel + Blade + Alpine +
Vite). Pattern: Svelte as a widget runtime — the pipeline page mounts a
Svelte app into a <div> from Blade, with its own Vite entry (precedent:
resources/js/dashboard.js for the Chart.js dashboard section). Adds
svelte, @sveltejs/vite-plugin-svelte, @xyflow/svelte to
package.json and one plugin line to vite.config.js; Alpine and the rest
of the stack stay untouched. Honest downsides: smaller community than React
Flow (fewer answers online), one more framework runtime on the page. The
alternative (React Flow — same team, same API) would bring a React runtime
instead: no meaningful win for us.
Open questions (answer before tech)
- Node shape — what does a box show? Ports (inputs / outputs)? Label?
- Execution — run the whole pipeline at once, or per node? Live, as data flows through?
- Where does execution run? On our server? — language: answered in the owner's section 3 description — everything runs in a sandbox: Python, R, Julia
- "Send a signal to the device" — what does it mean technically (protocol, payload)? — context: see part 4, device-to-device
- Versioning — does saving a pipeline overwrite it, or create a new version?
- Access — can all users use it? Per-user isolation of pipelines?
- Templates — answered (section 3): both — predefined pipelines as templates, or a blank canvas for advanced users
- Size — how big can a dataset be for in-pipeline processing?
Proposed milestones (after the description is locked)
| # | Milestone | Status |
|---|---|---|
| 1 | Engine foundation: pipeline + module data model; canvas with boxes & connections; save / load | Not started |
| 2 | First live pipeline: choose dataset + one processing module + result viewer | Not started |
| 3 | Save as module: compose a pipeline into another pipeline | Not started |
| 4 | First export to a service (one concrete target) | Not started |
| 5 | Python sandbox + IF / else build-blocks | Not started |
Steps
- [ ] 1. Owner describes each part (UI, module catalogue, viewer, save / export, reuse) — fill in this file (in progress — the owner's section 3 description is folded in; remaining gaps are marked "to describe")
- [ ] 2. Lock the description
- [ ] 3. Decide tech together: canvas approach, module config schema, execution engine (in progress — canvas approach: Svelte Flow proposed, see the Tech section above)
- [ ] 4. Page layout: nav label, page path, components top to bottom
- [ ] 5. Implementation plan per milestone (one file per milestone, in this folder)
- [ ] 6. Build milestone by milestone; keep milestone status updated here
Result
(Draft — description in progress with the owner.)