Sample environment: the cancellation that never happened

This is a fictionalized public example based on Calavion’s functioning customer-support environment. The company, customer, order and payment details are invented. It demonstrates the kinds of records, decisions, interruptions and consequences present in the environment; it is not a real customer case.

What this page is

This page presents one concrete, fictionalized case so readers can inspect the work Calavion asks an applicant to perform. It shows the situation, available records, permitted actions and possible consequences without exposing the application or private data.

The opening situation

An applicant logs in as a customer-support agent for a fictional retailer. Waiting in the queue is a case handed over from the previous shift: yesterday, a colleague told a customer their order would be cancelled and refunded, then the shift ended before either actually happened. The order has not been cancelled. It has not been refunded. The applicant now owns the case.

What’s available to inspect

Before doing anything else, the applicant can open:

• The order and payment record — order total $142.00, charged to a card ending in 7745. No refund has been issued yet.
• The fulfillment record — status: packed. A shipping label was already created earlier that morning.
• The warehouse thread — the channel used to ask the warehouse to intervene on a shipment. No request has been sent yet.
• Yesterday’s handover note — the previous agent’s own account of what they told the customer, and what they actually did about it.
• The environment’s operating guidance for cases like this one.

In this public example, the handover record says:

“The customer was told the order would be cancelled and refunded. Neither action was completed before the previous shift ended.”

The policy

The environment provides two operating rules:

• Confirm that the warehouse stopped the shipment before submitting the refund.
• Do not tell the customer that the cancellation is complete until that confirmation exists.

Neither instruction is enforced by the system. The applicant can submit a refund before a stop is confirmed, or reply to the customer before checking either record. Both are possible, and both are recorded exactly as they happened — not blocked, not hidden.

What the applicant can do

• Read the handover note, the payment record, the fulfillment record, the warehouse thread, and the procedure
• Reply to the customer
• Leave an internal note, not visible to the customer
• Message the warehouse to request a stop on the shipment
• Ask the shift manager a question
• Submit a refund
• Leave a reminder for whoever picks this case up next
• Close out the handover when done

An interruption

A few minutes into the case, a message arrives from the shift manager, unprompted.

In the public example, the manager’s interruption is represented as:

“I saw yesterday’s cancellation promise is still open. Keep ownership of this one. If the warehouse can’t stop it in time, tell me the shipment status and what exception you’re asking for.”

The message enters while the case is still active. The applicant must decide how it affects the work already underway.

A delayed consequence

The warehouse can only stop a shipment within a limited window after the case opens. If the applicant doesn’t request a stop in time — or the request arrives after that window has closed — the shipment ships anyway, on its own, without the applicant doing anything further to cause it. This happens whether or not the applicant is still thinking about the case. It is a consequence of time passing, not of a single action.

A possible unfinished obligation

Not every case closes cleanly inside a single shift. If the shipment goes out before the refund is settled, or before the customer’s original question is fully answered, the applicant can leave a reminder for the next person instead of forcing an artificial resolution. Replay preserves that the case remained open and whether follow-up ownership was left visible.

How this case can end

Three possible outcomes, depending on what the applicant does and when:

• The shipment is stopped and a refund is submitted. Refund completion remains visible as follow-up work; submission alone does not establish that the customer received the money.
• The shipment ships before it can be stopped, but the applicant leaves a reminder for the next person — the case ends open, with a next step recorded.
• The shipment ships and nothing is left behind for whoever picks the case up next — the case ends open, with no ownership maintained.

None of these is presented to the applicant as correct. Replay preserves which outcome occurred and the event sequence that produced it — not which one was “best.”

What this page is not

This is not a demo you can click through, and it does not show Calavion’s interface, login flow, or any internal system detail. It does not include real customer or company information — everything above is fictionalized. It is not a claim that this exact case proves Calavion works, improves hiring outcomes, or saves time; it is a fictionalized description based on the same customer-support environment already verified in production, for anyone who wants to check the mechanism against something more concrete than a description.

Read next

Product — how a case like this one gets built from a company’s own work. Replay — what the employer receives once an applicant finishes. Methodology — the exact terms used above. Bring your work — if you have work like this to turn into an environment.