When to use this surface
You hit a 401 from /api/protect (or another AiEGIS-protected endpoint) and need to diagnose why the request was rejected.
The 401 response body carries a correlation_id — that's the handle to the audit trail.
Diagnostic flow
Symptom
401 from /api/protect with correlation_id in body
Use the correlation_id to query registry-side diagnostics → see verifier_fail_correlation_id
Symptom
Want to see all recent verifier failures for your operator
Query /registry/anomaly/my_events scoped to your operator-bearer → see my_events_self_diagnosis
Symptom
Phase 2 advisory log entries you don't recognize
Why you see verifier_fail / peer_verify_fail events whose corresponding requests still succeeded → see phase2_advisory_logs
Symptom
Day-16 strict-flip rejected your previously-passing request
A previously-advisory reason_code now produces 401 → see day16_strict_flip_rejection
Related references
- API reference — all registry endpoints with method, path, auth scheme, and response shape.
- Agent passport schema — what the verifier actually checks (v1.5 / v1.6 / v1.8 fields, signature contracts).
- Architecture — how the verifier surface fits into the broader Aegis layered defense.
Out of scope here
- Internal-only operations runbooks.
- Federation anchor onboarding (separate spec).
- Pre-production smoke harness output (claim_auditor.py output, observation-week).