Day-16 strict-flip rejected my previously-passing request

What changed

On Day-16 (2026-05-16, gated by /registry/anomaly/flip_gate?hours=168 returning flip_recommended: true) the verifier flipped from advisory mode to strict mode for v1.8 governance-signature and v1.6 capability-attestation paths. Any failure that previously produced an advisory log entry now produces a 401 rejection at the boundary.

How to confirm this is the cause

1. Pull the rejection's correlation_id from the 401 response body.
2. Fetch your event: GET /registry/anomaly/my_events?correlation_id=<id> (operator-bearer auth).
3. The event's reason_code is the same machine-readable cause it would have carried during the advisory window.

If the reason_code is one of the strict-flip-affected codes (table below), the cutover is the cause — your passport issuance has a pre-existing defect that observation-week was tolerating.

Strict-flip-affected reason_codes

Reason codes outside this list (e.g. expired passport, registry-revoked agent) were strict from Phase 1 and are not affected by the cutover.

Fix checklist

For each affected reason_code:

• GOVERNANCE_SIGNATURE_INVALID — your governance_payload_signature does not verify against the pubkey served at governance_signing_pubkey_url. Confirm the URL is reachable from the registry's network, returns a valid PEM, and that you signed the canonical bytes per canonicalize_passport_governance(passport) (see agent passport schema).
• CAPABILITY_ATTESTATION_INVALID — same story for attester_pubkey_url + canonicalize_passport_attestation(passport). Common cause: the attester rotated their key but the passport still references the old key URL.
• DELEGATION_CHAIN_INVALID — walk the chain. Each hop must (a) verify against the prior agent's pubkey, (b) not be expired, (c) carry a scope that's a subset of the prior hop's. The detail field in the event names the failing hop index.
• GOVERNANCE_TRUST_ROOT_NOT_SEPARATE — your governance_signing_pubkey_url and passport-level signing key resolve to the same origin/path. Move the governance signing key onto an independent rotation surface; the policy reason is documented in v1.8 governance_payload_signature.

If your fix takes longer than acceptable

Strict-flip is one-way during a window — there is no per-operator opt-out. If you cannot remediate in time:

1. Open a /registry/anomaly/classify entry on the rejected event with classification legitimate and a short description of the root cause + ETA. This puts your case on the team's radar.
2. Email the team (hello@aiegis.ie) with the correlation_id so we can coordinate manual mitigation. Manual mitigation paths are case-by-case — there is no automatic suppression layer.

See also

• Phase 2 advisory log entries — what these events looked like before the flip.
• my_events self-diagnosis — pulling the events for your operator.
• Agent passport schema — canonical fields and signing contracts.