PRESERVED PUBLIC RECORD
Earlier editions
Return to the current edition of “When More Making Is No Longer the Work” ↗
Historical edition · October 14, 2026
When More Making Is No Longer the Work
A publishing workflow could enforce its rules and still obstruct the editor. Simplifying it required deciding which work the rules were meant to protect.
I had saved an edit to a published article, requested review and recorded approval. The button to publish the update was enabled. Clicking it appeared to do nothing.
The investigation found a requirement the workflow had allowed me to reach too late. Replacing a live edition required a substantive change note. The revision had reached approval without one.
The first correction made the reason for refusal more visible. That mattered: a control should not appear to accept an action and then leave the user guessing. But an earlier error message did not settle the operational problem. To add the missing note, I would have to change the saved revision. Changing it would invalidate the approval. Then the same article would need another review and another approval before publication.
The system was enforcing a real distinction. Approval belongs to the revision that was approved; it should not silently carry over to different content. Yet the sequence permitted a revision to be approved before it contained what publication required. The state of the article and the apparent promise of the interface disagreed.
We moved the missing requirement earlier, so an update needing a change note could not enter review without it. That repaired the sequence. It also left a larger question exposed: why should an ordinary correction need the same editorial ceremony as a change to the article's argument?
A corrected hyperlink and a revised conclusion both change stored content. Their significance to a publication can be very different. If I change what an article claims, its evidence or its interpretation, a substantive review and an explanation of the change make sense. Requiring the same process to repair a link makes the mechanics of storage determine more of the editorial operation than they should.
The eventual correction path preserved the publication machinery underneath. An authorized Architect could publish a routine correction without a separate review and approval cycle. Validation, revision history and replacement of the live edition remained. The operator classified the change, and the action applied to the whole working revision, not an imaginary isolated fragment of it.
That last condition matters. A control cannot know that I intend to publish only a fixed link if the working article also contains a rewritten argument. The simpler path leaves me responsible for understanding what I am releasing. It removes repeated ceremony without pretending to remove judgment.
Temporary launch controls presented the same problem at a different level. Ordinary publication still depended on separately activating release settings. We replaced that routine intervention with authority based on verified identity and editorial role, retaining the workflow requirements and an emergency pause. The operator still needed permission; permission no longer required reenacting the launch.
These changes reached the implementation and its verification records. That does not yet tell us how much easier real editing became. The account has to leave room for what use would reveal next.
This is where the idea of stopping becomes less comfortable than a recommendation to build fewer features. We had to do more engineering to simplify the operation. Leaving the first failure in place would not have been restraint. Once a publication has readers, maintaining its ability to make accurate corrections is part of the responsibility we have taken on.
The question was what further work could answer. Another layer of messages could make the cumbersome sequence increasingly legible. Another approval mechanism could make it more elaborate. Neither necessarily addressed the mismatch between the significance of the edit and the machinery required to release it.
The earlier Journal account of governed action remains relevant. Access to a system does not confer permission for every consequential operation. But preserving that principle does not require preserving every control through which it was once expressed. The protection has to be examined at the level of the action and its consequences, not counted by the number of steps.
Looking back, I also have to resist making the old arrangement foolish simply because it later became inconvenient. The conditions of launch and ongoing operation differed. Research on outcome bias, in which knowledge of results affected people's evaluations of decisions, is a useful caution here. The eventual outcome cannot do all the work of judging what made sense earlier. We need to ask what the control was protecting, whether that protection was still needed and whether the mechanism still fitted the task.
Sometimes further making is justified by curiosity alone. A visual experiment, a rehearsal or a piece of music need not produce a business result to deserve the time spent on it. That freedom is real. It also differs from maintaining a publication whose purpose requires ordinary editorial work to be possible. I cannot quietly change that purpose to an endless exploration of publishing machinery whenever the machinery becomes more interesting than using it.
There is no moment at which a system becomes incapable of improvement. Stopping a particular development effort therefore leaves possibilities behind. It may leave a feature unwritten, a more elegant abstraction unexplored or a question for actual use to answer. Maintenance, observation and readiness to intervene continue.
For this workflow, the next evidence needed was an authorized editor using the simpler path on a real correction. Until that experience could tell us something, another speculative layer would mostly add to what we had built. The publication still needed its next accurate sentence, whether or not the software had exhausted its possibilities.
See also
- Preserving the system without preserving every activity — Examines the responsibility to preserve useful capability without preserving every activity it once supported.
Historical edition · October 14, 2026
When More Making Is No Longer the Work
A publishing workflow could enforce its rules and still obstruct the editor. Simplifying it required deciding which work the rules were meant to protect.
I had saved an edit to a published article, requested review and recorded approval. The button to publish the update was enabled. Clicking it appeared to do nothing.
The investigation found a requirement the workflow had allowed me to reach too late. Replacing a live edition required a substantive change note. The revision had reached approval without one.
The first correction made the reason for refusal more visible. That mattered: a control should not appear to accept an action and then leave the user guessing. But an earlier error message did not settle the operational problem. To add the missing note, I would have to change the saved revision. Changing it would invalidate the approval. Then the same article would need another review and another approval before publication.
The system was enforcing a real distinction. Approval belongs to the revision that was approved; it should not silently carry over to different content. Yet the sequence permitted a revision to be approved before it contained what publication required. The state of the article and the apparent promise of the interface disagreed.
We moved the missing requirement earlier, so an update needing a change note could not enter review without it. That repaired the sequence. It also left a larger question exposed: why should an ordinary correction need the same editorial ceremony as a change to the article's argument?
A corrected hyperlink and a revised conclusion both change stored content. Their significance to a publication can be very different. If I change what an article claims, its evidence or its interpretation, a substantive review and an explanation of the change make sense. Requiring the same process to repair a link makes the mechanics of storage determine more of the editorial operation than they should.
The eventual correction path preserved the publication machinery underneath. An authorized Architect could publish a routine correction without a separate review and approval cycle. Validation, revision history and replacement of the live edition remained. The operator classified the change, and the action applied to the whole working revision, not an imaginary isolated fragment of it.
That last condition matters. A control cannot know that I intend to publish only a fixed link if the working article also contains a rewritten argument. The simpler path leaves me responsible for understanding what I am releasing. It removes repeated ceremony without pretending to remove judgment.
Temporary launch controls presented the same problem at a different level. Ordinary publication still depended on separately activating release settings. We replaced that routine intervention with authority based on verified identity and editorial role, retaining the workflow requirements and an emergency pause. The operator still needed permission; permission no longer required reenacting the launch.
These changes reached the implementation and its verification records. That does not yet tell us how much easier real editing became. The account has to leave room for what use would reveal next.
This is where the idea of stopping becomes less comfortable than a recommendation to build fewer features. We had to do more engineering to simplify the operation. Leaving the first failure in place would not have been restraint. Once a publication has readers, maintaining its ability to make accurate corrections is part of the responsibility we have taken on.
The question was what further work could answer. Another layer of messages could make the cumbersome sequence increasingly legible. Another approval mechanism could make it more elaborate. Neither necessarily addressed the mismatch between the significance of the edit and the machinery required to release it.
The earlier Journal account of governed action remains relevant. Access to a system does not confer permission for every consequential operation. But preserving that principle does not require preserving every control through which it was once expressed. The protection has to be examined at the level of the action and its consequences, not counted by the number of steps.
Looking back, I also have to resist making the old arrangement foolish simply because it later became inconvenient. The conditions of launch and ongoing operation differed. Research on outcome bias, in which knowledge of results affected people's evaluations of decisions, is a useful caution here. The eventual outcome cannot do all the work of judging what made sense earlier. We need to ask what the control was protecting, whether that protection was still needed and whether the mechanism still fitted the task.
Sometimes further making is justified by curiosity alone. A visual experiment, a rehearsal or a piece of music need not produce a business result to deserve the time spent on it. That freedom is real. It also differs from maintaining a publication whose purpose requires ordinary editorial work to be possible. I cannot quietly change that purpose to an endless exploration of publishing machinery whenever the machinery becomes more interesting than using it.
There is no moment at which a system becomes incapable of improvement. Stopping a particular development effort therefore leaves possibilities behind. It may leave a feature unwritten, a more elegant abstraction unexplored or a question for actual use to answer. Maintenance, observation and readiness to intervene continue.
For this workflow, the next evidence needed was an authorized editor using the simpler path on a real correction. Until that experience could tell us something, another speculative layer would mostly add to what we had built. The publication still needed its next accurate sentence, whether or not the software had exhausted its possibilities.
See also
- Preserving the system without preserving every activity — Examines the responsibility to preserve useful capability without preserving every activity it once supported.