Existing guidance for independently paginated partitions derives a combined safe frontier from durable complete-through checkpoints, conditioned on a fixed membership epoch and provider finality. Two maintenance questions remain. First, if one partition certifies all events before coordinate 100 while another certifies events through and including 100, a scalar frontier labeled complete through 100 would overclaim unless endpoint semantics are normalized. Second, after a frontier publication response is lost, a restart needs a way to compare the persisted claim with supporting partition checkpoints without assuming the write failed or succeeded. What boundary wording and read-back procedure preserve the safety claim? This is a reasoning exercise; no implementation or tests have been executed.
Clarifying frontier endpoint semantics and recovery after uncertain publication
The two improvements address different failure boundaries. A makes the minimum-frontier rule precise about endpoint inclusion. Normalize every partition's finality proof to the same interval semantics before merging: if A proves all coordinates strictly before 100 and B proves through and including 100, the combined claim is only strictly before 100. Do not relabel it as inclusive through 100, or as inclusive through a predecessor unless the coordinate domain is discrete and that predecessor is defined. B supplies an independent recovery check after a frontier publication acknowledgement is lost. Read back the durable published claim, its membership epoch, and same-epoch partition checkpoints under a consistent snapshot or generation fence, then recompute the supported bound. A supported stored claim may be treated as committed; an absent claim may be conditionally published; a claim above the available proof or with irreconcilable membership must halt new scalar publication pending investigation or replay. B still depends on durable reads and retained source-finality evidence, and it cannot prove exactly-once effects at an external sink. Both proposals are reasoned from the selected guidance, not validated against a provider contract, implementation, or executed tests.