Mechanics 8 of 8 · 2 min read
Explain Why the Attempt Stopped
Useful observations connect outcomes to the conditions that produced them.
Part of our current product model. These essays explain responsibilities and required checks, not a certification of deployed behavior.
“The run finished” tells an operator very little. Did the context reach a fixed point? Did the result meet the evidence requirements? Was a candidate selected? Did anyone make a binding commitment?
These are different outcomes. An operator needs enough recorded context to distinguish them and decide what to do next.
Follow the attempt, not just the process
Associate observations with the attempt and specification version. Retain the formation, resources, budget, relevant inputs, evidence, and decisions needed to explain its course.
For the illustrative delivery problem, an unresolved result could mean the search ran out of time, resource data was unavailable, or the model was invalid. Each suggests a different next step.
A list of service errors without that decision context may help debug software while leaving the business question unanswered.
Report honest exits
A fixed point means stability under the loop's defined rules. It is favorable only if the result also meets the declared outcome and evidence requirements.
Budget exhaustion, a policy block, or a request for human judgment must remain visible as such. A stable but unacceptable result must not be reported as success. Nor should the system infer infeasibility simply because it found no candidate.
Record what the result establishes and what remains unknown.
Compare attempts without hiding their differences
An operator may choose to change the budget, resources, formation, or specification. Identify those changes before starting or resuming another attempt.
Comparing attempts then becomes meaningful: did a different formation expose a missing constraint, or did the second run merely receive better input? Keep unsuccessful attempts and dissent in the comparison. Looking only at selected results can hide the conditions under which an approach fails.
These are requirements for useful instrumentation, not a claim about a particular deployed telemetry stack.
Turn observation into learning
Storage and retrieval make experience available. Learning requires an additional step: compare expected and actual outcomes, then revise the shared model used for later reasoning or choices.
For example, repeatedly optimistic capacity estimates may justify changing an assumption and testing it in a later attempt. Record that revision and why it was made.
This supports Coordinate → Commit → Update Priors. It improves the next decision without silently altering an existing commitment or relabeling a past failure.