DOCUMENTATION
How Alert Decision fits into monitoring operations.
Alert Decision is designed to sit between monitoring signals and human response without replacing the systems that detect or deliver alerts.
ADCON Alert Decision Controller
Live path: HTTP webhook events are normalized and routed through stream-specific decision state. Customer-facing outcomes include visible action, grouping, safe abstention and suppression, together with traceable evidence and verification status.
Batch evaluation: CSV, JSON and JSONL replay formats can be used for proof and validation workflows.
Webhook payload example
A minimal normalized event can look like:
{
"source": "prometheus",
"asset": "api-01",
"service": "checkout",
"signal_type": "latency_ms",
"value": 842,
"status": "firing"
}
Production source-to-field mapping is confirmed during onboarding. Public documentation intentionally does not expose proprietary thresholds, coefficients, internal scores, or decision boundaries.
Decision outcomes
| Outcome | Operational meaning |
|---|---|
| SHOW | Surface a distinct human-visible interruption. |
| GROUP | Attach the event to an existing visible alert or incident context instead of creating another independent interruption. The runtime may expose this as GROUPED. |
| HOLD | Use the safe uncertainty path instead of forcing an automatic suppress/escalate decision. The runtime may expose this as ABSTAIN. |
| SUPPRESS | Do not create a new human interruption for the current event. |
Shadow mode
Shadow mode evaluates decision behavior without changing the team's existing production paging route.
- Keep the current monitoring-to-operator path unchanged.
- Mirror or replay the selected alert stream to Alert Decision.
- Compare raw alert load with SHOW / GROUP / HOLD / SUPPRESS outcomes, critical-event handling, and verification status.
- Move to live routing only after the replay and shadow evidence meet the agreed acceptance criteria.
Replay formats
Evaluation workflows support CSV, JSON, and JSONL mappings. A compact normalized CSV example is:
timestamp,source,asset,service,signal_type,value,status 2026-09-10T07:00:00Z,prometheus,api-01,checkout,latency_ms,842,firing 2026-09-10T07:00:15Z,prometheus,api-01,checkout,latency_ms,811,firing
Error scenarios
| Situation | Behavior |
|---|---|
| Malformed or unmappable payload | Rejected rather than converted into a guessed decision. |
| Request exceeds the accepted payload size | Rejected; the sender should not assume a decision was produced. |
| Runtime capacity / backpressure condition | Returns a non-success response so the integration can retry according to its policy. |
| ACRD provider or required attestation evidence unavailable | Fails closed. There is no silent fallback to ordinary plaintext execution. |
For any non-success response, the caller must not treat the event as successfully decision-evaluated.
ADBP Alert Decision Benchmark Platform
ADBP is a batch benchmark and governance layer. It evaluates prediction, recommended action, actual action and realized outcome together. It is not the live webhook runtime.
Integration pattern
| Source | Typical connection |
|---|---|
| Grafana Alerting | Webhook contact point configured in the Grafana UI. |
| Prometheus / Alertmanager | Webhook receiver configured in Alertmanager routing. |
| Datadog | Webhook integration associated with selected monitors or notification rules. |
| Other systems | Generic JSON webhook or approved replay input. |
Production endpoints are supplied during onboarding; this public documentation intentionally does not publish a fake gateway URL.
Evaluation path
- Run a sample or approved customer-data replay.
- Inspect reduction, critical-event handling and evidence quality.
- Use shadow mode before altering production alert routing.
Security
See the ACRD security model for confidential-result delivery and fail-closed behavior.