Self-diagnosis

Phase 2 advisory log entries

You see verifier_fail or peer_verify_fail events in /registry/anomaly/my_events but the corresponding requests still succeeded. This page explains why.

What's happening

During the observation window (2026-05-08 → 2026-05-15) the v1.8 governance signature check, capability_attestation check, and a few related verifier paths run in advisory mode. Failures are logged for analysis but not rejected at the boundary. After the Day-16 strict-flip cutover, the same failures will produce 401 responses.

This window exists so operators can fix passport-issuance issues before they become user-visible rejections.

Reading the log entry

Every advisory event carries:

FieldMeaning
event_kindverifier_fail (this operator) or peer_verify_fail (downstream peer relayed the failure)
severitylow / medium / high — heuristic-classifier scoring
reason_codeMachine-readable cause (see codebook below)
agent_idWhich agent's passport tripped the check
correlation_idHandle for joining against your own request logs
observed_atWhen the verifier saw the failure
classificationlegitimate / adversarial / unknown (heuristic v0.X output)
classification_versionv0.3 at window kickoff; may bump during observation week

A request that hit advisory failures is allowed through, but the correlation_id lets you reproduce the same input and understand what the strict-mode rejection would look like.

Common reason_codes during observation week

Reason codeWhat's wrongWhat to check
GOVERNANCE_SIGNATURE_INVALIDv1.8 governance_payload_signature did not verify against the operator's governance_signing_pubkey_urlPubkey URL reachable and serving the correct PEM? Canonical-bytes contract honored when signing?
CAPABILITY_ATTESTATION_INVALIDv1.6 attestation signature did not verifyattester_pubkey_url reachable? Attestation rotated past attested_at validity window?
DELEGATION_CHAIN_INVALIDOne hop in the chain failed signature, expiry, or scope-subset checkAudit detail for the failing hop index. Most common: hop expired between issuance and call.
GOVERNANCE_TRUST_ROOT_NOT_SEPARATEgovernance_signing_pubkey_url resolves to the same origin as the passport-level signing keyThese should be independent rotation surfaces; see agent passport schema v1.8.
SG_MGAIF_* / ZA_POPIA_*Jurisdictional pack required field absent under governance_payload.jurisdictional_extensions.<JURISDICTION>See Jurisdictional extensions for the required field paths.

Expected volume during the window

Anomaly observatory baseline freezes at window kickoff. The /registry/anomaly/flip_gate?hours=168 endpoint reports flip_recommended: true only when the legitimate / adversarial / unknown ratio crosses the configured threshold; until that flag flips, expect a small but non-zero advisory-event stream as operators iterate on their passport-issuance pipelines.

What to do

  1. Pull the events for your operator: see my_events self-diagnosis.
  2. For each reason_code, check the table above + the linked schema section.
  3. Fix the root cause in your issuance pipeline before Day-16 strict-flip.
  4. If you classify an event you investigated, post the classification back via POST /registry/anomaly/classify so the heuristic improves for everyone.

When advisory becomes mandatory

Day-16 (2026-05-16) cutover, gated by flip_recommended on /registry/anomaly/flip_gate. After cutover, the same reason_code produces a 401 from /api/protect with correlation_id in the body — see verifier_fail correlation_id and Day-16 strict-flip rejection.