What it is
GET /registry/anomaly/my_events returns anomaly events scoped to the calling operator. Auth: operator-bearer (the same HMAC scheme you use against the registry).
Query parameters
correlation_id(optional) — return only the matching event.hours(optional, default 168, range[1, 720]) — lookback window.limit(optional, default 50, range[1, 500]) — max rows.
Out-of-bounds values return 400.
Response shape
{
"operator_id": "<your operator id>",
"events": [
{
"correlation_id": "<uuid>",
"event_kind": "verifier_fail",
"severity": "low | medium | high",
"reason_code": "<machine-readable code>",
"agent_id": "<agent id>",
"detail": "<short human description>",
"observed_at": "<RFC3339 timestamp>",
"source": "<emitting service identifier>",
"classification": "legitimate | adversarial | unknown",
"classification_version": "v0.1 | v0.2 | v0.3 | manual",
"received_at": "<RFC3339 timestamp>"
}
],
"total_returned": 0
}The classification field is the registry's post-hoc triage tag (heuristic version stamped in classification_version). Tagging hardens through the observation window.
Auth-scoping guarantee
/my_events returns only events attributable to the calling operator. Querying with another operator's
correlation_id returns an empty result, not a 403 or a row leak. Cross-operator leak prevention is enforced via SQL filter on operator_id at the registry layer.
Examples (placeholder)
Filled during observation week as real customer flows land. Initial reference: integration test tests/test_anomaly_my_events.py covers the schema-shape contract.