Which version of the plan are we actually building?

The documents had started to multiply

The work recorded for 15 July was consolidation: major game and project bibles were brought together, with the next step being to separate current direction from older ideas.

That may not sound like a dramatic chapter in an AI startup diary. There is no launch countdown in the note. No glamorous new model. The problem is more familiar to anyone who has worked on a project for long enough: several documents can each look official while disagreeing about what happens next.

The day's bottleneck was a large design scope without external validation. There was plenty of material to organise, but the amount of material did not establish whether the proposed product would work for someone outside the project.

So this was a day about making the inside more legible while remembering that the outside still had questions. A project bible can be useful. It cannot interview a customer merely by becoming longer.

A bible needs to know its limits

In a creative or technical project, a bible is a reference: the agreed world, rules, direction, or structure that later work should respect. It saves people from deciding the same things repeatedly.

It also acquires an unfortunate superpower. Once a statement is written with enough confidence and surrounded by enough other statements, it can begin to feel settled even when it is only a proposal.

Looking back, that is the distinction this consolidation needed to protect. Some material described the active project. Some belonged to earlier thinking. Some remained an idea worth investigating. Putting it all in one place would only help if those differences survived the move.

Imagine a fictional game brief that once called for a single-player experience and later explored cooperative play. Both documents might contain useful thinking. An implementation assistant should not quietly combine them into a hybrid merely because both appeared in its context. Someone needs to decide which direction currently applies.

The same issue appears in business workflows, just with less entertaining scenery.

Old ideas are not automatically bad ideas

Separating current work from legacy material is easy to describe as cleaning up. That description misses something important: older ideas often contain the reasoning that explains why the current direction exists.

A discarded approach may preserve a useful warning. A previous version may contain an assumption that was later challenged. A design that is wrong for the present might still be relevant to another project.

The practical question is therefore not whether every old document should disappear. It is whether a reader can understand its status. Is it the plan to follow, a historical reference, an unresolved alternative, or an archived experiment?

That is especially useful when AI is involved. The assistant does not necessarily know that a polished old document has been superseded by a less polished recent decision. If both arrive as undifferentiated text, the old version can regain influence simply because it explains itself more fluently.

The work recorded today was about consolidation and clearer authority. It did not require pretending that the project had always moved in a straight line.

When context becomes a burden

More context sounds like an obvious advantage. Give the assistant the entire project, and surely it will make a better decision.

Sometimes it will. Sometimes the extra material introduces several competing versions of the same instruction and makes the important distinction harder to find.

A useful reference collection helps the reader locate what matters for the current task. If the task concerns the present product direction, the current decision should be easy to identify. If the task concerns why an earlier approach was abandoned, the history should remain available without masquerading as today's instruction.

This is a practical design issue rather than a demand for minimalism at all costs. A short document can be incomplete. A long document can be excellent. The difficulty is asking a reader to infer status from length, tone or location.

For UBIKITOS, the intended benefit of consolidation was to reduce that guessing. The work needed a clearer relationship between its records and its next actions, not simply a larger container for all the records.

A helpful test for a reference document

One way to assess a project bible is to imagine giving it to someone who was absent from the last several conversations. Could they answer the questions that matter before starting work?

What are we trying to achieve? Which parts are decided? What can change? Where is the unresolved question? What would make the proposed work acceptable?

Those are not tests documented as completed on this date. They are a useful retrospective way to explain why the task mattered. Consolidation is valuable when it helps a new reader make fewer incorrect assumptions.

For example, a hypothetical instruction to “build the dashboard” can conceal many decisions. Is it an illustration, a read-only view, or a working control panel? Which data is real? Which actions are available? A reference that settles those questions is doing work. One that merely repeats “dashboard” in several sections is asking the implementer to supply the missing product decisions.

Clear references reduce the amount of invisible design happening inside an apparently straightforward request.

The product still had to meet the world

The day's record also makes the external-validation gap explicit. Consolidating the design did not close it.

That matters because internal coherence can be deeply persuasive. Once the components fit together on paper, the whole project begins to feel inevitable. A prospective user may still ask a much simpler question: what problem does this solve for me?

A good internal reference should make that question easier to explore. It should not become a reason to postpone it indefinitely. If an assumption about a customer is central to the plan, its status needs to remain visible as an assumption until there is evidence for it.

There is no recorded customer interview or product-market conclusion to add to 15 July. The honest account is that the project's design material became more consolidated while the commercial questions remained open.

That is a useful distinction for a founder to keep. A better-organised plan can support the next experiment; it does not get to award itself the result.

A cleaner handoff to tomorrow

The next step was to freeze the current direction and distinguish it from legacy ideas. “Freeze” here should not be read as a promise never to change anything again. It means giving the next piece of work a stable reference long enough to understand what it is implementing.

If that work reveals a mistake, the decision can change explicitly. The important part is that the change can be followed. Otherwise every session risks rebuilding the project from a slightly different set of assumptions.

The achievement on this date was consolidation. The larger ambition was a working system that could use its own context reliably. Between those two sits an ordinary but demanding discipline: make the relevant decision easy to find, and make its status hard to misunderstand.

It is not the most cinematic founder task. But if the project has several bibles, someone eventually needs to answer which one the builders should open.