Challenges/Gordian Software/General/Building a Reliable Refund Logic Flow

Building a Reliable Refund Logic Flow

State Machines

API Design

Logic Flow Reliability

Software Engineering

Estimated Time:

1 hour

Status:Not started

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)

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

Logic Clarity & Safety — 40% Practical Implementation Thinking — 30% Communication & Reasoning — 20% AI Usage Transparency — 10%

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)

On this page

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)