Behind the builder / 18 September 2026
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.
The missing result still could not be interpreted
September eighteenth kept the exact experiment result on hold because its artifact, metrics, and verdict were still unavailable in the connected evidence. The founder-confirmed existence of the result remained part of the record. The scientific effect remained uninterpreted. This entry uses that unchanged checkpoint to explain why the conditions around a number matter so much. Recovering a headline percentage would not necessarily be enough. The project needed the result in the form that made its meaning inspectable.
AI performance stories are full of numbers that look self-explanatory. A success rate, a gain, a reduction, a faster run. Each can be useful, and each depends on a question hiding underneath: success at what, compared with which baseline, using which resources, under which conditions? The number is a compact representation of those choices. If the choices disappear, the reader may reasonably give the number a broader meaning than the experiment supports. UBIKITOS needed to avoid that mistake while waiting for the exact evidence.
Start with what was counted
The denominator tells us what the percentage is a percentage of. Tasks, attempts, subtasks, or selected cases can produce different interpretations. A system might complete most easy cases and struggle on the few consequential ones. An aggregate can conceal that distribution. The useful report should make the unit of measurement clear and preserve the task families that matter to the claim. Otherwise, the number becomes difficult to connect to the work a user actually wants done.
The earlier development comparisons in this diary illustrate why distribution matters without supplying the missing result. One run showed a promising recovery signal alongside a grounding regression and greater resource use. That was a mixed development outcome, not a universal performance verdict. The lesson is methodological: inspect where the score comes from. A later experiment must be read on its own terms. Its denominator, task set, and conditions cannot be borrowed from a nearby run simply because the project names sound related.
The baseline is part of the claim
A gain means something relative to a comparison. The baseline should therefore be identifiable and appropriate. If the baseline receives weaker instructions, less information, or different resources, the apparent improvement may not measure the intended mechanism. If the baseline is unusually strong or uses a different task interpretation, the comparison can be distorted in another direction. The point is not to demand one universal baseline. It is to understand why the chosen baseline answers the question being asked.
For a hypothetical tool-use experiment, comparing a complete governed workflow with an unrelated single response might answer a product-level question, but it would not isolate every cause of the difference. A more controlled comparison could answer a narrower mechanism question. Both designs may be useful if described honestly. Trouble begins when the conclusion switches levels after the run. A broad product comparison becomes proof of a specific causal mechanism, or a narrow mechanism result becomes a promise about the entire platform. The baseline helps define which conclusion is justified.
Cost and time belong beside success
A system can improve its success rate by spending more resources. That may be a good tradeoff for the task, but it is still a tradeoff. Token use, elapsed time, retries, and human review can affect whether an improvement is practical. A founder deciding what to build next needs those dimensions, especially when the product is intended to reduce effort. A result that requires much more supervision may not deliver the benefit suggested by a higher automatic score.
This does not mean every experiment needs to optimise every metric at once. It means the report should preserve the relevant conditions so the reader can judge the result in context. A slower but more reliable workflow could be valuable for one use. A faster but less grounded one could be unsuitable for another. The score alone cannot make that decision. The exact artifact should help explain what was measured and what was not, so a performance claim does not quietly become an efficiency claim as it moves into public language.
Development and confirmation have different jobs
A development set helps the builder learn how to improve the system. A confirmatory evaluation examines a defined claim under conditions intended to support a more independent conclusion. The distinction is important because the builder may have adapted the system in response to development failures. That adaptation is useful engineering. It also changes how much the same cases can tell us about performance beyond themselves. A result needs its evaluation role attached to it, just as it needs its task count.
The project had already kept a holdout closed while the treatment was being refined. That boundary preserved the possibility of asking a cleaner question later. The missing experiment result still needed its own exact conditions before interpretation. Its name and remembered existence could not establish whether it was confirmatory, claim-eligible, or successful. Those properties belong in the artifact and protocol. Recovering them is how the founder can turn an interesting number into a statement that remains accurate when someone asks how it was obtained.
A result can be useful without being universal
One reason people overstate metrics is the assumption that a bounded finding sounds too small. In practice, a clear local result can be highly useful. It can identify a workflow where the system helps, a failure family that needs attention, or a resource tradeoff worth testing further. The limitation does not erase the information. It tells the next experiment where to begin. A vague universal claim is often less actionable because it leaves the builder uncertain about what specifically produced the improvement.
For UBIKITOS, this is the right relationship between research and product development. The experiment should help choose a next task or support a defined capability claim. It does not need to prove the entire company in one run. Commercial usefulness, operational reliability, and scientific interpretation may each require different evidence. Keeping those questions separate makes progress easier to recognise. It also prevents a missing result in one area from being filled with an unrelated success in another simply to make the overall story feel complete.
Wait for the whole sentence
September eighteenth ended with the same retrieval requirement: recover the exact result, reconcile the records, and issue only the interpretation its evidence supports. The technical baseline remained unchanged in the accepted account, and commercial proof remained separate. The reflection explains why that patience was necessary. The missing item was not just a number; it was the context that would make the number a meaningful answer.
A percentage without its denominator is half a story. So is a gain without its baseline, a score without its task set, or a result without its evaluation role. UBIKITOS needs the whole sentence before turning an experiment into a claim. That standard can make a daily journal less dramatic while making the eventual result more valuable. When the artifact is found, it should be read for what it actually says, including the conditions that keep the conclusion honest. Until then, the blank remains more informative than a number borrowed from somewhere nearby.