Human workflow
Incidents and controlled actions
Events are machine observations; Incidents are human work. Physical actions use separately enrolled devices, bounded semantic operations, expiry, and human confirmation.
Incident lifecycle
open → claimed → closed
↑ ↓ │
└── released └── reopenGET /v1/incidents
GET /v1/incidents/{incident_id}
POST /v1/incidents/{incident_id}/claim
POST /v1/incidents/{incident_id}/release
POST /v1/incidents/{incident_id}/close
POST /v1/incidents/{incident_id}/reopen
POST /v1/incidents/{incident_id}/notes
PUT /v1/incidents/{incident_id}/tagsAn analytic cleared event never closes an Incident automatically. Downstream systems should use Incident status as human-workflow truth while retaining Event lifecycle as analytic evidence.
Action safety boundary
- Models may suggest only enrolled semantic operations; they cannot supply URLs, shell, PLC addresses, or code.
- Every action requires an Idempotency-Key, bounded expiry/duration, and authorization.
- Actions configured for human confirmation do not execute before approval.
- Inference, webhooks, and third-party actions never block the capture/inference loop.
Action APIs are public only when listed in /v1/openapi.json. Treat the current OpenAPI as authoritative and never infer /v1 paths from legacy /api/sdk routes.