Kubernetes OTEL Control Gym: A Controlled Kubernetes/OpenTelemetry Stand For DevOps World Models

Status: draft system description based on the latest notes.

Decision principle: the controller should not chase one fixed target latent. It should predict a vector of operational outcomes under each candidate action plan, enforce hard safety constraints, preserve the Pareto frontier, and choose one plan only through an explicit incident policy, preference profile, or human decision.

Block diagram of Kubernetes OTEL Control Gym as a controlled Kubernetes/OpenTelemetry stand where observability data, actions, new telemetry, outcome vectors, and constraints connect a live testbed to an action-conditioned world model and AI SRE controller.

Collaboration

If this direction resonates with you, I would be happy to talk with like-minded people, collaborate on research, and work on use-cases together.

Ideas are not the bottleneck. Hands are. Time-series modeling should be moving at least as fast as vision, audio, and robotics.

1. Motivation: Why This Is Needed

Modern DevOps is already good at collecting observability data: metrics, logs, traces, Kubernetes events, service graphs, alerts, and RCA reports. But most of that data answers passive questions:

what is broken right now;
where the root cause is most likely to be;
how metrics will look if nothing changes;
which service looks anomalous relative to past behavior.

In real operations, the most important question is often different: what will happen if we do something.

For example:

what will happen to latency and error rate if checkout is scaled from 2 to 5 replicas;
whether restarting cart will help, or whether it will make the cache problem worse;
whether it is safe to continue rolling out a new version;
when rollback is better, and when increasing CPU limits is enough;
which sequence of actions returns the SLO to green fastest;
how to distinguish real service degradation from an expected effect after changing traffic, limits, or workload mix.

Ordinary observability datasets usually record only past events. They are useful for diagnosis and forecasting, but they do not teach a model well enough to understand the consequences of actions. For that, we need trajectories of the form:

observation -> action -> new observation -> outcome

That is the environment to build: not just a file generator, but a controlled gym for DevOps systems. It should be a stand where a microservice application can be run reproducibly, its state can be changed, faults can be injected, graph telemetry time series can be collected, and we can evaluate how well a model predicts and chooses actions.

2. What We Want To Build

We want to build Kubernetes OTEL Control Gym (k8s-otel-control-gym): a reproducible Kubernetes environment based on OpenTelemetry Demo, Coroot, Chaos Mesh, and a custom orchestrator.

The concrete substrate is intentionally search-legible and buyer-legible: Kubernetes provides the actuator surface, OpenTelemetry provides the sensor stream, Chaos Mesh provides controlled faults, and the custom orchestrator turns the stand into an action-conditioned gym.

The environment MUST support two modes:

Offline dataset generation: scripted policies run scenarios, apply actions, inject faults or interventions, and export labeled trajectories.
Online live-stand evaluation: a trained model or controller connects to the live stand through the same gym API, observes the state, chooses an action, and receives measured outcomes, constraint status, and an optional policy-specific reward.

The key idea is that dataset generation is a special case of running the gym. We are not building a separate “dataset factory” that lives apart from the evaluation environment. We are building one environment in which scripted policies, baseline controllers, and trained models use the same interface.

The minimal interface is:

reset(seed, config) -> initial_observation
observe(window, granularity) -> observation
step(action, dt) -> observation, outcomes, constraints, reward, done, info

Where:

reset deploys the stand or returns it to a known state;
observe returns a telemetry window: node features, edge features, events, logs, traces, Kubernetes events, and Coroot findings;
step(action, dt) applies an action and advances the environment by one control step;
outcomes exposes the measured objective vector, including SLO, latency, error rate, recovery time, resource cost, stability, and blast radius;
constraints records hard safety, approval, availability, and action-validity checks separately from optimization preferences;
reward is an optional named scalarization of the outcome vector under a versioned policy profile, not the only canonical outcome record;
done marks the end of an episode, a declared policy objective, an emergency state, or a required reset.

3. Why This Should Be A Gym, Not An Ordinary Benchmark

A benchmark usually defines a fixed set of inputs and expected answers. That is useful for comparing algorithms, but it is not enough for learning behavior.

In DevOps, behavior matters as much as diagnosis. An operator or automatic controller makes decisions over time:

first inspect state -> choose an action -> wait for the effect ->
reassess the situation -> choose the next action

This loop cannot be fully tested on a passive dataset, because a passive dataset contains only one historical branch. It cannot answer: “What would have happened if, instead of restart, we had scaled up?”

A gym gives three things that an ordinary dataset does not:

controlled actions: the model can intervene in the system;
repeatability: the same scenario can be run with different policies;
closed-loop evaluation: we can measure not only prediction accuracy, but also decision quality on a live stand.

World Models is the visual-control precedent for training through a learned environment, but its simulator-exploitation failure mode is exactly why this gym should keep learned-model scores separate from live-stand transfer.

Agentic World Modeling gives the cleaner evaluation vocabulary: the gym should test whether a model is an L2 simulator, not only an L1 predictor. That means explicit multi-step rollout, intervention sensitivity, and constraint consistency, plus an MREP-style package with versioned scenarios, saved action/observation traces, and failure taxonomy.

stable-worldmodel is the closest robotics-side infrastructure precedent for the gym shape: common trajectory storage, standardized action-conditioned baselines, common solvers, and factor-of-variation sweeps. For OTEL control, the transferable lesson is the evaluation contract, not the visual manipulation domain.

CityLearn is an energy-domain precedent for the environment-first shape: dataset generation comes from running policies against a versioned simulator and schema, so action, reward, version, and source-data provenance become part of the benchmark contract.

Grid2Op is the energy-grid graph-control analogue: graph-structured observations, topology/control inputs, exogenous contingencies, simulator-backed rollouts, and safety/cost outcomes. It is useful as a benchmark-contract precedent, while OTEL still needs its own operator-action schema and live-stand protocol.

The World Model for Robot Learning Survey gives the robotics version of the same evaluation split: open-loop prediction, closed-loop policy utility, and executability diagnostics should be measured separately.

The first version does not need to imitate all of production. It is more important to build a clean, controlled environment with clear labels than to maximize realism immediately. Realism can be increased after the data contract and the observe -> action -> outcomes + constraints loop are proven.

4. How This Differs From Existing Datasets And Benchmarks

ChronoGraph

ChronoGraph is the closest existing source to the desired data shape: graph-structured multivariate time series with service nodes, service-to-service edges, node features, edge features, and incident labels.

But ChronoGraph remains a passive dataset. It has graph structure and dynamics, but no first-class channel for operator actions or control inputs. A model can learn to forecast future metrics and find anomalies, but it does not learn to answer: “What changes if we execute this action right now?”

For Kubernetes OTEL Control Gym, ChronoGraph is a good reference for the shape of graph time-series data, but not the final schema.

IO-Aware GNN Layers adds a baseline-hygiene requirement for this ChronoGraph-to-OTEL path. Direct message-passing baselines SHOULD use modern IO-aware or vendor-backed GNN layers when available, and benchmark reports SHOULD include latency, peak memory, graph degree distribution, backend/kernel choice, and graph preprocessing or reordering cost. Otherwise the gym can accidentally compare a strong Transformer graph-context interface against outdated sparse-kernel overhead.

RCAEval, GAIA/MicroSS, LEMMA-RCA, OpenRCA, AnoMod, ops-lite

These datasets and benchmarks are useful, but they solve neighboring tasks.

RCAEval is good as a reproducible RCA benchmark: it has failure cases, fault types, telemetry, and expected root causes. But its focus is root-cause localization, not controlling the system after observation.

MicroSS, LEMMA-RCA, OpenRCA, and AnoMod provide useful data for AIOps, diagnosis, multimodal anomaly detection, and LLM-agent investigation. But they mostly answer “what happened and where is the cause”, not “which action should be chosen and what consequences will it have”.

LLM Agents Need Action-Conditioned World Models makes the corresponding baseline argument explicit: Codex, Claude, and similar tool-calling agents should be measured on the same stand, but the gym should also test whether a telemetry-native action-conditioned world model improves action ranking, safety, and regret.

CWM is the code-domain precedent for training on explicit action-observation trajectories in a digital environment. It should inform the Kubernetes OTEL Control Gym data-contract design, while remaining separate from telemetry-native OTEL control evidence.

ops-lite is interesting because it provides compact causal graphs for RCA. That is valuable for testing causal hypotheses, but it is not a live environment with a control loop.

Tennessee Eastman Process Simulation Data is an industrial-control analogue for the data-contract boundary. It exposes measured variables, manipulated variables, and fault regimes, but its faults are benchmark disturbances rather than logged remediation actions. The OTEL gym should preserve that separation explicitly.

AIOpsLab

AIOpsLab is closer in spirit: it separates application, task, fault, workload, and evaluator. That decomposition is worth using as an architectural example.

But in our case, the main object is not an RCA agent or a fault diagnosis task. The main object is an action-conditioned time-series world model for controlling a microservice system over time.

Therefore, AIOpsLab can be treated as a future adapter or a source of useful abstractions, but the first data contract should be world-model-oriented:

state/action/next_state/outcomes/constraints/reward/label

Ordinary TSFMs

Time-series foundation models usually learn to predict future values from past values and context. That is useful for forecasting, anomaly detection, imputation, and sometimes pattern classification.

But an ordinary TSFM is usually passive. It sees the system history, but it does not know which action the operator took, which control inputs changed, or which alternative actions could have led to a different outcome.

Kubernetes OTEL Control Gym adds the missing part: actions and their consequences.

5. What A Time-Series World Model Is

An ordinary time-series model answers roughly this question:

If the past 30 minutes looked like this, what will the next 5 minutes look like?

A time-series world model answers a stronger question:

If the past 30 minutes looked like this, and we now take action A,
what will the system look like in 5 minutes?

The difference looks small, but in DevOps it is fundamental.

An ordinary TSFM models observed dynamics. It can be a very strong forecaster, but it does not necessarily understand the causal role of actions.

Action conditioning is not extra ML complexity for its own sake. In an operations system, many telemetry changes are caused by operators, automation, deploys, rollbacks, scaling, traffic shifts, feature-flag changes, and remediation steps. If those actions are missing from the timeline, the model sees a metric change but not the reason the system changed. The passive task becomes harder because it must average over many hidden operational choices. Logging actions turns those hidden interventions into first-class inputs, so the model can learn simpler conditional mappings:

history -> future

becomes:

history + action -> future

The tradeoff is that the stand contract becomes stricter. The gym must record the action type, target, parameters, timing, status, prechecks, postchecks, and outcome. Otherwise the action channel can become noisy labels rather than an ambiguity-reducing input.

A time-series world model models system dynamics as a controlled process. Its inputs are:

observation: the current and past telemetry state;
graph: services, dependencies, and service-to-service edges;
action: the action of an operator or controller;
control input: a numeric or actuator-like parameter, such as replica count, traffic split, CPU limit, or workload rate;
intervention: an intentional manipulation whose effect matters causally;
exogenous variables: external factors not controlled by the policy;
labels, outcomes, constraints, and optional rewards: ground truth about the scenario, measured consequences, hard decision boundaries, and policy-specific evaluation signals.

The outputs of the world model can include:

forecasts of node features and edge features after the action;
probability of SLO violation;
expected recovery time;
cost estimate for the action;
counterfactual prediction: what would have happened under a different action;
latent state that a controller can use for planning.

In other words, an ordinary TSFM is like a very smart forecast chart. A time-series world model is closer to a consequence simulator: it learns the internal dynamics of the system well enough to support planning.

6. New Applications This Enables

What-if Analysis Before Change

An operator wants to know what will happen after changing limits, scale, or version. A world model can estimate several options before the action is applied:

scale checkout +2 replicas
restart cart
rollback recommendation
increase CPU limit for payment
shift 20% traffic to old version

This does not replace rollout policy or SRE procedure, but it adds another layer for risk forecasting.

Safe Autoscaling And Resource Control

An ordinary autoscaler reacts to metrics. A world-model-based controller can account for delayed effects and graph effects. For example, scaling up one service can move the bottleneck to a dependency, increase queueing, or change the error pattern on another edge.

The gym makes it possible to train and test a controller that optimizes a complex objective, not just one CPU metric:

latency;
error rate;
SLO burn rate;
resource cost;
stability;
recovery time;
penalty for unsafe actions.

These quantities form an outcome vector, not one universal reward. During an incident, recovery speed and tail risk may dominate cost; during steady operation, cost and stability may dominate. If no preference or policy is supplied, the controller should return a Pareto set rather than invent one allegedly optimal action.

Rollout And Rollback Decision Support

During rollout, a new version can have weak, delayed, or workload-dependent effects. Passive anomaly detection can say “the metrics are strange”. A world model should help answer:

continue rollout;
stop rollout;
rollback;
increase resources;
change traffic split;
wait, because the effect is expected and temporary.

Incident Recovery Planning

During an incident, it is important not only to find the root cause, but also to choose the recovery order. A world model can compare possible sequences:

restart -> scale -> rollback
rollback -> scale -> restart
scale -> wait -> rollback

This is a planning problem, not only RCA.

Counterfactual RCA

RCA usually searches for the most likely cause. A world model adds the ability to test a hypothesis with an action or simulated action:

If the cause is cache, then recovering cache should reduce latency on edges
that go through cart.

This does not replace classical RCA, but makes it more operational: a cause should explain not only the past, but also the expected effect of remediation.

Offline Training For Live Control

Without a gym, it is dangerous to train a controller directly in production. A gym provides an intermediate step:

collect controlled episodes;
train a world model offline;
test forecasting and action-effect prediction;
test the policy in the live stand;
only then consider more realistic environments.

7. How The Gym Helps Train A Model

For someone with a DevOps background, training can be described as follows.

We run the stand many times under different conditions. Each run records:

what the service graph was
what the workload was
what metrics, logs, and traces were observed
which action was applied
which fault or intervention was injected
what happened afterward
which outcome is considered good or bad

The model receives not just “metrics for the past hour”, but pairs:

(observation, action) -> next_observation

And additional signals:

label: what exactly we did and where the cause was
outcomes: SLO, latency, errors, cost, recovery, stability, blast radius
constraints: which safety, approval, and availability rules held
reward: an optional policy-specific scalarization of the outcome vector
graph: how services are connected

This supports several model layers:

next-state model: predict the next node and edge features;
action-effect model: predict the difference between “do nothing” and a concrete action;
anomaly/RCA head: find the fault type or affected service;
outcome and risk heads: predict the separate SLO, cost, recovery, stability, blast-radius, and uncertainty components;
constraint model or verifier: reject plans that violate hard safety, approval, or availability rules;
preference layer: select among feasible trade-offs under an explicit incident or operating policy;
controller: execute the first action of the selected plan, observe the result, and replan.

On Training in Imagination adds a budget and label-quality warning for this stack. The next-state/action-effect model and the outcome, preference, or utility layers may need different data streams: cheap telemetry transitions can scale differently from expensive human, SLO, or expert preference labels. Cheap noisy preference labels are only attractive when the noise is plausibly zero-mean; systematic utility bias is a control-safety problem, not a variance problem.

CFLight adds a concrete rare-incident data recipe: after an unsafe event, return to the common pre-event snapshot, evaluate typed alternative actions, and store the resulting branches as one counterfactual group. For this gym, direct stand replay should be ground truth and learned-model branches should carry source and uncertainty metadata. NOOP/WAIT, normal-operation episodes, shared workload/fault seeds, and group-safe train/test splits are required so incident-triggered replay does not create action–incident shortcuts.

CF-Reg is complementary but narrower. Counterfactual flip distance can diagnose whether nuisance edits to telemetry or serialized state destabilize an incident classifier or action ranker, and can be tested as a regularization ablation. It must not replace physical action branching: changing an embedding until a prediction flips does not generate the telemetry trajectory that would follow a restart, scale, rollback, or traffic shift.

The important point is that the same gym is needed for dataset generation and for testing the trained model. That protects against the situation where a model passes an offline benchmark but cannot work in a closed loop.

For LLM-agent baselines, the gym should save both raw action/observation episodes and structured episode summaries. That makes it possible to compare summary-based reuse against raw-trace replay before deciding which compression interface is safe enough for operations.

8. Multi-Objective Planning Without A Single Target

8.1 Decision Contract

LeWM-style visual planning often scores a candidate action sequence by the distance between its predicted terminal latent and one goal latent. Kubernetes operations rarely has one such target. The useful model output is a distribution over an interpretable outcome vector:

Y (A) = [SLO burn, latency, error rate, resource cost, recovery time, blast radius, stability, reversibility],

conditioned on current latent state $z_{t}$ , system context $c_{t}$ , and candidate action plan $A$ :

p_{θ} (Y_{t + 1 : t + H} ∣ z_{t}, A, c_{t}) .

The world model should predict consequences. It should not hide business policy inside one irreversible scalar reward. If the decision layer has no preference profile, budget, lexicographic priority, or human choice, it cannot select a unique optimum from conflicting outcomes.

8.2 Constraints Before Preferences

The decision layer should separate three levels:

Hard constraints: action validity, minimum availability, approval requirements, maximum blast radius, and chance constraints on catastrophic SLO or safety outcomes. Unsafe plans are rejected rather than traded for lower cost.
Lexicographic priorities: for example, avoid catastrophic failure first, restore SLO second, minimize recovery time third, and optimize resource cost only afterward.
Soft preferences: compare the remaining feasible plans by a versioned utility profile, Tchebycheff or other scalarization, Pareto dominance, or explicit operator choice.

A chance constraint has the form

P (g_{j} (Y, A) \leq 0) \geq 1 - δ_{j} .

Safety MUST NOT become merely another small coefficient in a weighted sum.

8.3 MVP Planner: Constrained Pareto Beam Search

Operational actions are typed and mixed discrete/continuous objects rather than dense motor vectors. The first planner should therefore use constrained Pareto beam search, not CEM as the default:

enumerate valid WAIT, NOOP, evidence-gathering, escalation, scale, restart, rollback, traffic-shift, limit, and circuit-breaker actions;
predict the outcome distribution of every action prefix;
reject plans that violate hard constraints or action preconditions;
keep non-dominated plans plus a bounded set of diverse near-frontier plans;
expand the surviving prefixes by one action and repeat to horizon $H$ ;
execute only the first action, observe the real transition, and replan.

flowchart LR
  S["belief state + graph + context"] --> C["typed candidate actions"]
  C --> W["action-prefix world model"]
  W --> O["outcome distributions for every prefix"]
  O --> G["hard constraint gate"]
  G --> P["Pareto frontier"]
  P --> D["policy profile or human choice"]
  D --> E["execute first action"]
  E --> S

CEM remains a useful baseline, an offline teacher, and a fallback for continuous parameter subspaces. It is not the natural primary planner when the action catalogue is typed, constraints are explicit, and the required output is a set of trade-offs rather than one terminal-goal minimum.

τ₀-VLA is the closest current physical-robotics analogue for spending extra compute at this sparse candidate-selection boundary: it proposes language subtasks, predicts one terminal image per candidate, scores progress, expands a beam, and reflects before handing one subtask to a faster executor. The OTEL transfer must keep the interface stricter than that precedent. Candidates should be typed operational actions with preconditions and execution status, predictions should be numeric trajectory distributions with delayed and failed-action effects, and hard constraints must remain outside the learned progress score.

8.4 LeWM-Like Action-Prefix World Model

The visual Fast-LeWM result suggests a transferable query interface, not a literal operational implementation. The gym model should first maintain a belief state from history rather than anchor every forecast to one observation:

z_{t} = S_{θ} (x_{\leq t}, e_{\leq t}, a_{< t}, g_{t}, c_{t}),

where $x$ is multivariate telemetry, $e$ is the event stream, $a$ is action history with execution status, $g_{t}$ is the service graph, and $c_{t}$ is workload and operational context.

A causal action-prefix encoder then builds one representation per partial plan,

p_{t, k} = E_{ψ}^{(k)} (a_{t}, \dots, a_{t + k - 1} ∣ z_{t}, c_{t}),

and predicts future latent states and outcomes for all prefix horizons in parallel. Dense prefix supervision matters because every intermediate action can create a temporary outage, failed precondition, unsafe rollout, or delayed dependency effect even when the terminal outcome looks good.

Fast LeWorldModel is the deterministic baseline for this interface. The operations version must additionally test partial observability, irregular time, delayed and failed actions, variable horizons, path constraints, and stochastic future regimes. Direct-versus-composed prediction disagreement can be recorded as a self-consistency diagnostic, but it is not automatically calibrated uncertainty.

8.5 Probabilistic Futures And Risk

One deterministic latent future is not enough when the same rollback, restart, or traffic shift can recover the system, have no effect, or trigger another failure. The first baseline can combine deterministic action-prefix prediction with ensembles and calibrated outcome heads. A later model can use probabilistic JEPA latent trajectories or another expressive conditional distribution when separated future regimes matter.

The planner should compare expected utility with tail risk, for example

A^{*} = ar g A \in P_{t} max [E U (Y (A); w_{t}) - λ CVaR_{α} (L (A)) - c_{change} (A)],

where $P_{t}$ is the feasible Pareto set and $w_{t}$ is an explicit incident or operating preference profile. Epistemic uncertainty should be able to select WAIT, COLLECT_MORE_EVIDENCE, or ESCALATE_TO_HUMAN rather than force an intervention.

8.6 Later: Amortized Plan Proposals

INTACT provides the closest current precedent for moving from broad candidate search to a learned state-and-intent-to-action proposal. Its local branch asks which action produced an observed latent change; its goal branch asks which action should produce a desired latent change; and the shared action operator supplies a Direct proposal that can be locally verified by the forward world model. The reusable idea is proposal amortization, not the literal visual encoder, Gaussian action mean, fixed goal latent, or claim that model-based verification is unnecessary.

Once the gym can produce Pareto-optimal or near-optimal plans offline, those plans can train a preference-conditioned proposal model

q_{φ} (A ∣ z_{t}, c_{t}, w_{t}, C_{t}),

where $w_{t}$ is the explicit incident or operating preference profile and $C_{t}$ is the current action/constraint context. A categorical, diffusion, flow-matching, autoregressive typed-action, or hierarchical generator can then propose a diverse shortlist quickly. One unimodal mean is not adequate when rollback, traffic shift, resource change, WAIT, and escalation are distinct valid action families.

The world model still predicts consequence distributions for each proposed prefix, Fast-LeWM-style parallel prefix prediction can accelerate verification, the hard-constraint layer still rejects unsafe plans, and the Pareto/risk selector still reranks them. Low support, high uncertainty, poor proposal diversity, or changed preferences should trigger broader constrained beam search, evidence gathering, or human escalation. This amortizes candidate generation; it does not justify removing consequence evaluation or safety verification.

The gym should train and evaluate two operational analogues of INTACT supervision:

local: belief state plus measured successor change and execution status predicts the action/control input that produced it;
goal: belief state plus a later successful outcome profile and the policy/preferences in force predicts an action that moved toward it.

Controlled replay is essential because production logs contain operator selection bias, exogenous workload, delayed and failed effects, and concurrent actions. The decisive falsification test is whether safe near-optimal proposal recall at $K$ stays high under unseen workloads, graph changes, action repertoires, and preference profiles while world-model calls and end-to-end latency fall. A proposer that invokes broad fallback search in most difficult cases has not reduced the operational planning burden.

9. System Architecture

The system has four planes.

9.1 Application Plane

The application plane is the microservice application where observations are generated. The base candidate is OpenTelemetry Demo.

It is convenient because it already includes:

several services in a web-store domain;
HTTP/gRPC dependencies;
a load generator;
traces, metrics, and logs;
services with synchronous and asynchronous dependencies;
infrastructure components such as cache, queue, and database.

For the MVP, the application can run in several service configurations:

small-core: frontend, cart, checkout, product catalog, recommendation, payment, shipping, cache;
medium-store: small-core plus ad, currency, email, quote, frontend proxy, load generator;
async-store: medium-store plus queue, accounting, fraud detection;
review-store: medium-store plus product reviews, PostgreSQL, LLM/flagd, if that does not make the stand too expensive.

Different configurations are needed so the model does not overfit to one graph size.

9.2 Control Plane

The control plane is a Python orchestrator plus Kubernetes and Chaos Mesh integrations.

The orchestrator MUST:

manage reset, observe, step, outcomes, constraints, reward, and done;
store the seed, config, chart versions, and Git SHAs;
apply ordinary DevOps actions through the Kubernetes API;
apply fault interventions through Chaos Mesh;
record action logs before applying the action;
check action status after applying it;
record ground-truth labels independently of Coroot diagnosis;
run scripted policies for dataset generation;
run online evaluation for a trained controller.

Ordinary DevOps actions matter as much as failures. The MVP should support:

scale deployment up/down;
add/remove pods through replica count;
restart a deployment or individual workload;
enable/disable an optional service group;
rollout config change;
rollback config change;
change CPU/memory requests/limits;
change autoscaler target/bounds;
shift traffic between versions once canary support exists;
change workload generator rate or request mix as a controlled input.

Fault interventions are needed for learning diagnosis and recovery:

CPU pressure;
memory pressure or leak-like behavior;
network delay on an edge;
packet loss on an edge;
network partition on an edge;
pod kill/restart loop;
cache/database dependency outage;
bad config or wrong target port at a later stage.

9.3 Telemetry Plane

The telemetry plane collects observations.

At minimum, it needs:

Prometheus metrics for node and edge numeric features;
OpenTelemetry Collector for metrics, traces, and logs;
Kubernetes events;
Coroot findings as an additional feature stream;
raw or aggregated traces;
log patterns and error summaries.

Coroot diagnosis MUST NOT replace ground-truth labels. It should be saved as:

weak labels;
baseline observability-tool output;
additional features;
an explanatory layer for model error analysis.

Ground truth should come from the orchestrator: it knows which action was applied, when, to which target, and with which parameters.

9.4 Export And Evaluation Plane

The export plane normalizes telemetry into time buckets and writes the canonical dataset.

The canonical format should be world-model-oriented:

run_<id>/
  metadata.json
  graph.json
  node_features.parquet
  edge_features.parquet
  actions.parquet
  events.parquet
  labels.parquet
  outcomes.parquet
  constraints.parquet
  preferences.parquet
  rewards.parquet
  logs.jsonl.zst
  spans.parquet
  k8s_events.jsonl.zst
  coroot_findings.json

Adapters can export additional views:

ChronoGraph-like graph time series for forecasting/anomaly experiments;
RCAEval-style flat DataFrame for RCA baselines;
compact causal graph view for graph/path scoring.

But those adapters should not dictate the main contract. The main contract is:

state/action/next_state/outcomes/constraints/reward/label

10. Data Contract

Every run should be self-contained. If the run directory is opened a year later, it should be clear:

which application was deployed;
which gym version was used;
which Helm charts and configs were applied;
which seed was used;
which workload profile was running;
which actions and interventions were applied;
which telemetry streams are available;
how temporal windows were aggregated;
which labels and measured outcomes are ground truth;
which constraints and preference policy produced any derived scalar reward.

10.1 metadata.json

metadata.json contains:

run_id;
seed;
gym_api_version;
chart_versions;
git_shas;
kubernetes_version;
collector_config_hash;
service_config;
workload_profile;
policy_name;
preference_policy_name;
constraint_policy_version;
run_start;
run_end;
action_schedule;
intervention_schedule;
granularity_config.

10.2 graph.json

graph.json describes the service graph:

nodes: services, workloads, infrastructure dependencies;
edges: service-to-service calls, protocols, expected dependencies;
mapping to Kubernetes names;
optional attributes: namespace, deployment, container, endpoint, protocol.

This is static or slowly changing context for the time-series model.

10.3 node_features.parquet

node_features.parquet contains time-bucketed features by service:

time;
run_id;
service;
request rate;
error rate;
latency summaries;
CPU usage;
memory usage;
restarts;
network in/out;
saturation indicators.

10.4 edge_features.parquet

edge_features.parquet contains features by directed edge:

time;
run_id;
source;
target;
protocol;
request rate;
error rate;
latency summaries;
status counters;
retry indicators, if available.

10.5 actions.parquet

actions.parquet is the central table for the world model.

Fields:

time;
run_id;
actor: scripted policy, human, model, baseline;
action_id;
action_type;
target_service or target_edge;
parameters;
duration;
status;
preconditions;
approval_requirement;
reversibility;
precheck_status;
postcheck_status.

If an action did not apply, that is also data. Such cases must not be silently dropped, otherwise the model will learn from incorrect causal labels.

10.5.1 Graph Encoding Baselines

graph.json is not only stored metadata. It is the system-topology context that the model must use when interpreting node features, edge features, and action targets.

The first model baselines SHOULD compare graph-as-context encodings instead of flattening service identity into anonymous channels:

TokenGT-style node and edge tokens, where services/resources are node tokens and directed dependencies are edge tokens;
Graphormer-style pairwise attention bias over service distance, dependency direction, edge type, and action-target relation;
GraphGPT or Graph Tokenization-style reversible graph serialization for graph snapshots, ego-subgraphs, trace-induced subgraphs, or action-targeted subgraphs;
GQT-style learned graph-token vocabularies as a later front-end candidate, with the caveat that the tokenizer can use graph-specialized machinery.

The first implementation SHOULD use TokenGT-style node, edge, and action tokens plus one small relation-bias ablation, not the 2022 repository unchanged. The attraction is the input contract: services remain node tokens, dependencies remain directed edge tokens, and actions can reuse the same endpoint identifier pair as their target. An edge action on $(u, v)$ carries $[P_{u} ∥ P_{v}]$ ; a service action on $v$ carries $[P_{v} ∥ P_{v}]$ , with a distinct action type identifier. The same attention mechanism can therefore learn graph incidence and action-target incidence.

Four identity channels MUST remain separate:

episode_entity_key: stable for the logical service, workload, or dependency across the complete trajectory and topology versions;
semantic metadata: resource kind, namespace, workload/service role, version, protocol, ownership, and capability fields used for cross-system transfer;
token type: node, directed edge, action, event, outcome query, or another schema-defined role;
optional structural position: Laplacian, hop, or relation features tied to a specific topology version rather than persistent identity.

Raw pod UIDs and array positions MUST NOT be the learned identity vocabulary. Pod membership and lifecycle belong in observations/events under a durable logical workload. Independently resampled ORF identifiers reveal incidence within one graph but do not align entities through time; Laplacian identifiers also move under topology changes.

The MVP SHOULD encode each node or edge’s recent numeric telemetry with a shared temporal patch encoder, producing one current-state token per persistent entity before graph mixing. Naively repeating all $n + m$ tokens for every history step creates $H (n + m)$ tokens and an avoidable quadratic space-time cost. If temporal summaries erase restart, rollout, queue, or saturation transients, the next architecture SHOULD alternate per-entity temporal attention with cross-entity graph attention rather than immediately adding a learned graph tokenizer.

The minimal matched experiment is:

no-graph / semantic-ID-only Transformer;
current IO-aware message-passing GNN;
pure TokenGT-style node/edge/action tokens;
TokenGT plus relation bias for incidence, directed one/two-hop distance, action target, topology version, and failure domain;
Graphormer-style structural-bias baseline;
one reversible-serialization baseline if implementation budget allows.

All variants MUST share temporal encoders, world-model heads, parameter or training-compute budget, trajectories, and optimization. Required tests are next node/edge observations, action delta versus matched NOOP, multi-horizon outcomes and constraints, safe top- $K$ action recall, and live-stand closed-loop regret/recovery. Stress splits MUST include service renames, unseen replicas, topology versions, workloads, graph sizes, and action targets. Input-order permutation, topology removal/corruption, action-target swaps, and deletion of rare dependencies are falsification probes. A model that forecasts normal telemetry but does not react to an action-target swap has not learned action-conditioned graph dynamics.

These encoders only solve the graph-context interface. The world-model test remains:

observation + graph context + action/control input -> next observation/outcomes/constraints

See Graph Structure As Transformer Context for the comparison frame and TokenGT for the mechanism, repository audit, newer-method comparison, and identifier caveats.

10.6 events.parquet

events.parquet contains observed events:

Kubernetes events;
rollout events;
pod lifecycle events;
Coroot symptom events;
workload schedule events;
caused_by_action_id, if the event is linked to a known action.

10.7 labels.parquet

labels.parquet contains ground truth:

run_id;
action_id;
intervention_id;
is_fault;
fault_type;
target;
start;
end;
intensity;
root_cause_kind;
expected_symptoms.

Labels should describe not only failures, but also normal operator actions. For a world model, an ordinary scale up is as important as a fault injection.

10.8 outcomes.parquet

outcomes.parquet is the canonical multi-objective result table. It SHOULD store measured components before any scalarization:

time;
run_id;
action_id or plan_id;
outcome_name;
value;
unit;
horizon_seconds;
measurement_status.

Outcome names include SLO satisfaction or burn, latency, error rate, recovery time, resource cost, stability, blast radius, reversibility, and operator effort when measured. Missing or undefined outcomes MUST remain explicit rather than becoming silent zeros.

10.9 constraints.parquet

constraints.parquet records hard decision boundaries separately from outcomes:

time;
run_id;
action_id or plan_id;
constraint_name;
threshold;
satisfied;
violation_magnitude;
policy_version;
evidence.

Examples include minimum replica availability, approval requirements, maximum traffic-shift fraction, forbidden simultaneous restarts, action preconditions, and chance constraints on catastrophic outcomes.

10.10 preferences.parquet

preferences.parquet records how a feasible Pareto set is turned into a decision:

time;
run_id;
policy_name;
mode: incident, canary safety, steady-state cost, maintenance, or another declared mode;
objective_weights;
lexicographic_priorities;
risk_level or cvar_alpha;
human_choice, when applicable;
policy_version.

The preference profile is context, not dynamics ground truth. It may change without retraining the world model.

10.11 rewards.parquet

rewards.parquet is an optional compatibility view for RL or scalar baselines:

time;
run_id;
reward_name;
value;
components;
preference_policy_name;
constraint_policy_version;
action_id.

Every reward MUST be reproducible from versioned outcomes, constraints, and a named policy. Safety violations SHOULD remain hard gates or explicit penalties rather than disappear inside an undocumented scalar.

10.12 coroot_findings.json

coroot_findings.json contains Coroot diagnosis output:

timestamp;
affected services;
affected edges;
symptom class;
severity or confidence, if available;
explanation text;
suggested root cause, if available.

This is not ground truth. It is observability-tool output that can be compared with labels or used as a weak signal.

11. Temporal Granularity

The gym MUST allow several time scales to be configured:

control_step_seconds: how often the controller can act;
observation_bucket_seconds: how metrics are aggregated;
observation_window_seconds: how much history the model sees;
outcome_bucket_seconds: how often measured outcomes are computed;
reward_bucket_seconds: how often an optional scalar reward adapter is computed;
scrape_interval_seconds: metric collection frequency;
trace_aggregation_seconds: trace aggregation window;
log_pattern_window_seconds: log aggregation window;
action_duration_seconds: duration of actions/interventions;
warmup_seconds;
cooldown_seconds.

Control steps and telemetry buckets do not have to match. For example, metrics can be aggregated every 10 seconds while the controller acts every 30 or 60 seconds. This is closer to real DevOps, where observability often has one frequency and decisions are made at another.

12. Workloads And Scenarios

The MVP should include several workload profiles:

steady: stable load;
diurnal: smooth changes similar to a daily profile;
burst: short spikes;
checkout-heavy: more write-like flows;
read-heavy: more catalog/product flows.

Temporal diversity is as important as fault-type variety. For each action or intervention, vary:

start time after warmup;
duration: transient, medium, slow-burn;
intensity: mild, visible, severe;
presence of a recovery phase;
no-fault baseline runs;
normal-control episodes without failures;
multi-action episodes after single-action scenarios are validated.

Without no-fault and normal-control episodes, the model will learn that almost every action is associated with an incident. That is a common dataset mistake in incident analysis.

13. MVP: What Must Be Ready First

The first usable MVP should prove the correctness of the loop, not scale.

Minimum acceptance criteria:

4 service configurations;
at least 5 ordinary DevOps actions;
at least 5 fault/intervention types;
at least 3 workload profiles;
at least 100 labeled runs, including no-fault baselines;
at least one online loop through observe/action/step/outcomes/constraints/reward;
graph per run;
node numeric features;
edge numeric features;
action logs;
labels;
measured outcome vectors;
hard-constraint and preference-policy records;
optional scalar rewards derived from versioned policies;
baseline scripts for:
- action-conditioned next-state prediction;
- action-prefix multi-horizon prediction;
- outcome, risk, and constraint prediction;
- constrained Pareto beam search over typed actions;
- fixed scalar-reward and CEM baselines where their action-space assumptions apply;
- passive forecasting;
- anomaly detection;
- RCA-style root-cause ranking.

After these consequence-modeling and constrained-planning baselines work, add an INTACT-style preference-conditioned top- $K$ typed-plan proposer and a proposal-plus-verifier baseline. This is deliberately post-MVP: the verifier, outcome model, constraints, and broad-search reference must exist before proposal amortization can be evaluated honestly. The post-MVP proposer milestone should test whether top- $K$ preserves safe near-optimal plans while reducing world-model evaluations, fallback-search frequency, and end-to-end decision latency.

The first milestone can be treated as successful if, after 100-500 episodes, we can answer practical questions:

which telemetry streams are actually useful;
which actions have a measurable effect;
where labels diverge from observed symptoms;
how hard it is to predict edge-level effects;
whether a simple model can distinguish action consequences from an exogenous fault;
whether Pareto planning improves decision quality without hiding safety or cost trade-offs inside one reward.

14. How This Differs From Production Observability

Kubernetes OTEL Control Gym should not pretend to be full production.

Production has:

unknown configurations;
human changes without perfect labels;
business events;
complex release processes;
incomplete telemetry;
third-party dependencies;
seasonality;
organizational constraints.

The gym should be different at the first stage: small, clean, controlled, and reproducible. Its value is not that it is “like production”, but that it has what production data usually does not have:

precise action labels;
precise intervention labels;
repeatable scenarios;
ability to run an alternative policy;
ability to do online evaluation without risking real users.

After that, it can move toward realism:

more services;
more workload profiles;
noisy telemetry;
partial observability;
irregular human-like actions;
production traces as a background distribution;
domain randomization.

15. Main Risks

Local Kubernetes Limitations

Some eBPF and observability capabilities can work poorly in Docker-in-Docker or local MiniKube-like environments. For a stable MVP, it is better to use k3s/kind on a real VM or a remote Kubernetes cluster.

Label Drift

An action or fault may fail to apply, apply only partially, or create an effect somewhere other than expected. Therefore, the orchestrator should record status, precheck, and postcheck. Failed interventions should either be marked explicitly or excluded through a verifiable rule.

Telemetry Gaps

Traces and logs may be incomplete. The MVP should first make metrics and the service graph reliable, then add traces/logs as additional streams.

Confounding Between Actions And Faults

If faults always appear together with remediation actions, the model can learn false relationships. The dataset needs no-fault runs, normal-control runs, and scenarios where actions are applied without incidents.

This is the main caveat to the “actions reduce ambiguity” argument. Logged actions simplify the learning target only when the log separates what the operator controlled from what happened externally, and when the dataset contains enough cases where actions, faults, and no-op periods vary independently.

Overly Synthetic Faults

Chaos Mesh faults do not cover all of production. That is acceptable for a curriculum. Clean interventions are needed first, then more realistic failure modes.

Data Volume Cost

Traces, logs, and frequent buckets will quickly increase dataset size. Start with short runs, a metrics-first format, and controlled aggregation.

Reward Collapse And Preference Drift

A single scalar reward can hide trade-offs, change meaning across incident modes, and encourage reward hacking. The dataset should preserve measured outcomes and constraints independently, version every preference profile, and evaluate policy changes without relabeling the underlying dynamics.

World-Model Exploitation

A planner can select plans that exploit model error rather than the live system. Offline Pareto quality, latent prediction loss, or self-consistency is not enough. Every controller should be evaluated through live-stand transfer, conservative action sets, uncertainty-triggered abstention, and saved failure traces.

Incident-Triggered Replay Bias

Rare unsafe episodes should trigger targeted common-snapshot branching, following the design pattern in CFLight. But an incident-only buffer can teach the model that every operator action predicts failure. Preserve normal episodes and NOOP/WAIT, record whether a branch is measured or model-generated, keep all branches from one snapshot in one dataset split, and validate learned branches against direct stand replay before using them as safety labels.

16. Recommended Implementation Path

The first path should be pragmatic:

Use the Coroot chart as a fast way to deploy OpenTelemetry Demo, Coroot, and Chaos Mesh.
Add a Python orchestrator on top of the Kubernetes API and Chaos Mesh.
Implement a real gym API: reset, observe, step, outcomes, constraints, optional reward, and done.
Support metrics-first node and edge features first.
Save action/intervention logs as ground truth.
Save Coroot findings as weak labels and baseline outputs.
Define the canonical world-model dataset contract with separate outcomes, constraints, preferences, and derived rewards.
Add ChronoGraph-like and RCAEval-style adapters as secondary views.
Run 100-500 short episodes.
Train simple baselines and check that an action-conditioned model outperforms a passive model where the action actually changes dynamics.
Add a history-conditioned action-prefix predictor and constrained Pareto beam-search baseline over typed interventions.
Measure Pareto coverage, regret, calibration, constraint violations, and live-stand transfer before training a learned plan proposal model.
Train an INTACT-style preference-conditioned typed-plan proposer from controlled near-optimal trajectories, then measure safe proposal recall at $K$ , diversity, verifier rejection, fallback-search rate, end-to-end latency, and robustness to changed workloads, graphs, actions, and preferences.

17. Bottom Line

Kubernetes OTEL Control Gym is needed to move from passive observability to training models that understand the consequences of actions.

Existing datasets cover forecasting, anomaly detection, RCA, and LLM-agent diagnosis well. But they usually lack the controlled loop:

observe -> action -> next observation -> outcomes + constraints

A time-series world model differs from an ordinary TSFM because it models not only the continuation of a time series, but also system dynamics under actions, control inputs, and interventions. For DevOps, the model should predict a vector of outcomes and constraint risks rather than optimize one fixed target state. A separate decision layer preserves the feasible Pareto frontier and applies explicit incident policy or human preference. Once that verified path works, an INTACT-style proposer can amortize candidate generation while the world model and constraints remain the safety-critical verification path. This enables what-if analysis, safe control, rollout/rollback decision support, incident recovery planning, and offline controller training before live-stand evaluation.

The gym is the bridge between dataset and production: controlled enough to provide clean labels and repeatable experiments, and live enough to test the closed-loop behavior of a model on a real Kubernetes application.

Relation To Foundation TSFM Agenda

This is an idea page, so the verdicts below describe the intended contribution if the proposed system or experiment works. Evidence status is recorded separately in the Evidence and Missing pieces columns.

The gym is a proposed body, sensor stream, and actuator interface for digital-world robots in operations. The table maps that north-star contribution to concrete agenda slots instead of using Digital-world robots as a slot name.

Agenda slot	Verdict	Evidence	Missing pieces
Causal structure, counterfactuals, and control	partially closes	If implemented, the live `observe -> action -> next observation -> outcomes + constraints` environment would provide typed DevOps actions, fault interventions, action logs, measured outcome vectors, and versioned decision policies.	Build the environment, collect episodes, and show that models can rank candidate action plans under changing preferences without violating constraints.
Benchmarks: what level of modeling is tested?	partially closes	If implemented, the gym would separate passive forecasting, RCA-style diagnosis, action-conditioned next-state prediction, action-prefix rollout, Pareto planning, INTACT-style top- $K$ proposal, proposal plus verification, and closed-loop control utility.	Add a baseline suite with Pareto coverage, safe proposal recall, model-call and latency budgets, fallback rate, regret, calibration, constraint violations, and live-stand transfer.
Multi-modal future distributions	adjacent	The proposed probabilistic outcome interface requires distinct recovery, persistent-degradation, and failure regimes under each action prefix.	Demonstrate calibrated mode mass, tail-risk coverage, and action-sensitive probability shifts rather than only diverse samples.
Native multivariate encoding and high-channel scaling	adjacent	Proposes service graphs, node features, edge features, telemetry streams, and topology as the canonical data shape.	Scale beyond the controlled MVP and demonstrate high-channel behavior.
Context interface	partially closes	If implemented, graph structure, workload profile, service configuration, action history, and intervention metadata become first-class context.	Stabilize a schema that generalizes beyond the OpenTelemetry Demo stand.

Alex Open Research Wiki

Explorer

Kubernetes OTEL Control Gym