This is the fourth post in Problems Cotomy Set Out to Solve. This continues from Screen Lifecycle and DOM Stability . The previous article argued that a business screen needs an explicit lifecycle and a stable working surface.
That raises the next question immediately: if the screen stays stable, what exactly is being preserved on it?
Most business UI is a loop of input, revision, validation, and submission. It is not a single event. It is sustained work. Yet form state is still treated as a temporary payload.
Cotomy treats form state as a long-lived context, because that is how business systems actually operate. Form state continuity means that user progress remains meaningful across input, validation, retry, reload, and return.
The Usual Pattern Falls Short
Typical implementations assume:
you load the screen, fill the form, submit once, and exit.
That model breaks down in real operations. Business forms are edited, paused, revisited, and corrected. Partial input and iterative validation are the norm.
In other words, the operational shape of the screen is not submit-and-leave. It is work, interruption, correction, and continuation.
The Failure Modes Are Familiar
When form state is treated as transient, these failures appear:
partial input is lost, back navigation destroys work in progress, validation errors reset unrelated fields, revisions after errors become fragile, and long edits accumulate inconsistencies.
The form state is not just a set of values. It is a working context that changes over time.
That context includes more than raw input values. It also includes what has already been loaded, which fields depend on each other, which corrections are still in progress, and what the user currently understands the screen to mean.
Event vs. Continuity
The difference is not technical. It is structural.
An event model assumes momentary submission, while a continuity model assumes long-lived interaction.
Business systems require the second model.
This follows directly from the previous article. A stable screen lifecycle is the condition that makes continuity possible. Form state is the content that continuity is preserving.
Why This Matters in Business UI
Inputs can take minutes or longer. Users pause, switch tasks, and resume. Fields depend on each other. Corrections are common. The UI must preserve continuity over re-render.
Form state is a sustained working context, not a transient event payload. Because that context belongs to an ongoing business operation, continuity must be preserved across interaction, validation, and retry.
Cotomy treats form state as a sustained working context bound to DOM rather than a transient payload. This aligns with Cotomy’s design where the DOM is the source of truth and runtime behavior provides lifecycle structure such as scoped style handling and removal observation, while keeping form state on the DOM side (see Cotomy Reference – Forms Basics ).
That design choice matters because it avoids introducing a second hidden source of truth for ordinary form work. Inputs stay where the user already sees them, while the runtime standardizes submit flow around that state instead of moving the state into a separate store by default.
Why This Is a Design Problem
This goes beyond UX polish, validation logic, or convenience layers. It is about structural consistency for long-lived UI state.
Seen more precisely, it is a question of guarantees.
The input continuity guarantee means a user’s in-progress values remain part of the same working context. The validation continuity guarantee means error handling should not silently redefine unrelated state. The return continuity guarantee means that when a page is restored or reloaded through the intended lifecycle path, the form can be brought back into a coherent operational state instead of becoming a detached snapshot.
Cotomy’s Position (Without Implementation Detail)
Cotomy treats form state as DOM state. State must survive user delay and navigation. The runtime provides structural safety and lifecycle consistency. Screens declare state. The runtime manages continuity around that state.
In practical terms, CotomyForm standardizes submit handling without replacing the DOM as the place where field state lives. CotomyEntityFillApiForm can load and refill form inputs on ready timing, and registered forms can participate in page restore flow through CotomyPageController. That is enough to give form state a lifecycle-aware structure without turning Cotomy into a global state store.
Problem Series
This article is part of the Cotomy Problem Series, which examines recurring structural failures in business UI design.
Series articles: HTML and CSS as One Unit , Form Submission as Runtime , Screen Lifecycle and DOM Stability , Form State and Long-Lived Interaction, API Protocols for Business Operations , Runtime Boundaries and Operational Safety , UI Intent and Business Authority , and Binding Entity Screens to UI and Database Safely .
