Developers · Event model
Sentinel has no free-floating chat: investigations open on events, proceed as events, and close as events. That's what makes the workflow match real operations, and what makes the ledger a complete account rather than a partial log.
Triggers
A monitoring alert, an error-rate threshold crossed on the ingestion service, arrives with its labels and firing context intact, and maps to an agent and policy.
A declared incident from your on-call tooling, with severity, service, and responder context, so the investigation attaches to the incident your team is already tracking.
A teammate selects, edits, validates, and dispatches an event sample by hand, for exploratory testing, rehearsal, and ground-truth evaluation runs.
States and entries
triggered → investigating → reported | escalated. The transitions are few and meaningful; the detail lives on the ledger, not in the state machine. A run reaches exactly one final state, and the transition that got it there is itself an entry.
Tool calls with their outputs, model prompts with their responses, evidence artifacts, configuration overlays, and human interventions. Every entry is typed, timestamped, and appended, never rewritten, so the ledger reads as one causal story.
{
"type": "tool_call",
"tool": "grafana.query",
"input": { "panel": "ingest-5xx" },
"output_ref": "ev-07",
"policy": "observability-readonly",
"seq": 12 // append-only ordering
}
A posted report carries its citations; an escalation carries the reason and the human it went to. Downstream systems, your incident tracker, your chat, subscribe to these the same way Sentinel subscribed to your alerts.
{
"type": "report_posted",
"findings": 3,
"citations": ["ev-07", "ev-08", "ev-09"],
"ledger": "/v1/runs/inc-4212/ledger"
}
Wire your first trigger in the quickstart, then subscribe your incident tooling to the outcomes.