This piece shares current state with the team so we can design the future. It is working notes from building a form engine in the wild — for people designing and building future forms and workflows, and for small-organization practitioners who need the technical choices explained through consequences for people.

It is not a feature tour and not a launch piece. The practical question is simpler: what works today, what is still pending, and what we build next.

The problem we were trying to solve

Today's general purpose chatbots introduce instead of remove friction for some use cases. For example, some multi-step workflows could benefit by separating the gather what is needed for a prompt from generating and submitting the prompt.

This separation allows us to use a fit for purpose UX for every step in the process. Bespoke Forms, a dynamic data entry form engine, is one possible step in these processes.

A form is a portable working document

The unit of work is a document that carries its own definition — not a fleeting page that dies when the gallery changes.

A few plain words we use:

  • Template — the definition of what to ask and how to structure answers
  • Answers — what someone filled in
  • Identity — which document this is, and who or what it belongs to
  • Source notes — where material came from when that matters
  • Report instructions — how to turn the working document into something humans can read

JSON or YAML (plain text formats machines read) is the editable working document. Markdown or PDF is the report for humans. When a gallery template changes later, a saved document still keeps the definition it was created with. That is what “portable” means here: the work travels with its own rules.

How the current architecture fits

At a plain-language level, the pieces fit like this:

  • Shared rules for what counts as a valid document (schema and validation).
  • A reusable engine runs in the browser as a form component.
  • Drafts save locally in browser storage so incomplete work survives a closed tab. (Linear tickets say browser-local drafts; exact storage mechanism naming stays [NEED SOURCE] until code excerpts land.)
  • A shared report model and local rubric evaluation — scored checks with explainable calculations — turn answers into structured findings without mixing machine scores into human judgment.
  • A gallery or host presents templates and controls trusted configuration. Imported documents cannot invent email destinations; submission profiles resolve only in trusted host config.
  • An optional delivery boundary sends a packaged result onward. In plain Linear language: Forms artifacts pinned through Toolkit and Front Door — our hosting and delivery layers. Finer module names stay [NEED SOURCE] until code-verified.
Template gallery / host
        |
        then
Browser form engine  -- local drafts --  Device storage
        |
        answers + embedded definition
        then
Working document  -- then --  Report / rubric layer
        |
        optional delivery
        then
Trusted host config  -- then --  Delivery path / downstream workflows

That last step is load-bearing. A visible form without a working delivery path is not a finished product. Field use taught us that the hard way.

Decisions and tradeoffs

Every “nice” property has a cost. Builders should choose with eyes open.

Local drafts and portable backups.

  • Benefit: offline continuity and the ability to keep working when the network is flaky.
  • Cost: device burden, backup habits, and sync complexity.

Incomplete work stays saveable.

  • Benefit: progress is preserved; people can leave and return.
  • Cost: partial state is harder to reason about than “submit once.”

Conditional answers are preserved; reports use active content.

  • Benefit: honesty about what was asked, even when questions were hidden later.
  • Cost: the report is not a full dump of every possible branch — readers see the active path.

Explicit conflict handling.

Benefit: safer merges when copies diverge.

Cost: more friction in the user experience.

Explainable calculations stay separate from human findings.

Benefit: auditability — you can see what the machine scored versus what a person concluded.

Cost: two layers to maintain and explain.

Trusted host configuration controls sending.

Benefit: safer delivery — the form itself cannot quietly invent a send path.

Cost: delivery is only as good as the host setup and human acceptance of the result.

Our environment

  • Staging leaves Turnstile off on purpose (that adds deploy friction).
  • Production has Turnstile working. That is an intentional tradeoff, not a forgotten setup — and it is separate from whether any one form is live.

What actual use taught us

Field use beats design intent. Three lessons load this case study.

Transparent rubrics

On Vendor AI and Shadow AI assessment-style forms, optional local rubrics make calculations explainable while human findings stay human. Unanswered items keep an assessment incomplete.

The machine can score in the browser. The person still owns the judgment and written findings. Shadow AI records a manual scan. It does not claim to automate discovery.

Visible form is not working delivery

Intake taught a hard lesson. A form can look complete on screen and still have no working submission path. There was no adapter (the connector into the backend) and no backend intake endpoint. Submit was useless.

Later work added protected review and send. A Worker — a small server program that handles the send step — was promoted to production. The live form reaches the review step and a Cloudflare human checkbox. Empty submissions correctly fail.

Human acceptance of end-to-end receipt is still pending. A synthetic send with confirmed inbox receipt has not closed that loop yet.

Lesson for builders: ship the delivery path, not only the UI. Closing one fence later does not erase the habit — host setup and a human receipt check still matter for other forms that send.

Blank never means Pass

Game-test and testing-workflow forms taught another habit. Prefer one conditional form with a device selector, editable device defaults, and partial results. Supporting results include Blocked and Not tested. Email reports put failures and blockers first. Blank never means Pass. An unanswered check is not a green light. It is unfinished evidence.

What we can honestly claim today

Honesty here means separating layers of truth:

  • Source implementation is not the same as consumer integration
  • Staging is not the same as production
  • An automated pass is not the same as human acceptance

Limits we can name from current evidence:

  • Browser-local storage has real limits. Do not treat a device draft as a full backup strategy. Clearing site data can lose local drafts.
  • Format compatibility is still experimental in places. Plan for migration work.
  • Repetition support is whatever we have actually shipped — do not assume unlimited nested repeats. Using JSON and YAML means we are limited only by memory or repetition. We might want to impose a limit for safety.
  • Email-service acceptance (including simulated Worker acceptance) is not the same as confirmed inbox receipt. Note: This has been true about email workflows since the beginning of email.
  • A staging keyless environment does not support review/send and has sent no email. Staging leaves Turnstile off on purpose; that friction is real. Do not treat staging “form works” as production delivery proof. Production Turnstile working does not, by itself, prove any one form is live end-to-end.
  • Ideas/Feedback is still a design and Verification record — not a live production claim.

What comes next — use now and where headed

Use now (builders)

  • Prefer Bespoke Forms for form-entry jobs the engine can already handle.
  • Design for portable documents, local drafts, and an explicit delivery path.
  • Treat explainable rubrics and Blank never means Pass as defaults for assessment-style forms.
  • Remember: “use now” is not the same as “intake is proven end-to-end.” Delivery still needs trusted host setup and a human receipt check where send matters.

Where headed (direction, next, then expand)

True north (direction): chat is not suited for many use cases. We — and others exploring the same problem — are looking at an alternate for certain ones. That is not “chat is obsolete,” and it is not “forms everywhere.”

This is not general-purpose. It is meant for bespoke workflows — not “sit down and type a prompt.”

Figuring out what the prompts and questions should be often does not need a big model. Sometimes the work must look up enterprise information that should never go to the cloud. Those are observations about the problem shape — not a claim that we already ship a local lookup stack.

LoopUX is our working name for cutting data-entry friction with smart forms instead of chat when that makes sense. GenAI may help fill or guide those forms; it is optional aid, not the thesis.

The form stays separate: it collects structured input and builds the prompt (or other handoff) for the next stage in the pipeline — not the whole product.

Intended shape of that handoff: pick up the form, generate the prompt, then redact anything private before it goes onward — especially before anything that would leave for the cloud. That is how the stages separate, and it keeps human judgment on what stays private. It is direction for the pipe, not a claim that redaction already ships everywhere.

Next (concrete bet): build an engine that consumes a bespoke form and produces meaningful output and decisions.

Then expand where form entry fits, as capability and evidence grow — into downstream workflows that are automated and manual, with AI among them, not exclusive to AI. Easier authoring and validation, clearer compatibility and migration, and wider browser coverage stay on the path. An article-to-useful-action path is a proposed Library experiment, not a shipped Forms capability.

Deferred ideas are not promises. Soft “where it fits / expand as we go” is direction for this team document — not a claim that coverage is already everywhere. True north does not soften the fences above: intake end-to-end receipt is still pending; Ideas/Feedback is still Verification-only; Kirby is not deployed.