---
title: Invalidate and Reproject
status: draft
maturity: hypothesis
families: [projection, synchronization]
scales: [L3, L6]
admission: research-candidate-only
---

# Invalidate and Reproject

Context: several views derive from remotely accepted records. Problem: a successful
write does not refresh every observation. Freshness competes with network work and
interaction continuity.

Proposed solution: identify affected observations after acceptance and reload or
replace them from authoritative data. Guard against obsolete responses and preserve
unfinished drafts separately. Show accepted-but-refresh-failed when necessary;
a failed refresh does not undo the accepted mutation.

Consequences: views can converge without treating speculative data as truth, but
invalidation scope and ordering need explicit contracts. Blind cache replacement
loses edits; broad refresh costs bandwidth. A continuous subscription or authoritative
response containing all affected data may avoid a separate fetch.

Evidence: T04 describes React Router action revalidation and stale response handling,
including its limits. One framework mechanism, not independent application recurrence.
Exact known uses of this whole draft: unknown. Hypothesis only.

Proposed connection: depends on outcome information from
[Mutation Outcome Tracking](MutationOutcomeTracking.md) and preserves
[Local Draft State](LocalDraftState.md). Client ordering cannot replace server checks.

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