The waterpark test: could the work continue without me?

A different sort of progress report

On 4 August, I spent the day at a waterpark and checked in through WhatsApp while Hermes continued working on the system.

The ordinary detail is the point. I was somewhere other than the workbench, and work continued. There were no spectacular business results to attach to the outing. What made it memorable was the possibility of stepping away from the machine without every piece of work stopping beside it.

For a project concerned with AI-supported operations, that is a more human question than how impressive an architecture diagram looks. Can useful work move while the person building the system is doing something else?

The day's note records a promising answer within a limited scope. It also records unfinished work. Phases F and G had been merged, while the next phase remained incomplete. No revenue was generated. This was a day about the possibility of returning time, not the arrival of a company that could take care of everything itself.

The phone was still part of the picture

The WhatsApp check-ins matter because they keep the story honest. I had not vanished from the process entirely. There was still a founder checking in, and there was still work whose direction and acceptance needed attention.

That makes the episode more interesting, not less. In real use, the useful question is often how much supervision a workflow needs and when it needs it. The answer does not have to be either constant involvement or complete absence.

A system that can continue a clearly defined task and return a useful update may already change the shape of a day. A system that produces a stream of ambiguous messages can simply move the work onto a smaller screen.

The record does not measure the time I saved or count every intervention. It provides an anecdote about continued progress while I was away. I would not turn that into a productivity percentage. I would use it to identify what deserves measuring next: whether the work genuinely reduces the attention needed from the person it is meant to help.

The work had not become magically finished

The engineering side of the note is specific enough to prevent a fairy-tale ending. Two phases had merged. The next phase had policy foundations and a self-audit, but it was still only partly complete.

That remaining work included the sort of responsibilities that make an operating system dependable: resilience, provenance, recovery, reporting and independent review. These were not decorative extras to add after the interesting part. They shaped whether later work could be trusted.

There was also a defined dossier pipeline in the record. A defined pipeline and a fully accepted operating process are different stages. Today did not erase that distinction just because the founder happened to be away from the desk.

This is one reason I like the waterpark episode as a journal entry. It can hold two truths without forcing one to cancel the other. The continued work was encouraging. The system was unfinished. A useful account of a startup should be able to say both in the same paragraph.

Returning time is a demanding promise

“Give people their time back” is easy to put on a website. The hard part is deciding what counts as giving it back.

If an automated process completes a task but leaves the user with a confusing result, the saved time may disappear during review. If it creates an error that takes an afternoon to repair, a fast first response was not the whole story. If the user has to monitor every step, the task may have changed shape without moving very far away from them.

Those are hypothetical situations, not incidents recorded at the waterpark. They explain why the underlying ambition needs careful evaluation.

A useful workflow should reduce the right burden while making its outcome understandable. It should know when to keep going within the agreed scope and when to ask for a decision. It should leave the human with meaningful control rather than the job of continuously guessing what the machine has done.

Today supplied a small, personal reason to care about that distinction.

The most useful update is not the longest one

Checking work through a phone introduces a practical constraint: the update has to help someone understand the situation without reconstructing the entire project.

Looking back, a good remote update would answer a few simple questions. What changed? What was checked? What still needs a decision? Is there a problem that requires attention now, or can it wait?

A lengthy report can contain all of those answers and still make them difficult to find. A very short message can be equally unhelpful if it says only “done.” The useful unit is the decision the person needs to make.

The historical note does not preserve every WhatsApp exchange from the day, so there is no dialogue to recreate here. The check-ins themselves are enough to show the design pressure. If UBIKITOS is going to support work beyond a founder sitting in front of a terminal, it needs to communicate in a way that respects the person's context as well as the task's complexity.

Away from the desk is not away from responsibility

The appeal of delegated work is obvious. The responsibility does not disappear with it.

A system continuing an approved task should not interpret the user's absence as permission to expand its remit. A process that encounters a new consequential decision needs a clear way to surface it. A result still needs an appropriate basis for acceptance.

For UBIKITOS, this is where the larger purpose becomes concrete. The goal is useful autonomy with human accountability. That can include work proceeding without repeated nudges, while preserving decisions that require a person.

The day did not prove the entire model of operation. It gave the project a lived example of the benefit it was trying to make dependable. The next challenge was to reproduce useful continuation under clear conditions and understand how much supervision it actually required.

A waterpark visit is a good story. A repeatable workflow needs more than one good story. The ambition is to connect the two without pretending they are already the same thing.

What I wanted the next step to earn

The recorded next action was to finish the remaining phase without weakening its requirements, then use DemiPage as the first real company workflow through the governed loop.

That was a plan for what came next, not a claim that the operating proof was already complete. It provided a practical direction for the promise suggested by the day: turn continued background work into a result that could be checked from beginning to end.

Looking back, the most memorable part of 4 August is still the contrast between a very technical project and a very ordinary human benefit. There were phases, policies, dossiers and unfinished requirements in the record. There was also a day away from the desk.

The latter is why the former should matter. If the system eventually becomes dependable, the payoff should not only be a more impressive report about how much it did. It should be room for a person to do something else with their day.

Today offered a glimpse of that possibility, with the check-ins and unfinished work still visible around it.