Documentation · OpenTelemetry

Connect the observability stack you already run

OpenTelemetry is the open standard the industry has converged on, and the major AI observability platforms already export OTLP. Accept it once and evidence flows from whatever your team runs — no adapter on either side.

Status: coming soon

The RiskBorne OTLP receiver is not accepting traffic yet. You can create an OpenTelemetry connector today — we issue your endpoint, bearer token and field mapping so your collector configuration is finished and reviewed — but nothing sent before the receiver goes live is stored, and no requirement is satisfied by it. To reach the verified tier now, use the webhook or heartbeat, both of which are available today.

Setup

Create an OpenTelemetry connector in Connected evidence. We issue a per-tenant OTLP endpoint and a bearer token. The token is shown once; store it in your secret manager before leaving the page.
Map a resource attribute value — normally service.name — to a RiskBorne agent profile. This step is required: telemetry carrying no attribute we recognize is attributable to no agent and satisfies no requirement.
Add the exporter and pipeline below to the collector you already operate, then reload it.
Watch the connector card. It stays in “waiting for first signal” until data arrives, then shows what we received so you can confirm the mapping worked.

Endpoint and authentication

OTLP over HTTP/protobuf, TLS only. Present your bearer token in the authorization header. The endpoint is scoped to one tenant and one connector; a token presented against another tenant's endpoint is rejected with 401 and recorded in your delivery log.

POST https://riskborne.com/api/public/otlp/<your-connector-id>/v1/metrics
authorization: Bearer <your bearer token>
content-type: application/x-protobuf

Field mapping

One resource attribute value maps to one agent profile. Most teams already set service.name per deployment, which is why it is the default; any resource attribute works as long as it is stable.

# In your application or collector, set the resource attribute we map on.
# Anything else you already set is preserved; we read only this one.

resource:
  attributes:
    - key: service.name
      value: patient-intake-prod
      action: upsert

Collector configuration

Paste into your existing collector. In the app this snippet is pre-filled with your real endpoint. The filter and attribute processors are optional — we discard everything outside monitoring metadata on receipt regardless — but they keep the data inside your network in the first place, which is usually the easier conversation with your security team.

# Add to the exporters and pipelines of your existing OpenTelemetry collector.
exporters:
  otlphttp/riskborne:
    endpoint: https://riskborne.com/api/public/otlp/<your-connector-id>
    headers:
      authorization: Bearer <your bearer token>

processors:
  # We only need monitoring metadata. Drop everything else before it leaves
  # your network — we discard it on receipt regardless.
  filter/riskborne:
    error_mode: ignore
    metrics:
      metric:
        - 'not (IsMatch(name, "^(gen_ai|llm)\\..*") or IsMatch(name, ".*\\.(errors|requests|evaluations)$"))'
  attributes/riskborne:
    actions:
      - key: gen_ai.prompt
        action: delete
      - key: gen_ai.completion
        action: delete

service:
  pipelines:
    metrics/riskborne:
      receivers: [otlp]
      processors: [filter/riskborne, attributes/riskborne, batch]
      exporters: [otlphttp/riskborne]

# The resource attribute below is what we map to a RiskBorne agent profile.
# It must match the mapping on this connector exactly:
#   service.name = patient-intake-prod

What each signal satisfies

Signal	Derived from	Satisfies
drift_monitoring	Any metric indicating an evaluation or drift suite ran — counts of checks, evaluations or scored runs.	Requirements that ask for ongoing output monitoring or drift detection.
error_rate	Error or failure counters, and span error status aggregated per service per day.	Requirements that ask for incident detection and error thresholds.
version_change	Changes in resource attributes such as service.version or a model identifier.	Requirements that ask for change control over model or version updates.

Privacy — what we receive and what we keep

We read monitoring metadata only: whether monitoring exists, when it last ran, error counts, and model or version changes. We never receive or store prompts, completions, customer data, or your agents' inputs and outputs. Everything else in the stream is discarded on receipt.

We store aggregates, not spans. A counter, a timestamp and a version string per agent per day — never the telemetry itself. Nothing we keep can be reassembled into a trace, a prompt or a record about one of your users.

Confirming it works

The connector card leaves “waiting for first signal” and shows a receipt.
The signal feed lists an entry against the mapped agent, marked fresh.
The requirements evidenced by that signal move from attested to verified on the next assessment.

If any of those do not happen, see troubleshooting.