Started ≠ Done

We had spent weeks teaching BOSS how to work. Now we had to teach it how to tell the truth about its own work.

Started is a state, not an outcome.

A worker can start. A process can receive an ID. A job can enter a queue. A model can produce a confident final message. None of those facts, by themselves, prove that the expected result exists.

That distinction sounds obvious when written down. In a fast-moving system, it is surprisingly easy to blur the states together. A process disappears and it looks like a crash. A worker says it finished and it looks like success. A receipt is missing and everything looks unknown.

The important correction was simple: started, running, progressing, completed, and verified are different states. A missing process ID is not an outcome state. An active process ID is not proof of progress. And a worker's final message is not the same thing as independent verification.

Receipts > Claims.

Language models are very good at sounding certain. Reliable systems cannot treat certainty as evidence.

So we began separating what a worker said happened from what the surrounding system could demonstrate happened. Depending on the task, that evidence could include an exit code, session identity, machine-readable events, timestamps, expected artifacts, output validation, and a worker receipt.

There was an equally important second half to that rule: missing evidence does not automatically prove failure. A process may exit normally after producing its result. A required receipt may be missing even though the task itself succeeded. Receipt noncompliance and task outcome are related, but they are not the same fact.

That forced BOSS to reconcile terminal evidence instead of collapsing every unusual ending into the same label. The system became less interested in a single signal and more interested in the evidence set.

Then speed created a different kind of risk.

As worker execution became faster, we hit a more subtle failure mode. A manual worker launch bypassed the governed dispatch path and produced two concurrent sessions against the same workspace.

Neither session needed to be malicious or incompetent for that to be dangerous. Both could be doing individually reasonable work while believing they had authority to change the same target. The problem was not intelligence. It was ownership.

The correction became another durable principle: one immutable task may have only one active mutation authority for its target workspace.

The governed path was hardened around that idea. Task ownership became durable across processes. Duplicate in-flight work was blocked. Replays required verified completion. Changed inputs could not silently inherit old success. A prior HOLD could not magically become a successful replay.

Proof before trust.

This was the point where verification stopped feeling like a final checkbox and started becoming part of the architecture itself.

Multiple workers can investigate the same problem. Multiple tests can challenge the same assumption. Multiple drafts can compete. But authoritative state has to converge before the system commits.

That principle mattered inside BOSS, but the business version mattered even more. Customer identity, commitments, approvals, payments, permissions, communications, and deliverables cannot become competing versions of reality just because parallelism is convenient.

The system learned to distrust confidence.

Earlier in the journey, we were trying to make the model more capable. By this stage, capability was no longer the only problem. We needed the system around the model to be appropriately skeptical.

That meant preserving evidence even when the worker looked healthy. It meant checking outputs even when the answer sounded right. It meant treating a vanished process as something to investigate rather than automatically calling it a crash. And it meant refusing to let two mutation authorities silently own the same task.

What came next

Once we knew how to verify one worker, a larger question came into focus: how much work could we safely do at the same time without creating competing versions of truth?

That question would push BOSS deeper into parallel execution, synchronization, Founder attention, and the difference between making many things happen at once and letting many things become authoritative at once.