What we tested in Cadence /
The tests behind Cadence: inputs, actions, observed results and the limits of that evidence.
A light blue calendar workspace brings the week, host filters and appointment details together. The interface preview supports local appointment creation and conflict checks, with a day view on small screens.
Internal local testing, using synthetic inputs and owned assets. The results below establish the observed software behavior in those scenarios. They do not establish customer ROI, uptime or external deployment readiness.
Concurrency and boundary behavior
Fourteen Cadence HTTP checks passed. Two concurrent requests for the same interval produced exactly one successful hold and one conflict. A booking adjacent to the end of another interval was accepted, while a one-minute overlap was rejected. A zero-length request failed validation. These controlled races exercise capacity conservation for the supported single-resource model.
Confirmation, cancellation and expiry
Replaying confirmation returned the same saved booking. Cancelling it freed the interval for another hold. Explicit hold cancellation was idempotent, prevented later confirmation and immediately released capacity. A separately configured one-second hold expired without page activity, refused confirmation and permitted a replacement reservation. The expiry test reads the API's actual numeric epoch-millisecond field.
A concrete repeated-hour regression
For America/New_York Sunday hours 01:30–02:30, a request from 2026-11-01T05:45Z to 07:15Z was rejected as OUTSIDE_HOURS because the fall-back transition crosses the repeated closed 01:00–01:29 period. The shorter positive control starting at 06:30Z succeeded. This records one important transition scenario rather than claiming every timezone edge has been exhaustively tested.
Persistence and evaluation limits
Saved booking access survived logout and subsequent login. Anonymous access, invalid credentials, missing CSRF or hostile origin, and another workspace's attempt to read the booking were covered by the common harness. These are HTTP observations. This content does not claim a complete mobile booking audit, calendar delivery, a payment gateway check or a long-running production availability test.
What this evidence does not establish
Each resource supports capacity one; group inventory, pooled capacity and multi-resource atomic booking need a different model.
Reservations are future, whole-minute intervals of at most 12 hours and must remain within a supported local working day.
The tested confirmation is operator-managed with payment not required. It does not represent a paid reservation or a payment authorization.
ICS export is a downloadable record, not verified email delivery or two-way synchronization with Google or Microsoft calendars.
The daylight-saving test covers a specific New York fall-back boundary. Spring-forward and broader timezone coverage remain separate acceptance work.
A similar problem in your business?
Bring a real workflow, representative inputs and the result that needs to be reliable.
Shape a project brief