Common post-go-live signals

• Works in Postman, fails behind AppRouter or Work Zone.
• The first tenant works, the next exposes architecture drift.
• Security hardening breaks flows that previously looked stable.
• Technical-user shortcuts preserve function but weaken identity validity.
• Data copies work, but ownership truth becomes unclear.
• Vendor or internal teams disagree and no one owns the chain.
• Strongest people keep being pulled back to preserve old stability.

Why this is not always a delivery issue

Go-live proves current behavior, not future survivability. Protected paths can hide boundary violations, and local fixes can preserve motion while increasing structural risk. The architecture can remain busy and still become less governable with every patch.

Assessment questions

• Is the failure local or structural?
• Is the system working only along a protected path?
• Can a new tenant reach correct state without manual repair?
• Can version N move to N+1 across tenants without divergence?
• Are identity, tenant, data, integration, and lifecycle boundaries still aligned?

What comes out

• Classification of the failure.
• Boundary diagnosis.
• Go / No-Go / Re-Architect decision framing.
• What must be decided before more implementation continues.

The assessment does not replace a full audit. It classifies whether the failure is local, structural, or already severe enough to require a boundary verdict.

When to request a review → · Implementation vs Verdict → · What an independent verdict does → · Services →

What to send

A one-page summary is enough to classify whether the issue fits a failure assessment or should move directly into a fuller audit. Use the intake template if the team needs a neutral structure.