Building a Reliable Refund Logic Flow
Design a simple state machine or API flow to make refund responses more accurate and reliable
Create a free account to upload your work. Your progress saves as a draft until you submit.
What You'll Be Doing
Description:
Scenario — "Refund or Credit?":
Context: Axel's AI travel agent helps users handle cancellations and rebookings automatically. Recently, users have received incorrect refund responses — for example:
User: "My flight was canceled by the airline. Can I get my money back?" AI: "Sorry, your ticket is non-refundable, but you can use it as credit."
That's wrong — airline-canceled flights should trigger refunds, even for non-refundable fares.
Your Task:
Design a lightweight Refund Decision State Machine or Refund API flow that helps the AI determine what to say reliably.
Your system should:
- Accept key inputs (e.g., cancellation reason, fare type, airline policy data)
- Transition through simple states (e.g., checking policy → confirmed refund → safe fallback)
- Output a safe, correct response (refund / credit / escalate)
- Handle uncertain or missing data gracefully
You don't need to build it — just design how it works and explain how you'd test it.
Submission Guidelines
Video Requirements:
Your 7-10 minute video must include ALL three components:
1. Introduction (1-2 minutes)
- Share one example of a time you automated something or made a system more reliable. What tradeoffs did you make, and what did you learn?
2. Traits Assessment (2-3 minutes)
Which situation sounds more like the kind of challenge you enjoy — and why?
- Scenario A — "The Friday Fix" (Execution): Customer support flags that refund messages are wrong for one airline. You're asked to fix the refund logic — one specific carrier, one intent — and deploy safely today. You'll test it end-to-end and verify nothing else breaks.
- Scenario B — "The Hidden Pattern" (Discovery): You notice refund messages vary depending on input phrasing. You propose a cleaner state machine that classifies each case — refundable, credit-only, unclear — before generating a response. You present it to the team as a small reliability improvement project.
There's no right answer — just explain which fits your working style and why.
3. Challenge Response (3-5 minutes)
Walk us through your approach to the scenario:
- How would you structure the logic or API to handle refund eligibility safely?
- What states or conditions would it include?
- How would you handle "uncertain" or "missing data" cases?
- How would you test that it works before shipping?
You can describe this as pseudocode, diagrams, or plain-language logic — we care more about clarity than syntax.
AI Usage Declaration:
At the end of your video, please state:
- ☐ I did not use any AI tools
- ☐ I used AI tools (briefly describe how, including what I changed or adapted)
Challenge Guidelines
- Video: 7–10 minutes (continuous recording, one take)
- Written Artifacts: Two short documents (1 page each)
- Scenario: Design a simple state machine or API flow to make refund responses more accurate and reliable
- AI Usage Declaration: Required
What You'll Accomplish
Handle uncertain or missing data gracefully
Design state machines for business logic
Create safe fallback patterns Test and validate decision logic Balance simplicity with reliability
Test and validate decision logic
Balance simplicity with reliability
How Your Work Will Be Scored
What to Submit
Required Submissions:
- Refund Logic Flow (Required)
- Format: PDF or Document
- Length: 1 page maximum
- Create a short diagram, table, or pseudocode outline of your logic
- Example format:
Inputs: fare_type, cancellation_reason, airline_policy
States:
START → VALIDATE_INPUTS
VALIDATE_INPUTS → CHECK_POLICY
CHECK_POLICY → [REFUND_ELIGIBLE | CREDIT_ONLY | UNKNOWN]
Outputs:
REFUND_ELIGIBLE → "You are eligible for a full refund."
CREDIT_ONLY → "You're eligible for a travel credit."
UNKNOWN → "Let me confirm this with an agent."
- Include 1-2 example user cases showing how it works
- Reliability & Testing Plan (Required)
- Format: PDF or Document
- Length: 1 page maximum
- Describe how you'd test and monitor your logic:
- What small test cases or edge cases you'd check
- How you'd handle airline-specific overrides
- How you'd detect and log uncertain outcomes
- One metric you'd track after shipping (e.g., refund-related error rate)
- Video Recording (Required)
- Format: MP4 or MOV
- Length: 7-10 minutes (continuous recording, one take)
- Must include all three components detailed below
Submission Guidelines
Video Requirements:
Your 7-10 minute video must include ALL three components:
1. Introduction (1-2 minutes)
- Share one example of a time you automated something or made a system more reliable. What tradeoffs did you make, and what did you learn?
2. Traits Assessment (2-3 minutes)
Which situation sounds more like the kind of challenge you enjoy — and why?
- Scenario A — "The Friday Fix" (Execution): Customer support flags that refund messages are wrong for one airline. You're asked to fix the refund logic — one specific carrier, one intent — and deploy safely today. You'll test it end-to-end and verify nothing else breaks.
- Scenario B — "The Hidden Pattern" (Discovery): You notice refund messages vary depending on input phrasing. You propose a cleaner state machine that classifies each case — refundable, credit-only, unclear — before generating a response. You present it to the team as a small reliability improvement project.
There's no right answer — just explain which fits your working style and why.
3. Challenge Response (3-5 minutes)
Walk us through your approach to the scenario:
- How would you structure the logic or API to handle refund eligibility safely?
- What states or conditions would it include?
- How would you handle "uncertain" or "missing data" cases?
- How would you test that it works before shipping?
You can describe this as pseudocode, diagrams, or plain-language logic — we care more about clarity than syntax.
AI Usage Declaration:
At the end of your video, please state:
- ☐ I did not use any AI tools
- ☐ I used AI tools (briefly describe how, including what I changed or adapted)
Refund Logic Flow
Format: .pdf, .doc, .docx, .rtf, .txt, .md
Format: PDF or Document
Length: 1 page maximum
Create a short diagram, table, or pseudocode outline of your refund decision logic:
- Inputs: fare_type, cancellation_reason, airline_policy
- States: START → VALIDATE_INPUTS → CHECK_POLICY → [REFUND_ELIGIBLE | CREDIT_ONLY | UNKNOWN]
- Outputs:
- REFUND_ELIGIBLE → "You are eligible for a full refund."
- CREDIT_ONLY → "You're eligible for a travel credit."
- UNKNOWN → "Let me confirm this with an agent."
Include 1-2 example user cases showing how the logic works.
Sign in to upload files
Reliability & Testing Plan
Format: .pdf, .doc, .docx, .rtf, .txt, .md
Format: PDF or Document
Length: 1 page maximum
Describe how you'd test and monitor your logic:
- What small test cases or edge cases you'd check
- How you'd handle airline-specific overrides
- How you'd detect and log uncertain outcomes
- One metric you'd track after shipping (e.g., refund-related error rate)
Sign in to upload files
Video Recording
Format: .mp4, .mov, .webm
Format: MP4 or MOV
Length: 7-10 minutes (continuous recording, one take)
Must include ALL three components:
1. Introduction (1-2 minutes)
- Share one example of a time you automated something or made a system more reliable
- What tradeoffs did you make, and what did you learn?
2. Traits Assessment (2-3 minutes)
- Which scenario fits your working style: "The Friday Fix" (execution-focused) or "The Hidden Pattern" (discovery-focused) and why?
3. Challenge Response (3-5 minutes)
- How would you structure the logic or API to handle refund eligibility safely?
- What states or conditions would it include?
- How would you handle "uncertain" or "missing data" cases?
- How would you test it before shipping?
AI Usage Declaration: Include at the end of your video
Sign in to upload files
Create a free account to upload your work. Your progress saves as a draft until you submit.
On this page