Validate isolation with adversarial load and honest oracles

Start from the resource and authority map. For each shared boundary, choose a victim with a stable useful-work objective and an aggressor that exercises a named mechanism: CPU execution, cache pressure, memory streaming, small random I/O, large writeback, many network flows, accelerator memory pressure, or expensive permitted API operations. Record the exact topology and versions. Combining every aggressor at once can expose a failure but makes attribution difficult; include controlled single-mechanism cases before combined stress and recovery. Limit the fixture so it cannot harm unrelated tenants.

Use separate oracles. Performance oracles include deadline goodput, latency distributions, resource shares, and queue growth. Availability oracles include rejection behavior, bounded recovery, and whether unrelated tenants remain able to make useful progress. Confidentiality and integrity oracles check explicit forbidden reads or changes using controlled objects, identities, and audit evidence. A service surviving a memory scan does not establish authorization, and a denied object read does not establish useful throughput under saturation. State the acceptable outcome for each test before observing the result.

A closed-loop generator waits for completion before issuing replacement work. When the system slows, that generator can reduce offered load, making an overloaded service appear less stressed than the intended arrival process. Open-loop scheduling can expose this effect, but the generator itself must have enough capacity and record scheduling delays. Preserve offered, accepted, rejected, completed, timed-out, and outstanding counts. A histogram containing only successful completions excludes exactly the work most affected by a severe stall unless that selection is explicitly part of the defined metric.

Coordinated omission is one form of this measurement problem: long pauses cause intended observations to disappear. Histogram correction based on an expected interval can illustrate missing experience under its assumptions, but it cannot reconstruct every unknown workload or fix a broken experiment automatically. Report raw counts and scheduling behavior alongside any correction. Match prompt lengths, output lengths, batching, cache warmup, and workload versions across baseline and shared cases. Otherwise a latency change may be caused by a different useful-work distribution rather than the proposed tenant-interference mechanism.

Randomize or pair baseline and shared runs to reduce drift, repeat across relevant placements, and include the recovery phase after the aggressor stops. Track warmup, thermal state, page placement, retries, and instrumentation overhead. A single favorable percentile can result from small sample size or selection, so retain distributions, event traces, counts, and configuration snapshots. Investigate failures and rerun the affected mechanism after a change. Successful bounded tests support their named configuration; changes to drivers, policies, workload shape, or trust assumptions may require a new assessment.

Reset the sampling lab, explicitly set p=0.5 and sample size 20, predict the sample-mean variance, then Play or Step. For an independent comparison Reset and explicitly set p=0.5 and sample size 80 before predicting again. The variance drops from 0.0125 to 0.003125 under independent identical Bernoulli assumptions. Playback highlights exact possible outcomes rather than drawing samples, and the normal curve is an approximation. Correlated production requests need not follow this model; more repetitions do not repair a biased workload or an incorrect oracle.