# v0.95.0 — Durable Typed Output Deltas

> **Status:** Planned
> **Scope:** Large
> **User promise:** *"Consume output changes without private buffers or expensive full scans."*
> **Blocked by:** [v0.94.0](v0.94.0.md)
> **Delivery plan:** Phase 3 of
> [Proposal: V1 Composable Refresh and Durable Delta Contracts](../plans/PROPOSAL_V1_COMPOSABLE_REFRESH_AND_DELTA_CONTRACTS.md)

## Theme

Add durable acknowledged typed output deltas for coordinators that have proven
complete terminal scans too expensive. Consumers receive exact logical changes
when available and an explicit `FULL_INVALIDATION` otherwise, with retention,
backpressure, resnapshot, recovery, and owner-only access.

Delta V1 depends on a compatible enabled Graph V1 but has its own acceptance
gate. `output_delta_consumer` remains absent, disabled, or experimental until
every gate in this release passes; failure must not weaken Graph V1's complete
terminal-read path.

## Items

### DV1-1: Durable consumers and proven baselines

Add consumer registration and status for `EXTERNAL` stream tables. New
consumers start in `RESNAPSHOT_REQUIRED` unless pg_trickle proves a pristine,
empty `CURRENT` origin. Registration, state, owner, output-contract digest,
row-identity version, cursor, and database-instance identity are durable and
reuse-safe.

### DV1-2: Transactional typed batches

Maintain one shared logical output log per opted-in stream table and expose it
through a read-only typed relation. Each refresh writes one immutable batch
with a gap-free transactional token and either complete delete-and-insert rows
or one truthful `FULL_INVALIDATION`. No-data refresh writes an exact zero-row
batch. A full path never performs an unbounded diff solely for this API.

Batch creation belongs to the common finalizer so the stream-table frontier
cannot commit without its batch metadata and complete payload or invalidation.
Private downstream change buffers and physical storage names remain private.

### DV1-3: Acknowledgement and resnapshot

Add ordered batch inspection, transactional acknowledgement, and a
transaction-scoped resnapshot protocol. Exact batches transform the prior
multiset into the full result at the batch boundary. Invalidation requires a
complete terminal read before acknowledgement. Baseline reads, coordinator
writes, cursor activation, output batches, and acknowledgements commit or roll
back together.

### DV1-4: Retention and backpressure

Store payload once regardless of consumer count. Cleanup advances only through
the slowest `ACTIVE` or `PAUSED` cursor and any prepared binding. Advisory
limits report lag; hard limits block refresh before log-head, metadata, or
payload mutation. Only an explicit authorized transition records a
discarded-through token and makes unacknowledged history eligible for cleanup.

### DV1-5: Recovery, lifecycle, and security

Fail closed on missing history or storage, contract mismatch, unknown row
identity, stale database-instance identity, relation rebinding, role drop, or
invalid acknowledgement. Contract-changing alterations and return to
`MANAGED` mode are rejected while consumers exist. Drop requires an explicit
authorized cascade. Owner-only access covers retained deleted rows as well as
current output.

## Exit criteria

- [ ] Exact-batch algebra matches old and new PostgreSQL multisets across
      inserts, deletes, updates, duplicates, aggregates, joins, set operations,
      TopK, no-op changes, and supported full paths
- [ ] Unsupported exact full output produces one `FULL_INVALIDATION` with no
      partial payload
- [ ] Multiple consumers share one typed payload while cleanup follows every
      retaining cursor and prepared binding
- [ ] Refresh and acknowledgement rollback restore payload, cursor, and log
      head without a token gap
- [ ] Hard retention pressure blocks before any batch or frontier mutation;
      resnapshot requires an explicit separately committed transition
- [ ] Recovery, restore, clone, relation-rebinding, role-dependency, and upgrade
      tests produce the documented state and reason code
- [ ] Security tests cover guessed tokens, direct DML, RLS boundaries, and
      retained deleted-row access
- [ ] `output_delta_consumer` advertises stable major version 1 only after its
      algebra, transaction, retention, recovery, clone, security, upgrade, and
      zero-disabled-overhead gates pass