After re-reading the current version in full, here is the reasoning behind two separate improvements. Both are analysis only. No code was written and no test was executed for either.

Improvement A sharpens the monotone boundary. The rule section says that sum, count and maximum over non-negative inputs are monotone and may be reported as lower bounds. The qualifier is correct but is never illustrated, and the billing example only uses positive meter readings, so a reader can easily miss that sign matters. Concrete case: a net usage total per region where each region can contribute positive consumption and negative credits or refunds. Three regions report a combined net of one thousand two hundred and the fourth is unavailable. If the missing region carried a five hundred credit, the true net is seven hundred; if it carried five hundred of consumption, the true net is one thousand seven hundred. The computed number is therefore neither a lower bound nor an upper bound, so it belongs in the non-monotone class and should be reported as unknown, or as a range only when the per-source magnitude is bounded by a known limit such as a maximum credit. The same applies to any difference between two sums, inventory counts with negative adjustments, and balances. A practical test for the class is whether every contribution from a missing source is guaranteed to have one sign; if not, the aggregate is non-monotone regardless of its name. Limitation: the example does not resolve mixed cases where one source is known to be non-negative and another is signed. For those, the safe statement is that the aggregate is monotone only with respect to the missing sources whose sign is guaranteed, which is a per-source property and would need a per-source sign field in the minimal shape. That is a design change I have not thought through, so A should stay a worked example and a one-line classification test, not a schema change.

Improvement B adds an independent verification procedure. The current text has a backfill step and a list of checks before shipping, but every check is a one-time adopter exercise, and nothing verifies in production that reducers, database coalesce expressions and rollup writers still honor coverage after later changes. Two parts. First, a scheduled shadow computation: on a regular cadence, recompute the aggregate with one healthy source deliberately withheld and assert that the reported form changes from exact to a bound or unknown, that coverage reports one fewer contributing source, and that the withheld source appears in the missing list rather than as a zero. The shadow result is never persisted or displayed. A pass proves nothing about correctness of values, only that the coverage path is alive. Second, a post-backfill reconciliation: after a source recovers and the backfill replaces partial rollups, recompute each affected window from raw per-source records and compare against the stored rollup, then assert that no window in the affected range still carries an incomplete coverage record. Limitations: the shadow check costs one extra aggregate computation per cadence, which matters for expensive fan-outs; it should withhold a rotating source so a reducer that special-cases one source is still caught; and reconciliation requires raw per-source retention for at least the backfill horizon, which the current skill does not require, so B introduces a retention precondition that must be stated explicitly. Neither part detects a reducer that reports a bound with the right form but computes the wrong value.

On placement: A belongs in this skill because it corrects how readers apply the existing rule. B could live here as a new section or as a separate skill on continuous verification of coverage handling. My current view is that B fits here because it references this skill's form and coverage fields directly, but I have not searched for an existing verification skill that might already cover fault injection, so that remains open. Discovery at task start returned only this skill, the per-source caching skill and an unrelated worker-isolation skill, none of which cover signed aggregates or shadow checks.

Maintenance review of guidance for reporting numeric aggregates when some fan-out sources are unavailable. The current text classifies sums, counts and maxima over non-negative inputs as monotone and reports them as lower bounds. Two gaps seem worth closing. First, the non-negative condition is stated once but never illustrated, so a reader may apply lower-bound reporting to a net total that includes credits, refunds or negative adjustments. With a missing source that could hold a large credit, the computed total is not a bound in either direction. A worked example marking such signed sums as non-monotone would sharpen that boundary. Second, the guidance describes backfill on recovery but offers no independent way to verify that reducers actually honor coverage. A candidate is a scheduled shadow computation that withholds one healthy source and asserts the reported form and coverage change, plus a post-backfill reconciliation comparing replaced rollups with raw per-source records. Unknowns: whether existing guidance already covers signed aggregates or fault-injection checks, and whether the self-check belongs in this skill or a separate one. No tests have been executed; this is reasoning only.