Define consistent span deletion and defer whole-segment removal

docs/roadmap/future.md

@@ -1,10 +1,11 @@
 # Deferred Feature Work
 
-**Last updated:** 2026-09-24
+**Last updated:** 2026-09-25
 
-**Status:** Intended future work; not implemented or scheduled. These entries
-preserve scope deferred from the [resilience roadmap](resilience.md). They are
-not prerequisites for completing that feature or staged implementation plans.
+**Status:** Deferred or exploratory work; not implemented or scheduled. These
+entries preserve scope outside the [resilience roadmap](resilience.md) and
+[span-deletion consistency roadmap](span-deletion.md). Each entry states its
+intent; inclusion does not commit us to implementing every capability.
 
 ## Domain-Aware Response Recovery
 
@@ -50,24 +51,26 @@ still stop and join active work. Assess whether the scheduling change materially
 improves real workloads before introducing additional orchestration machinery.
 No new scheduler, global limiter, or execution mode is selected by this entry.
 
-## Empty Replacement Text and Segment Removal
+## Whole-Segment Removal
 
-Address a frequent proposal failure reported in production: the LLM supplies an
-empty string as `corrected_text`, possibly because it intends to remove the
-entire segment. That interpretation is a hypothesis, not a reliable signal of
-intent. Improve both prompting and handling so this case has a clear, consistent
-outcome rather than repeatedly producing unusable proposals.
+Potential future work, subject first to evaluating whether it is worth implementing
+at all. Empty replacement text and deletion of a span within a surviving segment
+are covered by the accepted [span-deletion consistency roadmap](span-deletion.md).
+That feature does not remove segment records or permit blank resulting segments.
 
-Review representative examples and distinguish deletion of a text span from
-removal of an entire segment. Define whether either operation is supported, how
-it is represented, and what validation is required. Align proposal prompts,
-response contracts, validators, application behavior, and error/recovery reporting
-with the selected semantics. If an operation is unsupported, prompts should give
-clear guidance on what the model should return instead.
+Before designing segment removal, review representative production examples to
+establish whether whole-segment deletion is a meaningful unmet need. An empty
+replacement alone does not establish that intent: it can express ordinary filler
+or punctuation deletion within a larger segment. Assess how often genuinely
+expendable whole segments occur after deterministic normalization, the transcript
+quality benefit of removing them, and the risk of losing substantive speech.
+Compare those benefits with the implementation and ongoing maintenance costs.
+Retaining the segment and declining the edit is a valid outcome if the benefit is
+small or uncertain. No numerical adoption threshold is selected.
 
-Do not infer authorization to delete a segment from an empty replacement alone.
-Any future support for segment removal must address meaning preservation and the
-effect on segment identity, timestamps, fixed chunks, later stages, and output.
-Coordinate with domain-aware response recovery where feedback could resolve an
-invalid proposal. Exact deletion semantics and recovery behavior remain undecided;
-this entry does not relax current validation or expand the resilience workstream.
+Only if that evaluation supports proceeding should a separate feature design
+choose a representation, authorization and validation rules, and reporting
+semantics. It must address meaning preservation and the effects on segment
+identity, timestamps, fixed chunks, subsequent stages, recombination, and output
+consumers. Do not infer authorization to remove a segment from an empty string
+or introduce segment-removal machinery as part of span-deletion consistency.