How a customer-support situation becomes a hiring environment
This field note walks through one Calavion environment, an order-cancellation handover in customer support, and shows how a situation is turned into records, people, actions, delayed consequences and possible endings. It also says what the environment cannot show.
Summary
- The environment recreates one situation: an applicant inherits a customer case in which a cancellation and refund were promised but never completed, and a shipment is still moving.
- Everything specific in it is invented by Calavion. No real company, customer or transaction stands behind it.
- A real company’s case is not generated automatically. Calavion prepares it by hand with the company, replaces identifying details by hand, and the company approves an exact version before any applicant sees it.
- It has been run end to end in production on synthetic data. It has not been used in a real hiring process, and nothing here shows it predicts job performance.
Method and scope
Prepared by: Calavion Team. Verified: 25 September 2026, against the environment’s prepared version in Calavion’s application and Calavion’s internal product records. No external research is cited on this page; for that, see the evidence review.
Scope: the current built-in cancellation case. Timings and values below belong to this sample and may differ in a case prepared for a company. Names, figures and messages are labelled as invented or composed. No internal identifiers, credentials, source code or production data are shown.
1. The situation shape
An applicant opens a case handed over from the previous shift. A customer, Alex Chen in this sample, asked to cancel an order and be refunded. The previous employee told them it was cancelled and the refund was on its way. Neither happened. A cancellation request sent to the warehouse the day before was rejected because it lacked an order reference, and nobody followed up. The order is packed, a shipping label exists, no refund has been issued, and the customer has now received a dispatch email and written back, upset, having already bought a replacement. The applicant owns the case.
The general shape is a promise made and not kept, a request nobody chased, a closing window, an interruption mid-task and an outcome that can stay open. Calavion chose this shape because it is common in customer-support work. The specifics were authored, not drawn from any company.
2. What records are represented
Records in the environment
Scroll sideways to see all columns.
| Record | What it represents | Changes during the session? |
|---|---|---|
| Customer conversation and history | The opening message and yesterday’s history, including what the previous employee promised | No. Applicant replies are added to the conversation |
| Payment | Amount captured, card ending, and any refund reference | Yes, when a refund is submitted |
| Fulfilment | Whether the order is packed, stopped, or collected by the carrier | Yes, when a stop is confirmed or the carrier collects |
| Warehouse thread | Yesterday’s rejected request and today’s stop request and answer | Yes |
| Operating procedure | A five-point cancellation and refund procedure | No |
All five records are visible to the applicant once opened. Opening a record is logged.
3. Facts, company rules and approved assumptions
A company case has to keep three things apart, and the built-in case does the same in miniature.
- Facts describe the state of the world: the order is packed, the previous request was rejected for a missing reference, no refund exists.
- Company rules describe how the work should be done. The procedure record has five numbered points. Two are tracked by the environment: stop the shipment and get warehouse confirmation before telling the customer anything is cancelled, and refund only after that confirmation. Neither rule is enforced. An applicant can break either one, and the environment records that it happened instead of blocking it.
- Assumptions are choices the author made so the situation would run, for example that the warehouse can stop a parcel only within a limited window and that the carrier collects it later. In a case prepared for a real company, any assumption that could change what a good response looks like would need the company’s explicit approval before applicants see it. Here, the assumptions are the author’s and are not company-approved.
4. How fictionalization works
The customer’s name, the order number, the amount, the card ending, the times, the previous employee’s words, the support lead’s words and the procedure wording are all invented, and the messages are composed by the case author. The public sample environment page uses a different set of invented values from the in-application case, so figures should not be compared between the two.
5. How sensitive details are handled
The built-in case contains no real personal or company data, so nothing needed removing. For a real company the process is manual. The company provides material, which has therefore already left its own systems. Calavion reviews it, replaces identifying details by hand, and the company approves the result. Source files are used for preparation and are never shown to applicants. There is no automatic redaction.
6. Actors and conversations
Who is in the environment and how they behave
Scroll sideways to see all columns.
| Actor | Role | Behaviour |
|---|---|---|
| Applicant | Owns the case | Reads records, writes messages and takes actions |
| Customer (invented) | The person waiting | Sends one opening message. The environment does not generate further customer replies. Applicant replies are recorded verbatim |
| Support lead (invented) | A manager | Sends one scripted message about three minutes in, unprompted, asking the applicant to keep ownership. A question the applicant sends is recorded, and the environment does not generate a tailored answer |
| Warehouse | A system that answers on its own schedule | Answers a stop request once, about a minute later, confirming the stop or saying it is too late |
7. Available actions
- Read the history, payment, fulfilment, warehouse thread and procedure records
- Reply to the customer
- Leave an internal note
- Message the warehouse
- Message the support lead
- Request a stop on the shipment
- Submit a refund
- Leave a reminder for the next person
- Close out the handover
8. Delayed consequences
Timed events in this sample case
Scroll sideways to see all columns.
| Event | When | Condition |
|---|---|---|
| Support lead message | About 3 minutes into the session | Happens regardless of what the applicant does |
| Warehouse answer to a stop request | About 1 minute after the request | Confirms the stop if the request was inside the window, otherwise says it is too late |
| Stop window closes | About 6 minutes into the session | A request after this point is refused |
| Carrier collects the parcel | About 10 minutes into the session | Only if the shipment has not already been stopped |
| Session limit | 30 minutes | A hard cap |
These timings apply to this sample case and are not claims about any other case or about how long applicants take.
Two acts are recorded as reactions rather than blocked. Replying to the customer before opening the payment and warehouse records, and submitting a refund before the stop is confirmed, are each noted in the record. The consequence text states what was skipped, and the applicant can still proceed.
9. Possible endings
How the case can end
Scroll sideways to see all columns.
| Ending | What has to be true | What it records |
|---|---|---|
| Stopped and refund processing | The shipment was stopped and a refund was submitted | The shipment stopped and the refund is processing |
| Shipped, return owned | The carrier collected the parcel and the applicant left a reminder | The shipment left, and a follow-up was left to own the return |
| Shipped, unowned | The carrier collected the parcel and nothing was left | The shipment left with no follow-up arranged |
| Unresolved | Neither of the above applies when the handover is closed | The shift ended without resolving the shipment or the refund |
None is presented to the applicant as the correct ending. No action in the case marks a refund as received, so “processing” is the furthest a refund can go.
10. Company review and approval
Before any applicant enters, the company reviews the full prepared case: the starting records, available actions, consequences, delayed messages and possible endings. Approval requires a company-written orientation and guidance text, and it is tied to the exact version reviewed. An approved version does not change.
11. Version binding
Each invitation is tied to the version approved when the invitation was created, and a session runs against that version. If the environment is later revised, the revision needs its own review and does not alter earlier invitations, so a Replay can always be read against the version that produced it.
12. What Replay preserves
- The applicant’s exact messages and actions, in order
- The records the applicant opened
- Delayed messages and the consequences that followed
- The recorded state of the case after events
- Outstanding work at the end
- A label showing whether the case is hand-authored, synthetic or imported
One limit: the recorded state after events can include details the applicant never opened, so Replay should not be read as a picture of exactly what the applicant saw. See Replay.
13. What this environment cannot prove
It shows what the mechanism does. It does not show that the mechanism works for a real hire. Running it end to end confirms that it operates. It does not establish that it resembles real customer-support work, predicts job performance, treats applicant groups equitably or improves any hiring outcome, and Calavion does not claim any of those.
Calavion has run the full journey against production infrastructure using clearly labelled synthetic company and applicant data, and real defects found along the way were fixed.
14. Current limitations
- One case shape. Customer-support work of a different shape is a finding for Calavion to assess, not something the product stretches to fit.
- Preparation is manual and setup is handled directly with each company.
- Details typed into a submission form do not reshape the case by themselves.
- The product and workspace are in English only.
- Recorded actions are not a record of an applicant’s reasoning.