Telemetry

ABS Core telemetry should be described as an observability layer for governed AI runtime activity. Its job is to expose operational health, policy decisions, and audit-relevant metadata without overstating the level of isolation or sovereignty provided by every deployment.

Telemetry goals

The telemetry model exists to support:

• runtime visibility,
• policy and risk monitoring,
• audit investigation,
• and customer-side operations in sensitive environments.

---

Recommended separation model

A practical telemetry design separates two kinds of information:

1. Infrastructure metadata

This includes health and transport signals such as:

• latency,
• request volume,
• failure rates,
• service availability,
• and enforcement path health.

2. Governance metadata

This includes runtime decision information such as:

• policy verdicts,
• risk flags,
• approval events,
• audit record identifiers,
• and selected integrity metadata.

Where payload sensitivity is high, telemetry should be designed so that business content and sensitive data remain under customer control whenever possible.

---

Deployment interpretation

Different customers may run telemetry in different ways:

• partially centralized for convenience,
• customer-routed for regulated environments,
• or predominantly self-hosted for stricter sovereignty requirements.

Because of this, public claims about sovereignty should be framed as deployment options and design goals, not as universally identical behavior across all installations.

---

Observability value

Telemetry is most valuable when it helps operators answer practical questions such as:

• Which actions were denied and why?
• Which agents triggered repeated high-risk patterns?
• Which policy versions were active at decision time?
• Where did approval bottlenecks occur?
• What governed actions require forensic review?

This is a more credible positioning than presenting telemetry as a complete security guarantee on its own.

---

Claims discipline

The telemetry layer should not be marketed as proof that no sensitive data ever leaves the environment unless the deployment architecture and controls make that guarantee explicit.

Likewise, terms such as air-gapped, sovereign, or zero-leakage should be used only when the exact customer topology and operational controls support those claims.

---

Telemetry V1 (Beta)

The current implementation runs as a Cloudflare Worker service, ensuring global low-latency collection of governance events.

Technical Stack

• Ingestion: OTLP/HTTP compatible endpoint.
• Runtime: Cloudflare Workers.
• Persistence: Cloudflare D1 (SQLite) for real-time aggregation.
• Integration: Native connectors for Grafana and internal ABS Dashboards.

Data Model

For every intercepted action, the Telemetry layer captures:

1. Identity Fingerprint: Cryptographic proof of origin (OID).
2. Policy Verdict: ALLOW/DENY/WARN with associated rule ID.
3. Risk Score: Normalized value derived from CHI and Econ-Sentinel (OCS).
4. Latency Trace: Detailed breakdown of enforcement overhead.

---

Maturity note

Telemetry V1 is currently in Beta. It provides baseline observability and risk scoring integrated with the Heptagon Ledger. Advanced behavioral forensics (CORTEX integration) are scheduled for Q3 2026.