Behind the builder / 26 August 2026
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.
Assurance became something executable
August twenty-sixth added an executable adversarial assurance capability to the shared code line, alongside governance improvements for the project’s Git estate. The work separated probing, comparison, proposed remediation, and judgement into distinct roles. That separation is the interesting part of the day. A system intended to check itself should not rely on one confident voice producing the work, inventing the test, and declaring the result acceptable. Useful disagreement needs a structure that can affect the outcome.
The changes materially strengthened assurance and governance. They did not change the release’s readiness status. Learning-transfer and release certification remained unresolved, the staged research path stayed closed, and there was still no paying-customer proof. Those limits are not an attempt to drain the achievement of meaning. They identify what was actually built: a stronger way to challenge and govern the work, not the conclusion of every challenge the new machinery might eventually help resolve.
A critic needs a real job
It is easy to add an AI “critic” to a workflow. Ask another model to review the answer and a review appears. The harder question is whether that review is sufficiently independent, specific, and consequential to improve the result. If it simply restates the author’s assumptions in a more cautious tone, the system has added text rather than scrutiny. If it identifies a problem but nothing changes, it has added commentary rather than control.
The useful direction is to give the roles different responsibilities. A probe looks for a defined class of weakness. A comparison examines behaviour under meaningful conditions. A remediation step proposes a change. A separate judgement decides whether the evidence supports accepting it. These are broad descriptions of the assurance approach, not a disclosure of private test mechanisms. Their value is that a successful-looking output does not automatically get to certify itself. The workflow has somewhere for a disagreement to land and a process for resolving it.
The builder cannot be the whole jury
Human teams face the same problem. The person who built a feature understands it deeply, but also knows the intended path so well that unexpected uses can be harder to see. Independent review brings a different vantage point. With AI-assisted development, the need remains, even when the work is produced quickly and the explanation is unusually fluent. Speed does not remove blind spots. It can make an unsupported assumption travel through more artifacts before someone notices it.
For UBIKITOS, role separation was a way to make that risk more manageable. It does not guarantee that every issue will be found. It creates a more credible process for testing claims than a single uninterrupted chain of self-approval. The relevant result still has to be examined. A critic can be wrong, a proposed fix can be ineffective, and an adjudication can need better evidence. The structure is valuable because it makes those possibilities explicit, rather than assuming that more agents automatically produce better judgement.
A proposed repair should remain proposed
One of the useful boundaries in assurance work is the distinction between finding a problem and authorising a change. A system may be able to suggest a remedy without being permitted to apply it broadly. That keeps investigation productive while preserving control over consequential modifications. The proposed correction can be reviewed, tested, and accepted within a defined scope. The existence of a plausible fix does not have to become permission for unrestricted self-modification.
A hypothetical workflow illustrates this. An assistant notices that a process mishandles a missing field and proposes a validation change. The proposal may be excellent. It still needs to be checked against the intended behaviour and any affected cases. Applying it everywhere immediately could solve one problem while creating another. Keeping proposal and acceptance separate gives the system a way to learn from criticism without allowing criticism itself to become an unlimited source of authority. That is a useful distinction for both builders and users.
The repositories needed the same clarity
The Git-estate governance work addressed where authoritative changes belong and how they are checked. A project spread across several repositories can accumulate ambiguity about which state is current, which branch is under review, and which changes are allowed to guide the next task. Clear routing and validation help reduce that ambiguity. They make it harder for a convenient but unaccepted piece of work to become the basis of a broader claim simply because someone found it first.
This is not glamorous product work, but it supports a practical founder need: knowing which thing to trust when resuming. The assurance process and the repository governance reinforce each other. A careful review is less useful if its accepted result cannot be distinguished from an abandoned candidate. A clear repository structure is less useful if changes enter it without adequate scrutiny. Today strengthened both sides of that relationship while explicitly leaving the release status unchanged. The project gained better control over the work, not a shortcut around the remaining evidence.
Stronger machinery still needs a result
The temptation after building an assurance system is to let its sophistication stand in for the assurance it is meant to provide. That would repeat the very problem the work is trying to solve. A collection of probes, comparisons, and review roles is a capability for investigation. It is not proof that every important question has been answered. The next step was to use the new machinery against the current executable system and close the outstanding transfer and release questions through actual results.
The research gate remained closed for the same reason. Preparation can make the eventual decision better informed without making the decision automatically. A well-equipped laboratory still needs to run the experiment. A well-organised review process still needs to produce and assess evidence. This is a useful check on founder enthusiasm: ask whether the new work is the answer, or whether it is a better way to obtain the answer. Both can be valuable, but confusing them makes the project harder to understand.
Disagreement as a product feature
What I find useful about this day is that disagreement became part of the workflow rather than an interruption to it. The project was building a place for challenges, alternative interpretations, and rejected fixes. That is a healthier basis for consequential AI than treating every objection as friction between the system and its goal. Sometimes the objection is the most useful output because it prevents the wrong goal state from being accepted.
August twenty-sixth ended with stronger assurance machinery and several important questions still open. The next work was to apply that machinery, preserve the research boundary, and earn the pending certifications. There was no new commercial proof to report. There was a clearer way to challenge technical claims before making them larger. A company building with AI needs help that can disagree usefully, not just continue enthusiastically. Today moved that idea from a desirable personality trait into something the software could begin to enact and test.