deployment and uat

why

deployment tooling proves the bundle was accepted, not that the released behavior works. a release claim is a claim about the running system: the changed route answers, the authorization holds, the mutation landed in the authority. without a live-boundary probe, broken releases surface as customer reports instead of a two-minute check.

rule

a deployment is incomplete until the live system proves the changed boundary. run health checks first, then exercise the exact route, flow, data mutation, or user-visible state changed by the release.

a successful deploy upload means the bundle was accepted; it does not mean the released route works, the authorization is correct, the database migration applied, or the data arrived in the authority. deployment logs are infrastructure noise without proof that the user-visible contract changed.

workflow

review the focused diff, generated artifacts, migrations, and deployment order.
deploy through the owning package command.
probe health endpoints.
perform narrow UAT: observe real status codes, typed payloads, and side effects where relevant.
record the evidence with the change.

match evidence to the changed authority

changed boundary	insufficient evidence	release evidence
static UI composition	a local screenshot alone	deployed route returns and renders the intended state.
API contract	generated types compile	live request has the intended status, typed payload, and authorization behavior.
durable mutation	HTTP success only	created/updated fact and its invariant are observable in the authority.
migration	migration command exited zero	live schema and representative old/new rows satisfy the new constraint.
workflow or asynchronous handoff	dispatch acknowledged	downstream durable result or terminal status is observed.

decision process

deployment completion is a claim about a running environment, not that the command accepted a bundle. start from the user-visible outcome, trace it to the authoritative mutation or response, collect the smallest live proof crossing that boundary. a health endpoint proves availability, not the released feature.

on a failed UAT probe, preserve the exact route, status, correlation ID, and typed response. diagnose ownership before changing code: stale deployment routing, authorization, request construction, dependency failure, or a real product defect.

verification record

record the deployed revision, exact probe or flow, observed status/payload, authoritative side effect where applicable, timestamp, and correlation ID. state what was not verified instead of letting a green build imply live success.

good and bad

bad

change: fixed workflow-list authorization check
deploy log: 2026-08-25T09:15:00Z succeeded
release: marked complete
customer report: 1 hour later, "list route returns 403 for everyone"
root cause: route handler never loaded due to import error; deployment succeeded,
  but the code path was never active. nobody probed the live endpoint.
time to detection: 1 hour; cost: support response, partial outage

the deploy log stayed green while every request hit the failure — the first real probe was a customer, one hour and a partial outage later.

good

change: fixed workflow-list authorization check
deploy command: 2026-08-25T09:15:00Z succeeded
immediate uat:
  probe: GET /api/workflows (no auth) → 401 expected
  observed: 401, correct error code
  probe: GET /api/workflows (valid token) → 200 with workflows
  observed: 200, typed payload, 3 workflows listed
  timestamp: 2026-08-25T09:16:15Z
  correlation: cor_abc123
release: marked complete and verified

both authorization branches are exercised at the route level with real status codes, so a silent import failure or routing drift fails the release gate ninety seconds after upload instead of one hour later in a customer report. the recorded correlation id and timestamp make the evidence auditable.