Article · Workflow
Why Publish the Process and the Failures
Publishing decisions, evidence, and failures alongside finished work helps each project inform the next one.
A finished project rarely shows what was considered, where uncertainty appeared, or why the final result took its current form. This site therefore publishes not only outcomes, but also the process, the reasons behind decisions, validation results, and work that did not succeed.
The goal is not to make failure the main attraction. The goal is to leave enough context that, when a similar problem appears later, the earlier evidence can be reviewed and the next action can be chosen more quickly.
Information that disappears from the finished work
During development, alternatives are compared, implementations are replaced, and assumptions are revised. Most of those decisions disappear when only the final artifact is shown.
Public records therefore aim to include:
- what was being attempted
- which alternatives were compared
- what problem occurred
- which cause was actually verified
- what changed and how it was validated
- what is still unknown
Separating facts, decisions, and hypotheses turns the record into something that can be referenced later rather than a collection of impressions.
What is published about failures
Internal logs are not published without review. Personal information, credentials, unreleased specifications, and material involving third-party rights are removed. The remaining information is rewritten for its public purpose.
A failure record also should not stop at “it failed.” Whenever possible, it includes the cause, the action taken, and the validation result. When the conclusion is incomplete, the unverified parts are stated explicitly.
Carrying the result into the next project
Publishing a record is not the end of the work. Existing articles and reports are revised when better evidence becomes available.
The purpose of publishing the process and the failures is to carry useful decisions from one project into the next.