---
title: Local Draft State
status: draft
maturity: hypothesis
families: [affordance, mutation]
scales: [L6]
admission: research-candidate-only
---

# Local Draft State

Context: editing a shared server-validated record. Problem: a refresh or rejected
write can destroy unfinished intent. Responsiveness and recoverability compete with
state complexity and privacy.

Proposed solution: keep base observation, editable proposal and current server
observation distinct. Rejection preserves the proposal; refreshed data prompts
comparison instead of replacing input. Explicit discard clears the draft. Define
whether navigation or restart persistence is required rather than implying it.

Consequences: review is possible after rejection, but stale drafts and sensitive data
need lifetime rules. Binding inputs directly to a refreshed cache is simpler when
there is no unfinished work; durable local authority is a different requirement.

Evidence: T01/T02 motivate rejection recovery; T05 illustrates local submission data.
None verifies this complete draft lifecycle in a deployed frontend. Exact known uses
and recurrence: unknown. Hypothesis only.

Proposed connection: supports recovery from [Version-Checked Mutation](VersionCheckedMutation.md).

T01–T05 refer to [TransactionalEvidenceExpansion](../reviews/TransactionalEvidenceExpansion.md).
Connections are research proposals, not admitted graph edges.
Reasoning exercise: [VC-01](../walkthroughs/VC01-TransactionalAdministration.md).