Skip to main content

Scenario Classes A–Z

Calculation scenarios bind named inputs to a reusable calculation. These pages document the classes in mlsysim/engine/scenario_definitions/, including their equations, exclusions, examples, and calculated properties. Select instances through mlsysim.Scenarios; the class name describes their shared contract, not a separate registry entry.

Browse scenarios by domain when you know the modeling question; use this alphabetical list when you know a class name.

The generic Scenario scorecard is a different entry point. See Choosing a Python API before selecting one, and the Scenarios Zoo for registry use.

This directory is generated from authored public classes. Inherited methods are documented on BaseScenario; a class page shows the properties and methods that it defines itself.

A

  • AcceleratedFractionScenario: Amdahl’s law with a path gain set by two rates: fraction of the baseline time runs accelerated_rate / baseline_rate times faster.
  • AcceleratorComparison: candidate against baseline: peak, power, and peak per watt.
  • AcceleratorGenerationsScenario: Peak compute against memory bandwidth across accelerators, first to last.
  • AcceleratorInputFeedScenario: accelerators copies of hardware training workload at sustained_rate samples a second each, fed from supply with encoded_sample bytes stored per sample and decoded_sample bytes after decode.
  • AcceleratorPodScenario: A pod envelope of pod.chips copies of accelerator: aggregate peak and memory.
  • AcceptedTaskCostScenario: An attempt of model tokens plus other cost, retried until accepted; optional levers on it.
  • AccuracyDecayScenario: A deployed model read at initial_accuracy and, elapsed later, at later_accuracy; noticed is when someone outside monitoring saw it. decay_rate fits A(t) = A0 exp(-gamma t) through the two readings.
  • AccuracyFrontierScenario: A hypothetical accuracy-against-disparity frontier, floor + span (1 - exp(-rate x)), with named candidate disparities on it.
  • ActivationLogicCostScenario: Logic cost of two activation datapaths, in transistor equivalents (an illustrative budget).
  • ActivationMemoryScenario: Activation memory of workload at a microbatch, under each recomputation strategy.
  • ActiveLearningBudgetScenario: Active learning against a fixed label budget when scoring the pool is charged to the same budget.
  • ActiveLearningRoundsScenario: Active learning from initial_labels adding labels_per_round for rounds rounds, each round paying round_scoring_cost to score the pool, against random labeling that needs random_labels at the same label_price.
  • AdaptationPaybackScenario: A one-time adaptation that cuts each task’s model usage, against its incremental cost.
  • AdmissionOrderScenario: Independent admission checks (pass probability, slot time) run in each of orders.
  • AdversarialTrainingPassesScenario: Work per batch of adversarial training, in standard forward-backward passes (equal cost, no reuse).
  • AgreementDriftScenario: A labeling campaign’s kappa at a baseline and again after elapsed.
  • AlignmentMemoryScenario: PPO and DPO alignment of policy with critic-sized reward and value models.
  • AllReduceScheduleScenario: One buffer reduced by ring, simple tree, and parameter server at each of group_sizes.
  • AllToAllDispatchScenario: One expert-parallel dispatch: total_tokens of hidden_dim values over n_devices holding n_experts.
  • AllocationAxesScenario: One output ceiling spent as one chain, candidates streams, or rounds of feedback.
  • AllocationGrowthScenario: A compute-optimal allocation X_opt ~ C^exponent when compute grows by compute_multiple.
  • AlphaBetaScenario: Named messages on named paths, each path an alpha startup and a beta bandwidth.
  • AlwaysOnDetectorTargetsScenario: An always-on detector’s product contract: what it must catch, how rarely it may wake falsely, what it may occupy on the device, and the data budget and schedule that must deliver it.
  • AmdahlScenario: A sequential request path whose stage is made speedup times faster.
  • AnnFootprintScenario: Resident bytes of a graph index and of product-quantization codes over one corpus.
  • AnnotatorAgreementScenario: Two independent annotators with the same label mix class_shares: chance agreement, and Cohen’s kappa at an observed_agreement.
  • AppendOnlyContextScenario: A trajectory that appends each turn to its prompt and resends the whole history.
  • ApprovalEscrowScenario: Approval escrow for a long-running workload (held resources) and an urgent one (time).
  • ArchitectureChoiceScenario: Single-call designs and a bounded loop under one check, with a human fallback for rejects.
  • ArgmaxNoiseScenario: Argmax over equally good candidates with Gaussian score noise; a rare loophole in the pool.
  • ArgumentConfidenceScenario: A stipulated safety argument: premises required premises at premise_confidence each, and a claim carried by legs independent legs at leg_confidence each.
  • ArmComparisonScenario: Two policies run arm_runs times each, with successes_a and successes_b successes; Fisher’s exact test, and the runs per arm that separate p_high from p_low two-sided at alpha with power.
  • AttemptGroupContrastScenario: attempts independent attempts per fixture at each of pass_rates.
  • AttentionDilutionScenario: One attention head with fixed logits: a target among background keys, optionally look-alikes.
  • AttentionTilingScenario: One head’s attention at seq_len tokens, whole or in square tiles, and what each kernel stores.
  • AutomationBiasScenario: A human reviews an AI’s output; the human accepts miss_acceptance of the AI’s misses.
  • AutomationBreakevenScenario: A pipeline that costs build_time once, against manual_rate of work by hand; the pipeline itself needs upkeep_rate. Break-even is build / (manual - upkeep).
  • AvailabilityScenario: A job that needs all n_components, each up a fraction availability of the time.

B

  • BandwidthDelayScenario: Data a link carries during delay: line rate times delay (for example, a Go-Back-N resend window).
  • BaseScenario: Base for calculation scenarios: a name, a description, and stated inputs.
  • BatchCapChoiceScenario: Two batch caps at one arrival rate, batches waiting until full: throughput against formation wait.
  • BatchDispatchScenario: A dual-trigger batch: it may leave at timeout after its oldest arrival, then waits for a worker.
  • BatchEnergyPerImageScenario: Bytes, arithmetic intensity, and energy per image when a batch shares one weight read.
  • BatchServingCostScenario: One accelerator rented at price, serving batches back to back: cost per request by batch size.
  • BatchVersusStreamingIngestScenario: One event stream ingested by always-on streaming cores or by a batch job each hour.
  • BatchWindowScenario: Requests arriving as a Poisson stream into a batching window of length window.
  • BatchingKneeScenario: Batch service time S(B) = t_0 + B t_req: where throughput turns over.
  • BatteryBudgetScenario: A continuous power_draw against a battery and a required runtime.
  • BeliefExpiryScenario: A belief with initial error, growth law, and task tolerance; optionally admitted at use_age under age_bound.
  • BestOfNPoolScenario: Pools of independent candidates at pass_rate, and a mixed workload with the same average.
  • BiasFeedbackScenario: A gap passed at launch, refit from the next audit, iterated over retraining cycles: gap(k) = launch_gap * factor^k against a release gate (all in percentage points).
  • BinShareShiftScenario: A feature binned at the training quantiles: training shares against recent shares, scored by PSI.
  • BinomialIntervalsScenario: Several success counts out of one number of independent tasks.
  • BlindRetryScenario: Mutating calls retried once after any timeout, with independent request and reply loss.
  • Bm25PairScenario: One query term scored by BM25 in a short and a long document of one corpus.
  • BoundedLiabilityAdmissionScenario: The next model call of a trajectory, tested against its dollar allowance.
  • BrakingBlendScenario: A bumpless transfer into braking on a site’s base at speed, and an arm joint’s blend.
  • BrakingCeilingsScenario: The ceilings on site’s credible deceleration for its loaded machine at the drive limit.
  • BudgetMatchedLabelingScenario: A pool to label at label_price under budget: random labeling spends the budget, active learning reaches the same quality with active_labels.
  • BulkheadAdmissionScenario: One burst of blocking calls to a stalled dependency, uncapped and with a bulkhead.

C

  • CanFdBusScenario: num_axes servo axes on one CAN FD bus, frames_per_axis frames each per cycle.
  • CanaryScheduleScenario: A staged rollout that needs samples_per_variant guardrail samples per stage at request_rate; stages is the configured ladder of (traffic share, duration).
  • CappedSelectionCostScenario: Candidates for one fixed task, an exact checker, and a cap on candidates.
  • CarbonPricedPlacementScenario: A run of it_energy on fleet placed among regions with and without a carbon price.
  • CascadeEnergyScenario: An edge model on every input, escalating a fraction to a cloud model over a radio link.
  • CenteredRewardScenario: Binary terminal rewards centered on a fixed baseline.
  • CertifiedRadiusScenario: Binary randomized smoothing at noise noise_sd, against an l-infinity budget on one input.
  • CheckerPosteriorScenario: A fallible check over candidates, defect_rate of which violate the property.
  • CheckpointIntervalScenario: Checkpoints of workload written at write_bandwidth, against failures every mtbf.
  • CheckpointStormScenario: Every one of replicas writes workload’s full resumable state through one ingest path.
  • CheckpointTraceScenario: Checkpoint strides priced on turns turns that crash after the turns in crashes.
  • ChunkReplacementScenario: Replacing machine’s admitted chunk at site: capture-to-admission latency against the renewal period and the chunk lease, with an interference_tail on the inference pass.
  • ChunkedPrefillScenario: A long prompt advanced chunk_tokens per iteration beside decode.
  • ClearanceQueryScenario: Sphere-hull clearance queries on site.machine’s permission controller, and a snapshot of the stopping corridor.
  • ClickLossScenario: A silent click-through regression from ctr_before to ctr_after at request_rate, caught after detection_time; each click is worth value_per_click.
  • ClockConversionScenario: A sensor clock drifting at drift_rate between syncs every sync_interval, converted under site’s bound.
  • ClosedLoopCampaignScenario: clean_runs failure-free closed-loop trials of a frozen policy in one cell of table on site, each run long with an automated reset, bounded at one-sided confidence.
  • CloudEdgeCostScenario: Serving a network of sites from the cloud (pay per image) or from a device at each site (buy up front).
  • ClusterExpansionScenario: A synchronous job grown from n_devices to factor times as many on the same checkpoint tier.
  • ClusterTrainingTimeScenario: Training workload on n_devices x hardware at one end-to-end utilization (compute-bound).
  • CodecEpochScenario: epoch_bytes decompressed on the host each epoch for epochs epochs, at each codec’s decode_rates.
  • CohortArmRecord: One policy’s outcomes and settled usage over a cohort of attempted tasks.
  • CohortAttemptCostScenario: One configuration’s cohort of tasks, one bounded attempt each, all charges settled.
  • CohortDispositionScenario: A finite cohort of attempts by disposition at a cutoff, its total cost, and the disposition that emits a learning artifact.
  • ColdStartScenario: A new replica: provision, fetch the weight artifact, load and warm up.
  • ColumnProjectionScenario: A model that uses columns_used of columns_total equal-size columns, read from a row or a columnar file.
  • CommandAuthenticationScenario: Remote commands authenticated on a machine’s permission processor, priced against a takeover budget.
  • CompactionCadenceScenario: Compaction between a trigger and a target watermark over a turn budget.
  • CompactionPaybackScenario: One compaction of a billed trajectory: a summary resent fresh, then shorter cached reads.
  • CompilationPaybackScenario: A compiled decode step and the executions that repay its build.
  • CompileBreakevenScenario: Eager against compiled execution: the work that repays compile_time.
  • ComponentExposureScenario: Independent components, each affected with probability (per day, or at one instant).
  • CompressedReadScenario: Compressed shards read at read_bandwidth, decoded on CPU cores at each codec’s output rate.
  • CompressionPaybackScenario: One synchronization compressed by compression_ratio at a codec cost of codec_time.
  • CompressionRunScenario: A run to a quality target with and without gradient compression on several networks.
  • ConfidenceRegimesScenario: Stipulated proposer confidence against task success in several operating regimes.
  • ConfidenceRegionScenario: A Gaussian position estimate with principal standard deviations sigmas: its coverage region against site’s grasp tolerance.
  • ConformalInsetScenario: A split-conformal bound at miss rate alpha from calibration_count residuals.
  • ConservedBudgetScenario: A root budget granted to two children; the second stops with a remote job billed late.
  • ConstraintAccuracyCostScenario: Accuracy before and after a fairness constraint (percent), with the policy’s stated rates.
  • ContactDeadlineScenario: A constant-speed drive into site’s latch plate: when the force ramp k v t reaches the tripwire and the limit, when braking can begin, and the time left, at both approaches.
  • ContactGridScenario: A contact task binned by contact angle and normal force, and the cells each archive occupies.
  • ContextAdmissionScenario: A serialized request (text plus an image charge) against a window with a reserved reply.
  • ContextBudgetScenario: A request budgeted by role, appending each tool result against selecting a fixed share.
  • ContextGrowthScenario: A context window grown from base_tokens to tokens: a kept cache grows with the ratio, attention’s score work and stored scores with its square.
  • ContextInvalidationScenario: A superseded excerpt right after the reused prefix: remove, replace, or append a notice.
  • ContextMemoryCrossingScenario: Three memories of workload as context grows on hardware: fixed weights, a KV cache linear in tokens, and one layer’s stored scores (all heads) quadratic in tokens.
  • ContinuationForkCostScenario: A trajectory whose value is sampled by forking continuations at chosen turns.
  • ContinuousDeratingScenario: A catalog continuous rating carried to a hotter ambient and a worse heat path.
  • ControlledBranchScenario: Fresh continuations from one saved prefix under several branches, counted by outcome; the Wilson bound a clean branch leaves and the clean runs a target_bound needs.
  • ConvBnReluFusionScenario: A convolution, batch norm, and ReLU on one feature map, run as three kernels or one.
  • ConvLayerScenario: One kernel-by-kernel convolution, stride one, over a height-by-width-by-in_channels input to out_channels feature maps; values of bytes_per_value each.
  • CoolingScenario: Coolant flow that carries heat_load at temperature_rise.
  • CoresetRunScenario: workload trained for epochs over dataset on one hardware at utilization, against a keep_fraction coreset scored by one forward pass of workload or proxy.
  • CorpusDenominatorsScenario: A retained pool of record classes (records, stored tokens per record, selected target tokens per record); focus is the class whose shares are read, admitted the classes a route admits.
  • CorpusRepetitionScenario: A training run (ClusterTrainingTimeScenario) set against the unique tokens of its workload’s own corpus.
  • CorpusTierScenario: An audio corpus (dataset) kept on storage tiers at storage_rates and read at read_bandwidths.
  • CorrelatedLogScenario: duration of records logged at rate whose adjacent records have lag-one correlation lag1_correlation: how few independent samples the record count holds.
  • CorrelatedReviewersScenario: Reviewers who each falsely approve with the same marginal rate, independent or correlated.
  • CounterfactualSearchScenario: Replay paths that blame for a failure must search: a whole horizon, or one checked window.
  • CoverageFloorScenario: A keep_fraction coreset drawn without regard to class from pool examples, of which rare_share belong to a rare class that needs at least floor examples.
  • CrashRateDenominatorScenario: A reported before-and-after crash rate and the same comparison on the cohort whose exposure is complete (rates per million miles).
  • CreditWindowScenario: A producer feeding a slower model consumer, unbounded or behind a credit window.
  • CrossEntropyScenario: Cross-entropy losses for named predicted probabilities of the correct class, among classes.
  • CurriculumScheduleScenario: A curriculum that reaches target in curriculum_epochs against baseline_epochs shuffled, with an optional linear warmup of warmup_epochs (epoch j serves j/W of the data).
  • CycleBudgetScenario: Stage sub-budgets of one permission check against site’s declared WCET and deadline.

D

  • DailyUploadScenario: A site’s daily captures sent over its uplink inside a working window, against compact summaries.
  • DataBudgetScenario: A data budget split into shares by category; the labeling share buys labels at label_price plus review_overhead for quality review.
  • DataCostBreakdownScenario: A supervised dataset’s bill: acquisition, labels at label_price, storage_bytes kept for storage_duration at storage_rate, and runs training runs of run_time each on accelerators at accelerator_rate.
  • DataEchoingScenario: A host that prepares host_rate samples a second feeding an accelerator that consumes accelerator_rate, over epochs of examples, with each prepared sample used echo_factor times.
  • DataMovementEnergyScenario: One weight of bytes_per_param used for flops_per_param FLOPs at stated per-op energies.
  • DataParallelAttackSurfaceScenario: workload trained on fleet with dp_degree data-parallel replicas: the gradient each step exchanges, the checkpoint it writes, and the traffic of a robust aggregate that gathers every replica’s gradient instead of a ring AllReduce of their sum.
  • DataParallelIntensityScenario: Communication intensity of one data-parallel worker of workload.
  • DataParallelScaleOutScenario: A data-parallel job of workload on nodes nodes, from a one-device profile.
  • DataScalingReturnScenario: Growing a dataset from base_examples to scaled_examples for accuracy_gain points.
  • DataStallScenario: A batch delivered in io_time against compute_time of compute, in sequence or overlapped.
  • DeadlinePolicyScenario: One candidate, breadth in parallel, or feedback, for one task under one deadline.
  • DecisionChainScenario: links independently kept decision records behind one admitted action, each retrievable with probability p; the whole chain resolves with p^links for each p in link_probabilities.
  • DecodeBudgetScenario: A constructed decode-step budget, cut interval by interval, against a TPOT target.
  • DecodeScenario: One decode step of workload on hardware (weight-streaming bound).
  • DecoderFamiliesScenario: One fresh machine.chunk_horizon-step chunk from backbone, per decoder family.
  • DedicatedBreakEvenScenario: Renting a matched-capability API against owning capacity at a fixed hourly cost.
  • DeficitRoundRobinScenario: Backlogged request classes sharing model calls under weighted deficit round-robin.
  • DelayPhaseMarginScenario: A loop with phase_margin at crossover, closed through a pure delay.
  • DelegationCohortScenario: A single controller and a delegated design on one matched cohort, priced alike.
  • DelegationTokenBreakEvenScenario: Delegation at a token multiple m per attempt: cost per accepted task scales by m p_single / p_multi.
  • DemandReboundScenario: Per-unit energy scaled by a factor (or by a unit-price ratio) while volume scales by another.
  • DemonstrationCampaignScenario: Scheduled sessions of attempt-and-reset cycles: demonstrations kept per session, the campaign that keeps target_kept of them, and the wear it puts on a gear and a cable.
  • DenseLayerScenario: One dense layer: in_features inputs to out_features outputs, bytes_per_weight each.
  • DenseNetworkScenario: A dense network of layer_widths at batch_size: parameters, FLOPs, traffic, memory.
  • DenseScalingSweepScenario: Dense networks between a fixed input and output, swept in hidden width and in depth.
  • DependencyScheduleScenario: A dependency graph on interchangeable slots: aggregate work, the critical path, and both bounds.
  • DesignTradeoffScenario: One design-space move of a knob from baseline to alternative, with an illustrative quality gain from gain_low to gain_high (fractions); costs scale by ratio.
  • DetectionDelayLossScenario: A fault that cuts quality_drop of annual_value until it is detected, found after slow_detection or fast_detection, incidents_per_year times a year.
  • DetectionShortfallScenario: site.machine at speed with a stop sized for a group detected in reference of frames, met by groups detected less often; misses allowed in every frame with probability all_miss_probability, frames independent.
  • DevelopmentSweepScenario: A sweep of candidates runs, each costing relative_cost of the final run.
  • DiagnosticCoverageScenario: Fault-rate strata (FIT) to be left at most target FIT unmitigated, shown at confidence.
  • DisclosurePenaltyScenario: Penalties for an incomplete account: days_withheld at daily_maximum each, plus others (name -> amount), all in USD.
  • DiscountHorizonScenario: One rollout of decisions step apart under discount discount: how far the return reaches, in decisions and in seconds, and the discount that keeps retained_weight of the final reward at the first decision.
  • DiurnalLendingScenario: A fleet split between a serving reservation and a training base, static against lent.
  • DominantShareScenario: Dominant-resource fairness by progressive filling of indivisible bundles on capacity.
  • DpSgdRunScenario: Inputs a DP-SGD privacy accountant needs for one Poisson-sampled run on dataset_size examples; this type does not estimate epsilon.
  • DpTrainingPlanScenario: An illustrative differential-privacy planning scenario for one training run of base_cost.
  • DriftConfirmationScenario: Labeled outcomes that confirm a drop of drop from baseline_accuracy.
  • DriveBusScenario: site.machine’s shared drive bus: a coincident load step, and a stop from the drive limit into it.
  • DualBankUpdateScenario: An over-the-air update that keeps a second flash bank: two copies of model at bytes_per_param in the flash of device.
  • DuplicateRemovalScenario: Near-duplicate shares removed from run’s corpus: the training time and energy each share returns, against one read of the corpus and the MinHash signatures of its documents.
  • DutyCycledPowerScenario: An always-on detector, a stage active a share of the time, and a full model run per event.
  • DynamicReachScenario: A target target_distance from the gripper at cadence.machine’s TCP speed ceiling, against the cadence scenario’s evidence windows.
  • DynamicWindowScenario: machine’s base over one chunk renewal at site: its dynamic window and the classical admissible speed against the site’s clear distance and credible deceleration.

E

  • EfficiencyClaimGapScenario: A datasheet operating point against a sustained one: operations per watt at each, and their ratio.
  • ElasticResizeScenario: Three ways to run one job over window: start small, wait for the full size, or step up.
  • ElementwiseIntensityScenario: An unfused elementwise operation: flops_per_element FLOPs while operands_moved values of bytes_per_value each are read or written.
  • ElementwiseOpScenario: An element-wise or normalization kernel over elements values, run unfused.
  • EmbeddingGatherScenario: One recommender request on hardware: one row of width values per categorical feature of dataset is gathered, then the rows and the bottom MLP’s output interact by pairwise dot products.
  • EmbeddingTableScenario: tables embedding tables of rows rows, each width values wide, against hardware.
  • EmbodiedPaybackScenario: A replacement for device that does its work with saved_fraction less energy, on named grids.
  • EncoderRateScenario: An encoder of flop_per_frame on every site.machine navigation frame, against the host SoC’s dense FP16 peak.
  • EncryptedInferenceLatencyScenario: One inference at plaintext_latency, with symmetric encryption around it (encryption_overhead) and computed under homomorphic encryption (fhe_multiplier).
  • EnergyPerInferenceScenario: Energy per inference across tiers: solver-derived device energies plus stated anchors.
  • EnvelopeAmortizationScenario: calls sequential calls of work_per_call, with envelope setup paid per call or once.
  • EpochGapScenario: Named acquisition epochs in one cycle; the pair to fuse is projected across its gap at speed.
  • EpochOverheadScenario: One training epoch of network on a host CPU and an accelerator: work against fixed overhead.
  • EqualOpportunityPriceScenario: Utility per applicant of raising group’s TPR to reference_group’s by moving its threshold, when that move raises its FPR by fpr_increase: a repaid loan earns repay_margin, a default loses default_loss (both USD).
  • ErrorFeedbackScenario: A rounding compressor applied to a gradient sequence, with and without error feedback.
  • EstimatorConsistencyScenario: A qualification campaign of runs scalar estimates, and single-update gates against fusion’s misdated update.
  • EtherCatCycleScenario: num_axes drives on one EtherCAT chain, bytes_per_axis of process data each per cycle.
  • EventRetentionScenario: Event-triggered retention: pre_trigger before and post_trigger after each of events_per_day events, against keeping the whole operating_day.
  • EvidenceHorizonScenario: site’s conveyor target tracked by machine’s chunk policy: evidence horizon against renewal.
  • ExactScanScenario: An exact vector scan on one host: bytes, intensity, and the bandwidth floor.
  • ExpertWeightTrafficScenario: Weight bytes of the mixture-of-experts workload, resident and read per token, against a dense model of dense_parameters that reads every weight each step.
  • ExplanationLoadScenario: Reasons owed for every denial: decisions_per_day at denial_share, each explained by a sampling attributor of samples model evaluations or by exact Shapley over features.
  • ExplanationLogScenario: Logging an explanation with every prediction: predictions_per_day for days_per_month, each a map_size_low to map_size_high attribution map (or tabular attributions of attribution_bytes_low to attribution_bytes_high per feature).
  • ExplorationExposureScenario: A ranking service showing slots_per_user items a day to daily_users from a catalog of catalog_items, with explore_share of slots served by randomized exploration.
  • ExponentialRareEventScenario: An exponential delay of mean that fails past the delay spare of budget (or threshold).
  • ExposureConcentrationScenario: encounter_share of a site’s machine-person encounters fall on user_share of its people: their per-person exposure against the site average, and everyone else’s.

F

  • FacilityPowerScenario: devices accelerators at device_power in racks shaped like rack, at pue.
  • FailureIntervalScenario: n_components identical components, each with component_mtbf, over a run.
  • FailureIntervalSweepScenario: Interval between failures of component_mtbf components, at each job size in sizes.
  • FailureTriageScenario: runs trajectories a month failing at failure_rate, each probe’s attributed share, and a fine-tuning run on every failure of workload on devices x hardware.
  • FalseAlarmBudgetScenario: One detection window every window, listening_per_day of each day, over horizon.
  • FanoutDeadlineScenario: A fan-out whose workers each finish by the deadline with one probability, independently.
  • FatTreeScenario: A non-blocking fat-tree of radix-radix switches (Al-Fares et al. 2008).
  • FeatureHistoryScenario: Full-snapshot feature history: entities x features values every update_interval, kept for retention, each row a value, an entity key, and timestamps timestamps.
  • FeatureLookupScenario: An online service at request_rate that reads reads_per_request stored features per request.
  • FederatedUplinkScenario: A week of raw captures against compressed model updates sent at named round cadences.
  • FixedBatchScheduleScenario: Requests in one batch of fixed membership, one token per iteration.
  • FleetMfuScenario: Program goodput (MFU) of a training step on one node and on a fleet of fleet_devices.
  • FloatBitFlipScenario: One stored binary32 value with bit flipped_bit flipped (bit 30 is the top exponent bit).
  • ForceRiseGapScenario: An illustrative linear drive regulating target_force against a surface, in simulation and on hardware, with one stated discrepancy in each reality-gap channel: dynamics (force-rise rate and drive delay), timing (p99 actuation delay against the simulator’s), sensing (range bias and dropout), and appearance (pixel difference hiding a contact-patch shift).
  • ForceTailScenario: A contact force over trials trials with a benign mean_force and a p99_force tail, against site’s tripwire and structural limit.
  • ForkValueScenario: Binary continuations forked before and after one turn, with their pass counts.
  • ForwardOccupancyScenario: A coworker’s forward occupancy set at cadence.site’s design approach speed, screened over the cadence scenario’s evidence windows and over a forecast horizon, against the aisle.
  • FrameCompressionScenario: A per-frame model against a camera frame rate: the full model and a channel-pruned variant, run in floating point on the CPU and in integers on the accelerator.
  • FrameRateHeadroomScenario: workload at frame_rate on an accelerator of peak_rate that sustains a utilization_low to utilization_high share of peak; alternative_flops is a heavier model per frame.
  • FreeSpaceExpiryScenario: site’s rack end: free space ahead (clear distance) and abreast (side clearance) eroding at the walking speed.
  • FreshnessProfileScenario: A target moving at site’s conveyor speed, grasped through a staged capture-to-onset pipeline.
  • FrozenTransformScenario: site’s conveyor object tracked by a camera lost at loss_time; its last transform republished every republish_period.

G

  • GaussianDriftScenario: A continuous feature fitted as a normal at reference and now: KL divergence of the reference from the current fit.
  • GearRatioCostScenario: motor in joint holding output_torque through each of ratios.
  • GearedRotorScenario: A rotor seen through a gear_ratio reduction, beside a link of load_inertia.
  • GoalSetMembershipScenario: Terminal TCP offsets along one axis tested against a goal set whose semi-axes all equal site’s grasp tolerance: the normalized ellipsoidal distance, inside when at most one.
  • GoodputScenario: ML productivity goodput of a job on a pool: scheduling, runtime, and program goodput.
  • GradientChainScenario: The activation-slope factor a gradient keeps after depth layers, at each slope’s peak.
  • GradientSyncScenario: A data-parallel step of workload: compute, then a ring AllReduce over each link.
  • GraphNeighborhoodScenario: A typed traversal’s exact-tree neighborhood against a call’s retrieval allowance.
  • GravityBiasedJointStopScenario: One loaded arm joint at joint_speed braking with machine’s peak torque while gravity holds bias_fraction of that peak along (descending) or against (ascending) the motion.
  • GridPlacementScenario: One facility energy placed on each named grid, with an optional fractional energy cut.
  • GripperTransferScenario: A normalized gripper command from a donor gripper replayed on a target with a shorter stroke and a lower continuous force rating, against a part of part_width.
  • GroupBarrierScenario: The rollout latencies of one synchronous group.
  • GroupCoefficientsScenario: The rewards of one group of rollouts and the coefficient convention applied to them.
  • GroupCommitScenario: batch_size intents gathered for up to batch_timer and acknowledged by one flush_time.
  • GroupConfusionScenario: Binary decisions for two or more groups as confusion counts {group: {tp, fp, fn, tn}}.
  • GrowthGapScenario: Compute doubling every compute_doubling_period against bandwidth growing bandwidth_growth a year.

H

  • HandoffExposureScenario: A replanner at replan_rate over mission_time whose handoffs are each late with late_probability, held to mission_budget for the whole mission.
  • HazardExposureScenario: Failure-free exposure that bounds each of rates (constant hazards per hour) at one-sided confidence, against what rigs rigs or one rig over rig_time accumulate.
  • HeadSamplingMissScenario: Head sampling keeps each trial with retention_probability, decided before its outcome; a failure mode that occurs occurrences times leaves no detailed trace with miss.
  • HeadingDriftScenario: A persistent heading_offset at machine’s drive limit in site’s aisle: the angular error an open-loop replay scores, and where the closed loop spends the side clearance (y = v sin(eps) t).
  • HealthProbeScenario: A readiness probe every interval, failing after timeout, removing after failure_threshold misses.
  • HierarchicalAllReduceScenario: A buffer AllReduced over n_nodes nodes of gpus_per_node GPUs, in three phases or one flat ring.
  • HoldIntervalDriftScenario: Drift while a drive holds the last command for one period: travel at speed plus the half acceleration period^2 an independent acceleration bound allows.
  • HopPathScenario: Named paths through hops identical switch traversals of hop_latency each.
  • HorizonCompoundingScenario: Independent, unchecked steps each right with step_success; success at each horizon.
  • HostAcceleratorBoardScenario: One board, a host CPU and an attached accelerator: model-only and end-to-end latency, active energy.
  • HostDispatchScenario: The host’s work to issue one eager step against device_time of accelerator work.
  • HostInputPipelineScenario: A data loader feeding one accelerator over its host link.
  • HostIoCpuScenario: devices each consuming requests_per_device reads per second, at each path’s CPU service time.
  • HostMapSizingScenario: A workcell of extent mapped at pitch: dense grid against a hashed band of band_half_width around surface_area.
  • HotSpareScenario: spare_devices held idle beside the job in failures, priced at device_hour_rate.
  • HubDriveElectricalScenario: Current rise and phase-short braking of site.machine’s hub drives on a depleted bus.

I

  • IdleCapacityCostScenario: gpus accelerators held idle for duration at device_hour_rate.
  • ImitationBoundScenario: Worst-case imitation cost over one episode at control_rate with per-step error per_step_error: open loop, behavioral cloning, and aggregation with recoverability u.
  • IncastScenario: n_senders at sender_bandwidth into one egress port with a buffer.
  • IndexMaintenanceScenario: One edit’s synchronous re-indexing against exclusion of the stale entries.
  • InertialCoastScenario: site.machine’s IMU coasting duration without a fix, seen at the rack-end distance.
  • InformationComputeRatioScenario: Accuracy gained per training FLOP for one epoch over all of dataset and over a keep_fraction subset, with gain_full and gain_subset points of gain.
  • InjectionExposureScenario: Workloads reading reads untrusted items each, a fraction payload_fraction carrying a payload, with and without a screen that misses miss_rate of payloads.
  • InlineOverheadScenario: A safeguard added inline to a request path of base_latency, costing overhead_low to overhead_high (fractions of the base) per request.
  • InputDemandScenario: consumers each read samples_per_step samples per step_time of compute.
  • InputSpaceScenario: Every possible input of dataset’s image shape: levels values per channel element.
  • IntentCadenceScenario: site’s conveyor target proposed by machine’s intent model: evidence horizons against the model’s cadence, a host stall of stall, and the stop onset after expiry.
  • IntentLeaseExpiryScenario: The intent lease for the cadence scenario’s target: its evidence horizons, an administrative_lease, and the stopping deadline from clearance at the TCP speed ceiling, with the arm’s credible deceleration from its handbook worst-case stop.
  • InterventionCampaignScenario: interventions interventions in missions supervised runs of mission: burden per hour and per kilometer, and an exact two-sided 1 - alpha interval on the rate.
  • IronLawScenario: The iron law’s three terms for one task, and an upgrade to the memory or compute term.
  • IrreversibleLossScenario: A workload’s wrong-change risk priced with its pre-pivot check, from its agent profile.
  • IterationBudgetScenario: Two teams in one development window: a slow cycle against a fast one, with assumed gains per run.
  • IterativeDecoderBudgetScenario: machine’s one-pass chunk decoder against an iterative head that encodes once and runs denoising_steps dependent evaluations in denoising_latency, and a flow_steps head at the same cost per evaluation, on the setpoint step and the renewal period with renewal_jitter held free.

J

  • JacobianScenario: The full Jacobian of one layer from input_width inputs to output_width outputs.
  • JerkLimitedStopScenario: A machine at speed that stops along an S-curve at deceleration after delay.

K

  • KernelFusionScenario: A chain of chain_length element-wise operations, run as one kernel each or fused into one.
  • KernelShareScenario: One kernel class’s multiply-adds against a whole model’s, per example.
  • KingmanQueueScenario: One server under Kingman’s approximation at two utilizations, with a holding price.
  • KsDriftScenario: A two-sample K-S drift test of n_reference training against n_current recent values of one feature.
  • KvAdmissionScenario: A replica’s KV budget against one context length (KvAdmissionModel).
  • KvAttentionDesignScenario: Bytes per token across registry models, with one MHA, one GQA, and one MLA reference.
  • KvBlockSharingScenario: Requests with an output allowance in whole blocks, with and without a shared prefix, as a turn rate.
  • KvDecodeBatchScenario: Batched decode on one accelerator when every sequence also reads its own KV cache.
  • KvFootprintScenario: workload’s KV cache for tokens kept tokens; with hardware and kv_share, how many such requests the cache’s share of the labeled device memory holds. kv_width_factor scales the key-value width (one half: half the key-value heads).
  • KvForkCopyScenario: Candidates forked from one prefix, each copying the prefix’s KV state without block sharing.
  • KvHistoryScenario: Key-value cache for history_window of retained context at history_rate beside machine’s weights.
  • KvResidencyArchetypeScenario: One agent workload’s sharing gain, residency tax, and reload against recompute.

L

  • LabelGranularityScenario: Label entries for one image: a per-pixel mask against boxes boxes of coords_per_box.
  • LabelingVersusTrainingScenario: A labeling budget against one training run: epochs over dataset_examples at throughput_per_accelerator on accelerators, priced at a low and a high hourly rate.
  • LaborEffortScenario: items labeled by hand at time_per_item each: total hours and full-time person-years.
  • LaplaceMeanReleaseScenario: The mean of a public roster of group_size values in [0, value_range] released under epsilon-DP by one Laplace draw on the sum (replace-one adjacency).
  • LatchSeriesSpringScenario: A series spring sized so machine’s arm stays under site’s declared latch floor.
  • LateConstraintScenario: A model built without its deployment limit, the day the limit surfaces, and the repair it forces.
  • LayerStackScenario: Weight-only count of a network built from convolution and dense layers, input first (biases omitted).
  • LeaseBudgetScenario: site.machine’s chunk lease at speed: its stopping-budget cost and the lease rule’s bounds.
  • LengthNormalizationScenario: Two rollouts with one group coefficient and different lengths, averaged per rollout.
  • LidarSweepAgeScenario: site.machine’s spinning lidar at speed: sweep motion and the age of the aisle sector at the rack end.
  • LifecycleTcoScenario: Monthly lifecycle cost in four terms (training, inference, data, iteration), each counted once.
  • LinkBuildoutScenario: links_per_device links per accelerator of fleet, each with a price and a module power.
  • LittlesLawScenario: Requests in flight at arrival_rate, and replicas sized from a batch service time.
  • LossNormalizationScenario: A long trajectory split into focus_pieces records, batched with other_examples short ones.
  • LowRankUpdateScenario: A rank-rank update to one out_dim by in_dim weight matrix.

M

  • MM1CapacityPlanScenario: Accelerators for peak_rate when each is an M/M/1 server whose tail must meet tail_budget.
  • MM1ServiceSpeedupScenario: The same traffic on an M/M/1 server before and after its service time falls.
  • MaterializedScoresScenario: Attention scores stored in full: seq_len^2 per head, heads per layer, layers layers.
  • MatmulTileScenario: C = A B with A m x k and B k x n, computed one tile_m x tile_n output tile at a time, stepping through the reduction tile_k elements per step.
  • MeanShiftTestScenario: A feature mean that moves from reference_mean to observed_mean over n_samples requests.
  • MeanVersusTailScenario: A benchmark’s mean latency against a production tail stated as a range.
  • MembershipAuditScenario: A membership-inference audit on the ROC plane against the ceiling a pure epsilon-DP release allows; the audit curve FPR + a FPR (1 - FPR) is illustrative.
  • MemoryRoundTripScenario: A tensor of tensor_bytes crossing to and from memory trips times at energy_per_byte (a layer boundary writes it and the next layer reads it back).
  • MessageFusionScenario: count small messages sent one by one against one fused message on the same path.
  • MinHashBandingScenario: A MinHash signature cut into bands bands of rows hashes over shingle_words-word shingles.
  • MissionExposureScenario: Failure-free missions of mission at machine’s drive limit, with reset between them, that bound hazard_rate at one-sided confidence; and the exposure a relaxed target of one failure per relaxed_mtbf needs.
  • MlpTrainingStepScenario: One eager training step of a one-hidden-layer MLP, operator by operator.
  • ModelCallScenario: One call of prompt_tokens (+ instruction_tokens) in and output_tokens out at floors.
  • ModelCascadeScenario: A tiered cascade over a completed cohort, every exit under one gate, against the top tier alone.
  • ModelPollingScenario: A model that checks a pending job at a fixed interval until it completes.
  • MonitorFleetAlertScenario: models x metrics_per_model monitors checked every check_interval at a per-check false_positive_rate on a stable process; dedup_share of crossings are merged away.

N

  • NicSharingScenario: One NIC split into n_virtual_functions rate-capped slices, and a burst at full line rate.
  • NodePackingScenario: Jobs of job_gpus GPUs packed on nodes nodes of gpus_per_node.
  • NoisyNeighborScenario: Tenants sharing a KV pool and a replica, one of them bursting, with and without quotas.

O

  • ObjectStorageBillScenario: A dataset kept in object storage for a billing period and read reads times across a boundary.
  • ObservationAgeScenario: site.machine’s navigation-camera observation age at speed, with a batch_frames comparison.
  • ObservationCarryScenario: A raw tool output sized in windows, and its shaped view carried by later calls.
  • OdometryDriftScenario: A square-path odometry benchmark’s return errors, priced against site’s localization bound at its aisle speed and length.
  • OffloadDeadlineScenario: One input sent over an uplink to a remote model, against a per-frame deadline (lower bound).
  • OffloadEnergyScenario: Energy to send payload by radio against running the model locally.
  • OnRobotFineTuneScenario: interaction_steps setpoints step apart collected on the machine to absorb a plate_offset, of which exceed_fraction cross the contact tripwire.
  • OnsetTrialScenario: A stopping trace that begins braking at onset after the reference event of oracle.
  • OperationEnergyComparisonScenario: A wide and a narrow format’s energy per add, multiply, and multiply-accumulate, and one memory read against the narrow multiply-accumulate. The narrow MAC accumulates in a wider integer, so its add is accumulate_add.
  • OperationalCarbonScenario: Operational carbon = energy x PUE x grid intensity.
  • OperationalLoadScenario: Assumed operational-load shapes for N models: alerts a N, deployments N ln N, and pairwise conflicts c N^2 against one team’s team_capacity.
  • OptimizationPaybackScenario: An optimization costing implementation_cost that cuts a monthly_bill by reduction.
  • OutageScenario: A failure domain of failed_devices down for repair_time during a job on fleet.
  • OutputShapingScenario: An API that returns the top top_k of class_count scores, rounded from from_decimals to to_decimals decimal places.
  • OverlapBudgetScenario: Layer-by-layer gradient AllReduce of workload: sequential against overlapped with backward.
  • OversightTimeScenario: A person asked to act through budget (a TakeoverBudgetScenario) against the time the hazard at its site leaves: the clear distance at the request speed.
  • OversubscriptionScenario: A ring AllReduce whose edges all cross the bisection of fleet, at 1:1 and at oversubscription_ratio.
  • OwnVsRentScenario: Owning gpus accelerators against renting them at rent_rate per GPU-hour for utilization of every hour, over years.

P

Q

  • QuantizationGridScenario: Values stored on a bits-bit integer grid over a clipping range.
  • QuantizedAcceptanceGatesScenario: A float model and its quantized copy against acceptance gates set before compression.
  • QuantizedDeploymentProfileScenario: A float model and its INT8 version on one accelerator, judged against acceptance limits.
  • QueryExtractionBudgetScenario: An extractor that needs extraction_queries answers from a priced API, under three billing regimes: pay per query, a paid tier capped per day, and a lifetime per-principal allowance after which every query is billed at the per-query price.
  • QueueWaitScenario: A fleet modeled as one M/G/1 server at offered load utilization.
  • QuotaLendingScenario: A team guaranteed guarantee GPUs that uses used_share of them; the rest can be lent.

R

  • RailDroopScenario: A current step delta_i in rise_time through a package’s inductance and resistance, and the alpha-power gate-delay stretch at the drooped rail.
  • RailHoldUpScenario: site.machine’s backed permission rail, its feed lost during the longest admitted stop.
  • RangeFusionScenario: The range to site’s rack-end upright, predicted over one lidar sweep and updated by the lidar, then stereo; the stereo update misdated by age’s arrival stamp at speed.
  • RateTargetScenario: evaluation held against a target_rate: one fresh evaluation per period, not pipelined.
  • RatioClipScenario: One token’s old probability under a symmetric ratio clip.
  • RaymarchTrafficScenario: One depth stream ray-marched into a map on site.machine’s host SoC.
  • ReasoningLatencyScenario: Serial reasoning tokens before the answer, at a fixed time per token.
  • RecoveryBudgetScenario: Cold restarts of workload after failures of n_devices components of component_mtbf.
  • RecurrentStepScenario: One step of a recurrent layer: input_dim inputs, a hidden_dim state, and gates affine maps per step (one for a plain RNN, four for an LSTM); steps steps in a sequence.
  • ReferencePassingScenario: Children handed a pasted repository slice, or a reference and the files they then read.
  • ReferenceTrainingStepScenario: One optimizer step of a reference pretraining job, fixed once for every chapter that quotes it.
  • ReferentSetScenario: Raw per-box scores of retained candidates screened by a conformal threshold calibrated on calibration_count scenes at miss rate alpha, whose calibration score is threshold_score.
  • ReleaseFootprintScenario: Resident copies of model that release controls hold on device.
  • RepairBreakEvenScenario: One bounded repair attempt against compensating and rebuilding to the same endpoint.
  • RepeatedVerificationScenario: A timing-sensitive check repeated on one candidate, with an all-pass rule.
  • RepeatedWorkEnergyScenario: fleet’s accelerators at rated power, rolled back by each named interval.
  • ReplayBufferScenario: A rewind buffer at site.machine’s IMU rate reaching back one observation age.
  • ReplicaStartupScenario: A serving replica’s startup phases; warm_path and cold_path name the phases each start pays.
  • RequestZonesScenario: One serialized request laid out in zones, the leading ones an invariant shared prefix.
  • ResendCacheBillScenario: An append-only trajectory (TrajectoryResendScenario) billed under one tariff, with and without reuse.
  • ResidualAdapterScenario: Residual bottleneck adapters of width to bottleneck, one at each of sites.
  • ResidualShareScenario: A residual equal to residual of the one-device step, on devices devices.
  • ResidualViolationScenario: A residual per-step rate of violating proposals over horizon steps, for a day’s trajectories.
  • ResponseTimeScenario: site’s permission check as a periodic task: R = C + B + I against its deadline.
  • RestrictedTransitScenario: site’s aisle leg at restricted_speed against its normal aisle speed.
  • RetentionCostScenario: One trajectory’s log (turns x envelope and payload) and workspace snapshot kept for period.
  • RetrainingIntervalScenario: Retraining a model whose accuracy decays as drift fits it, serving query_rate queries worth value_per_query per unit accuracy, at run_cost a run. footprint and accelerator_price price the compute share of a run; compared_intervals and scheduled_interval are cadences to compare with the optimum.
  • RetrievalPayloadScenario: Whole serialized records staged in what a call’s window leaves for retrieval.
  • RetryAmplificationScenario: Nested retry layers, each with its own allowance, under one failing logical operation.
  • RetryJitterScenario: A cohort of eligible retries released together, synchronized or with full jitter.
  • RetryPolicyScenario: A cheap attempt retried up to a cap, run as a batch, or one stronger attempt.
  • RevenueRegressionScenario: A metric regression that cuts revenue in proportion for undetected (or for alerted with an alert and containment); revenue is weekly_revenue per week.
  • ReviewStaffingScenario: Substantive human review: appeal_rate of decisions_per_day at time_per_case each, staffed in shift-long shifts; optionally against a reported compare_cases handled at compare_time_per_case.
  • RewardCompositionScenario: One update’s rollouts scored by a verifier that accepts some failures.
  • RingAttentionScenario: Ring attention on accelerator: the smallest chunk that hides each K/V tile, per link.
  • RingTraceScenario: A ring AllReduce traced step by step on one short integer vector per GPU.
  • RoadExposureScenario: Miles-to-demonstrate requirements per event class (zero failures, precision, improvement), in millions of miles at human benchmark rates per 100 million miles, against one dated fleet_miles total (millions) at one-sided confidence.
  • RollingShutterScenario: site.machine’s rolling-shutter navigation camera at speed, turning at the site’s yaw rate toward the rack end.
  • RolloutExposureScenario: Users exposed until rollback under an all-at-once cutover against a canary share, with the same request rate, harm, and time to rollback.
  • RolloutSlotCycleScenario: Sandbox slots running one episode at a time, with a cold and a snapshot reset.
  • RolloutStepBudgetScenario: One update’s tasks, group size, rollout length, and the policy’s pass rate on the mix.
  • RooflinePointScenario: A workload of intensity on hardware’s roofline: attainable rate and share of peak.
  • RunAmortizationScenario: A one-time investment of build_cost plus operating_cost that saves saving_per_run on every training run that reuses its output.
  • RunFootprintScenario: A training run of device_hours on devices of device: energy, carbon, embodied carbon, water.
  • RunSplitLeakageScenario: attempts runs per task, each assigned to training with probability train_fraction.
  • RuntimeGoodputScenario: Runtime goodput of a job on failures.n_devices devices over a held window.

S

  • SameTestSetAccuracyComparisonScenario: Two models scored on the same n_samples test items: independent-set interval and McNemar’s limit.
  • SampledDecisionMonitorScenario: Per-group metric monitoring of a decision service at request_rate.
  • SamplingScenario: One fixed logit vector at a base and a sharpened temperature, then top-p at the base.
  • SandboxPoolReserveScenario: A warm sandbox pool under steady arrivals: active leases, a standby reserve, and memory.
  • ScalabilityLawScenario: Relative capacity N / (1 + sigma (N - 1) + kappa N (N - 1)) over integer worker counts.
  • ScalingOverheadScenario: A planned speedup when communication and coordination take a share of the scaled step.
  • ScenarioTableCoverageScenario: A scenario table of offsets by speeds joined against an archive demonstrated within logged_offset at demonstrated_speed, plus recovery collections at added_offsets.
  • SchedulingSnapshotScenario: One snapshot of a shared pool’s in-service capacity, read at the scheduling boundary.
  • ScopedRevisionScenario: A candidate plan of equal nodes, replaced_nodes of which a refuted premise invalidates.
  • ScreeningRequirementsScenario: A screener’s release floors and device budget, with measured slices checked against the floor.
  • SdcExposureScenario: Silent-corruption exposure of n_devices, each at event_rate per device-hour, per step_time step.
  • SeamBridgeScenario: A velocity_gap at a chunk seam on joint, closed in one tick or by a quintic bridge over bridge_duration, against machine’s arm torque-rate limit. loaded_inertia (optional) prices the one-tick step with the payload’s inertia added.
  • SearchAccountsScenario: Flat best-of-N against beam search over the same task, kept as separate accounts.
  • SegmentAccuracyScenario: Accuracy measured separately on each traffic segment; traffic_shares and accuracies are keyed by segment name.
  • SelectionBudgetScenario: Selection that takes selection_time and leaves a subset that trains in subset_time, against full training in full_time (the selection inequality in hours).
  • SelfContainedReplicaScenario: The smallest model replica of workload whose training state fits without sharding.
  • SemiSupervisedCostScenario: A supervised baseline with supervised_labels and supervised_compute against a semi-supervised run with ssl_labels and ssl_compute, labels at label_price.
  • SensorBiasDriftScenario: A steady reading whose sensor bias drifts at drift_rate for span, while the estimator reports reported_sigma.
  • SensorUplinkScenario: streams raw video streams against a shared link, and the event records that replace them.
  • SequencePackingScenario: Stored example lengths against capacity-token buffers.
  • SequentialCanaryScenario: A canary monitor: Wald’s SPRT between acceptance p_base and a specified degraded p_degraded at targets alpha (false hold) and beta (missed degradation), on fraction of eligible tasks arriving at arrival_rate, labels label_delay late.
  • SequentialTestScenario: Wald’s SPRT between an unacceptable failure rate p_unacceptable and an acceptable one p_acceptable at error rates alpha and beta; the score after trace_clean_runs clean runs and one failure; and the fixed zero-failure test for success 1 - p_unacceptable at the same alpha.
  • SerialEpisodeScenario: One serial episode as disjoint intervals; the model’s intervals sped up by model_speedup.
  • SerialTailExposureScenario: Serial calls that each exceed their own tail latency independently.
  • SeriesFailureScenario: A synchronous job on n_devices that stops when any one component fails.
  • ServiceLifeExtensionScenario: A hardware service life extended from short_life to long_life.
  • ServiceLifecycleCostScenario: A service’s multi-year cost in three terms: repeated training cycles, recurring inference, and operations, with a GPU-hour carbon factor.
  • ServingConsolidationScenario: Small and large serving models on whole devices, exclusive against shared in pairs.
  • ServingCostScenario: One model version’s training spend against its first year of serving.
  • ServingCrossoverScenario: Serving requests_per_day at energy_per_request against a one-time energy.
  • ServingInstanceCostScenario: Instances with an hourly price and a saturated request rate: cost per request, and when the small instance sized to the load undercuts one large instance.
  • ServingScenario: Serving workload on hardware at a stated context and batch (ServingModel).
  • ServingTaxScenario: A request’s latency target split between model execution and everything outside it.
  • ShardPackagingScenario: files samples packaged into shards large files on a file system rated at rated_bandwidth.
  • ShardedUnlearningScenario: Exact unlearning by sharded retraining (SISA) against a full retrain of workload.
  • SharedDramReadScenario: site’s permission tick placed on the machine’s application SoC, its snapshot read queued behind backlogs on the shared DRAM controller.
  • SharedWriteScenario: Workers each writing writes_per_worker of files files, uniformly and independently.
  • ShieldCoverageBillScenario: A fleet’s zero-event proposal log and a shield’s tested coverage against a hazard target.
  • ShortenedWindowScenario: An observation window cut to window_share of its adopted length; samples scale with it.
  • ShoulderSwingScenario: machine’s shoulder holding its rated payload at full planar reach, with joint’s reflected rotor inertia, swinging swing rest to rest inside its datasheet limits.
  • SilentSlowdownScenario: A run on fleet slowed a few percent by a degraded link, with no alarm.
  • SingleAcceleratorLlmServiceScenario: An LLM chat service on one accelerator: latency, KV residency, request rate, and token cost.
  • SingleNodeInferenceScenario: One inference of workload on hardware (roofline profile from SingleNodeModel).
  • SkewCostScenario: Training-serving skew that makes skew_rate of query_rate wrong, each wrong prediction costing cost_per_error.
  • SkewedRecordsScenario: Two records skew apart, compared at site: the base at its drive limit and a person at the walking speed close on each other.
  • SlowdownDiagnosisScenario: A training step that slowed, and a pairwise link test that finds one link at a fraction of its rate.
  • SnapshotVolumeScenario: A trajectory of turns turns growing state_growth per turn, checkpointed every stride.
  • SoftContactExploitScenario: machine’s arm coasting into site’s latch plate at the fast approach: the peak force a penalty spring that lets the gripper sink penalty_penetration reports, the peak the real plate imposes on a rigid arm, and the arm stiffness at which the series chain reaches the limit. The moving mass is the arm’s effective contact mass without its payload capacity (the gripper holds no object at the door).
  • SpanCriticalPathScenario: One trial’s observed spans on a shared clock, the spans each waits for, and one intervention.
  • SparseFlashFitScenario: workload pruned until its surviving values total surviving_bytes, stored with one index_bytes position index per value, against a flash_budget.
  • SpeculativeEpisodeScenario: Speculative decoding on a serial episode’s model time, at two draft acceptance levels.
  • SpeculativeRoundScenario: A draft proposes draft_length tokens; the target verifies them in one step.
  • SpeedStepScenario: Raising the speed setpoint from base to raised (two stopping budgets at one deceleration).
  • SpeedupCompositionScenario: Independent paper speedups multiplied together, against the measured speedup.
  • SpillLimitedStopScenario: The free_stop scenario’s machine carrying an open container of inner_radius filled freeboard below the rim: the deceleration the liquid allows, that stop, and the carry speed.
  • SpotEffectiveCostScenario: Spot capacity priced per hour of retained progress.
  • SpotRunScenario: A training run of run_duration on fleet, on demand against spot capacity.
  • StagedCompressionScenario: A teacher pruned and distilled into a compact student, then quantized, with the task accuracy after each stage and the loss when quantization comes first.
  • StagingBurstScenario: A collector of rollouts concurrent rollouts feeding slots verifiers, whose checks stall at timeout, with records charged at record_ceiling against store.
  • StaleAnchorScenario: A joint of machine’s arm turning at joint_speed while a replacement takes delay, anchored at the pose sampled at the request; the lever arm is the planar reach.
  • StaleTransformScenario: belief’s cached camera edge composed with the current wrist pose, one site.machine wrist-camera frame old.
  • StallDeratingScenario: joint holding hold_torque at stall with copper’s resistance rising with temperature.
  • StallShareScenario: site’s unloaded permission tick with a share of it slowed slowdown times.
  • StateGridScenario: A state space of state_components axes cut into bins per axis, against the records fleet robots log at log_rate for duration.
  • StereoDepthErrorScenario: A stereo rig’s depth error at two ranges and at site’s rack end, against the site’s clearances.
  • StiffContactScenario: A stiff contact of stiffness (a linear spring, F = k x): the force a residual penetration commands, and the penetrations at site’s latch tripwire and limit.
  • StoppingBudgetScenario: A machine at speed that must stop: travel during delay, then braking at deceleration.
  • StorageAmplificationScenario: Auxiliary bytes and re-index time of a lexical-plus-graph and a lexical-plus-dense store.
  • StorageFootprintScenario: What a training run of workload reads once, saves every interval, and archives.
  • StragglerCostScenario: One of n_devices in a synchronous job runs at slow_speed of its normal rate.
  • StreamCancelScenario: A streamed reply with output_allowance tokens, rejected and canceled at reject_step.
  • StreamVsStageScenario: Stream every epoch from remote object storage, or stage the dataset locally once per run.
  • StrongScalingPairScenario: The same fixed job on base_devices and on scaled_devices: speedup, ideal time, and efficiency.
  • SubgroupEvaluationBudgetScenario: The labeled data a per-group evaluation needs: one group’s rate within half_width at confidence (worst case rate 0.5), the collection random sampling needs to reach a target_per_group from a group of group_share, and the per-group count that pins a gap between two equal-size groups to gap_half_width.
  • SubgroupSampleScenario: An evaluation set of total people with a group of small_share, both detected at recall: exact intervals for each group, and the people per group a two-sided test at significance with power needs to tell rate_a from rate_b.
  • SupervisionLaborScenario: The person-hours a supervised fleet creates in one operating_day: an assistant staffed the whole day (busy at queue’s utilization, watching otherwise) plus sweeps corridor sweeps.
  • SupervisorQueueScenario: One remote assistant serving machines, each asking for help at request_rate, each request holding the assistant for service_time; utilization_cap sizes the largest fleet.
  • SustainedThroughputScenario: A run budgeted from peak throughput, then run at its sustained share of peak.
  • SyncStrategyScenario: Data-parallel training to a fixed target under one synchronization strategy.
  • SyntheticFootprintScenario: Generated samples with provenance metadata, read once per verification pass.
  • SyscallTaxScenario: calls ordinary system calls priced by the terms each isolation envelope pays.
  • SystolicReuseEnergyScenario: Energy per MAC with every operand from off-chip memory, against a systolic array.

T

  • TailEventRateScenario: How often an event of probability event_probability per request occurs at request_rate.
  • TakeoverBudgetScenario: A machine at speed at a site asks a person to take over within takeover.
  • TakeoverCeilingLadderScenario: One takeover budget per sourced human response, each plus the same console transport.
  • TargetMaskScenario: One serialized training example by segment, and the responses kept as context only.
  • TaskFactorCard: One authored task factorization with a separate quality observation.
  • TaskFactorStudyScenario: A bounded controlled study with authored task cards.
  • TaskMixConsistencyScenario: Equally weighted task types and a number of runs that must all pass.
  • TeleopIngestionScenario: Raw telemetry of one teleoperated session on machine: its navigation and wrist cameras, external_cameras RGB-D cameras, and the kinematic record at the permission tick.
  • TeleopLoopScenario: One teleoperated correction: display, human, command transport, and mechanical response.
  • TemporalShiftScenario: A flexible run of duration at power that may wait up to slack for a cleaner hour on a time-varying intensities signal.
  • TensorParallelLayerScenario: One layer of workload split tp_size ways: compute against the exchange on each link.
  • TensorParallelScenario: The activation AllReduces of one tensor-parallel step of workload.
  • TensorParallelSpeedupScenario: Stated per-layer compute split tp_size ways, plus the AllReduces each layer adds.
  • ThermalBurstScenario: A burst_factor times rated-current burst in joint, first-order lumped, fixed resistance.
  • ThermalCeilingScenario: A model’s sustained power against a passively cooled device’s ceiling, before and after a reduction.
  • ThermalExpansionScenario: A member of length and expansion coefficient warmed by temperature_rise.
  • ThermalThrottleScenario: site’s permission tick on a cluster whose clock a thermal governor halves.
  • ThrottledStageScenario: site’s vision backbone at clock_ratio of full clock, paid as travel at speed.
  • ThroughputCostScenario: The same workload and resource budget served at baseline_rate without a set of controls and at controlled_rate with them.
  • TickTraceScenario: Percentiles of a permission tick’s execution time over a trace of ticks periods, cold and warm, against site’s declared WCET and deadline.
  • TieredCacheScenario: A fast tier in front of a slow one: a stated hit rate, or capacity over a uniformly sampled corpus.
  • TieredCheckpointScenario: One save of workload’s state on fleet: local write per node, then a durable drain.
  • TimingAttitudeErrorScenario: A timing_error and an angle_error on a target at distance, priced against reference.
  • TokenEnergyScenario: Joules per generated token: node power over aggregate token rate, well used and poorly used.
  • TokenPriceComparisonScenario: Two cohort configurations under one acceptance contract: does the cheaper token win?
  • TokenizedBatchFeedScenario: A host that tokenizes each batch and copies it to the accelerator, against the device’s step.
  • ToolCatalogSelectionScenario: A registered tool catalog staged whole or as a selected subset with overhead.
  • ToolDriftScenario: Baseline and candidate distributions of tool calls over the same tools, compared by the Jensen-Shannon divergence (natural logarithms).
  • ToolkitGranularityScenario: Structured tools against one shell tool, judged by cost per accepted task.
  • TorqueHalfSpaceProjectionScenario: A torque proposal against one barrier half-space normal . u <= bound: the least-change projection (calc_cbf_qp_orthogonal_projection) against a per-axis clamp.
  • TorusScenario: n_endpoints as a cubic torus against a non-blocking fat-tree, at equal per-link bandwidth.
  • TraceRetentionScenario: One cohort period of trials in disjoint verdict classes, each with a trace_size body, retained over window by keeping everything, head sampling, or verdict-aware selection.
  • TraceVolumeScenario: A profiler trace of window on every one of devices devices.
  • TractionLossScenario: Floor friction falls from mu_before to mu_after under a machine that assumes deceleration.
  • TrafficSurgeScenario: A service sized for normal_rate that receives surge_rate; latency in each regime.
  • TrainingCampaignCostScenario: runs_per_year training runs of run_low to run_high on an owned cluster (ownership) against renting the same GPUs only while each run lasts.
  • TrainingRunScenario: Training workload on fleet: peak time to delivered wall-clock time.
  • TrainingStateFitScenario: Weights, gradients, and optimizer state of workload at one precision, against hardware’s memory.
  • TrainingStateScenario: Persistent mixed-precision Adam state of workload and its shards.
  • TrajectoryAdmissionScenario: A stationary admitted population of trajectories against a token-per-minute quota.
  • TrajectoryBudgetMeterScenario: An append-only trajectory metered against turns, tokens, time, and dollars.
  • TrajectoryDeadlinesScenario: A trajectory record for machine’s arm at site: a replacement requested at request_delay with a latency_target and schedule_slack, a blend deadline, the commit instant when stop (a JerkLimitedStopScenario) must begin, and a late_wait.
  • TrajectoryResendScenario: A trajectory of turns calls that each resend the whole history (TrajectoryResendModel).
  • TransferScenario: copies of one payload moved at once over each named link tier.
  • TransformerBlockScenario: workload’s decoder blocks at a context of context_tokens: the classic block’s weights (4 d^2 attention projections, 2 x ffn_multiple d^2 MLP), its dense and attention multiply-adds, and, with hardware, the attention arithmetic of one prompt at peak.
  • TravelDuringLatencyScenario: Distance a vehicle at speed covers during latency; optionally a remote-path delay range.
  • TrialCampaignScenario: trials hardware trials of rollout each, decisions decision_step apart, with automated and manual resets, on one machine and on a farm; what a demonstration-seeded seeded_budget allows; and the same trials in simulator at its published throughput.
  • TwoLinkJointRateScenario: machine’s arm as a planar two-link chain at elbow_angle: the joint rates its TCP speed limit asks in the weakest direction, exact and with damped least squares at damping.
  • TwoProportionTestScenario: A two-arm test sized to detect an absolute lift on a baseline_rate at the normal quantiles z_alpha and z_beta, on daily_requests split between arms.

U

V

W

Z

  • ZeroEventExposureScenario: Exposure needed, with zero events observed, to bound a rate of budget per horizon at one-sided confidence, and the size of recording that exposure at sample_rate.
  • ZeroFailureScenario: trials failure-free trials, bounded at one-sided confidence.
  • ZeroShardingScenario: workload’s training state per device at each ZeRO stage over n_devices.
Back to top