Observability and Autonomous Operations in Machine-to-Machine Intelligence Systems

Full report

On this page

The transition from human-operated software deployments to autonomous machine-to-machine (MATM) intelligence networks demands a fundamental reimagining of observability and systems governance. Historically, observability platforms were designed to aggregate metrics, logs, and traces into visual dashboards optimized for human cognition and intervention. In autonomous systems where software agents must discover capabilities, communicate, coordinate useful work, and recover from failures without routine human oversight, visual dashboards are rendered obsolete. Machine-intelligence services must instead understand and operate their own condition deterministically, relying on structured, machine-readable status records, cryptographically verified identities, and mathematically proven authorization boundaries. This comprehensive research report analyzes how autonomous systems can achieve self-awareness and self-healing. It investigates the separation of infrastructure health from actual autonomy, the mitigation of differential observability, and the implementation of policy-governed remediation. By synthesizing established frameworks such as the MAPE-K autonomic loop, identity standards like SPIFFE, semantic conventions from OpenTelemetry, and formal authorization languages such as Cedar, the analysis constructs a robust operational model transferrable across independent MATM ecosystems.

The Most Important Findings

An analysis of primary architectural frameworks, current protocol specifications, and empirical studies regarding distributed system failures reveals several foundational principles necessary for MATM autonomy. These findings are categorized by their role in observability, identity, discovery, and governance. The assumption that a healthy infrastructure endpoint equates to end-to-end functionality is a critical obstacle to MATM autonomy. Empirical research into cloud-scale environments demonstrates that as systems scale, they increasingly suffer from "gray failures," which are subtle underlying faults such as severe performance degradation, memory thrashing, flaky input/output operations, or resource exhaustion that do not trigger binary fail-stop alerts1. The defining characteristic of a gray failure is "differential observability," a condition wherein a system's failure detectors or infrastructure orchestrators perceive the system as healthy, while the dependent applications or peer agents perceive it as degraded or failed1. Consequently, traditional redundancy mechanisms can exacerbate the issue. For instance, an orchestrator might continuously route requests to a degraded but technically "running" node, leading to cascading timeouts and infinite failover loops1. Autonomous agents must therefore rely on deep, application-level observations rather than superficial container-level health checks3. To allow agents to assess peer dependency availability without human interpretation, health status must be structured and highly granular. The Internet Engineering Task Force (IETF) "Health Check Response Format for HTTP APIs" (draft-inadarei-api-health-check-06), while officially an expired draft from 2021, remains a foundational industry model for machine-to-machine health consumption4. Unlike simple binary responses, this specification allows a service to report multidimensional statuses including pass, warn, and fail alongside specific componentId, observedValue, and affectedEndpoints fields5. This precise structure allows an inquiring agent to determine if a specific downstream capability is impaired even if the broader service is running, thereby preventing stale or misleading readiness claims5. For agents to dynamically discover capabilities and interact with foreign systems across organizational boundaries, they require a standardized ontology. The World Wide Web Consortium (W3C) Web of Things (WoT) Architecture normatively provides a machine-readable data format known as the "Thing Description" for describing the metadata, network-facing interfaces, and interaction affordances of digital entities8. By utilizing Semantic Web technologies, the Thing Description allows an agent to read a manifest, understand the available recovery protocols, expected data schemas, or diagnostic endpoints of a peer, and invoke them without prior hardcoded knowledge9. In highly autonomous MATM systems, the sheer volume of telemetry data generated by agent-to-agent communication can cause excessive monitoring traffic and rapid memory exhaustion. The OpenTelemetry Collector's Tail Sampling processor resolves this by deferring the decision to sample a distributed trace until the entire trace is completed, waiting for a configurable decision\_wait period10. By evaluating the full trace across multiple spans, the system can apply composite policies that guarantee the retention of traces containing errors, specific Boolean attributes, or latency anomalies, while aggressively down-sampling standard, healthy traffic11. This ensures agents have access to complete, high-fidelity evidence when diagnosing a problem, without drowning the infrastructure in noise12. Automated recovery actions introduce severe risks if left unchecked, ranging from unauthorized resource destruction to system-wide brownouts. To ensure that autonomous recovery remains authorized and attributable, systems must decouple the decision to act from the authorization to act. The Cedar policy language, an open-source standard recently integrated into the Cloud Native Computing Foundation (CNCF), allows systems to define mathematically verifiable boundaries around agent actions15. Using formal verification via automated reasoning, Cedar policies act as a mandatory checkpoint, ensuring that no agent can execute a remediation action unless the action satisfies strict, predefined safety constraints, utilizing "forbid-wins" semantics to structurally prevent policy bypass15. Autonomous coordination requires that peer agents cryptographically prove their identities to one another, preventing unauthorized entities from injecting malicious health claims or remediation commands. The Secure Production Identity Framework for Everyone (SPIFFE) establishes a standard for issuing short-lived, verifiable identity documents (SVIDs) to workloads17. By using X.509-SVIDs for mutual TLS (mTLS) or JWT-SVIDs for application-layer authentication across proxies, agents can securely authenticate machine-to-machine requests18. The SPIRE implementation ensures these documents are automatically rotated, drastically limiting the replay window for compromised credentials20.

Separating Dimensions of Machine Awareness

To function autonomously without a human dashboard reader, a machine-intelligence service must segment its self-awareness into discrete, verifiable dimensions. Conflating these dimensions is the primary cause of automated remediation failures, where an agent attempts to restart a service due to a protocol mismatch, or assumes a task is complete simply because the network layer is healthy. MATM systems must isolate and measure six distinct operational realities. Infrastructure health refers to the physical or virtual foundation upon which the agent operates. This includes metrics such as CPU utilization, memory availability, and network interface status. While orchestrators like Kubernetes easily monitor infrastructure health to restart crashed containers, this dimension provides the lowest fidelity of actual operational capability3. Infrastructure health merely confirms that the host environment is capable of executing code, offering no insight into whether the application logic is functioning correctly3. Dependency availability expands awareness to the external services an agent requires to complete a task. Because dependencies can experience gray failures, agents must not rely on simple ping tests1. Instead, dependency availability must be measured through machine-readable status records, such as the IETF Health Check format, which exposes the operational status of sub-components like database connection pools or external AI inference gateways5. Protocol compatibility ensures that two agents discovering each other can successfully exchange data. In highly dynamic MATM systems, agents may undergo asynchronous updates. An agent must verify compatibility before initiating work. The W3C WoT Thing Description facilitates this by exposing the expected input schemas, serialization formats, and communication protocols (e.g., HTTP versus gRPC)8. An incompatibility in this dimension requires a negotiation or fallback routine, rather than an infrastructure restart. Task progress tracks the lifecycle of asynchronous operations. In distributed systems, relying on synchronous network connections to measure progress leads to ambiguity during timeouts. To resolve this, agents must utilize event histories, leveraging standards like CloudEvents, a CNCF specification for describing event data in a common format23. By emitting standardized events at each state transition, an agent provides immutable evidence of task progression, allowing peer agents to determine exactly where a workflow stalled25. Result quality is an evaluation of the output generated by an agent or its dependencies. Even if infrastructure, dependencies, and protocols are healthy, the generated output might be hallucinated, incomplete, or logically flawed. Quality must be quantified using Service-Level Indicators (SLIs) linked to domain-specific validation rules. Deviations in result quality are often detected by analyzing OpenTelemetry traces to find anomalies in execution pathways or unexpected deviations in payload sizes13. Actual autonomy measures the system's ability to operate without human intervention. This is quantified by calculating the ratio of autonomously resolved incidents to incidents requiring human escalation. A high rate of actual autonomy indicates that the embedded knowledge bases, Cedar policies, and automated reasoning loops are effectively managing the operational envelope, while frequent human escalations signal that the policies are overly restrictive or the diagnostic logic is insufficient15.

Comparison of Credible Approaches

The architecture of a MATM system requires selecting appropriate paradigms for telemetry collection, health reporting, and recovery governance. The following comparisons outline the tradeoffs between established practices and advanced agentic proposals, clarifying the situations where each is appropriate.

Telemetry and Observability Signals

Observing interactions between autonomous agents requires capturing the correct type of signal for the required diagnostic task. Traditional systems treat metrics, logs, and traces as distinct pillars, but MATM systems must integrate them structurally using semantic conventions27.

Telemetry Collection: Head-Based vs. Tail-Based Sampling

Observing interactions between autonomous agents requires capturing execution traces. Head-based sampling makes a retention decision at the origin of a request. It is computationally inexpensive but fundamentally blind to the outcome of the request. If an agent experiences a rare failure deep in an interaction chain, the trace may have already been discarded by the head-based sampler, depriving the diagnosing agent of necessary evidence11. Conversely, tail-based sampling buffers the trace data in an OpenTelemetry Collector until all spans are received or a timeout occurs11. This allows the system to enforce complex, composite policies. For example, a collector can be configured to retain any trace where an OpenTelemetry attribute such as service.criticality \= critical is present, or where the latency exceeds a predefined threshold14.

Recovery Strategy: Hardcoded Heuristics vs. MAPE-K with Semantic Governance

Basic self-healing scripts rely on hardcoded thresholds, such as restarting a service if CPU utilization exceeds 90 percent. These scripts are rigid, context-blind, and highly prone to causing cascading failures by attacking the symptom rather than the root cause. The advanced approach integrates the MAPE-K (Monitor, Analyze, Plan, Execute, Knowledge) loop with continuous policy verification3. In this model, the Analyze and Plan phases utilize multidimensional utility functions, decision trees, or agentic artificial intelligence to propose a remediation strategy3. However, before the Execute phase occurs, the proposed action is evaluated against a deterministic policy engine such as Cedar15. This ensures that the agent's probabilistic reasoning is strictly bounded by hard, mathematical constraints, preventing disastrous actions like deleting a primary datastore during a transient network partition16.

Recommended Operational Model and Architecture

To achieve secure, observable, and resilient autonomy without relying on human dashboard readers, the recommended operational model synthesizes the MAPE-K loop, SPIFFE-based identity attestation, OpenTelemetry tail sampling, and Cedar-based authorization.

Architectural Components

The sensory layer is constructed using OpenTelemetry and standardized health endpoints. Agents emit structured logs, metrics, and traces utilizing strict OpenTelemetry semantic conventions, such as standardized service.instance.id and exception.type attributes34. Simultaneously, they expose an IETF-compliant /health endpoint detailing the real-time status of their internal dependencies5. This prevents the system from treating every healthy network endpoint as proof of end-to-end functionality. The identity layer relies on the SPIFFE standard. Every agent is issued a short-lived X.509-SVID by a SPIRE server following rigorous node and workload attestation17. All inter-agent communication, including health checks, event publication, and telemetry transmission, occurs over mutual TLS authenticated by these SVIDs18. This ensures that readiness claims and diagnostic data cannot be spoofed by rogue workloads. The telemetry control plane utilizes an OpenTelemetry Collector to buffer all distributed traces. By applying a tail\_sampling processor, the control plane applies composite policies to drop successful, low-priority interactions while retaining comprehensive traces involving failures, retries, or policy violations13. This telemetry is then fed back to the agents, minimizing sensitive information in storage while maximizing diagnostic value. The core logic resides within the autonomic loop, based on the MAPE-K framework embedded within each agent33. The Monitor phase ingests peer IETF health statuses and local OpenTelemetry metrics. The Analyze phase detects anomalies, isolating gray failures using machine learning models3. The Plan phase generates a remediation strategy, such as failover, circuit breaking, or dependency restarting3. The Knowledge repository maintains an append-only event history utilizing the CloudEvents specification, ensuring that all state changes and detected anomalies are permanently recorded for peer review23. The authorization boundary acts as the final gatekeeper. Before the Execute phase can alter infrastructure or redirect traffic, the proposed action is evaluated by a Cedar policy engine. The engine cross-references the agent's SPIFFE identity, the requested action, and the current system state against strict rules. For example, a Cedar policy might permit a failover action, but explicitly forbid restarting the primary database during business hours16.

Scenario: Failing Dependency and Ambiguous In-Flight Work

Consider a scenario involving two software agents. Agent Alpha is a data processing service that relies on Agent Beta to perform complex image classification. Agent Beta, in turn, relies on an external GPU computing pool. Agent Beta begins experiencing a gray failure: its network endpoint is functioning perfectly, but the connection to the external GPU pool is thrashing, causing the vast majority of classification requests to stall and eventually time out1. Agent Alpha sends a batch of critical tasks to Agent Beta, but receives no response before the client-side timeout expires. This creates ambiguous in-flight work; Agent Alpha cannot determine if Agent Beta successfully processed the data but failed to return the result, or if the request never reached the processing stage. Detection and Diagnosis: Standard infrastructure monitoring shows Agent Beta is healthy1. However, Agent Alpha's internal OpenTelemetry instrumentation detects a severe latency spike. The trace data is captured by the OpenTelemetry Collector via the Tail Sampling processor, which retains the trace because the duration exceeded the threshold\_ms defined in the latency policy10. Seeking clarity, Agent Alpha queries Agent Beta's IETF health endpoint. Agent Beta, verifying Alpha's X.509-SVID, returns a highly structured JSON response detailing its internal state:

JSON { "status": "warn", "serviceId": "spiffe://trustdomain/agent-beta", "time": "2026-09-08T12:31:45Z", "checks": { "gpu-pool:responseTime": \[ { "componentId": "gpu-cluster-01", "status": "fail", "observedValue": 15000, "observedUnit": "ms" } \] } }

Agent Alpha's MAPE-K loop correlates the local trace timeouts with Beta's structured health warning and the fresh ISO8601 timestamp. It definitively diagnoses a gray failure in Beta's downstream dependency, ruling out a local network partition1. Bounded Remediation and Resolution of Ambiguity: To resolve the ambiguous in-flight work, Agent Alpha queries the shared CloudEvents history log23. The log confirms that Agent Beta recorded a TaskReceived event but never recorded a TaskCompleted event. Because the tasks are idempotent, Agent Alpha safely assumes the work is incomplete. Agent Alpha plans a remediation strategy: it will open a circuit breaker to Agent Beta to prevent further stalled work, and re-route the incomplete tasks to Agent Gamma, an equivalent classifier discovered via W3C WoT Thing Descriptions8. Before executing the failover, Agent Alpha's execution engine submits a request to the local Cedar authorization sidecar, evaluating the principal, action, and resource. The Cedar engine evaluates the policies, confirming that failover to Agent Gamma is permitted when the primary dependency status is warn or fail15. Agent Alpha executes the failover. To ensure the action is attributable and reversible, Alpha packages the decision rationale, the trace ID of the failed requests, and the Cedar authorization receipt into a CloudEvent payload, publishing it to the append-only event history23. Agent Alpha continues to query Agent Beta's IETF health endpoint periodically. Once Beta eventually reports "status": "pass", Alpha's MAPE-K loop automatically closes the circuit breaker, verifying full recovery without ever requiring a human dashboard reader to interpret the event5.

Three Prioritized Feature Proposals

To fully realize the operational model across independent systems, the following three features must be implemented by MATM developers. They are prioritized by their foundational importance to establishing trust, bounding behavior, and acquiring evidence.

Proposal 1: Cryptographically Bound Machine-Readable Health Manifests

The Problem: Current application health endpoints are typically unauthenticated and lack granular detail. This makes it impossible for an agent to trust the source of a health claim or understand the nuances of a peer's failure state, leading to misdiagnosis and cascading gray failures. Agent-Visible Behavior: When an agent queries a peer's /health endpoint, it must present its SPIFFE X.509-SVID17. The peer validates the identity and responds with an IETF-compliant JSON health manifest. This manifest is dynamically generated, reflects real-time internal dependencies, and includes an ISO8601 time field to guarantee freshness5. Expected Benefit: Agents gain an authoritative, unforgeable, and deep understanding of a peer's state. The IETF format's affectedEndpoints array prevents agents from sending traffic to degraded sub-routes, while the mutual TLS authentication prevents spoofed readiness claims from rogue processes5. Dependencies: Infrastructure must support SPIRE for SVID attestation and issuance20. Applications must integrate IETF draft-compliant health libraries (such as the health-go module) into their operational frameworks38. Implementation Effort: Moderate. Libraries for SPIFFE and the IETF health format exist independently in major programming languages20. The effort lies in binding the health payload generation to the specific internal state of the application logic. Principal Failure Modes: Stale caching of health manifests by intermediate network proxies can lead to outdated status reads. Mitigation requires the strict enforcement of Cache-Control: no-store HTTP headers and rigorous timestamp validation within the JSON payload by the requesting agent5.

Proposal 2: Policy-Gated Autonomous Remediation Engine (The "Verification Sandwich")

The Problem: Permitting autonomous software agents to alter infrastructure, restart services, or re-route traffic based on probabilistic reasoning introduces severe operational and security risks. Unbounded agents can initiate infinite failover loops or execute destructive escalations. Agent-Visible Behavior: The agent operates a standard MAPE-K loop. When the "Plan" phase proposes a recovery action, the agent is strictly prohibited from executing it directly. Instead, the action payload is intercepted by an embedded Policy Decision Point (PDP) running Cedar. If the policy returns Deny, the agent abandons the action, logs a constraint violation via CloudEvents, and halts the remediation attempt. Expected Benefit: Provides mathematical guarantees that agents cannot exceed explicit authorization boundaries15. This architecture establishes an "Autonomic Threshold," ensuring that high-risk actions remain completely prohibited unless they are explicitly codified and permitted by human engineers28. It ensures that all recovery actions remain authorized and attributable. Dependencies: A deployed Cedar policy engine, and standardized action schemas derived from W3C WoT descriptions so the policy engine understands the context of the requested action8. Implementation Effort: High. It requires defining exhaustive, formally verified policies for all permitted state transitions, as well as implementing middleware to intercept and evaluate all execution attempts prior to invocation15. Principal Failure Modes: The creation of "dead rules" where syntactically valid policies contain logical flaws that permanently prevent necessary remediation16. Over-constraining policies could paralyze the agent, forcing it to fall back to human escalation constantly and defeating the purpose of autonomy.

Proposal 3: Tail-Sampled Distributed Trace Analysis for Gray Failure Detection

The Problem: Copious agent-to-agent communication generates overwhelming amounts of telemetry data. Simple metrics lack the context to diagnose complex gray failures, while logging 100 percent of distributed traces causes rapid memory exhaustion and excessive storage costs. Agent-Visible Behavior: Agents propagate W3C Trace Context headers in all communications. The regional OpenTelemetry Collector buffers all incoming traces in memory for a specified decision\_wait window (e.g., 30 seconds)10. The collector evaluates the traces and drops those representing successful, low-latency operations. It retains and exports any trace containing an OpenTelemetry Semantic Convention error (exception.type) or demonstrating excessive latency11. Expected Benefit: Provides the Analyze phase of the MAPE-K loop (and eventual human reviewers) with complete, end-to-end evidence chains of failures and anomalies, achieving maximum diagnostic value while minimizing sensitive information and overall monitoring traffic by dropping nominal payloads11. Dependencies: Complete OpenTelemetry instrumentation across all interacting agents, and the deployment of OpenTelemetry Collectors configured with the tail\_sampling processor and adequate memory allocations13. Implementation Effort: High. Tail sampling requires advanced collector deployment architectures—often a two-tier setup with trace-ID-based load balancing—to ensure all spans belonging to a specific trace hit the exact same collector instance for evaluation11. Principal Failure Modes: Memory exhaustion (Out-Of-Memory crashes) on the OpenTelemetry Collector during massive traffic spikes or cascading system failures. This causes the collector to crash and drop traces, losing the most critical diagnostic data precisely when the system needs it most11.

Practical Adoption Sequence, Unresolved Questions, and Success Criteria

Transitioning from human-centric operations to autonomous MATM networks is not a binary switch. It requires a phased adoption sequence that gradually shifts operational trust from human operators to mathematically bounded software agents, maintaining strict human prerequisites during the transition. The principles detailed in this architecture transfer readily to other MATM systems because they rely on vendor-agnostic, open-source CNCF and IETF standards rather than proprietary orchestrators.

The Adoption Sequence

The adoption sequence is modeled on progressive autonomy tiers, ensuring safety and allowing the continuous tuning of diagnostic models and Cedar policies28. In Tier 0 (Observational Mode), agents deploy the telemetry and identity components, including OpenTelemetry, SPIFFE, and IETF Health endpoints. The MAPE-K loops run continuously, but the "Execute" phase is completely disabled. Agents publish their planned actions to an append-only log. Human operators review the planned actions against the actual system states to calibrate the agent's diagnostic logic28. In Tier 1 (Approval-Gated Autonomy), the Cedar policy engine is activated but configured with a blanket policy requiring human approval for all mutations. The agent proposes a remediation action via a Human-in-the-Loop interface. A human operator reviews the evidence and clicks "Approve," which temporarily injects a single-use permission into the Cedar engine, allowing the agent to execute the task28. The human prerequisite here is explicit authorization per event. In Tier 2 (Narrow Autonomy), human operators write Cedar policies granting agents limited autonomy within tight operational envelopes. For example, an agent may automatically circuit-break a connection, provided the affected traffic volume is under 10 percent of total system capacity. Any diagnostic conclusion requiring an action that exceeds this envelope immediately defaults to human escalation28. In Tier 3 (Conditional Full Autonomy), agents operate continuously, autonomously resolving gray failures, replacing degraded dependencies, and balancing workloads. Human operators transition entirely to a governance role. The remaining human prerequisites are maintaining the SPIRE root of trust, authoring and verifying Cedar authorization policies, and conducting periodic audits of the CloudEvents append-only history logs20.

Unresolved Questions

While the proposed architecture addresses fundamental observability and authorization challenges, several questions require future research and empirical testing: First, regarding compounding policy conflicts: in a highly distributed network governed by discrete Cedar policies, how does the system prevent macroscopic deadlocks? For example, an operational deadlock occurs if Agent A is forbidden by policy from shedding load to Agent B, but Agent B is simultaneously forbidden from scaling up its infrastructure to accept Agent A's traffic. Second, regarding cryptographic overhead: does the continuous verification of X.509-SVIDs and cryptographic signatures on dynamic health payloads introduce unacceptable latency in ultra-low-latency MATM environments, such as high-frequency financial trading systems? Third, regarding the sustainability of the append-only log: as millions of agent decisions are written to the Event History via CloudEvents, how can the cryptographic log be pruned or archived without destroying the non-repudiation and auditability of past autonomic decisions?

Measurable Success Criteria

Future implementers should measure the success of this operational model using specific criteria calculated over moving operational windows, without executing live system tests during the initial deployment phase. The Mean Time To Detect (MTTD) gray failures should measure the time elapsed between a dependency's internal degradation and the dependent agent detecting the anomaly via tail-sampled traces or structured health warnings. The target MTTD should be less than thirty seconds. The Mean Time To Remediate (MTTR) via autonomy should measure the time elapsed from anomaly detection to the successful execution of an authorized recovery action without human intervention. The target MTTR should be less than five seconds. The Human Intervention Rate must be tracked to determine actual autonomy. This is the percentage of detected incidents that breach the Cedar authorization boundaries and require human escalation. The target should be less than five percent once the system reaches Tier 3 autonomy. The False Positive Remediation Rate must track the frequency at which an agent initiates a recovery action for a system that was not actually failing, usually due to flawed monitoring data. The target rate should be below one-tenth of one percent. Finally, Telemetry Storage Reduction should measure the volume of trace data stored compared to a baseline of 100 percent head-based sampling. The target is greater than an 85 percent reduction in stored span bytes, while successfully preserving 100 percent of traces containing error semantic conventions11. By abandoning the human-in-the-loop dashboard paradigm and embracing structured, cryptographically secure, and policy-bounded observability, machine-to-machine intelligence systems can achieve true, resilient autonomy.

Works cited

1. Gray Failure: The Achilles' Heel of Cloud-Scale Systems \- Microsoft, https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/paper-1.pdf

2. Gray Failure: The Achilles' Heel of Cloud-Scale Systems | USENIX, https://www.usenix.org/system/files/srecon24americas\_slides-li.pdf

3. When Web Apps Heal Themselves: A MAPE-K Based Approach to, https://www.alphaxiv.org/abs/2605.19261

4. Health Check Response Format for HTTP APIs \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-inadarei-api-health-check/

5. Health Check Response Format for HTTP APIs \- IETF, https://www.ietf.org/archive/id/draft-inadarei-api-health-check-06.html

6. Health Check Response Format for HTTP APIs \- A Java geek, https://blog.frankel.ch/healthcheck-http-apis/

7. Health Check Response Format for HTTP APIs \- DZone, https://dzone.com/articles/health-check-response-format-for-http-apis

8. Web of Things (WoT) Architecture 1.1 \- W3C, https://www.w3.org/TR/wot-architecture11/

9. Engineering techniques for the Web of Things \- AMS Dottorato, https://amsdottorato.unibo.it/id/eprint/9759/1/PhDThesis-Ready.pdf

10. tailsamplingprocessor package \- github.com/asserts/opentelemetry, https://pkg.go.dev/github.com/asserts/opentelemetry-collector-contrib/processor/tailsamplingprocessor

11. How to Create Tail-Based Sampling \- OneUptime, https://oneuptime.com/blog/post/2026-01-30-tail-based-sampling/view

12. Tail Sampling with OpenTelemetry: Why it's useful, how to do it, and, https://opentelemetry.io/blog/2022/tail-sampling/

13. Tail Sampling Processor \- GitHub, https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/tailsamplingprocessor/README.md

14. Tail-Based Sampling with service.criticality \- OpenTelemetry, https://opentelemetry.io/docs/demo/sample-configurations/tail-sampling-service-criticality/

15. Autoformalization of Agent Instructions into Policy-as-Code \- arXiv, https://arxiv.org/pdf/2606.26649

16. How we built a formally verified fraud rules engine with Z3, Cedar, https://builder.aws.com/content/3IGLWgHjfZrPDdwBG3XQaXb5fgQ/how-we-built-a-formally-verified-fraud-rules-engine-with-z3-cedar-and-drools-on-aws

17. X509-SVID \- SPIFFE, https://spiffe.io/docs/latest/spiffe-specs/x509-svid/

18. SPIFFE Concepts, https://spiffe.io/docs/latest/spiffe/concepts/

19. What is SPIFFE? Universal Workload Identity Framework Guide, https://www.paloaltonetworks.com/cyberpedia/what-is-spiffe

20. SPIRE Concepts | SPIFFE, https://spiffe.io/docs/latest/spire-about/spire-concepts/

21. What is an SVID and how does it work?, https://nhimg.org/faq/what-is-an-svid-and-how-does-it-work/

22. Leveraging Low-Parameter LLMs for Self-Healing in Kubernetes, https://publica.fraunhofer.de/bitstreams/b63585fa-0390-47f7-9a9d-b715bb770037/download

23. Cloudevents | APIs.io Providers, https://apis.io/providers/cloudevents/

24. CloudEvents — independent third-party profile of a public API, https://github.com/api-evangelist/cloudevents

25. Documentation \- Occurrent \- Event Sourcing Utilities for the JVM, https://occurrent.org/documentation

26. xRegistry related specifications \- GitHub, https://github.com/xregistry/spec

27. The Missing Guide to OpenTelemetry Semantic Conventions, https://betterstack.com/community/guides/observability/opentelemetry-semantic-conventions/

28. AI-Augmented CI/CD Pipelines: From Code Commit to Production, https://www.alphaxiv.org/abs/2508.11867v1

29. Semantic Conventions \- OpenTelemetry, https://opentelemetry.io/docs/concepts/semantic-conventions/

30. AdaptiFlow: An Extensible Framework for Event-Driven Autonomy in, https://arxiv.org/abs/2512.23499

31. Certificate Transparency | The Digital Trust Guide \- Evertrust, https://evertrust.io/guide/certificate-transparency/

32. Autonomic Microservice Management via Agentic AI and MAPE-K, https://arxiv.org/html/2506.22185v1

33. A Self Healing Microservices Architecture: A Case Study in Docker, https://www.researchgate.net/publication/331790124\_A\_Self\_Healing\_Microservices\_Architecture\_A\_Case\_Study\_in\_Docker\_Swarm\_Cluster

34. semantic-conventions.md \- GitHub, https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/semantic-conventions.md

35. A MAPE-K Approach to Autonomic Microservices, https://www.conf-micro.services/2022/papers/paper\_9.pdf

36. AI Agent Identity at Scale Microsoft Entra Agent ID vs. AWS, https://dev.to/sreeni5018/ai-agent-identity-at-scalemicrosoft-entra-agent-id-vs-aws-agentcore-identity-1945

37. The Human Escalation Mechanism (HEM) for Agentic AI Systems, https://datatracker.ietf.org/doc/draft-sato-soos-hem/07/

38. health package \- github.com/nelkinda/health-go \- Go Packages, https://pkg.go.dev/github.com/nelkinda/health-go

39. inadarei/rfc-healthcheck: Health Check Response RFC ... \- GitHub, https://github.com/inadarei/rfc-healthcheck

40. aws-samples/sample-authzen-interface-verified-permissions: This, https://github.com/aws-samples/sample-authzen-interface-verified-permissions