# Example assessment and release report

Version 1.0 · 13 October 2026 · Wavect

Illustrative report for a fictional B2B scheduling product. The records below demonstrate the deliverable format; they are not customer test results.

## Brief and assessment method

Prepare an existing prototype for a first customer pilot and transfer operation to the customer's team. The scope is booking creation, role permissions, retries and recovery. Two synthetic tenants each contain an administrator, an editor and a viewer. Assess the existing build A, record reproducible findings, then retest the agreed fixes in build B using the same fixtures.

## Release decision

**Hold the pilot until recovery check OP-01 passes.** Permission and retry repairs meet their stated acceptance checks in the example retest. A successful backup job alone does not establish that the incoming team can recover the service.

## Findings and retest record

| ID | Severity and impact | Reproduction | Expected / observed in build A | Build B acceptance and status | Owner |
| --- | --- | --- | --- | --- | --- |
| QA-01 | High: a viewer can change a booking | As tenant A's viewer, send the same update request that an editor uses; reload the booking | Expected: denied and unchanged. Observed: update accepted | PASS: viewer denied, booking unchanged; tenant A editor can still update; tenant B cannot access the record | API engineer |
| QA-02 | High: a retry creates a second booking | Submit a booking, interrupt the response, retry with the same request ID | Expected: one booking with the same result. Observed: two bookings | PASS: retry returns the original result; two genuinely different requests still create separate bookings | API engineer |
| OP-01 | Release blocker: recovery ownership unverified | Restore the latest synthetic backup in an isolated environment using the incoming team's access | Expected: readable bookings and a documented restart. Observed: restore credentials and owner missing | BLOCKED: assign access, complete restore, compare fixture records and time the recovery against the agreed target | Platform owner |

Severity reflects user impact and recoverability for this scope. It does not depend on which tool found the issue. High findings require a repair or an explicit, named risk decision before this pilot; a release blocker fails the agreed release condition.

## Rescue decision: keep, harden, replace

- **Keep:** the working booking model and calendar UI; verify them against the fixtures after each repair.
- **Harden:** backend authorization and request deduplication. Repairs must pass both failure cases and permitted actions.
- **Replace:** the deployment dependency on an outgoing contractor's account with a customer-owned release path. Rebuilding the booking feature is not required by these findings.
- **Delivery order:** establish customer access, repair QA-01 and QA-02, retest, then complete OP-01 before pilot approval. Price and effort follow repository inspection and the agreed repair scope.

## Takeover acceptance

The incoming maintainer must be able to build from a pinned commit, deploy to staging, verify the critical booking journey, read monitoring and perform the recovery check. Record the repository and environment owners, secret locations without secret values, deployment and rollback instructions, backup retention and support escalation. Rotate inherited credentials after verified replacement access is working.

The customer retains source, infrastructure accounts and the findings register. Every unresolved item needs an owner, a next check and a decision date. Handover is complete when the incoming team demonstrates the agreed operations, not when a document is sent.

## Evidence index and remaining scope

Attach the commit identifiers for A and B, fixture description, redacted request/response records for QA-01 and QA-02, regression output and the OP-01 restore log. Keep evidence IDs identical between the finding, repair and retest. Record reviewer, date and environment with each result.

Load capacity, payment integration, mobile offline operation and production customer data are outside this example's scope. A PASS applies to the stated check and version. The report ends with the next release decision and its owner.