86 lines
4.9 KiB
Markdown
86 lines
4.9 KiB
Markdown
# Deferred Feature Work
|
|
|
|
**Last updated:** 2026-11-10
|
|
|
|
**Status:** Deferred or exploratory work; not implemented or scheduled. These
|
|
entries preserve work beyond completed feature and library upgrades.
|
|
Each entry states its intent; inclusion does not commit us to
|
|
implementing every capability.
|
|
|
|
## Domain-Aware Response Recovery
|
|
|
|
The implemented [partial-success decision reconciliation](../internal/validators.md#llm-validator-batching)
|
|
preserves usable decisions without another model call. Revision of rejected
|
|
correction proposals is now an agreed feature direction in the
|
|
[correction-repair roadmap](correction-repair.md), with its own open decisions.
|
|
That work includes substantive validator feedback and explicit proposal withdrawal.
|
|
It is distinct from recovering an unavailable validator decision.
|
|
|
|
Consider bounded feedback and regeneration for model responses that satisfy the
|
|
structural schema but leave requested decisions unavailable after reconciliation.
|
|
The goal would be to recover more usable work before excluding affected
|
|
candidates, when doing so materially improves outcomes.
|
|
|
|
This capability is explicitly deferred. Current behavior retains PromptKit
|
|
structural repair and per-candidate reconciliation; unavailable requested
|
|
decisions produce errors while other candidates can succeed.
|
|
|
|
Before implementation, define the Audita/PromptKit ownership boundary, which
|
|
checks are eligible for feedback, how feedback identifies defects without exposing
|
|
secrets, and how regeneration fits bounded budgets and operation deadlines. Reuse
|
|
shared library capabilities where appropriate; do not introduce an uncoordinated
|
|
outer retry loop that multiplies existing retry/repair budgets.
|
|
|
|
Editorial rejection remains a valid decision about the evaluated proposal. The
|
|
correction-repair roadmap owns any subsequent revision of that proposal and full
|
|
revalidation; this deferred entry concerns unavailable decisions. Decision recovery
|
|
must preserve required validation, candidate identity, partial-success safety,
|
|
and truthful error/recovery reporting. Validate with controlled responses that
|
|
distinguish protocol defects from valid negative decisions. Exact APIs, budgets,
|
|
and sequencing remain undecided. General per-entry salvage from structurally
|
|
invalid responses also remains a separate design question; current reconciliation
|
|
retains whole-response structural validation.
|
|
|
|
## Independent Whole-Pipeline Traversal by Chunk
|
|
|
|
Explore allowing each fixed chunk to advance through its ordered stages without
|
|
waiting for other chunks to finish the current stage. This could reduce waiting
|
|
behind a slow chunk and improve utilization while preserving stage order within
|
|
each chunk and deterministic final recombination.
|
|
|
|
The resilience feature deliberately retains stage barriers: finish a stage across
|
|
chunks before advancing to the next stage. Fixed boundaries alone do not authorize
|
|
independent traversal.
|
|
|
|
A future design must establish that stages do not depend on other chunks' evolving
|
|
state, preserve stable identities and partial-success rules, and continue to share
|
|
PromptKit's per-backend capacity across all roles and stages. Reporting must remain
|
|
deterministic despite different completion orders, and fatal cancellation must
|
|
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.
|
|
|
|
## Whole-Segment Removal
|
|
|
|
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 implemented [span-deletion behavior](../internal/modules.md#proposal-generation-ownership).
|
|
That feature does not remove segment records or permit blank resulting segments.
|
|
|
|
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.
|
|
|
|
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.
|