Documentation
Connect the observability you already run
RiskBorne accepts OpenTelemetry, the open standard the industry has converged on, plus a signed webhook and a polling endpoint for anything that does not speak OTLP. No custom integration work on either side.
Connection methods
Coming soon — configure now
OpenTelemetry (OTLP)
Connect the observability stack you already run. Point an existing collector at your private RiskBorne endpoint and evidence flows from Datadog, Langfuse, Arize, Braintrust, Weights & Biases, Honeycomb or anything else that exports OTLP.
Available today
Webhook and heartbeat
Push three signals to a signed URL whenever your monitoring runs, or expose one read-only endpoint and we poll it hourly. Payloads, HMAC signatures, limits and worked examples.
Reference
Troubleshooting
What each response code means, why a signal reads stale, why a mapped agent is not being credited, and how to tell the difference between silence and a control gap.
The three signals
Whichever method you use, the same three signals satisfy carrier requirements: drift_monitoring (monitoring exists and when it last ran), error_rate (errors or incidents over a window), and version_change (model or version changes). A requirement evidenced by a fresh signal reads as verified rather than attested; once a signal passes the requirement's cure window it goes stale and the requirement falls back.
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.