Before go-live, a design authority should confirm that the delivered solution still matches the approved intent and that the organisation can operate it. Review architecture deviations, integrations, data migration, identity and access, non-functional requirements, observability, support ownership, resilience, security, recovery, documentation, unresolved risks and the evidence behind readiness claims.
Architecture is not finished at design approval
Delivery changes assumptions. A design authority should follow material decisions through implementation rather than approve a document and disappear.
Operational readiness is part of design
Monitoring, support, runbooks, ownership and failure recovery are architectural concerns because they shape how the system behaves after launch.
Use conditions, not vague confidence
If go-live is acceptable only with specific mitigations, write them as named conditions with owners and dates.
How soapplied approaches the question
I would not start by assuming the stated problem is the whole problem. The first step is to understand the people, purpose, constraints and interactions around it, then test what intervention would improve the system rather than merely optimise one component.