• direct old-host vs new-host read parity
• direct old-host vs new-host protected-write denial parity
• direct old-host vs new-host successful authenticated write parity
• gateway fallback parity on reads
• gateway fallback parity on protected-write denials
• gateway fallback parity on successful authenticated write
• gateway cutover parity on reads
• gateway cutover parity on protected-write denials
• gateway cutover parity on successful authenticated write
• rollback by env flip back to fallback routing
• rollback confidence after successful authenticated ICPI writes

What Still Remains Risky

• verification used one seeded dev impersonation identity, not a broader user matrix
• verification used one representative ICPI upsert row family, not a bulk or multi-row ingestion batch
• the auth-service robustness issue from Sprint 50 still exists as a separate concern:
  • /auth/me crashed when given a valid-signature token whose sub was not UUID-shaped
  • that issue did not block the happy-path ICPI flow used here
  • it is still worth hardening separately

Live Env Cutover Readiness

Current readiness verdict:

• READY FOR A CONTROLLED ENV-ONLY CUTOVER WINDOW

Reasoning:

• gateway seam stayed unchanged
• auth seam stayed unchanged
• successful write parity is now verified, not just read parity
• rollback stayed an env flip plus gateway restart
• old colocated hosting still remains available as a safety net

This does not mean “risk free.” It means the main pre-cutover unknown around successful authenticated ICPI upsert has been removed for the checked operator-ready path.

Rollback Confidence

Rollback confidence is high for the current stage because:

1. old colocated hosting remains intact
2. gateway cutover is controlled by ICPI_SERVICE_URL
3. fallback remains TENDERS_SERVICE_URL
4. rollback was rehearsed after successful write verification
5. no code rollback is required for the first cutover step

Operational rollback remains:

• stop gateway
• remove or override ICPI_SERVICE_URL
• restart gateway with fallback env

Auth Caveats

What is now strong:

• existing dev impersonation produces a valid access token for a seeded active account
• that token succeeds through gateway auth and service-side requireServiceAuth
• principal resolution succeeds for the seeded identity used in verification

What still should not be overstated:

• this sprint did not harden all malformed-token paths inside svc-auth
• this sprint did not broaden into a full auth or identity refactor

Recommended Next Decision

The next sprint can reasonably choose between:

• a real controlled env cutover rehearsal in a higher-confidence environment
• one final targeted auth hardening fix before live cutover, if the team wants to reduce unrelated auth-service fragility first

Given the ICPI-specific evidence now available, a controlled env-only cutover is justified.