# Go-Live Risk and Hypercare Model

Illustrative template created for this portfolio. Contains no client data and is not a historical project deliverable. Example scenarios are synthetic; blank measurement fields are for future use.

Updated: 2026-09-08

## When to use

An integration is approaching a production launch or material change. Complete the record with delivery, engineering, QA, support, and the customer’s workflow owner.

## Decision this supports

The launch owner records go, conditional go, or no-go against explicit evidence and unresolved risks. A conditional go requires an approved boundary, mitigation, accountable owner, and review deadline.

## 1. Assemble the readiness record

Make release confidence traceable to evidence instead of a collection of optimistic status reports.

### Release scope

Connection and workflow [ ]; affected sites [ ]; change [ ]; launch window and time zone [ ]; release owner [ ].

Response: ____________________

### Evidence register

Gate [ ]; required proof [ ]; evidence link [ ]; reviewer [ ]; status [ ]; unresolved gap [ ].

Response: ____________________

### Workflow acceptance

Mapping approval [ ]; negative and duplicate tests [ ]; reconciliation [ ]; receiving-workflow UAT [ ]; sign-off owner [ ].

Response: ____________________

### Operational readiness

Alerting [ ]; support coverage [ ]; approved access [ ]; runbook [ ]; escalation contacts [ ]; communication channel [ ].

Response: ____________________

### Review checks

- [ ] Every launch gate has a reviewer and inspectable evidence.
- [ ] Missing evidence and failed gates are distinct from completed checks.
- [ ] The customer’s receiving workflow and support coverage are included in readiness.

## 2. Record risk and the launch decision

Keep acceptance of risk explicit and connected to the person who can act on it.

### Risk record

Risk [ ]; affected workflow [ ]; likelihood rationale [ ]; impact [ ]; detection signal [ ]; owner [ ]; mitigation [ ]; due date [ ].

Response: ____________________

### Decision

Go / conditional go / no-go [ ]; evidence reviewed [ ]; accountable approver [ ]; timestamp and time zone [ ].

Response: ____________________

### Conditional boundary

Permitted scope [ ]; unmet gate [ ]; accepted impact [ ]; containment [ ]; owner [ ]; expiry or review deadline [ ].

Response: ____________________

### Open dependencies

Dependency [ ]; responsible party [ ]; decision needed [ ]; escalation point [ ].

Response: ____________________

### Review checks

- [ ] An unresolved risk has an accepted treatment or blocks the affected scope.
- [ ] A conditional launch cannot expand beyond the approved boundary without a new decision.

## 3. Plan containment and reconciliation

Decide how to limit harm and restore an understood state before there is launch pressure.

### Trigger

Observable failure or data-integrity signal [ ]; agreed threshold [ ]; observation window [ ]; decision owner [ ].

Response: ____________________

### Containment sequence

Pause, isolate, route to an exception queue, or revert [ ]; sequence owner [ ]; effects on in-flight data [ ].

Response: ____________________

### Rollback feasibility

Reversible components [ ]; irreversible downstream effects [ ]; dependencies [ ]; approvals [ ]; recovery steps [ ].

Response: ____________________

### Reconciliation and replay

Comparison source [ ]; affected time window [ ]; duplicate protection [ ]; correction owner [ ]; replay approval [ ]; completion evidence [ ].

Response: ____________________

### Review checks

- [ ] Stopping new traffic is distinguished from undoing changes already delivered.
- [ ] Replay is authorized and checked for duplicate or out-of-order effects.
- [ ] Stakeholders know who communicates containment and recovery decisions.

## 4. Run hypercare and close with evidence

Carry release ownership into early production and turn observed issues into durable follow-up work.

### Coverage and triage

Coverage window [ ]; primary and backup owners [ ]; severity criteria [ ]; response expectations [ ]; escalation channel [ ].

Response: ____________________

### Incident record

First observed [ ]; workflow impact [ ]; incident owner [ ]; containment [ ]; communication cadence [ ]; recovery evidence [ ].

Response: ____________________

### Measurement record

Metric [ ]; definition and denominator [ ]; baseline [ ]; target [ ]; result [ ]; source [ ]; observation window [ ]; owner [ ].

Response: ____________________

### Exit and follow-up

Exit criteria [ ]; reconciled exceptions [ ]; outstanding risks accepted by [ ]; support handoff [ ]; product follow-up [ ]; review date [ ].

Response: ____________________

### Review checks

- [ ] Hypercare ends on agreed stability and ownership evidence rather than elapsed time alone.
- [ ] Recurring issues have product, engineering, or process owners and a review date.

## Synthetic worked example

Synthetic scenario: a fictional lab interface passes happy-path tests, but duplicate-result handling has not been validated.

Illustrative decision: no-go for the affected launch scope until duplicate behavior is tested and receiving-workflow ownership is clear. Record the missing evidence and reviewer.

Required evidence: duplicate and replay test outcomes, reconciliation procedure, receiving-user acceptance, and a named production support owner. Thresholds and observation windows must be agreed for the actual release; none are invented here.

Portfolio: https://jasonpagliaro.com/work-samples/go-live-risk-hypercare-model