Fluidforms

Self improving forms for collecting unstructured data in a structured way

Comment

Inspiration

Forms make us choose between structured fields and natural answers. Structured fields are easy to analyse, but someone must anticipate every useful question. Open-ended responses capture nuance, but the important details often remain buried in paragraphs, voice notes, or photographs.

That tension appears everywhere: a learner explains why a course was confusing, a mystery shopper describes a disappointing visit, or a contractor reports a delivery problem. The useful next question depends on what the person actually said.

Fluidforms started with a question: what if we build a loop that builds and improves the forms. So a form could understand the response, ask for the relevant detail, and improve its next version when the owner discovers something missing?

What it does

Fluidforms turns unstructured responses into structured records through contextual conversations.

An owner chooses from the list of starter templates, spanning course feedback, bookings, market research, mystery shopping, retail audits, customer support, site reports, and more.

The owner describes the outcome, reviews the configured workflow, runs checks, and publishes it. The respondent seamlessly share multimodal information. The owner can spot missing details or provide feedback that could improve information gathering. The optimisation loop then runs and optimises the form and the next respondent receives the modified form.

The dashboard makes the optimisation loop inspectable through response summaries, contextual answers, model information, checks, and publication events.

How we built it

The frontend uses React, TypeScript, Vite, and Vercel json-render. Typed workflow specifications are assembled into registered components, and the capability graph reflects the same declared rules used by the respondent form.

The backend uses Python, FastAPI, Pydantic, SQLAlchemy, and SQLite. It stores form releases, session snapshots, responses, evidence, and review records. Deterministic code enforces required answers, conditional branches, artifact checks, and release approval.

NVIDIA Nemotron Lightning runs through Nebius Token Factory to configure starter templates, interpret responses, detect dissatisfaction, and propose typed workflow patches. NVIDIA Nemotron 3.5 Super VL, also served through Nebius, checks whether packaging or delivery labels are visible in the evidence workflow. Those observations remain advisory.

DSPy defines the intelligent capabilities through typed signatures. A separate, bounded GEPA experiment compares prompt candidates against labeled examples. Its recorded site-report run retained the baseline; we do not claim an improvement it did not demonstrate.

The application is deployed on a persistent exe.dev VM with a systemd-managed service. The repository includes three C4 architecture views covering system context, containers, and backend components.

Challenges we ran into

  • Reliable structured output: reasoning consumed small response budgets before JSON was complete. Explicit non-thinking mode and narrower typed outputs made the workflow more reliable and economical.
  • Understanding mixed feedback: a response can praise an instructor while criticising an assignment. An explicit typed dissatisfaction decision worked better than relying only on a broad issue category.
  • Changing the workflow without losing its meaning: regenerating an entire form could ignore the intended change or alter unrelated details. Small typed patches let us preserve existing questions and make the added behavior reviewable.
  • Making improvements safe to publish: a proposed change needs more than a convincing explanation. We bind approval to the checked artifact, reject stale-base publication, and preserve the version used by an existing session.
  • Keeping the product understandable: the graph and activity trace make model interpretation, deterministic routing, and approved changes visible to the owner.

Accomplishments that we're proud of

  • A working end-to-end loop: create → collect → understand → review → improve → check → publish → collect better information.
  • Fifteen configurable starter contracts with immediate workflow previews.
  • Live negative/mixed-feedback routing, an approved additional question in version two, and a positive path that avoids unnecessary questions.
  • A visible dashboard trace connecting responses, proposals, checks, and releases.
  • Thirteen passing backend tests, including creation/publication of all 15 templates and required contextual answers across versions.
  • Successful desktop and mobile browser testing against the hosted application, plus verified database and photo persistence across a service restart.

What we learned

A self-improving form needs a clear boundary between interpretation, policy, and publication. Models help understand language and propose useful questions. Typed contracts and deterministic checks make those proposals understandable and enforceable. Owner feedback closes the loop.

We also learned that “more AI” is not automatically better. Small, well-scoped capabilities are easier to evaluate, debug, and compose. Showing the original response, allowing corrections, and preserving release history are as important to the experience as the model call itself.

Finally, evaluation must distinguish a working workflow from a better model. Our small recorded experiment is useful smoke evidence, but it does not establish real-world accuracy or gains from optimisation.

What's next for Fluidforms

The larger vision is to optimize both individual capabilities and how they are assembled. That includes choosing among deterministic code, language models, vision models, and smaller specialist models according to measured quality, latency, and cost.

Next steps include richer workflow packs, larger domain-specific evaluation sets, better-calibrated evidence checks, version-to-version comparisons, and stronger workspace isolation. We also want to explore distilling suitable decisions into lightweight models that can run on the edge or in the browser.

The current product demonstrates contextual collection, declared workflow assembly, and an owner-approved improvement loop. Continuous model training, automatic model/pipeline optimization, and edge execution are the direction we are building toward.

Built With

Share this project:

Updates

Submission history