fix(aws/ladder): residual on-demand baseline subtracts existing commitment again and falsely holds below target #282

The production AWS ladder baseline counts only uncovered On Demand Instances billed spend, then Allocate treats it as total demand and subtracts existing commitment again. A partly covered account can produce "target already met" while it still has substantial uncovered usage.

Verified on an exact archive of live platform main f2d60df86209eea85d81e9091c20832bd670a65f with its pinned pkg@90e61e668b99 and providers/aws@9962786e0695. Shared checkout 7ff8c1aee1bbe9f23a8c154c01c825f323797ad5 retains the same filter/formula. The initial probe also reproduced on the older local platform checkout 3131779c5fcdecaf1a8fd5dbfe93f590235fe1b5; it was rerun against live-main after discovering that local main was stale, with identical output below.

Trigger, expected, actual

Configure AWS ladder coverage=100%, buffer=0, no pending tranches. The account has a $6/hr existing Compute SP and a fresh 30-day CE series with $4/hr uncovered EC2 On Demand Instances spend.

Expected: the $4/hr residual is evidence that coverage is below target; size the remaining eligible demand using a consistent total-demand/covered-demand basis and the real offering rates. A residual-only baseline must not be reduced by existing commitment a second time.

Actual: AWSLadder.GetUsageBaseline -> GetLayerStates -> Allocate returns no purchases and a Hold claiming target already met, because 4 - 6 = -2. Discounted committed dollars and on-demand-priced usage dollars are also being treated as interchangeable here; simply adding existing dollars to the series is not a sufficient general fix.

Source

• providers/aws/recommendations/ondemand_series.go:78-80,196-214: daily UnblendedCost is restricted to EC2 compute AND PURCHASE_TYPE=On Demand Instances AND region; covered RI/SP usage is excluded.
• providers/aws/ladder/adapters.go:241-250: forwards that series to the baseline unchanged.
• providers/aws/ladder/baseline.go:128-155: percentile becomes LowWaterUSDPerHour.
• providers/aws/ladder/layer_states.go:169-174: existing SP amount is its native HourlyCommitmentUSD.
• pkg/ladder/allocate.go:133-154,414-425: target=lowWater*coverage, then subtracts existingTotal from target and lowWater.
• Platform consumer: internal/server/handler_ladder.go:326-380 obtains these exact read-side values and passes them into Allocate.

Reproduced evidence (mock provider boundary, no cloud calls/purchases)

A standalone Go consumer used the real exported aws/ladder.New, GetUsageBaseline, GetLayerStates, SupportedLayers, and pkg/ladder.Allocate. Boundary mocks supplied a 30-point strictly ordered fresh daily residual series, one active Compute SP with one-year remaining life, and empty RI coverage/inventory/utilization. Config: email_approval/daily, ramp={after_days:0,fraction:1}, target=100%, buffer=0%, P5/30 days, max actions=10; explicit zero in-flight.

Command run from the exact platform archive /private/tmp/ladder-audit-f2d60df8: go run /private/tmp/ladder-baseline-audit.go.

Observed:

uncovered-control residual_baseline=10.00 existing=0.00 allocations=1
compute-sp 10
partly-covered residual_baseline=4.00 existing=6.00 allocations=0
target already met: low_water=$4.0000/hr, target=100.00%, existing=$6.0000/hr, in_flight=$0.0000/hr, target_commitment=$4.0000/hr, gap=$-2.0000/hr <= min_allocatable=$0.0100/hr
total-demand-control residual_baseline=10.00 existing=6.00 allocations=1
compute-sp 4

The last input is a fail control on the same real consumer, demonstrating that the missing total-demand basis changes the allocation. The $4 control allocation is an engine arithmetic control, not a claim that a native SP commitment exactly equals its on-demand coverage.

Impact and fix direction

Present impact is incorrect persisted plans/Hold rationales; the platform ladder executor is still absent (#70/#118), so this is not a claim that live purchases already occurred. As existing coverage rises, the algorithm suppresses top-ups earlier than configured and can falsely stop laddering. Recover total eligible on-demand-equivalent demand including covered usage, normalize existing/expiring coverage onto the same units, and use actual offering rates to translate allocations into native purchase commitment. Add a regression through the actual CE filter/adapter plus engine consumer, including partly covered and completely covered accounts, multiple SP types, standard RIs, and RI/SP discounts.