Extending Expectation Chains With Security Requirements

Abstract

Expectation chains were originally defined as a formal method for expressing, measuring, and validating service guarantees across distributed systems using three primary axes: availability, reliability, and performance. These axes map cleanly to traditional observability practices and allow system designers to decompose end-to-end guarantees into measurable expectations across service boundaries. However, modern software systems face security threats that are as existential as outages or latency regressions. Treating security as a separate concern from observability introduces blind spots, operational friction, and systemic risk. This paper argues that security requirements can and should be incorporated directly into expectation chains as first-class expectation attributes. By extending expectation axes to include security properties such as encryption in transit, encryption at rest, authentication strength, and access control guarantees, organizations can unify security and observability into a single, coherent operational model. This article presents a conceptual framework for security-extended expectation chains, demonstrates how security requirements can be made observable and measurable, and provides concrete architectural examples. The result is a generalized pattern that allows software engineers to reason about availability, reliability, performance, and security using the same formal structure, enabling continuous verification of both operational and security guarantees.

Introduction

Modern software systems are expected to be simultaneously fast, reliable, available, and secure. Historically, these concerns have been managed using different frameworks, tools, and organizational structures. Reliability engineering focuses on uptime, error rates, and latency. Security engineering focuses on confidentiality, integrity, and access control. Observability practices provide insight into system behavior, while security monitoring focuses on threats and violations. Although these domains are deeply interconnected, they are often modeled and measured independently.

Expectation chains provide a unifying abstraction for reasoning about distributed systems. An expectation chain models a system as a sequence of provider–consumer relationships, where each interaction is governed by an explicit expectation describing what the provider must deliver to satisfy the consumer. Originally, expectation chains focused on three axes: availability, reliability, and performance. These axes map naturally to service-level objectives and can be continuously measured using observability data.

This paper proposes extending expectation chains by adding security requirements as additional expectation attributes. Rather than treating security as a policy layer or a separate monitoring concern, security properties are expressed as formal expectations on the same edges that already encode availability and performance guarantees. This extension allows security to be reasoned about, measured, and enforced using the same mechanisms that underpin observability-driven system design.

Expectation Chains and the Original Three Axes

Expectation chains model how value flows through a system from provider to consumer. Each interaction between components is governed by an expectation that defines the measurable conditions under which value is considered successfully delivered (Caldwell, 2018). Expectations are directional and explicit: a provider satisfies an expectation only if it meets the defined criteria.

Originally, expectation chains defined three axes:

Availability – the ability of a provider to be accessed when needed.
Reliability – the correctness and consistency of the provider’s behavior.
Performance – the timeliness or throughput with which the provider delivers value.

These axes correspond closely to established reliability engineering concepts such as uptime, error budgets, and latency service-level objectives (Beyer et al., 2016). Importantly, expectation chains do not prescribe how expectations are measured; they only require that expectations be objectively verifiable.

Expectation chains differ from traditional SLAs in that they are compositional. High-level business expectations are decomposed into lower-level technical expectations across dependencies. A failure at any point in the chain propagates upward, making the root cause observable and traceable.

Observability as the Measurement Mechanism for Expectations

Observability enables engineers to determine whether a system’s expectations are being met based on emitted telemetry (Charity & Crawford, 2018). Logs, metrics, and traces are merely data sources; observability is the capability to infer system state from those signals.

Within an expectation chain model, observability data answers a single question: Is the expectation satisfied? Availability expectations may be validated using synthetic probes or error rates. Reliability expectations may be validated using correctness checks or invariant violations. Performance expectations may be validated using latency distributions or throughput counters.

Crucially, observability is expectation-agnostic. Any property that can be measured can be expressed as an expectation. This characteristic makes expectation chains extensible beyond the original three axes.

Why Security Must Be Treated as an Expectation

Security failures are not orthogonal to reliability failures. A data breach, authentication bypass, or encryption failure represents a catastrophic violation of system guarantees, even if uptime and latency remain within acceptable bounds. From the consumer’s perspective, a system that leaks sensitive data has failed, regardless of how responsive it is.

Industry experience increasingly demonstrates that security and reliability failures are tightly coupled. Outages often create security exposure, and security incidents frequently degrade availability and performance (Gupta, 2025). Treating security as a separate discipline results in fragmented visibility and delayed response.

By incorporating security requirements into expectation chains, security becomes:

Explicit rather than implicit
Measurable rather than assumed
Continuously verified rather than periodically audited

This aligns with modern DevSecOps principles and zero-trust architectures, which emphasize continuous verification over static trust assumptions.

Extending Expectation Axes With Security Attributes

Security expectations can be expressed as additional attributes on expectation edges. These attributes define the conditions under which an interaction is considered secure. The following sections describe common security requirements and how they map to expectation chains.

Encryption in Transit as an Expectation

Encryption in transit ensures confidentiality and integrity of data exchanged between components. In an expectation chain, encryption in transit can be expressed as a binary expectation:

All data exchanged across this edge must be encrypted using approved cryptographic protocols.

This expectation can be measured by observing protocol usage, certificate validation, or connection metadata. If unencrypted traffic is detected, the expectation is violated regardless of latency or availability metrics.

Encryption in transit is widely recognized as a baseline security requirement for modern systems (Kast, 2025). Treating it as an expectation ensures that regressions, misconfigurations, or unauthorized endpoints are detected immediately.

Operational Benefits of Unified Expectation Chains

Extending expectation chains with security attributes provides several benefits:

Unified visibility across reliability and security
Reduced silos between engineering teams
Faster detection of misconfigurations and regressions
Objective security metrics aligned with business value
Improved incident response through shared observability context
This approach transforms security from a compliance activity into an operational discipline.

Conclusions

Expectation chains provide a powerful abstraction for reasoning about distributed systems. By extending expectation axes to include security requirements, organizations can unify security and observability into a single operational model. Security expectations become explicit, measurable, and continuously verified, eliminating blind spots and reducing systemic risk.

In modern systems, a service that is fast and available but insecure has failed its fundamental promise. Security-extended expectation chains provide a formal, observable, and scalable way to ensure that promise is kept.

References

Beyer, B., Jones, C., Petoff, J., & Murphy, N. (2016). Site reliability engineering: How Google runs production systems. O’Reilly Media.

Caldwell, S. (2018). Expectation chains: Observability by design. samcaldwell.net.

Caldwell, S. (2019). Expectation chains for developers. samcaldwell.net.

Charity, M., & Crawford, L. (2018). Observability engineering. O’Reilly Media.

Gupta, R. (2025). Building an effective SRE and security engineering team. Engineering Pulse.

Kast, B. (2025). Data encryption best practices. LMG Security.

Maynes, M. (2019). One simple action you can take to prevent 99.9 percent of attacks on your accounts. Microsoft Secure Blog.

U.S. Cybersecurity and Infrastructure Security Agency. (2025). Four cybersecurity essentials for businesses. CISA.