DocsIntegrationsWhere verdicts go

Where verdicts go

Slack, signed webhooks, and scores written back onto the original trace.

Every per-Run destination receives the same payload built from the completed Run. Delivery never re-derives the recommendation, evidence source, or price.

Slack

Add an incoming webhook under the Monitor's outbound settings. Slack receives the verdict, evidence summary, savings range when known, weakest category, and a link to the Run report. Incoming webhooks are send-only, so reviewing or adopting the recommendation happens on the report.

Signed webhooks

Each delivery includes X-PeerLM-Signature, X-PeerLM-Timestamp, X-PeerLM-Event, and X-PeerLM-Delivery. Verify HMAC-SHA256 over <timestamp>.<raw body>:

const expected = "sha256=" + createHmac("sha256", secret)
  .update(timestamp + "." + rawBody)
  .digest("hex");

Reject stale timestamps. The secret is returned only when the destination is created and only its final four characters remain readable. Rotate a lost secret. A destination is disabled after 20 consecutive failures.

Scores on source traces

Langfuse and Braintrust destinations can receive explicitly named Run context on the original source records. Writeback is best-effort and never fails a completed Run. It is capped per Run and only applies when ingestion preserved the real source trace or row identity. File and column-mapped imports have no trace ID, so PeerLM writes nothing rather than inventing one.

Email and digest

Completion email uses the same per-Run verdict payload. The digest is intentionally different because it summarizes several Monitors, but it uses the same dated savings-range rules.