Rowan Workshop / Sample deliverable

What is ready for handover, and what still needs a decision?

Web-app acceptance review · Synthetic booking portal · Three workflows, two roles

Illustrative sample. No tests were executed for this report. The statuses, failures and fixture behaviors below are invented examples of how a real review would be documented. This is not evidence about a working application or a customer result.

Sample revision 1.0 · October 21, 2026 · Source baseline: synthetic requirements A01–A06 below · Environment/build: illustrative fixture only, no URL

3 workflowsBooking, cancellation, branch management

2 example findingsEach tied to an agreed rule

1 blocked areaEmail delivery needs a test mail sink

Executive reading

In this example, the release decision would remain with the customer. Two specified behaviors need correction: a capacity race and the cancellation boundary. Confirmation email delivery would remain unverified until an authorized staging mail sink is supplied. This is a bounded acceptance review, not a correctness or security certificate.

Scope and illustrative coverage

One agreed desktop browser and viewport; disposable records; Customer and Branch manager roles. The table demonstrates nine case dispositions. Every result in this table is illustrative, not an observed pass or failure.

Case / source	Scenario	Illustrative disposition
T01 / A01	One booking within remaining capacity	Would pass
T02 / A01	Two requests compete for the last place	Example failure F01
T03 / A01	Repeat the same request ID	Would pass
T04 / A02	Cancel exactly 24 hours before start	Example failure F02
T05 / A02	Cancel less than 24 hours before start	Would pass
T06 / A02	Successful cancellation restores capacity once	Would pass
T07 / A03	Manager opens another branch's booking by known fixture URL	Would pass
T08 / A03	Manager opens their own branch's booking	Would pass
T09 / A05	Confirmation arrives in staging mail sink	Would be blocked

Example findings

F01 · Two bookings consume the same remaining place

High impact / illustrative failure Source A01 · Case T02

Precondition: NORTH-101 has capacity 2, one confirmed place and one place remaining. Two disposable customer sessions are ready to submit different request IDs.

Open the same session in both authorized fixture sessions.
Submit a one-place booking from each at the coordinated test step.
Read both confirmation results and reload the session count.
Reset the fixture and repeat before calling the result reproducible.

Expected: exactly one confirmation, one capacity rejection, total confirmed places 2.

Invented result used for this sample: both requests confirm, leaving 3 confirmed places against capacity 2.

Why it matters: the agency would need to correct the capacity transaction before claiming A01 is satisfied. No lost-revenue estimate is asserted.

Evidence in a real delivery: build identifier, UTC time, sanitized request IDs, permitted UI captures and repeat-run details. None is attached here because no test was run.

Retest: repeat T02 on the corrected build with fresh fixture data; record both responses and final capacity. Passing one ordinary booking is not a retest of this failure.

F02 · Cancellation is refused at the permitted 24-hour boundary

Medium impact / illustrative failure Source A02 · Case T04

Precondition: NORTH-102 starts November 20, 2026 at 12:00 UTC. B-CANCEL-1 belongs to customer-demo. The authorized test clock is November 19, 2026 at 12:00 UTC.

Open the customer's booking at the frozen clock time.
Choose Cancel and confirm the action.
Inspect the displayed outcome and booking/capacity state.
Reset and repeat using the same time boundary.

Expected: cancellation succeeds at exactly 24 hours; the booking is cancelled and its two places are restored once.

Invented result used for this sample: the application refuses cancellation and leaves the booking confirmed.

Retest: verify exactly 24 hours is allowed, 23:59:59 is refused, and a repeated successful cancellation does not restore capacity twice. Use a controlled server clock, not an assumed client clock.

Blocked and excluded work

T09 would be blocked: no authorized mail sink is supplied in this illustrative fixture. An on-screen confirmation does not prove email delivery. In a real review, the report would identify the required access and keep the case blocked until retested.

Not covered: production data/actions, real recipients, payment/refund processing, load or penetration testing, other browsers, mobile behavior, accessibility certification, infrastructure, and workflows outside the agreed three. Functional branch-scope checks do not establish overall system security.

Agreed synthetic baseline

A01 / Capacity: a confirmed booking consumes requested places atomically. Competing requests for the last place yield one confirmation and one rejection. Repeating a booking-request ID does not duplicate a booking.

A02 / Cancellation: compare stored UTC instants. Cancellation is allowed at least 24 hours before start, including exactly 24 hours. It is refused inside that cutoff. Successful cancellation restores places immediately and only once.

A03 / Manager scope: a branch manager may read/change only their assigned branch's records. Direct navigation to another branch's known fixture record must be rejected.

A04 / Fixtures: disposable staging data; booking, cancellation and branch-management workflows; Customer and Branch manager roles. North/South manager accounts are instances of the same role.

A05 / Email: confirmation email requires an authorized staging mail sink. Missing access means blocked, not passed. No real recipients are contacted.

A06 / Decision: one agreed desktop browser/viewport; exclusions above apply; customer retains acceptance decision.

What the service includes

Web-app acceptance review: proposed $750 pilot, then $1,490 standard for the stated bounded scope, with one retest of the original scenarios. Scope and access are confirmed before an order. This sample makes no claim of past customer results.