R4 is learning to carry the work through.
Explore UBIKITOS R4 development: autonomous AI workflow supervision, signed authorization, recoverable execution and the evidence required before R5.
Read the story ↗The founder’s workbench / UBIKITOS
Behind
the builder.
Building UBIKITOS, one day at a time. The decisions, the experiments, the things that broke—and the work of coming back to them.
A few days worth starting with
The work gets interesting here.
A WorkMachine needs to know when its memory is wrong.
How UBIKITOS R3.9.6 handles stale and contradicted knowledge, what the R3.8 audit checked, and why product integration remains a separate milestone.
Read the story ↗The website is the hook. The pilot has to do the work.
UBIKITOS refined a publisher pilot around existing tools, human approval and traceable outcomes. A smaller first campaign made the delivery and model choices concrete.
Read the story ↗A founder’s diary of building UBIKITOS: experiments, wrong turns, small victories, and the questions that keep the work moving. Each date marks the day in the story.
October 2026
R4 is learning to carry the work through.
R3 is live. R4 has moved from individual control-plane components into the harder work of native integration: authority, execution, evidence and recovery in one bounded route.
Read this day ↗A portfolio review made the next proof clearer.
The portfolio reconciliation separated planning status, artifact quality and operational acceptance, with R4’s bounded native trial still the next technical proof.
Read this day ↗The conversation moved beyond the workbench.
A Boomi discovery meeting and tailored partner brief opened a vendor discussion while customer proof and native R4 acceptance stayed separate.
Read this day ↗A key identifies the worker. It does not authorize the work.
R4 route-key enrollment, Learn V2 product changes and a publisher audit made the next operational decisions concrete.
Read this day ↗The next chapter was integration.
R4 shifted from adding components to wiring guarded execution into the actual loop, while Capital tested its reporting against controlled tournament records.
Read this day ↗The control plane learned to govern its surroundings.
R4’s local environment and authority work advanced while Capital and the jazz manuscript remained preparation candidates.
Read this day ↗More autonomy needs a better brake.
R4 advanced through continuation, replanning, scheduling and budgets; assurance work showed why scoped tests and release acceptance remain separate.
Read this day ↗Memory got its tests. Missions got their contract.
R3.9 advanced through compression, negative transfer and memory defenses while R4.1.1 began bounded mission-contract work.
Read this day ↗A WorkMachine needs to know when its memory is wrong.
R3.9.6 brought contradiction and forgetting into UBIKITOS. The day connected a sharper memory system, a mathematical audit and the practical work of learning and publishing.
Read this day ↗The website is the hook. The pilot has to do the work.
UBIKITOS refined a publisher pilot around existing tools, human approval and traceable outcomes. A smaller first campaign made the delivery and model choices concrete.
Read this day ↗The machine needed to know when it knew something.
R3.8.8 packaging and roadmap naming sharpened the WorkMachine story. Temporal memory asks what information was available when a decision was made.
Read this day ↗September 2026
A candidate could speak. It still could not give itself authority.
R3.8.5 gained a locally tested implementation for isolating candidate output. The engineering work kept evaluation, instructions and promotion authority separate.
Read this day ↗The server was full. The handbook was supposed to help.
An engineering handbook and technical atlas made UBIKITOS easier to inspect. A full VPS exposed why knowledge sync, recovery and authentication need bounded checks.
Read this day ↗One hundred puzzles. Still a few things between a manuscript and a book.
Downbeat & Across reached a complete hundred-puzzle manuscript. Print layout, checking and KDP economics revealed the next gates between creation and publication.
Read this day ↗A backup percentage became useful when something could be restored.
Cantera’s installed baseline stayed intact while a new candidate passed fifteen checks. Recovery work paired backup coverage with rollback and restore evidence.
Read this day ↗The architecture got clearer when I stopped worshipping the harness.
A recovery inventory and two architecture studies clarified UBIKITOS: preserve mission, authority and evidence while keeping the execution harness replaceable.
Read this day ↗A busy week still needed an honest scoreboard.
UBIKITOS had a redesigned website, UBI and substantial engineering work. The weekly review asked which completions were verified—and what customer feedback exposed.
Read this day ↗A proposal became something someone else could read.
A publisher proposal brought UBIKITOS closer to a real workflow. Twelve modules, a delivery plan and a questionnaire turned broad ambition into a buyer discussion.
Read this day ↗Thirty seconds of personality. Then UBI had to answer a question.
UBI needed thirty seconds of fluid personality and a chatbot that answered well. The UBIKITOS build connected visual ambition to cost, speed, and useful interaction.
Read this day ↗“Done 100%.” Then why is it not active?
I asked why completed UBIKITOS milestones were not connected. The answer separated working components from activation and defined the need for one control centre.
Read this day ↗A copy is not a connection
The UBIKITOS Galaxy made stored knowledge easier to explore. Later changes still needed an update path; motion on the screen did not make the sources live.
Read this day ↗Make the knowledge look like a galaxy. Then count the stars.
A founder wanted his second brain to feel like a galaxy. The useful result still depended on which notes were included, what links meant, and what stayed unconnected.
Read this day ↗Can the control centre admit it does not know?
An unresolved UBIKITOS result raised a product question: can the control centre distinguish unknown, proposed, tested, and active without confusing the founder?
Read this day ↗A percentage without its denominator is half a story
UBIKITOS still needed the exact experiment artifact. Denominators, baselines, resource use, and evaluation rules explain why a headline number cannot replace it.
Read this day ↗The next conversation should not need my whole memory
The missing-result search exposed a continuity problem for UBIKITOS: the next session needs the exact evidence, accepted corrections, and a clear unfinished task.
Read this day ↗Close is not the same as found
A connected search still lacked the exact UBIKITOS result. Similar reports were useful leads, but could not supply the missing experiment’s metrics or verdict.
Read this day ↗I knew the result existed. We still needed the result.
I confirmed a UBIKITOS result existed, but its exact artifact was still missing. Respecting that account and checking its scientific meaning were compatible tasks.
Read this day ↗Can one company hold all these ideas?
I asked whether one company could hold several software directions. UBIKITOS needed a clear offer and workable focus without losing the broader creative ambition.
Read this day ↗Five days without AI credits. Plenty of unfinished business.
Five days of limited AI access made continuity urgent. The UBIKITOS diary follows unfinished work, handoff preparation, and an experiment result still to recover.
Read this day ↗The experiment did not owe me a happy ending
The UBIKITOS development comparison tied on success while using more tokens and weakening recovery. The next decision needed the actual result, not a happier story.
Read this day ↗The report does not owe us a celebration
The UBIKITOS checkpoint stayed unchanged. A useful founder update should clarify the next missing proof rather than find a more exciting reading of old evidence.
Read this day ↗The morning after a substantial change
UBIKITOS carried a substantial technical result forward while independent operation, provider checks, and customer proof remained separate next questions.
Read this day ↗“Done” needed a witness
UBIKITOS connected attempted actions to independently checked outcomes. Audited components and approval setup advanced without expanding production authority.
Read this day ↗Before trying again, find out whether it happened
UBIKITOS strengthened bounded recovery after uncertain actions. A fresh attempt required evidence of no prior effect, with broader remote guarantees still unproven.
Read this day ↗A lesson finally had to survive until the next job
UBIKITOS linked validated experience, restart-safe knowledge, and bounded later improvement. Independent reproduction and wider performance claims remained open.
Read this day ↗The better score came with an asterisk worth reading
A fairer UBIKITOS development comparison showed a recovery signal, higher token use, and grounding problems. The promising score still needed a better next test.
Read this day ↗UBI was supposed to be a mascot. Why was it an egg?
The UBIKITOS mascot kept looking like an egg. A founder’s account of faces, lava-lamp motion, Blender errors, and the search for a glossy black character.
Read this day ↗The dashboard was telling two different stories
UBIKITOS repaired conflicting workload views and kept an old estimate historical. Current work shares still needed measurement rather than a more confident chart.
Read this day ↗The project moved. The status report had not.
UBIKITOS’s bootstrap closure and bounded self-prompting pass corrected an outdated hold. The next question was how that progress could help an external workflow.
Read this day ↗The timestamp changed. The capability did not.
A new UBIKITOS review returned the previous accepted state. Source age, review time, and actual activation needed to stay distinct in the founder’s dashboard.
Read this day ↗A new month is not a new version
September began with UBIKITOS’s accepted state unchanged. The next release, research, or customer result still had to earn its own evidence beyond a fresh date.
Read this day ↗August 2026
August: beach days, midnight builds, unfinished business
A month of UBIKITOS experiments, recovery work, and unfinished questions, including beach time with my son and a midnight-to-four-a.m. window for building.
Read this day ↗The customer column was still empty
Technical progress had not yet become customer evidence for UBIKITOS. A reflection on focused pilots, clear offers, and the value of an honestly empty sales column.
Read this day ↗A day without a breakthrough still belongs in the diary
UBIKITOS carried its accepted state forward with key evidence still pending. A founder diary needs room for useful continuity without manufacturing a new milestone.
Read this day ↗Do I need another dashboard, or a clearer next action?
A coordinating agent and hub design promised clearer control of UBIKITOS. The next test was whether the surface could reduce uncertainty rather than add a screen.
Read this day ↗What if the clever part already exists?
Prior work narrowed the UBIKITOS research frontier. A smaller unresolved question, a strategic roadmap, and external evaluation setup each needed distinct proof.
Read this day ↗We built a team whose job was to disagree
UBIKITOS added executable adversarial assurance and separated probing, proposed repairs, and judgement. Stronger checks did not automatically certify the release.
Read this day ↗The forecast was ready. Reality had not replied yet.
UBIKITOS produced a prospective forecast with a recorded cutoff and unresolved outcome. The interesting question was what the process proved before reality replied.
Read this day ↗The day the proof needed proof
Adversarial testing exposed an integrity weakness in UBIKITOS. The next sequence was repair, renewed checks, and a controlled test of learning in a later run.
Read this day ↗It was written in three places. Could we read it back?
UBIKITOS read back saved work across three destinations. The result strengthened persistence evidence while release review and research permissions stayed separate.
Read this day ↗A customer needs an answer, not our entire architecture
The beach-period build ended with acquisition design: opportunity briefs and focused chatbot sessions. UBIKITOS still needed one real customer experiment.
Read this day ↗The proof needs to survive a change of address
UBIKITOS made evidence storage configurable and corrected a dependency reference. The next proof had to survive a different destination, failure, and restart.
Read this day ↗Saved is not the same as allowed
A UBIKITOS merge tightened task identity and evidence custody. Duplicate requests, concurrent workers, and restarts still needed their post-merge verification.
Read this day ↗The receipts kept coming. What did they buy us?
During the beach-period build, UBIKITOS preserved a growing trail of work. The next question was whether those records made actual outcomes easier to understand.
Read this day ↗Nine gates closed. The tenth still mattered.
Nine UBIKITOS gates were certified offline, with independent agreement on the latest. The tenth remained unwired, so a nearly finished checklist was not a launch.
Read this day ↗A cockpit is only as useful as its instruments
UBIKITOS strengthened provider-failure handling and added a guarded live cockpit. The interface improved while independent launch checks still remained open.
Read this day ↗The beach, the midnight window, and a map with too many possibilities
With work limited to midnight–four a.m., UBIKITOS locked a baseline and mapped future experiments. The challenge was choosing one path without opening every branch.
Read this day ↗Restarting the process without repeating the consequences
Crash-and-resume work gave UBIKITOS a harder question than restarting code: how to preserve what happened and continue correctly after an interrupted workflow.
Read this day ↗The migration worked differently. That was the problem.
UBIKITOS found validation drift during migration, recorded a first execution, and kept broader launch limits intact. Progress crossed specific boundaries, carefully.
Read this day ↗A version number is not a passport
During the beach-period build, UBIKITOS clarified release scope and runtime identity. A version number needed to describe the tested system, not imply readiness.
Read this day ↗The test passes. Then the outside world joins in.
UBIKITOS separated repeatable local checks from live-provider tests. The distinction made failures easier to understand during a limited midnight work window.
Read this day ↗The launch mistake that deserved to stay in the instructions
An invalid launch configuration became a specific lesson for UBIKITOS. The beach-period build needed the next attempt to benefit from the failure, not repeat it.
Read this day ↗A mission that did not need another “continue”
A bounded UBIKITOS mission continued without founder prompts. During a beach trip and a narrow overnight work window, that was a particularly practical result.
Read this day ↗The system was busy. Was the mission moving?
UBIKITOS kept producing records during the beach-period build. The useful question was whether those receipts showed completed missions or simply more activity.
Read this day ↗Finish one experiment. Try not to start five more.
During a beach trip with my son, UBIKITOS work fit between midnight and four a.m. Several experiments advanced, making focus and reusable lessons more important.
Read this day ↗An AI tournament needs more than a scoreboard
Beach time with my son left a midnight work window. UBIKITOS gained a tournament board, while fair experiment identity and real-world proof still needed work.
Read this day ↗Which version is allowed to give instructions?
UBIKITOS brought governance and brand libraries together. The next test was whether a live workflow would follow current authority and close the whole goal.
Read this day ↗How much work actually left my desk?
UBIKITOS created a human-versus-system workload baseline. The challenge was separating forecasts, hidden supervision, and actual evidence of work transferred.
Read this day ↗The waterpark test: could the work continue without me?
A waterpark day gave UBIKITOS a practical autonomy question: could useful work continue without constant prompting, and what would count as proof that it did?
Read this day ↗A gap in the record stays a gap.
The recovered founder scorecard has no entry for 3 August. This archival note preserves the chronology without inventing work.
Read this day ↗A huge day of building. Also, a focus problem.
Hundreds of checks, brand assets, and several workstreams advanced UBIKITOS. The unfinished end-to-end loop showed why more output still needed a clearer priority.
Read this day ↗The assistant took the wrong bridge
A parked bridge concept was mistaken for UBIKITOS’s active integration route. The correction kept the next work focused on one live mission and verified write-back.
Read this day ↗July 2026
Sixty-seven steps. Please do not add step sixty-eight.
Sixty-seven steps and eleven agents gave UBIKITOS an execution queue. The most useful instruction was smaller: finish the next steps before adding anything else.
Read this day ↗The portfolio finally had a control centre
The UBIKITOS portfolio gained a control centre. The next challenge was making its view of projects, priorities, and unfinished work useful for daily decisions.
Read this day ↗Thirty tests, a model connection, and an unfinished journey
Passing checks and a model connection marked progress for UBIKITOS. The full workflow still needed proof that its pieces could complete a useful job together.
Read this day ↗Before adding another agent, give the existing ones a skill
Before adding another AI agent, UBIKITOS needed reusable skills and clearer execution. A founder’s account of making existing workers more useful and consistent.
Read this day ↗Who should get the next job?
Assigning work is more than picking an agent. UBIKITOS explored how capability, context, and responsibility should shape the route from request to result.
Read this day ↗Customer Zero was a way to make the idea answer back
Using the founder’s own work as Customer Zero gave UBIKITOS a concrete test. The goal was a useful outcome, with limits on what an internal trial could prove.
Read this day ↗The internet was not going to arrive in a neat input box
The internet does not arrive as clean input. UBIKITOS research work confronted uneven sources, retrieval limits, and the need to check what an answer rests on.
Read this day ↗The stack was growing. The first workflow needed a floor.
The software stack was expanding, but the first workflow needed dependable foundations. A founder’s look at turning promising components into a complete job.
Read this day ↗A register for the registers? Time to follow one job.
More tracking does not always make work clearer. UBIKITOS needed to follow one real task through the system and connect its records to a useful outcome.
Read this day ↗The audit said keep going. It also said make it smaller.
The UBIKITOS audit supported continuing with a narrower scope. A founder’s account of unfinished loops, misleading completion, and a more practical next test.
Read this day ↗Twelve hours is a long time to chase one research loop
A long UBIKITOS research session exposed the gap between continuing activity and a finished loop. What the effort revealed, and why the next scope had to shrink.
Read this day ↗Giving the AI a job title was the easy part
Giving AI agents job titles was easy. UBIKITOS needed clearer decisions, responsibilities, and checks before an organisation chart could become useful work.
Read this day ↗Everything cannot be the flagship
Games, tools, and an AI company all compete for attention. Inside the UBIKITOS effort to organise a creative portfolio without making every project priority one.
Read this day ↗The business plan was complete. The business had questions.
The UBIKITOS business plan was written; its assumptions still needed testing. A founder’s look at the distance between a documented model and a useful pilot.
Read this day ↗A ninety-day roadmap still needs a first useful promise
A ninety-day roadmap gave UBIKITOS direction. The harder founder task was choosing one understandable customer promise from a much broader product ambition.
Read this day ↗The boxes on the diagram still needed to do a job
An ambitious AI architecture still needs to complete a useful job. Inside the UBIKITOS work to connect roles, responsibilities, and bounded execution.
Read this day ↗Which version of the plan are we actually building?
Consolidating UBIKITOS project plans raised a deceptively simple question: which version should guide the next task, and which ideas belong in the archive?
Read this day ↗A company starts somewhere. Mine started with too many ideas.
UBIKITOS began with more ideas than focus. A founder’s first step toward choosing one flagship, defining the work, and turning creative ambition into a company.
Read this day ↗