From an Empty Schedule to the First Plan in Flowo

The request and the draft

Flowo builds the first plan from a description of between 1 and 4000 characters. The request to our backend carries that text together with the app locale and the device time zone. The response is a draft with these parts.

• Day schedules with sleep, meals and rest.
• Productive hours.
• Categories, optionally with weekly availability and reserved hours.
• Flexible habits with a count per period and a session length.
• Fixed weekly events and one-off events with a date.
• Tasks with a deadline.
• Clarifying questions and warnings.

The client does not accept the draft as written. The model is asked to mark a need as fixed only when there is an outside constraint, and we treat that mark as advisory: the client converts needs into preferences and turns broad recurring areas into categories. A validator then checks the result for problems such as a schedule with no sleep, overlapping category windows, or a window shorter than its own duration.

A valid draft with questions opens the question cards. A valid draft without questions opens the review.

What happens when generation fails

Flowo has a defined outcome for each way generation can fail, and none of them ends onboarding.

• An empty description keeps the person on the input screen with a message. An earlier build moved on to a review of untouched defaults, which read as a finished plan.
• An invalid draft from the service is replaced by a draft built from the stored settings, and the review opens on that.
• A network failure or an exhausted quota returns the person to the description screen with the text intact and an error line. The same locally built draft is ready behind it.

The client waits up to 60 seconds for a response. When the stored settings contain no night at all, the builder substitutes a 23:00 to 07:00 sleep window of 480 minutes, because a draft without sleep cannot pass validation. The review then states that substitution in a section of its own, with a first-person line that begins 'Set the night to'.

The question-card path does not call the service. It starts from the same local draft and applies the answers to it. Its busy-time card produces a work category with 09:00 to 18:00 on each chosen day and with those hours reserved, so other tasks are not placed inside them.

Review and correction in words

The review screen in Flowo shows the draft as read-only rows, and corrections are made in a sentence. Under the draft is a field that asks what should change. The app sends the current plan and the sentence, and the model returns the whole plan with that change applied.

The corrected plan passes the same conversion and validation as the first one. If the correction request fails, the draft that was on screen stays and the error is shown beside it.

The apply button is enabled only while the draft is valid. Editing a row directly, for example changing a habit into an event with a tap, is postponed until it has a design.

Applying writes data and scheduling makes it visible

Applying a draft in Flowo is two separate operations, and the first one puts nothing on the calendar. The apply step takes a snapshot of the settings and of the planner's weight matrix, writes the new settings and categories, and seeds the matrix. If any of that throws, both snapshots are restored. Habits, tasks and events are created afterwards, each kind in its own guarded block, so a failed habit does not cost the person the week they described.

At that point a fixed weekly event is only a repeat rule and a flexible habit is only a quota. For a while this was a defect: everything the person had described sat in storage until they happened to edit something.

The fix is a callback that runs after the apply returns. It does two things in a fixed order.

1. 1.The series engine materialises the occurrences of every fixed event.
2. 2.The planner simulates a schedule around those blocks with the freeze horizon released, and the result is committed.

The order matters because the planner has to work around the fixed blocks. The freeze horizon normally keeps anything starting within two hours in place. We release it here because this replan is the person's own doing.

Two smaller rules shape the first plan. A habit created by onboarding after noon starts tomorrow, since an exercise session placed two hours after sign-up was a plan nobody asked for. And preferred hours stated for a new habit or category are credited with 10 confirmed sessions in the weight matrix. Trust in the matrix is the session count divided by 50, so the seed starts at 0.2 and the stated hours influence the very first placement. Without the seed the starting trust is 0.

One task of the person's own

After the plan is applied, Flowo asks for one task before showing the result. The saved plan is only the shape of a week. A week that contains sleep, meals and work hours has nothing in it that the person came to get done.

The screen is titled 'One thing for this week' and has one text field. If the description already named tasks or one-off events, they are listed under 'Already in your week' and the prompt changes to ask for anything else. A 'Later' button moves on with nothing created.

The task goes through the ordinary creation path. It gets an estimate of one hour and a deadline of 23:59 on the seventh day counting today. Scheduling is awaited before the next screen opens. If the planning pass fails, the task is still saved and the next pass places it.

The first screen shows the committed plan

The last onboarding screen in Flowo reads the schedule the planner actually committed. It does not render the draft. It takes today's blocks once, on entry, and draws a 24-hour bar with up to three rows beneath it: the new task first, then other things the person entered, then the structure of the day.

Late in the evening there may be no room left today. In that case the screen looks through the following days and shows the first session of the new task.

The button on that screen opens Today at the current time.