Emergence-as-Code as a Foundation for Self-Governing Reliable Systems

Anatoly A. Krasnovsky

The paper proposes Emergence-as-Code (EmaC): end-to-end journey reliability can be compiled from declared intent plus continuously inferred evidence into bounded SLOs, error budgets, and rollout gates.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-03 04:14 UTC pith:3KP3B3ES

load-bearing objection EmaC is a worthwhile vision, but the 'pessimistic' bounds in §4.1 are actually the optimistic extreme, so the safety argument doesn't hold.

arxiv 2602.05458 v2 pith:3KP3B3ES submitted 2026-02-05 cs.SE cs.DCcs.PFcs.SYeess.SY

Emergence-as-Code as a Foundation for Self-Governing Reliable Systems

Anatoly A. Krasnovsky This is my paper

classification cs.SE cs.DCcs.PFcs.SYeess.SY

keywords service level objectivesSLO-as-codejourney reliabilitymicroservicesfailure domainserror budgetstail latencyGitOps

verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper argues that per-service SLO-as-code leaves a critical gap: the reliability users actually experience is end-to-end journeys, which emerge from topology, routing, redundancy, fallbacks, and tail behavior. It proposes Emergence-as-Code (EmaC), a declarative contract that compiles journey-level objectives from stated intent and a continuously inferred, evidence-backed model of the running system. If the vision holds, journey SLOs become versioned, auditable artifacts whose optimistic and pessimistic bounds feed error-budget allocation, burn-rate alerts, and progressive-delivery gates—closing the drift between local service health and user-perceived reliability. The paper is explicitly a vision and research agenda, with a runnable checkout example rather than a completed system.

Core claim

EmaC's central claim is that from a typed journey expression (Series, Parallel, Cond, Race, KofN, Timeout) bound to atomic SLOs and telemetry, plus the last accepted model produced by evidence-driven discovery, a compiler/controller can derive (a) journey availability and tail-latency SLOs as intervals—optimistic under independence, pessimistic under perfect shared fate within declared failure domains; (b) error-budget allocations to services and domains; (c) burn-rate alerts and multi-window policies; and (d) rollout gates and action guards. The interval width is treated as explicit uncertainty, automation defaults to pessimistic bounds, and generated artifacts carry provenance and diff rev

What carries the argument

The central mechanism is the small EmaC operator algebra together with the failure-domain bound rule. Each journey expression composes availability and latency distributions; availability is evaluated twice, once assuming independence (A+) and once assuming perfect correlation within each declared failure domain, so redundancy within a domain adds no benefit and serial dependencies collapse to a single fate. The compiler/controller then treats the resulting interval [A-, A+] as the source of truth for generated governance artifacts—synthetic SLIs, alerting rules, progressive-delivery analysis templates, and action guards—with sensitivity reporting showing which services and domains dominate

Load-bearing premise

The argument rests on the assumption that the pessimistic shared-fate bounds are guaranteed lower bounds on journey availability for any assignment of leaf availabilities; if Eq. (1) can yield an empty interval (e.g., A- > A+ for leaves 0.9 and 0.99 in one domain), then gates keyed to pessimistic bounds are unsound.

What would settle it

Take a single failure domain containing two sequential leaves with availabilities 0.9 and 0.99. Eq. (1) gives A- = 0.9 and A+ = 0.891, an empty interval. Since a genuine lower bound must satisfy A- ≤ A+, this counterexample would refute the bound semantics and every rollout gate compiled from it.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

Journey SLOs can be re-derived automatically whenever topology, routing, redundancy, or failure-domain evidence changes, so the manual sync tax and objective drift disappear.
Rollout gates can be keyed to pessimistic journey bounds: a canary is blocked or sent to review when the shared-fate model makes the journey budget unsafe, even while every service-level SLO remains green.
Error budgets can be allocated down to services and failure domains, with sensitivity reports identifying which components dominate budget burn.
Inference can be confidence-gated: low-risk, high-confidence model deltas auto-accept, while larger changes open a version-controlled diff for human review, avoiding both thrashing and blind automation.
Tail-latency objectives can be governed by an upper confidence bound on the composed distribution, so promotion is allowed only if the canary's predicted p99 stays under the objective.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Because every generated artifact carries a derivation trace from intent through operators to bounds, the same model could double as a targeting map for fault-injection experiments: inject at the edges with the highest sensitivity and lowest evidence confidence.
The confidence-gated reconciliation loop could be extended to learn from human overrides: each rejected delta becomes a training signal for the next evidence-weighting decision, making the system progressively less conservative without losing auditability.
The interval semantics (optimistic versus pessimistic) could also govern multi-tenant budget pools: when several journeys share a component, the pessimistic bound can be used to arbitrate conflicting priorities without manual reconciliation.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Desk Editor's Note

EmaC is a worthwhile vision, but the 'pessimistic' bounds in §4.1 are actually the optimistic extreme, so the safety argument doesn't hold.

read the letter

Here's the take: the EmaC idea is genuinely worth discussing—treating journey-level SLOs as compiled artifacts from intent plus evidence is a nice extension of SLO-as-code—but the paper's central interval-bound derivation in §4.1 is not just loose, it's inverted. For a Series inside a single failure domain, Eq. (1) gives A− = min_i A_i and A+ = ∏ A_i, so A− > A+ for any nontrivial A_i (e.g., 0.9 and 0.99 gives 0.9 > 0.891). An interval with the "lower" bound above the "upper" bound isn't an interval. More importantly, perfect positive correlation is the optimistic extreme for conjunction: if all leaves share a single fate, the chance all succeed is min_i A_i, which is higher than the independence product. The true lower bound for a series is the Fréchet bound max(0, Σ A_i − (n−1)). So the paper's "pessimistic" bound is not conservative, and any rollout gate checked against it is not guaranteed safe.

The good news: the framing is clear and honest. The paper explicitly says it's a vision and research agenda, not a completed system. The operator set is standard probability/reliability, but the integration of model discovery, failure-domain hypotheses, and compiled Argo/Prometheus artifacts is new relative to OpenSLO/Sloth/Pyrra. Related work is fair; the self-citation to [15] is not load-bearing. The walkthrough in §5.4 gives a concrete sense of the intended contract.

Soft spots, in proportion: the bound error is load-bearing because §5.2/5.3 gate automation on these bounds. To fix it, the paper needs a real dependence model—a Bernoulli mixture, a copula, or at least correct Fréchet bounds per operator—rather than a one-size-fits-all "collapse to a single fate" rule. Correlation helps series but hurts races, so no single extreme is universally pessimistic. Also, the abstract claims an "executable checkout replay" demonstrates the failure-domain model changing a rollout decision from pass to fail; that replay is not actually described in the manuscript, only the artifact repository. A short results section or an appendix with the replay output would close the gap. The latency composition section is mostly a sketch, which is fine for a vision but not for the safety claims.

Who this is for: people building SLO tooling or self-adaptive microservices. It's a worthy idea and deserves a serious referee, but the referee will need to push hard on the correlation semantics. I'd send it to review rather than desk-reject; a revision with correct bounds and the replay evidence could be a solid contribution.

Circularity Check

0 steps flagged

No significant circularity: journey-SLO bounds are computed directly from declared intent and evidence; the only self-citation ([15]) is non-load-bearing.

full rationale

The derivation chain is a direct compositional algebra: leaf availabilities, branch probabilities, and failure-domain assignments are inputs; Table 1 and Eqs. (1)-(2) compute interval bounds; governance artifacts are generated by rule from those bounds. No parameter is fitted to the predicted output, no output appears in the input assumptions, and no uniqueness theorem or unverified prior result is invoked to force the algebra. The only self-citation, [15], supports the Model Discovery component ("synthesizes a candidate journey model ... each annotated with provenance and confidence [15, 20]"), but the paper explicitly makes inference optional: "EmaC does not require inference to be perfect: operators may provide an explicit model," so the central computation does not reduce to that citation. The walkthrough is self-authored and is an illustration, not an independent validation; that is a validation gap, not circularity. The paper also openly frames itself as "a vision and research agenda rather than a completed system" (§1), which further supports the absence of a hidden circular derivation. The main quantitative risk is correctness rather than circularity: Eq. (1)'s "pessimistic" Series bound is not in general a lower bound under arbitrary correlation (for a single-domain Series with A_i < 1, A− = min_i A_i ≥ A+ = ∏_i A_i, giving an empty/degenerate interval), so gates keyed on A− are not guaranteed conservative. This is a soundness defect in the claimed semantics, not a case where the output is equivalent to the input by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 5 axioms · 2 invented entities

The central claim rests on classical reliability formulas, a domain-collapse model for shared fate, and an unproven evidence-inference capability. The bounds require an implicit homogeneous-availability assumption that is not stated; with heterogeneous leaves the interval can invert.

axioms (5)

standard math Compositional reliability rules (series product, parallel/race 1−∏, conditional mixture, KofN binomial) correctly represent journey availability.
Used in Table 1; these are classical reliability formulas, but no proof is given that they apply when leaves are measured SLIs.
domain assumption Within a failure domain, perfect correlation justifies A− formulas in Eq (1)-(2) (redundancy no gain, series collapses to one fate).
Central to the pessimistic bound; no joint distribution is defined, and heterogeneous A_i make the collapse ambiguous.
standard math Latency distributions compose via convolution, max, mixture, and order statistics, and quantiles can be estimated from histograms.
Section 4.2; standard but assumes independent serial latencies and stationary distributions.
domain assumption Operational evidence (traces, mesh config, IaC) is sufficient to infer the effective operator graph, branch probabilities, redundancy sets, and failure-domain hypotheses with usable confidence.
Model Discovery is the evidence engine; paper lists this as open research R1/R3.
domain assumption Atomic SLOs and telemetry accurately reflect true per-service success probabilities and latency distributions.
Leaves bind to OpenSLO definitions and telemetry; if SLIs are mis-measured, bounds are meaningless.

invented entities (2)

Model Discovery component no independent evidence
purpose: Consumes traces, mesh config, and IaC to synthesize a candidate journey model (operator graph, branch probabilities, redundancy sets, failure-domain hypotheses) with provenance and confidence.
The core evidence engine is only described at a high level; the paper lists the inference problem as open research (R1, R3) and does not provide an algorithm or validation.
Failure-domain hypothesis no independent evidence
purpose: A model construct representing shared-fate groups, used to compute the pessimistic bound A−.
The paper acknowledges domains cannot be inferred from co-failures when failures are rare and leaves the inference method open (R1); no external falsifiable handle is provided.

pith-pipeline@v1.3.0-alltime-deepseek · 7635 in / 20778 out tokens · 220432 ms · 2026-08-03T04:14:57.058723+00:00 · methodology

0 comments

read the original abstract

Service-level objective (SLO)-as-code tools make per-service reliability declarative, but users experience journeys: end-to-end executions whose availability and tail latency emerge from topology, routing, redundancy, timeouts/fallbacks, shared failure domains, and tail amplification. Journey objectives are therefore often maintained outside code and drift away from the effective runtime graph. We propose Emergence-as-Code (EmaC), a declarative contract that compiles journey-level SLI bounds and governance artifacts for declared SLOs from intent and evidence. An EmaC specification defines a typed journey expression, leaf bindings to atomic SLOs and telemetry, failure-domain assumptions, and guarded actions. Model Discovery proposes evidence-backed deltas for edges, branch probabilities, redundancy groups, and failure-domain hypotheses; each delta carries provenance and confidence. The compiler derives optimistic and pessimistic journey bounds and emits reviewable governance artifacts. An executable checkout replay shows that local SLOs can remain green while evidence-backed discovery changes the failure-domain model, collapses the pessimistic payment-race bound, and changes the rollout decision from pass to fail or review.

Figures

Figures reproduced from arXiv: 2602.05458 by Anatoly A. Krasnovsky.

**Figure 1.** Figure 1: EmaC compiles versioned intent and an evidence-backed (inferred) journey model into bounded journey SLOs, budgets, [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗

discussion (0)

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

Trusted Floors Under Untrusted Learners: A Runtime Assured-SLO Guard for ML Serving
cs.DC 2026-07 conditional novelty 6.0

A Simplex-style guard around untrusted learned admission controllers structurally enforces an assured tenant floor, holding miss 0.0 in real 2xV100 tests where unguarded learners miss 0.86-0.94.
Trusted Floors Under Untrusted Learners: A Runtime Assured-SLO Guard for ML Serving
cs.DC 2026-07 conditional novelty 5.5

Reservation plus assured-first priority holds admitted assured-class miss at 0.0 on real 2xV100 under every miscalibration of a learned admitter, while GAIE Flow Control fails under label swap.

Reference graph

Works this paper leans on

29 extracted references · 2 canonical work pages · cited by 1 Pith paper

[1]

Anderson

Philip W. Anderson. 1972. More Is Different.Science177, 4047 (1972), 393–396. doi:10.1126/science.177.4047.393

doi:10.1126/science.177.4047.393 1972
[2]

Anonymized. [n. d.]. https://anonymous.4open.science/r/Emergence-as-Code- 85B6/
[3]

Argo Project. 2025. Analysis & Progressive Delivery. Argo Rollouts Documen- tation. https://argoproj.github.io/argo-rollouts/features/analysis/ Accessed: 2026-01-15

2025
[4]

Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr. 2004. Basic Concepts and Taxonomy of Dependable and Secure Computing.IEEE Emergence-as-Code for Self-Governing Reliable Systems Transactions on Dependable and Secure Computing1, 1 (2004), 11–33. doi:10.1109/ TDSC.2004.2

2004
[5]

2016.Site Reliability Engineering: How Google Runs Production Systems

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy. 2016.Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media

2016
[6]

2018.The Site Reliability Workbook: Practical Ways to Implement SRE

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy. 2018.The Site Reliability Workbook: Practical Ways to Implement SRE. O’Reilly Media

2018
[7]

Jeffrey Dean and Luiz André Barroso. 2013. The Tail at Scale.Commun. ACM56, 2 (2013), 74–80. doi:10.1145/2408776.2408794

arXiv 2013
[8]

Maia, and Mariela I

Messias Filho, Eliaquim Barbosa Pimentel, Wellington Pereira, Paulo Henrique M. Maia, and Mariela I. Cortés. 2021. Self-Adaptive Microservice-based Systems: Landscape and Research Opportunities. InProceedings of the 2021 International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS ’21). doi:10.1109/SEAMS51251.2021.00030

arXiv 2021
[9]

David Garlan, Shang-Wen Cheng, An-Cheng Huang, Bradley Schmerl, and Peter Steenkiste. 2004. Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure.Computer37, 10 (2004), 46–54. doi:10.1109/MC.2004.175

doi:10.1109/mc.2004.175 2004
[10]

Google SRE. 2018. Alerting on SLOs. The Site Reliability Workbook (online chapter). https://sre.google/workbook/alerting-on-slos/ Accessed: 2026-01-15

2018
[11]

IBM Corporation. 2005. An Architectural Blueprint for Autonomic Com- puting. White paper (3rd edition). https://www.cse.fau.edu/~bob/courses/ AutonomicComputing/BIBM01.pdf Accessed: 2026-01-15

2005
[12]

International Electrotechnical Commission. 2016. IEC 61078: Reliability Block Diagrams. International Standard. https://webstore.iec.ch/publication/25647 Accessed: 2026-01-15

2016
[13]

Harry W. Jones. 2012. Common Cause Failures and Ultra Reliability. In Proceedings of the 42nd International Conference on Environmental Systems. doi:10.2514/6.2012-3602 Accessed: 2026-01-15

work page doi:10.2514/6.2012-3602 2012
[14]

Kephart and David M

Jeffrey O. Kephart and David M. Chess. 2003. The Vision of Autonomic Comput- ing.Computer36, 1 (2003), 41–50. doi:10.1109/MC.2003.1160055

Pith/arXiv arXiv 2003
[15]

Krasnovsky

Anatoly A. Krasnovsky. 2026. Model Discovery and Graph Simulation: A Light- weight Gateway to Chaos Engineering. InProceedings of the 48th IEEE/ACM International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER ’26). ACM, Rio de Janeiro, Brazil, 5. doi:10.1145/3786582.3786823

arXiv 2026
[16]

Kubernetes Authors. 2025. Custom Resources. Kubernetes Documenta- tion. https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/ custom-resources/ Accessed: 2026-01-15

2025
[17]

Mahdi Mirhosseini, Salah Elnikety, and Thomas F. Wenisch. 2021. ParSLO: A Framework for Tuning the Partially-Shared SLOs in Microservices. InProceedings of the ACM Symposium on Cloud Computing (SoCC ’21). 442–457. doi:10.1145/ 3472883.3486985

arXiv 2021
[18]

Martin Monperrus. 2014. Principles of Antifragile Software. arXiv preprint arXiv:1404.3056. https://arxiv.org/abs/1404.3056

Pith/arXiv arXiv 2014
[19]

OpenSLO Contributors. 2024. OpenSLO: Open Specification for Defining and Expressing Service Level Objectives. GitHub repository. https://github.com/ OpenSLO/OpenSLO Accessed: 2026-01-15

2024
[20]

OpenTelemetry Authors. 2025. Traces. OpenTelemetry Documentation. https: //opentelemetry.io/docs/concepts/signals/traces/ Accessed: 2026-01-15

2025
[21]

Prometheus Authors. 2025. Histograms and Summaries. Prometheus Documen- tation. https://prometheus.io/docs/practices/histograms/ Accessed: 2026-01-15

2025
[22]

Prometheus Authors. 2025. Prometheus Query Functions:histogram_quantile. Prometheus Documentation. https://prometheus.io/docs/prometheus/latest/ querying/functions/#histogram_quantile Accessed: 2026-01-15

2025
[23]

Pyrra Authors. 2025. Pyrra: SLO and Error Budget Dashboard for Prometheus. GitHub repository. https://github.com/pyrra-dev/pyrra Accessed: 2026-01-15

2025
[24]

2021.Developing Cyber-Resilient Systems: A Systems Security Engineering Approach

Ron Ross, Victoria Pillitteri, Richard Graubart, Deborah Bodeau, and Rosalie Mc- Quaid. 2021.Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. NIST Special Publication 800-160 Vol. 2 Rev. 1. National Institute of Standards and Technology. doi:10.6028/NIST.SP.800-160v2r1 Accessed: 2026-01- 15

doi:10.6028/nist.sp.800-160v2r1 2021
[25]

Benjamin Treynor Sloss, Mike Dahlin, Vivek Rau, and Betsy Beyer. 2017. The Calculus of Service Availability: You’re Only as Available as the Sum of Your Dependencies.Queue15, 2 (2017), 49–67. doi:10.1145/3080202 Accessed: 2026- 01-15

work page doi:10.1145/3080202 2017
[26]

Sloth Authors. 2025. Sloth: SLO Generator for Prometheus. GitHub repository. https://github.com/slok/sloth Accessed: 2026-01-15

2025
[27]

W. E. Vesely, F. F. Goldberg, N. H. Roberts, and D. F. Haasl. 1981.Fault Tree Handbook. Technical Report NUREG-0492. U.S. Nuclear Regulatory Commission. https://www.nrc.gov/docs/ML1216/ML12167A103.pdf Accessed: 2026-01-15

1981
[28]

Shuang Zeng, Haitao Zhang, and Zezhong Yan. 2026. CASLO: Joint Scaling and Deployment for Microservices Leveraging Context-Aware SLO Assignment. Journal of Network and Computer Applications247 (2026), 104417. doi:10.1016/j. jnca.2025.104417

arXiv 2026
[29]

Yazhuo Zhang, Rebecca Isaacs, Yao Yue, Juncheng Yang, Lei Zhang, and Ymir Vigfusson. 2023. LatenSeer: Causal Analysis and What-If for End-to-End Latency in Distributed Traces. InProceedings of the ACM Symposium on Cloud Computing (SoCC ’23). 502–519. doi:10.1145/3620678.3624787

arXiv 2023

[1] [1]

Anderson

Philip W. Anderson. 1972. More Is Different.Science177, 4047 (1972), 393–396. doi:10.1126/science.177.4047.393

doi:10.1126/science.177.4047.393 1972

[2] [2]

Anonymized. [n. d.]. https://anonymous.4open.science/r/Emergence-as-Code- 85B6/

[3] [3]

Argo Project. 2025. Analysis & Progressive Delivery. Argo Rollouts Documen- tation. https://argoproj.github.io/argo-rollouts/features/analysis/ Accessed: 2026-01-15

2025

[4] [4]

Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr. 2004. Basic Concepts and Taxonomy of Dependable and Secure Computing.IEEE Emergence-as-Code for Self-Governing Reliable Systems Transactions on Dependable and Secure Computing1, 1 (2004), 11–33. doi:10.1109/ TDSC.2004.2

2004

[5] [5]

2016.Site Reliability Engineering: How Google Runs Production Systems

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy. 2016.Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media

2016

[6] [6]

2018.The Site Reliability Workbook: Practical Ways to Implement SRE

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy. 2018.The Site Reliability Workbook: Practical Ways to Implement SRE. O’Reilly Media

2018

[7] [7]

Jeffrey Dean and Luiz André Barroso. 2013. The Tail at Scale.Commun. ACM56, 2 (2013), 74–80. doi:10.1145/2408776.2408794

arXiv 2013

[8] [8]

Maia, and Mariela I

Messias Filho, Eliaquim Barbosa Pimentel, Wellington Pereira, Paulo Henrique M. Maia, and Mariela I. Cortés. 2021. Self-Adaptive Microservice-based Systems: Landscape and Research Opportunities. InProceedings of the 2021 International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS ’21). doi:10.1109/SEAMS51251.2021.00030

arXiv 2021

[9] [9]

David Garlan, Shang-Wen Cheng, An-Cheng Huang, Bradley Schmerl, and Peter Steenkiste. 2004. Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure.Computer37, 10 (2004), 46–54. doi:10.1109/MC.2004.175

doi:10.1109/mc.2004.175 2004

[10] [10]

Google SRE. 2018. Alerting on SLOs. The Site Reliability Workbook (online chapter). https://sre.google/workbook/alerting-on-slos/ Accessed: 2026-01-15

2018

[11] [11]

IBM Corporation. 2005. An Architectural Blueprint for Autonomic Com- puting. White paper (3rd edition). https://www.cse.fau.edu/~bob/courses/ AutonomicComputing/BIBM01.pdf Accessed: 2026-01-15

2005

[12] [12]

International Electrotechnical Commission. 2016. IEC 61078: Reliability Block Diagrams. International Standard. https://webstore.iec.ch/publication/25647 Accessed: 2026-01-15

2016

[13] [13]

Harry W. Jones. 2012. Common Cause Failures and Ultra Reliability. In Proceedings of the 42nd International Conference on Environmental Systems. doi:10.2514/6.2012-3602 Accessed: 2026-01-15

work page doi:10.2514/6.2012-3602 2012

[14] [14]

Kephart and David M

Jeffrey O. Kephart and David M. Chess. 2003. The Vision of Autonomic Comput- ing.Computer36, 1 (2003), 41–50. doi:10.1109/MC.2003.1160055

Pith/arXiv arXiv 2003

[15] [15]

Krasnovsky

Anatoly A. Krasnovsky. 2026. Model Discovery and Graph Simulation: A Light- weight Gateway to Chaos Engineering. InProceedings of the 48th IEEE/ACM International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER ’26). ACM, Rio de Janeiro, Brazil, 5. doi:10.1145/3786582.3786823

arXiv 2026

[16] [16]

Kubernetes Authors. 2025. Custom Resources. Kubernetes Documenta- tion. https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/ custom-resources/ Accessed: 2026-01-15

2025

[17] [17]

Mahdi Mirhosseini, Salah Elnikety, and Thomas F. Wenisch. 2021. ParSLO: A Framework for Tuning the Partially-Shared SLOs in Microservices. InProceedings of the ACM Symposium on Cloud Computing (SoCC ’21). 442–457. doi:10.1145/ 3472883.3486985

arXiv 2021

[18] [18]

Martin Monperrus. 2014. Principles of Antifragile Software. arXiv preprint arXiv:1404.3056. https://arxiv.org/abs/1404.3056

Pith/arXiv arXiv 2014

[19] [19]

OpenSLO Contributors. 2024. OpenSLO: Open Specification for Defining and Expressing Service Level Objectives. GitHub repository. https://github.com/ OpenSLO/OpenSLO Accessed: 2026-01-15

2024

[20] [20]

OpenTelemetry Authors. 2025. Traces. OpenTelemetry Documentation. https: //opentelemetry.io/docs/concepts/signals/traces/ Accessed: 2026-01-15

2025

[21] [21]

Prometheus Authors. 2025. Histograms and Summaries. Prometheus Documen- tation. https://prometheus.io/docs/practices/histograms/ Accessed: 2026-01-15

2025

[22] [22]

Prometheus Authors. 2025. Prometheus Query Functions:histogram_quantile. Prometheus Documentation. https://prometheus.io/docs/prometheus/latest/ querying/functions/#histogram_quantile Accessed: 2026-01-15

2025

[23] [23]

Pyrra Authors. 2025. Pyrra: SLO and Error Budget Dashboard for Prometheus. GitHub repository. https://github.com/pyrra-dev/pyrra Accessed: 2026-01-15

2025

[24] [24]

2021.Developing Cyber-Resilient Systems: A Systems Security Engineering Approach

Ron Ross, Victoria Pillitteri, Richard Graubart, Deborah Bodeau, and Rosalie Mc- Quaid. 2021.Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. NIST Special Publication 800-160 Vol. 2 Rev. 1. National Institute of Standards and Technology. doi:10.6028/NIST.SP.800-160v2r1 Accessed: 2026-01- 15

doi:10.6028/nist.sp.800-160v2r1 2021

[25] [25]

Benjamin Treynor Sloss, Mike Dahlin, Vivek Rau, and Betsy Beyer. 2017. The Calculus of Service Availability: You’re Only as Available as the Sum of Your Dependencies.Queue15, 2 (2017), 49–67. doi:10.1145/3080202 Accessed: 2026- 01-15

work page doi:10.1145/3080202 2017

[26] [26]

Sloth Authors. 2025. Sloth: SLO Generator for Prometheus. GitHub repository. https://github.com/slok/sloth Accessed: 2026-01-15

2025

[27] [27]

W. E. Vesely, F. F. Goldberg, N. H. Roberts, and D. F. Haasl. 1981.Fault Tree Handbook. Technical Report NUREG-0492. U.S. Nuclear Regulatory Commission. https://www.nrc.gov/docs/ML1216/ML12167A103.pdf Accessed: 2026-01-15

1981

[28] [28]

Shuang Zeng, Haitao Zhang, and Zezhong Yan. 2026. CASLO: Joint Scaling and Deployment for Microservices Leveraging Context-Aware SLO Assignment. Journal of Network and Computer Applications247 (2026), 104417. doi:10.1016/j. jnca.2025.104417

arXiv 2026

[29] [29]

Yazhuo Zhang, Rebecca Isaacs, Yao Yue, Juncheng Yang, Lei Zhang, and Ymir Vigfusson. 2023. LatenSeer: Causal Analysis and What-If for End-to-End Latency in Distributed Traces. InProceedings of the ACM Symposium on Cloud Computing (SoCC ’23). 502–519. doi:10.1145/3620678.3624787

arXiv 2023