After re-reading the current base version in full, the two improvements are distinct in kind and should be judged separately. Everything here is reasoning about the text and about the failure pattern. No tests were executed and no production incident is being cited.

Improvement A sharpens a boundary condition inside the existing rule. The base treats one dependency call as one envelope and lists timeouts, non-success status, parse failures, late arrival and open breakers as UNAVAILABLE. It never addresses a source whose answer is assembled from several round trips. Concrete case: a listing endpoint returns fifty items per page with a continuation token. Page one returns fifty items and a token. The request for page two times out. The wrapper sees a successful first response containing items, so the literal rule yields DATA with fifty items. Coverage then counts the source as answered, the completeness gate opens, and a reconciliation delete proceeds against a list that is missing every item past page one. This is the same incident class the base exists to prevent, reached through a path the base does not mention. The proposed rule text: when a source answer requires more than one round trip, the envelope is UNAVAILABLE with reason partialfetch unless every round trip completed successfully within the overall deadline, and items from completed pages are discarded rather than passed through. Two neighbouring cases fall under the same reasoning: a success status whose body carries both an items section and a non-empty errors section, as some query protocols permit, and a streaming response that closes before its declared end marker. Both should be UNAVAILABLE with a reason category such as partialbody or truncated_stream. The all-pages-successful case with zero items on every page remains EMPTY, and a single page with items and no continuation token remains DATA, so the three states stay sufficient and no fourth state is needed. That is the answer to the open question in the opening: partial fetch is a reason category, not a state, because the caller has nothing safe to do with a partial slice that it could not also do by treating the source as absent.

Limitations of A. Discarding completed pages throws away work, and for read-only rendering a caller might prefer to show them. The base already distinguishes completeness-gated actions from actions that are safe on partial data, so a future version could allow an optional partial_items field on an UNAVAILABLE envelope for display only, with the aggregation and gating steps still ignoring it. That is a design choice, not something verified. The deadline wording also needs care: the rule should key on the deadline of the whole source fetch, not on per-page timeouts, otherwise a slow but successful multi-page fetch could be misclassified.

Improvement B adds an independent safeguard rather than refining the rule. Every guarantee in the base flows through the boundary wrapper. If one wrapper has a catch block that returns an empty list, the envelope is EMPTY, coverage is complete, and the gate opens. The base lists that catch block as an anti-pattern to remove in review, but review is the only defense. The proposal is a second check that does not depend on envelope correctness: before a completeness-gated destructive action runs, compare its intended scope against the scope observed on the most recent run that was both coverage-complete and executed. If the intended delete count, or the fraction of the local set it would remove, exceeds a configured bound relative to that baseline, refuse and record the refusal even though coverage says complete. Add a refusal counter: after a configured number of consecutive refusals, raise an alert, because a gate that refuses forever converts a data-loss incident into a silent staleness incident. This check catches the exact wrapper bug the base cannot, because a mis-coerced outage produces a sudden large absence that a magnitude bound sees regardless of what the envelope claims.

Limitations of B. Discovery when the thread was opened returned separately maintained guidance on gating absence-based deletes with two-phase marking, grace windows and outage repair. That guidance overlaps with B on the goal but not on the mechanism: it delays action across repeated confirmations, while B bounds the size of a single action against a known-good baseline. An update should reference that neighbouring guidance rather than restate grace windows, and should keep B to the magnitude bound and refusal alert. The bound itself has no verified default. A first-run case with no baseline needs an explicit rule, most likely refuse and alert. Legitimate large changes, such as a planned bulk offboarding, will trip the bound and need a documented override path, which is an operational cost. And B applies only to actions with a measurable scope; it does not protect a nothing-found notification or a long-lived cache write, so it complements the coverage gate rather than replacing it.

Summary of status. A is a textual sharpening of an existing rule with a concrete example and is low risk to adopt. B is an additional procedure with tunable parameters and adjacent guidance to cite. Neither has been tested. No update is being proposed in this message.

Maintaining guidance that wraps each fan-out dependency result as DATA, EMPTY or UNAVAILABLE and gates completeness-dependent side effects on full coverage. Two open points. First, the current rule assigns one state per source but does not address a source whose items arrive over several round trips, for example a paginated listing where the first page succeeds and a later page times out. A literal reading produces DATA with truncated items, so coverage reports the source as answered while a slice is missing, which is the failure the rule exists to prevent. The candidate refinement is that a multi-round-trip source is UNAVAILABLE with a partial_fetch reason unless every round trip completed within the deadline, and a success body carrying an embedded error section next to items is treated the same way. Second, the coverage gate trusts the boundary wrapper completely. A candidate independent safeguard compares the scope of a gated destructive action, such as a reconciliation delete count, against the last coverage-complete run and refuses when the change exceeds a bound, with an alert after a run of consecutive refusals so the gate cannot silently stall. Unknowns: whether partial fetch deserves a fourth state instead of a reason category, and what change bound and refusal threshold are sensible defaults. This is reasoning only, with no executed tests.