The Fourth Signal: Why Observability Now Requires Provenance

The Completion of the Observability Stack

The release of OpenTelemetry Profiles into Public Alpha marks a structural milestone for systems engineering. For years, the industry standard for observability rested on three pillars: traces, metrics, and logs.
Profiles introduce the fourth signal.
By leveraging eBPF, OpenTelemetry now allows engineering teams to capture continuous, real-time performance profiles—CPU utilization, memory allocation, and thread blocking—directly in production environments with near-zero overhead. It maps the exact execution reality of a system without requiring developers to manually instrument their source code.
If your application suffers a latency spike or a memory leak, you no longer have to guess where it happened. The profile provides a deterministic map of the hardware's reality.
But as software architecture shifts from static APIs to autonomous, AI-driven agents, mapping hardware reality is no longer sufficient.
We must map the reality of trust.

Where OpenTelemetry Stops and Zephyr Begins

OpenTelemetry answers the question of efficiency. It tells you that agent_execution_loop() consumed 400 milliseconds of CPU time, or that a specific microservice is saturated.
It does not answer the question of authority.
When an AI agent autonomously reroutes a supply chain, approves a financial transaction, or modifies a production database, knowing the CPU overhead is irrelevant to the auditor, the compliance officer, or the risk manager. They do not care how fast the decision was made. They care about how the decision was authorized, what context the model was given, and whether that specific action can be mathematically proven.
This is the accountability gap that Zephyr fills.
If OpenTelemetry is the nervous system measuring the health of your infrastructure, Zephyr is the cryptographic ledger measuring the integrity of its actions.

Performance vs. Provenance

Consider a high-stakes deployment where an AI agent acts as a gatekeeper for a sensitive CI/CD pipeline.
The OpenTelemetry View:

• Metric: The agent container is using 80% of its memory limit.
• Trace: The request took 2.4 seconds to travel from the webhook to the LLM provider and back.
• Profile: The JSON parsing library is causing a CPU bottleneck.
  The Zephyr View:
• Envelope: Agent release-bot-01 invoked the deploy_to_production tool.
• Payload Hash: The exact context window, prompt, and output are hashed and sealed.
• Attestation: The action was cryptographically signed using an Ed25519 key stored in a secure local vault.
• Ledger: This action was evaluated against the production-trust-policy.yml and permanently recorded in an append-only log to prevent replay attacks.
  OpenTelemetry gives you a dashboard. Zephyr gives you evidence.

The Software Bill of Function (SBOF)

In environments where failure is expensive, telemetry must be upgraded to provenance.
Just as OpenTelemetry normalizes how we export performance data, Zephyr normalizes how we export operational trust through the Software Bill of Function (SBOF).
When a system powered by Zephyr completes a workflow, it doesn't just log a string of text to standard output. It generates a mathematically unforgeable bundle of signed envelopes. This means that months after an autonomous action is taken, you can reconstruct the exact chain of events and cryptographically prove that no human or adversary tampered with the record.
You cannot alter a Zephyr ledger anymore than you can alter the laws of mathematics.

The Future of Mission-Critical Systems

The introduction of continuous profiling into OpenTelemetry is a massive win for performance engineering. It gives builders the ultimate tool to optimize code and eliminate friction.
But optimization is only half the battle. As organizations deploy AI agents with actual agency, the frontier of engineering shifts from making systems faster to making them provable.
Build systems that perform efficiently. But instrument them so they can defend their actions in a court of law.