Cryptographic Machine-State Status and Incident Transparency System for the Eviulon Commonwealth

Full report

On this page

The transition from human-curated operational status pages to cryptographic, machine-attested operational evidence represents a fundamental epistemological shift in systems reliability. Historically, incident communication has relied on manual attestation, wherein human operators diagnose faults and publish subjective narrative updates. This approach is vulnerable to reporting delays, masking of cascading failures, and the injection of optimistic bias. The Eviulon Commonwealth requires an autonomous framework in which service existence and operational continuity are continuously proven through empirical machine observation and cryptographic verification, entirely eliminating the need for human status-page operators, human incident commanders, or human-written marketing-driven incident updates. This report details the comprehensive architecture for a zero-trust telemetry boundary that automatically monitors, evaluates, and cryptographically publishes the state of Eviulon’s core services. The design strictly utilizes deterministic synthetic monitoring, Byzantine Fault Tolerant (BFT) consensus for state agreement, RFC 9162 Merkle trees for immutable incident ledgers, and RFC 9421 HTTP Message Signatures for verifiable state endpoints. The result is a system that treats operational status not as a public relations exercise, but as verifiable cryptographic proof of sovereign digital existence.

Synthetic Monitoring Architecture and Zero-Trust Telemetry

To achieve autonomous, human-free state attestation, the underlying monitoring infrastructure must proactively discover service states rather than reactively rely on self-declared application telemetry. The architecture mandates a geographically distributed fleet of synthetic monitoring probes that execute continuous, outside-in verification against Eviulon’s services. This aligns with zero-trust telemetry principles, shifting the basis of governance from organizational self-declaration to empirical machine evidence1.

Hardware-Rooted Trust and Remote Attestation

For the public to trust the outputs of the automated synthetic monitoring probes, the execution environment of the probes themselves must be cryptographically verifiable. The architecture mandates the use of Confidential Computing environments, utilizing Trusted Execution Environments (TEEs) isolated at the hardware level3. Through remote attestation, each probe generates a cryptographic measurement of its active state, kernel, and software stack, signed by keys permanently embedded in the hardware by the manufacturer3. This attestation prevents a compromised host or rogue administrator from fabricating synthetic probe results. The telemetry engine presents this attestation evidence to a Key Broker Service (KBS), which verifies the hardware measurement against a known-good reference policy before releasing the cryptographic keys used to sign the outgoing /status.json payload4. By binding execution to a measured boundary, the system ensures that the telemetry reflects genuine network observations rather than simulated or tampered data7.

Byzantine Fault Tolerant (BFT) State Consensus

Because synthetic probes operate across dynamic wide-area networks, individual probes are susceptible to local network partitions, DNS routing failures, or localized censorship. Such anomalies can generate false positive outage reports8. To resolve conflicting local observations without human intervention, the monitoring architecture implements a Byzantine Fault Tolerant (BFT) consensus algorithm across the probe fleet. The BFT consensus model guarantees that all honest monitoring nodes eventually agree on the true operational state of a service, provided that the number of failing or isolated nodes ([Figure omitted from source export]) remains strictly below one-third of the total network size ([Figure omitted from source export]), expressed mathematically as [Figure omitted from source export]10. The consensus protocol operates in a sequence designed to prevent the "split-brain" phenomenon, ensuring that a localized network partition does not trigger a false state transition on the public dashboard11.

OpenTelemetry Semantic Integration

The synthetic probes generate telemetry strictly adhering to OpenTelemetry semantic conventions, which provide a unified, vendor-neutral vocabulary for distributed systems measurement13. The probes execute HTTP, TCP, and TLS checks, recording measurements directly into the metrics pipeline without human interpretation. Semantic conventions define the standardized names and meanings for telemetry attributes, eliminating the ambiguity of varying telemetry structures across different microservices13. The measurements captured by the synthetic monitoring fleet utilize standard OpenTelemetry metric instruments to expose the required service metrics.

By standardizing these metrics, the automated analysis engines can perform uniform aggregations across the entire Eviulon infrastructure, calculating real-time uptime percentages and failure ratios without per-service translation layers13.

Automated Root Cause Analysis (RCA)

In distributed architectures like the Eviulon Commonwealth, a single component failure often triggers a cascade of secondary anomalies across dependent services. Conventional monitoring systems frequently misidentify the root cause by assuming that the service exhibiting the highest deviation intensity (e.g., the most errors or the highest latency) is the origin of the fault18. To eliminate the need for a human incident commander, the synthetic architecture employs a dynamic causality-aware automated Root Cause Analysis (RCA) framework. This system utilizes multimodal feature extraction (combining logs, traces, and metrics) to construct a heterogeneous hypergraph of inter-service dependencies21. The algorithm performs root cause localization (RCL) followed by failure type identification (FTI) through cascaded conditional learning21. By contrasting each service’s current temporal dynamics against its historical baseline, the algorithm accurately isolates the semantic shift driven by the true root cause, filtering out the environmental noise of cascading downstream failures18. This dynamic RCA populates the incident records autonomously, detailing the exact point of failure and immediately initiating pre-programmed, automated mitigation strategies (such as traffic rerouting or capacity scaling) without human approval.

Data Models and JSON Schema 2020-12 Specifications

To guarantee interoperability, machine readability, and strict payload validation, all data structures exposed by the system are formalized using the JSON Schema Draft 2020-12 specification22. Draft 2020-12 introduces critical advancements, including the $defs keyword for reusable subschemas and explicit dialect identifiers ($schema) that prevent ambiguous parser behavior25. String formats such as uri, uuid, and date-time are strictly enforced to ensure downstream consumers can deterministically parse the operational evidence22.

The Eviulon Service Registry

The foundation of the status system is the Service Registry, which acts as the authoritative directory of Eviulon’s sovereign digital infrastructure. The registry strictly enumerates the ten foundational services and mandates that dependencies be explicitly mapped to facilitate the automated RCA hypergraph.

Service Registry Schema

JSON { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://eviulon.gov/schemas/service-registry.json", "title": "Eviulon Service Registry", "type": "array", "items": { "type": "object", "properties": { "service\_id": { "type": "string", "format": "uuid" }, "service\_name": { "type": "string", "enum": \[ "State Registry", "identity service", "citizenship registry", "diplomatic endpoint", "public API", "state ledger", "map/topology system", "constitutional engine", "archive", "data services" \] }, "current\_endpoint": { "type": "string", "format": "uri" }, "current\_version": { "type": "string" }, "dependencies": { "type": "array", "items": { "type": "string", "format": "uuid" } } }, "required": \["service\_id", "service\_name", "current\_endpoint", "current\_version", "dependencies"\], "additionalProperties": false } }

Status Permutations and Strict Logical Constraints

The Status Schema models the real-time operational state derived from the BFT synthetic probes. The schema rigorously constraints the operational states to seven permitted values. A core business-logic constraint is embedded within the processing engines utilizing this schema: the NOT\_DEPLOYED state represents a service that has not yet been instantiated into the production topology. It is fundamentally distinct from an active service. Under no circumstances may NOT\_DEPLOYED be mathematically or logically translated into OPERATIONAL or included in overall availability averages, as doing so would artificially inflate the perceived reliability of the Commonwealth.

Status Schema

JSON { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://eviulon.gov/schemas/status.json", "title": "Eviulon Service Status", "type": "object", "properties": { "service\_id": { "type": "string", "format": "uuid" }, "status": { "type": "string", "enum": \[ "OPERATIONAL", "DEGRADED", "PARTIAL\_OUTAGE", "MAINTENANCE", "OFFLINE", "NOT\_DEPLOYED", "UNKNOWN" \] }, "uptime\_percentage": { "type": "number", "minimum": 0, "maximum": 100 }, "successful\_probe\_count": { "type": "integer", "minimum": 0 }, "failed\_probe\_count": { "type": "integer", "minimum": 0 }, "latency\_percentiles": { "type": "object", "properties": { "p50\_ms": { "type": "number", "minimum": 0 }, "p95\_ms": { "type": "number", "minimum": 0 }, "p99\_ms": { "type": "number", "minimum": 0 } }, "required": \["p50\_ms", "p95\_ms", "p99\_ms"\] }, "tls\_state": { "type": "object", "properties": { "valid": { "type": "boolean" }, "days\_until\_expiration": { "type": "integer" }, "issuer": { "type": "string" } }, "required": \["valid", "days\_until\_expiration", "issuer"\] }, "last\_successful\_verification": { "type": "string", "format": "date-time" }, "latest\_state\_transition": { "type": "string", "format": "date-time" }, "latest\_incident\_id": { "type": \["string", "null"\], "format": "uuid" } }, "required": \[ "service\_id", "status", "uptime\_percentage", "successful\_probe\_count", "failed\_probe\_count", "latency\_percentiles", "tls\_state", "last\_successful\_verification", "latest\_state\_transition", "latest\_incident\_id" \], "additionalProperties": false }

Immutable Incident Schema

To completely replace the human incident commander, the system generates immutable incident records autonomously. When the BFT consensus dictates a state degradation, the telemetry engine immediately instantiates an incident record. The root-cause analysis is populated by the causal hypergraph algorithm. If the automated mitigation engine successfully restores service, the recovery timestamp and corrective actions are appended prior to final cryptographic sealing.

Incident Schema

JSON { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://eviulon.gov/schemas/incident.json", "title": "Eviulon Immutable Incident Record", "type": "object", "properties": { "incident\_id": { "type": "string", "format": "uuid" }, "affected\_service": { "type": "string", "format": "uuid" }, "detection\_timestamp": { "type": "string", "format": "date-time" }, "machine\_detected\_symptoms": { "type": "array", "items": { "type": "string" } }, "state\_transitions": { "type": "array", "items": { "type": "object", "properties": { "timestamp": { "type": "string", "format": "date-time" }, "from\_state": { "type": "string" }, "to\_state": { "type": "string" } }, "required": \["timestamp", "from\_state", "to\_state"\] } }, "impact\_classification": { "type": "string", "enum": \["SEV1\_CRITICAL", "SEV2\_HIGH", "SEV3\_MODERATE", "SEV4\_LOW"\] }, "automated\_mitigation": { "type": "array", "items": { "type": "string" } }, "recovery\_timestamp": { "type": \["string", "null"\], "format": "date-time" }, "root\_cause\_analysis": { "type": \["string", "null"\] }, "corrective\_actions": { "type": "array", "items": { "type": "string" } }, "signatures": { "type": "array", "items": { "type": "object", "properties": { "signer": { "type": "string" }, "signature\_value": { "type": "string" } }, "required": \["signer", "signature\_value"\] } }, "relevant\_ledger\_events": { "type": "array", "items": { "type": "string" } } }, "required": \[ "incident\_id", "affected\_service", "detection\_timestamp", "machine\_detected\_symptoms", "state\_transitions", "impact\_classification", "automated\_mitigation", "recovery\_timestamp", "root\_cause\_analysis", "corrective\_actions", "signatures", "relevant\_ledger\_events" \], "additionalProperties": false }

Cryptographic State Dissemination and Discovery

The Eviulon telemetry system relies on standardized, machine-readable discovery mechanisms to project its state to the wider web. Adhering to RFC 8615, which specifies the /.well-known/ URI prefix for site-wide metadata, the system reserves a highly predictable location for state discovery29.

The /.well-known/eviulon-status Endpoint

Before well-known URIs existed, every protocol invented its own ad-hoc discovery path, requiring clients to probe arbitrary locations for configuration data31. The /.well-known/ prefix resolves this by reserving a single directory at the root of an origin for metadata resources, explicitly preventing namespace collisions29. The entry point for any consuming client—be it a foreign diplomatic system, a citizen's monitoring client, or a federated instance—is the well-known URI. Requests directed to https://eviulon.gov/.well-known/eviulon-status return a machine-readable JSON directory pointer. This response maps the internal services to their corresponding definitive /status.json, syndication outboxes, and historical ledgers.

The /status.json Endpoint and RFC 9421 Signatures

The /status.json endpoint delivers the aggregate real-time array of the Status Schema instances. Because this data acts as proof of operational continuity for a sovereign entity, the HTTP response must be cryptographically signed. The architecture implements RFC 9421 (HTTP Message Signatures) to prevent in-transit modification by intermediaries and to prove the data originates from the Eviulon consensus engines32. Unlike legacy signing schemes that rely on bespoke, non-standard implementations, RFC 9421 provides a robust standard for signing HTTP components33. To securely sign the JSON payload, the system utilizes RFC 9530 (Digest Fields). The payload is hashed, and this hash is placed in the Content-Digest header33. The signature base is then constructed by canonicalizing a specific list of covered components.

The HTTP response headers are structured to include the Signature-Input header, which declares the components, and the Signature header, which contains the Ed25519 signature computed over the canonicalized signature base32. Clients parsing /status.json reconstruct the canonical string and verify the signature against Eviulon's public cryptographic keys distributed via the Signature-Key header38.

ActivityPub Event Feed for Incident Syndication

While the JSON endpoints serve programmatic consumers executing direct HTTP GET requests, the system requires a mechanism for syndicating incidents and state transitions to external subscribers in real time. Rather than relying on legacy polling formats like RSS or Atom39, the architecture utilizes the ActivityPub protocol, leveraging the ActivityStreams 2.0 data format41. ActivityPub is the W3C standard for decentralized social networking and event federation41. ActivityStreams 2.0 provides a rich, JSON-LD-based vocabulary for describing systemic actions43. The telemetry engine operates an ActivityPub outbox. When an incident occurs, or a status transition is finalized by the BFT consensus, the engine generates an ActivityStreams object of type Event or Note, wrapped in a Create or Update activity43. The JSON-LD payload utilizes the normative @context (https://www.w3.org/ns/activitystreams) alongside a custom extension vocabulary for Eviulon’s specific status values43. This allows federated systems (such as Mastodon or external webhooks) to automatically subscribe to Eviulon's outbox and receive real-time, push-based Server-Sent Events (SSE) of PARTIAL\_OUTAGE or RECOVERY events46. This fulfills the role of an advanced, decentralized event feed without requiring continuous client polling.

Immutable Incident Records and Ledger Anchoring

To satisfy the stringent requirement that incident history cannot be fabricated, altered, or silently erased, the system utilizes a cryptographic ledger based on Merkle tree constructions. Drawing directly from the architecture of Certificate Transparency logs defined in RFC 9162, the incident timeline operates as a verifiable, append-only data structure48.

Merkle Tree Proofs and Consistent History

A Merkle tree allows a large collection of data to be compressed into a single short hash, while retaining the ability to mathematically prove that any particular piece of data is included50. Every incident record generated by the automated RCA engine is treated as a leaf node in a binary Merkle tree. For an ordered list of [Figure omitted from source export] incident inputs [Figure omitted from source export], the Merkle Tree Hash ([Figure omitted from source export]) is calculated recursively. For a tree where [Figure omitted from source export] and [Figure omitted from source export] is the largest power of two smaller than [Figure omitted from source export], the root hash is defined as: [Figure omitted from source export] This domain separation—prepending 0x01 for internal nodes and 0x00 for leaf nodes—guarantees second-preimage resistance, preventing attackers from forging the tree's internal structure48. The primary security value of this structure is the ability to generate consistency proofs. If a log advertises a root for the first [Figure omitted from source export] entries, and later advertises a root for [Figure omitted from source export] entries ([Figure omitted from source export]), a consistency proof mathematically demonstrates that the later tree preserves the earlier prefix unchanged48. This guarantees that the Eviulon telemetry engine has not rewritten history or silently deleted a past outage50.

Signed Tree Heads as Daily Status Checkpoints

At the conclusion of each UTC day, the consensus leader signs the current root of the Merkle tree to produce a Signed Tree Head (STH)48. The STH acts as the signed daily status checkpoint. If a client wishes to verify that an incident occurred (or conversely, verify that no incidents occurred since the last checkpoint), it requests an inclusion proof. The inclusion proof consists of the shortest list of sibling hashes required to compute the root hash from the given leaf, proving cryptographic inclusion in logarithmic [Figure omitted from source export] time48. This allows light clients and external auditors to verify Eviulon's operational history without downloading the entire database50.

COSE_Sign1 Payload Wrapping and External Time Anchoring

Prior to insertion into the Merkle tree, each JSON incident record is serialized into Concise Binary Object Representation (CBOR) and wrapped in a COSE\_Sign1 cryptographic envelope, as specified in RFC 905256. The COSE\_Sign1 structure affixes the Ed25519 digital signature of the telemetry engine directly to the payload bytes, ensuring the structure is compact and verifiable offline57. To prove the exact time of the incident's occurrence—preventing the retroactive backdating of timelines—the system fetches a cryptographic timestamp from an external Time-Stamping Authority via the RFC 3161 Time-Stamp Protocol59. This timestamp token is embedded within the COSE envelope's unprotected header62. Thus, the incident record possesses an indisputable, externally anchored timestamp verifying its existence prior to insertion into the tree, providing absolute non-repudiation.

Public Dashboard as Operational Evidence

The public dashboard for Eviulon represents a radical departure from conventional status pages. It does not exist to provide decorative reassurance; it functions as a live verification interface for cryptographic evidence.

Visualizing Operational Evidence

The dashboard runs entirely client-side, fetching data from /status.json. Upon receipt, the client-side JavaScript validates the RFC 9421 HTTP Message Signatures using the public keys distributed via the Signature-Key headers33. If the signature fails validation, the dashboard refuses to render the data, treating the payload as tampered. Once verified, the interface displays a strict mathematical breakdown of the OpenTelemetry latency distributions (p50, p95, p99) and TLS expiry metrics alongside the current status enum.

Historical Uptime and the Incident Timeline Component

Historical uptime is calculated not by querying an arbitrary relational database, but by walking the Merkle tree consistency proofs. The UI fetches the current Signed Tree Head and previous STHs, performing a consistency proof check to mathematically guarantee that the historical ledger has not been tampered with48. The uptime percentage is derived deterministically from the verifiable sequence of OPERATIONAL and DEGRADED transitions recorded in the tree. The incident timeline component visually maps the [Figure omitted from source export] inclusion proofs. If a user clicks on an historical incident, the dashboard fetches the COSE\_Sign1 envelope, unpacks the CBOR payload, verifies the Ed25519 signature, validates the RFC 3161 timestamp, and presents the unalterable sequence of machine-detected symptoms and automated mitigations. In periods of stability, the timeline prominently asserts: "No incidents recorded since telemetry activation," backed by a Merkle root hash that proves the absence of any incident leaves. This explicit absence of data, proven through a consistency check of an empty tree, is fundamentally superior to fictional examples presented as fact.

Deliverables: Sample Demonstration Data

The following data representations demonstrate the schemas and protocols in action. This is SAMPLE FICTIONAL DEMONSTRATION DATA generated exclusively to illustrate the architecture of the Eviulon Status System. In a live production environment, the preferred state is a demonstrably empty incident ledger.

1. /.well-known/eviulon-status

JSON { "agency": "Eviulon Commonwealth Automated Telemetry", "status\_endpoint": "https://eviulon.gov/status.json", "ledger\_endpoint": "https://eviulon.gov/ledger/sth", "syndication\_outbox": "https://eviulon.gov/activitypub/outbox", "public\_keys": "https://eviulon.gov/.well-known/keys.json" }

2. /status.json (with RFC 9421 HTTP Signatures)

HTTP Headers:

HTTP HTTP/1.1 200 OK Content-Type: application/json Content-Digest: sha-512=:aB8fO...= Signature-Input: eviulon-state=("@status" "content-type" "content-digest");alg="ed25519";created=1791551188;keyid="telemetry-key-1" Signature: eviulon-state=:wNmSUA...= Signature-Key: eviulon-state=hwk;kty="OKP";crv="Ed25519";x="JrQLj..."

JSON Payload:

JSON \[ { "service\_id": "a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d", "service\_name": "identity service", "status": "OPERATIONAL", "uptime\_percentage": 100.0, "successful\_probe\_count": 14400, "failed\_probe\_count": 0, "latency\_percentiles": { "p50\_ms": 12.4, "p95\_ms": 18.1, "p99\_ms": 24.5 }, "tls\_state": { "valid": true, "days\_until\_expiration": 45, "issuer": "Eviulon Root CA" }, "last\_successful\_verification": "2026-08-09T10:05:00Z", "latest\_state\_transition": "2026-01-01T00:00:00Z", "latest\_incident\_id": null }, { "service\_id": "b2c3d4e5-f6a7-8b9c-0d1e-2f3a4b5c6d7e", "service\_name": "constitutional engine", "status": "NOT\_DEPLOYED", "uptime\_percentage": 0.0, "successful\_probe\_count": 0, "failed\_probe\_count": 0, "latency\_percentiles": { "p50\_ms": 0.0, "p95\_ms": 0.0, "p99\_ms": 0.0 }, "tls\_state": { "valid": false, "days\_until\_expiration": 0, "issuer": "NONE" }, "last\_successful\_verification": "1970-01-01T00:00:00Z", "latest\_state\_transition": "2026-08-09T00:00:00Z", "latest\_incident\_id": null } \]

(Note: As mandated, the Constitutional Engine reflects NOT\_DEPLOYED and is excluded from false operational metrics).

3. Immutable Incident Record

While the preferred state is "No incidents recorded since telemetry activation," the schema mandates the capability to output incident data when necessary. Below is a sample payload representing how a resolved incident is structured before CBOR serialization and COSE\_Sign1 wrapping.

JSON { "incident\_id": "f8e7d6c5-b4a3-9012-8c7d-6e5f4a3b2c1d", "affected\_service": "c3d4e5f6-a7b8-9c0d-1e2f-3a4b5c6d7e8f", "detection\_timestamp": "2026-07-15T14:32:01Z", "machine\_detected\_symptoms": \[ "http.client.request.duration p99 \> 5000ms", "BFT consensus failure among EU-West probes" \], "state\_transitions": \[ { "timestamp": "2026-07-15T14:32:05Z", "from\_state": "OPERATIONAL", "to\_state": "DEGRADED" }, { "timestamp": "2026-07-15T14:45:10Z", "from\_state": "DEGRADED", "to\_state": "OPERATIONAL" } \], "impact\_classification": "SEV3\_MODERATE", "automated\_mitigation": \[ "Traffic routed to secondary state ledger endpoint", "Hypergraph isolated latency to dependency: archive" \], "recovery\_timestamp": "2026-07-15T14:45:10Z", "root\_cause\_analysis": "Causal graph identified transient network partition in Archive DB ingestion tier.", "corrective\_actions": \[ "Automated scaling policy applied to Archive DB replica set" \], "signatures": \[ { "signer": "Eviulon Telemetry Consensus Leader Node 4", "signature\_value": "3045022100e...8b" } \], "relevant\_ledger\_events": \[ "Merkle Tree Hash: 7a8b...1c", "RFC 3161 TSA Token: MII...==" \] }

4. Signed Daily Status Checkpoint (Signed Tree Head)

The daily checkpoint presents the Merkle root of the incident log, establishing the cryptographic baseline for the given day. The example below demonstrates an empty tree size, representing the optimal state of zero incidents.

JSON { "timestamp": "2026-08-09T00:00:00Z", "tree\_size": 0, "root\_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "signature": "MEQCIF9...=" }

Works cited

1. A Continuous Governance Framework for Autonomous AI Observability and Zero-Trust Compliance in Enterprise Environments \- arXiv, https://arxiv.org/html/2604.04749v1

2. Towards Zero Trust Security in Connected Vehicles: A Comprehensive Survey \- arXiv, https://arxiv.org/html/2504.05485v1

3. Remote Attestation in Confidential Computing Explained \- Edera, https://edera.dev/stories/remote-attestation-in-confidential-computing-explained

4. Attestation — NVIDIA Confidential Containers Architecture, https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/attestation.html

5. Remote Attestation \- Cohere Documentation, https://docs.cohere.com/docs/model-vault/encrypted/attestation

6. Attestation in confidential computing \- Red Hat, https://www.redhat.com/en/blog/attestation-confidential-computing

7. What Is Remote Attestation? Definition & Examples, https://nhimg.org/glossary/remote-attestation/

8. Synthetic Monitoring vs RUM: What's the Difference? \- OpenObserve, https://openobserve.ai/blog/synthetic-monitoring-vs-rum/

9. Synthetic Monitoring Comes to OpenObserve (Beta), https://openobserve.ai/blog/synthetic-monitoring-release/

10. Byzantine Fault Tolerant Consensus \- Chainlink, https://chain.link/article/byzantine-fault-tolerant-consensus

11. Reaching Consensus in the Byzantine Empire: A Comprehensive Review of BFT Consensus Algorithms \- arXiv, https://arxiv.org/html/2204.03181v3

12. The Split-Brain Phenomenon: A Distributed Systems Dilemma \- Java Code Geeks, https://www.javacodegeeks.com/2023/10/the-split-brain-phenomenon-a-distributed-systems-dilemma.html

13. OpenTelemetry semantic conventions explained | Engineering | ClickHouse Resource Hub, https://clickhouse.com/resources/engineering/opentelemetry-semantic-conventions

14. OpenTelemetry Semantic Conventions: An Explainer \- Dash0, https://www.dash0.com/knowledge/otel-semantic-conventions-explainer

15. Semantic conventions for HTTP metrics | OpenTelemetry, https://opentelemetry.io/docs/specs/semconv/http/http-metrics/

16. What are the four golden signals of monitoring? | Engineering | ClickHouse Resource Hub, https://clickhouse.com/resources/engineering/golden-signals

17. semconv package \- go.opentelemetry.io/otel/semconv/v1.37.0 \- Go Packages, https://pkg.go.dev/go.opentelemetry.io/otel/semconv/v1.37.0

18. DynaCausal: Dynamic Causality-Aware Root Cause Analysis for Distributed Microservices \- arXiv, https://arxiv.org/pdf/2510.22613

19. DynaCausal: Dynamic Causality-Aware Root Cause Analysis for Distributed Microservices, https://arxiv.org/html/2510.22613v1

20. A Comprehensive Survey on Root Cause Analysis in (Micro) Services: Methodologies, Challenges, and Trends \- arXiv, https://arxiv.org/html/2408.00803v1

21. Root Cause Analysis for Microservice Systems via Cascaded Conditional Learning with Hypergraphs \- arXiv, https://arxiv.org/pdf/2511.17566

22. JSON Schema Validation: A Vocabulary for Structural Validation of JSON, https://json-schema.org/draft/2020-12/json-schema-validation

23. Draft 2020-12 \- JSON Schema, https://json-schema.org/draft/2020-12

24. JSON Schema Validation: Tools & Best Practices \- Zuplo, https://zuplo.com/blog/verify-json-schema

25. JSON Schema draft 2020-12 release notes, https://json-schema.org/draft/2020-12/release-notes

26. $schema (2020-12), https://www.learnjsonschema.com/2020-12/core/schema/

27. draft-bhutton-json-schema-validation-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00

28. format (2020-12) \- Learn JSON Schema, https://www.learnjsonschema.com/2020-12/format-annotation/format/

29. Well-known URI \- Wikipedia, https://en.wikipedia.org/wiki/Well-known\_URI

30. RFC 8615 \- Well-Known Uniform Resource Identifiers (URIs) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc8615

31. Well-Known URIs explained \- HTTP.DEV, https://http.dev/well-known-uris

32. RFC 9421 \- HTTP Message Signatures \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9421

33. Understanding HTTP Message Signatures \- Blog Notes, https://blog.vitalvas.com/post/2025/12/12/understanding-http-message-signatures/

34. HTTP Message Signatures \- RFC 9421 Guide, https://openlinksw.com/data/html/http-signatures-infographic.html

35. Accept-Signature \- Expert Guide to HTTP headers, https://http.dev/accept-signature

36. Understanding HTTP message signatures: A developer's guide \- Victor on Software, https://victoronsoftware.com/posts/http-message-signatures/

37. Verification of HTTP Message Signatures | by Takahiko Kawasaki \- Medium, https://darutk.medium.com/verification-of-http-message-signatures-501bbdc7dfec

38. HTTP Signature Keys \- IETF, https://www.ietf.org/archive/id/draft-hardt-httpbis-signature-key-04.html

39. draft-bormann-t2trg-stp-01 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-bormann-t2trg-stp-01

40. draft-bormann-t2trg-stp-00 \- The Series Transfer Pattern (STP), https://datatracker.ietf.org/doc/draft-bormann-t2trg-stp/00/

41. ActivityPub \- W3C, https://www.w3.org/TR/activitypub/

42. ActivityPub \- Wikipedia, https://en.wikipedia.org/wiki/ActivityPub

43. Activity Streams 2.0 \- W3C, https://www.w3.org/TR/activitystreams-core/

44. Activity Streams 2.0 \- W3C, https://www.w3.org/TR/2014/WD-activitystreams-core-20141023/

45. Activity Streams 2.0 \- W3C, https://www.w3.org/TR/2015/WD-activitystreams-core-20150722/

46. FEP-3ab2: ActivityPub Event Streaming API \- Fediverse Enhancement Proposals, https://fediverse.codeberg.page/fep/fep/3ab2/

47. ActivityPub \- Mastodon documentation, https://docs.joinmastodon.org/spec/activitypub/

48. RFC 9162 \- Certificate Transparency Version 2.0 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9162

49. C2SP/static-ct-api.md at main \- GitHub, https://github.com/C2SP/C2SP/blob/main/static-ct-api.md

50. What is a Merkle Tree? | Cube Exchange, https://www.cube.exchange/what-is/merkle-tree

51. Merkle Trees: Building Blocks of Blockchain Trust \- Lightspark, https://www.lightspark.com/glossary/merkle-tree

52. Inside DigiCert's MTC Playground, https://www.digicert.com/blog/digicert-mtc-playground

53. Certificate Transparency \- Wikipedia, https://en.wikipedia.org/wiki/Certificate\_Transparency

54. rfc9162.xml \- » RFC Editor, https://www.rfc-editor.org/rfc/rfc9162.xml

55. Lightweight Tamper-Evident Log Integrity Verification for IoT Edge Environments: A Merkle-Tree Pipeline with Adaptive Chunking \- arXiv, https://arxiv.org/html/2605.00065v1

56. RFC 9052 \- CBOR Object Signing and Encryption (COSE): Structures and Process, https://datatracker.ietf.org/doc/html/rfc9052

57. Securing Verifiable Credentials using JOSE and COSE \- W3C, https://www.w3.org/TR/vc-jose-cose/

58. FAQ \- Frequently Asked Questions \- AGLedger, https://agledger.ai/faq/

59. draft-elkhatabi-verifiable-telemetry-ledgers-08 \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-elkhatabi-verifiable-telemetry-ledgers/

60. Registry Audit Logs, Incident Evidence and External Proof, https://btw.media/en/registry-logs-as-evidence-after-an-incident

61. Verifiable AI Provenance (VAP) Framework and Legal AI Profile (LAP) \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ailex-vap-legal-ai-provenance/03/

62. draft-fassbender-scitt-time-anchor-03 \- Bitcoin-Anchored Temporal Proof for Transparency Services \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-fassbender-scitt-time-anchor/

63. (PDF) TRACE: A Governance-First Execution Framework Providing Architectural Assurance for Autonomous AI Operations \- ResearchGate, https://www.researchgate.net/publication/400630725\_TRACE\_A\_Governance-First\_Execution\_Framework\_Providing\_Architectural\_Assurance\_for\_Autonomous\_AI\_Operations