Projects

+ New page

Plan: Website specification — sections, services, and tech

• Date: 2026-08-16
• Author:
• Status: Draft
• Related project: ../projects/hutfx.md

Goal

A section-by-section specification for the hutfx website. For each of the 5 sections we capture: what the service is (in the owner's words), what the user does, inputs, outputs, constraints, and the menu items it needs. From that we derive the per-section tech choices and the overall site structure.

Method: The owner describes each section first. Tech and layout are decided after the description is locked — not before.

Background

The existing product vision (plans/2026-08-16-product-vision.md) proposes experiments, datasets, artifacts, jobs, model registry, and a public API. This document reframes the product from the user's perspective as 5 website sections:

1. Data Exchange — get data in
2. Data Analytics — look at the data
3. Model Builder — build a model from it
4. Model as a Service — run it as an API
5. Marketplace — buy/sell models, datasets, templates

This is a different (and more product-shaped) framing than the internal milestones. It is the spec for what the website shows and does, not for internal infrastructure.

The owner has not yet confirmed which of these sections are in scope, what each one actually does, or what tech will be used. This file is the working draft for that conversation.

Section status

Section 1 — Data Exchange

• What it is: a place where we get data from different sources and get routed
• Sources:
• upload
• daemon SW that runs on various OS (Android, iOS, Windows, Linux and embedded)
• eventually in-house developed HW with sensors
• 3rd party APIs
• live data receiving
• What it does:
• store the data
• route the data to other microservices via API/MCP
• Storage:
• stored data is on our servers
• need physical locations and backups
• API:
• cover permissions
• receiving of data
• sending of data
• Permissions:
• data sets will be read only for users that have permission for that
• download for the owner or if the user has special permission
• HW device:
• for the HW device that we will develop — we will have development kit
• On the user dashboard user have section with the info about data, devices and data sets

Section 2 — Data Analytics

• Every user will have a dashboard
• On their dashboard they can create a Research project
• Each research project will have a research dashboard
• Each research will have one or more case studies
• A case study will be created with the Model Builder (described in the next section)
• Research dashboard will show all the stats and info for the case studies
• Each case study will be a model + results and meta data

Note: the terms "case study" and "research" are working terms and might change over time.

Note: 1st step — define goal of the research and use the objective later on to predict units of measurement and some things to be achieved.

Section 3 — Model Builder

• A model builder will open a blank Infinite Canvas (or Spatial Canvas) (or perhaps template)
• On the canvas the user will be able to add and connect modules
• Each module might be from one of the 4 main stages: Loading data, processing data, results, export
• For each of those stages different modules might be selected, e.g. for processing might be visualizing, edit, clean, graph, train etc.
• There will be predefined pipelines as templates, or a blank one for advanced users
• The visualization module might be different sub tools like linear graph, heatmap etc.
• Loading data might be module — select data or upload or read real time from something or it might come from the Data Router
• There will be an option to create custom modules with actions defined by the user
• Results will be sent and used in the Research dashboard for comparing results from different iterations
• There will be visual sliders to tune some tunable params and hyperparams
• A module in this pipeline will be represented in the backend as a config file, so the more experienced users might directly edit the config files
• All shall be in sandbox — Python, R, Julia etc
• Modules will be on the Market
• Instructions will be in natural language, but in backend this will be converted into code and config files

Note: better name — "pipeline builder", so the canvas can be used for device to device communication and relation.

Note: the module for training and explaining algorithms, quantum algorithms etc will open a new canvas similar to this one called model builder (once we rename this to pipeline builder) and there again with modules drag and drop the algo/model will be constructed.

Note: use the words "architect" and "constructor" in this context.

Pipeline Engine (dedicated document)

The reusable processing tool behind this section — choose a dataset, process it through modules on an infinite dot canvas, view the result, then save it as a module / research or export it to other services — has its own description document: 2026-08-17-pipelineengine.md. Description first; tech and page layout follow the same method.

Section 4 — Model as a Service

• Existing models can be used with data
• If user owns the model they can download it
• If the user rents it via market — they can submit data in an instance of the model and they get back results via hutfx platform
• There might be a device to device connection without a model in the middle — e.g. one sensor sends a specific value that triggers another sensor (or action)

Section 5 — Marketplace

What it is:

What the user does here:

Inputs:

Outputs:

Constraints:

Menu items needed:

Tech (decided after description is locked)

• Stack:
• Storage:
• API:
• Notes:

Page layout

• Nav label:
• Page path:
• Components (top to bottom):

Global site

Navigation

• Top-level nav items (in order):
• Sticky?
• Mobile behavior:

Auth & accounts

• Is login required to view sections, or is the site public?
• Free tier?
• Payment / billing?

Branding

• Product name: hutfx
• Domain:
• Colors / existing brand:
• Logo:

Tech baseline

The existing stack is Laravel + PostgreSQL + Tailwind + Alpine.js + Vite. Unless a section needs something else, new work builds on this stack. Each section's tech subsection above overrides this if a different choice is made.

Steps

• [ ] 1. Owner describes each of the 5 sections (fill in the description fields above). One section at a time or all at once — owner's choice.
• [ ] 2. For each section: lock the description, then decide tech and page layout together.
• [ ] 3. Lock the global site structure (nav, auth, branding).
• [ ] 4. Produce a per-section implementation plan in plans/ for each section that will be built (one file per section, following plans/TEMPLATE.md).
• [ ] 5. Build section by section; update status table as each section ships.

Risks / Open questions

• Which of the 5 sections are actually in scope? The existing project file (../projects/hutfx.md) explicitly lists "serving models / inference API" and "billing / subscriptions" as out of scope — but sections 4 (Model as a Service) and 5 (Marketplace) need exactly those. Either the scope expands, or those sections are dropped / deferred. Owner decision.
• Who is the user? A researcher building models, a company buying services, a general visitor? Affects every section's copy and layout.
• Is the website the product, or a public face for it? The existing landing page + /doc are public. The 5 sections above are mostly authenticated workspace features. We need to be clear which sections are public marketing pages vs. logged-in app pages.
• Relationship to existing milestones: The product vision's milestones (experiments, datasets, jobs, model registry, public API) map loosely onto these 5 sections but not 1:1. This document and ../projects/hutfx.md need to be reconciled once the sections are confirmed.

Result

(Draft — awaiting owner description of each section.)