Mentor Stage 5

Coding5s / Pillar 2 / Stage 05 Mentor

The Strategic Partner

Extend Mentor

The Strategic Partner helps the learner extend an existing implementation while protecting the requirements and behavior that already matter. Unlike earlier stages, the code alone is not enough: the mentor also needs the ticket context, acceptance criteria, expected behavior, and the learner’s current implementation so it can evaluate technical decisions against the actual business requirement.

TICKET → REQUIREMENTS → IMPLEMENT → VERIFY → CHALLENGE EDGE CASES
HOW TO USE THIS MENTOR
01 Generate and copy the Stage 5 Mentor Prompt from the Coding5s Creator Kit.
02 Paste the Mentor Prompt into your AI chat, then include the ticket context, acceptance criteria, and expected behavior. These define what the implementation is actually allowed to do.
03 Paste your implementation and explain what currently works, what requirement you are uncertain about, and any edge case or production risk that concerns you.
04 Ask the mentor to evaluate your decision against the ticket before suggesting changes. The goal is not merely to make the code work, but to extend it without silently changing the required behavior.
CONTEXT TO PASTE WITH THE MENTOR REQUEST
🎫 Ticket #48291 — Implement Tiered Transaction Risk Scoring

From: Sarah Jenkins — Risk & Compliance
Assignment: Implement dynamic multi-way decision logic that categorizes incoming financial transactions by transaction amount, account age, and origin country.

Tech Product Manager Note: Build the evaluate_risk() function using clean if, elif, and else statements. Follow the compliance rules strictly and avoid deeply nested branches by using compound boolean expressions.

✅ ACCEPTANCE CRITERIA
  • If the transaction amount is greater than $10,000, return 'High Risk'.
  • If the amount is greater than $5,000 OR (amount > $1,000 AND country is NOT 'US'), return 'Medium Risk'.
  • If the amount is greater than $100 AND new_account is True, return 'Low Risk'.
  • For all other cases, return 'Minimal Risk'.
EXPECTED BEHAVIOR

Conditions must be evaluated sequentially from top to bottom. Once a condition is met, the function should immediately return that risk tier. Transactions that fail every specific rule must fall back to "Minimal Risk".

EXAMPLE / STUDENT IMPLEMENTATION REVIEW

The implementation below passes every transaction included with the ticket, but the learner notices that passing the sample data does not necessarily prove that the acceptance criteria are implemented correctly.

Student: All five transactions give me the risk levels I expected, but now I’m nervous about calling this finished. I used >= for the thresholds, and I just noticed the ticket repeatedly says greater than. The sample data never hits the exact boundary values, so everything still passes and I can’t tell if I’ve introduced a hidden compliance bug.

Question: Before I change anything, how should I validate the exact boundary cases at 10000, 5000, 1000, and 100 against the acceptance criteria? I’m also unsure whether values such as "us" should be normalized to "US" or whether that would change a business rule that the ticket never specified. Which changes are safe implementation decisions, and which ones require clarification before this is production-ready?

Python / Current Test Output 
Txn T001 | Amount: $12,500.00 | Risk: High Risk
Txn T002 | Amount: $ 6,000.00 | Risk: Medium Risk
Txn T003 | Amount: $ 1,500.00 | Risk: Medium Risk
Txn T004 | Amount: $   800.00 | Risk: Low Risk
Txn T005 | Amount: $    50.00 | Risk: Minimal Risk
Python / Student Implementation 
def evaluate_risk(transaction):
    amount = transaction.get("amount", 0.0)
    country = transaction.get("country", "US")
    new_account = transaction.get("new_account", False)

    if amount >= 10000:
        return "High Risk"
    elif amount >= 5000 or (amount >= 1000 and country != "US"):
        return "Medium Risk"
    elif amount >= 100 and new_account:
        return "Low Risk"
    else:
        return "Minimal Risk"
Reference interaction: Stage 5 requires more than showing code. The student gives the mentor the original ticket, the exact acceptance criteria, the current implementation, evidence that the supplied examples pass, and a concern about behavior that the examples do not exercise. This allows the mentor to distinguish a coding decision from a business-rule decision and evaluate the extension without inventing requirements.

What happens next? When you paste the ticket context, acceptance criteria, implementation, and strategic question immediately after the Mentor Prompt, you receive feedback like the example shown below.

🚀 Elite Mentor Stage 5 | Topic #23 | Extend | Python Core & Scripting | 📊 Level: Intermediate

Topic: Implement multi-way conditional decision paths using if, elif, and else.

We are shipping this to production, and I am thrilled you caught this before the PR was merged. In financial systems, “close enough” is how companies get fined by regulators. You are asking the exact right questions for a senior engineer.

To answer your questions directly:

  1. The ticket explicitly says “greater than”. In legal/compliance logic, words are literal. > is “greater than”, >= is “greater than or equal to”. If you use >=, an exact $10,000.00 transaction triggers High Risk. A strict reading of the ticket means exactly $10,000.00 should fall through to Medium Risk.
  2. Normalizing inputs (like calling .upper() on a country code) is universally considered a safe, defensive implementation decision. Never trust the client to send perfectly cased data.

Let’s look at the broader system implications before we sign off.

Business Observations:

  • Boundary Compliance: Your current implementation includes the boundary values in the higher risk tier. If compliance audits our system and finds a $10,000 transaction flagged as High Risk when the policy states “greater than $10,000”, that is a bug.
  • Data Integrity & Case Sensitivity: The API upstream might send "us", "US", or even "uS". Your current country != "US" check will flag "us" as non-US, falsely elevating the risk of domestic transactions.
  • Type Safety in Finance: You are currently defaulting to 0.0 (a float). Financial systems should almost never use floating-point numbers due to precision loss (e.g., 0.1 + 0.2 != 0.3).

Socratic Question:

If a malicious actor or a front-end bug sends the amount as a string (e.g., {"amount": "15000", "country": "US"}), what happens when your code hits amount >= 10000? How can we harden the boundary checks so the system either coerces the type safely or fails predictably?

Next Step:

Before changing the operators, write three explicit unit tests for the exact values: 10000, 5000, and 100. Then, research Python’s decimal module for handling currency, and the string .upper().strip() methods to sanitize the country code.

🛑 THE EXPLANATION GATE 🛑 Before scrolling down to the final architectural review, articulate the TRADE-OFFS of your implementation. What happens when this feature faces extreme load? Pushing code without understanding scale builds Epistemic Debt.

Phase 2: Final Review

I will not rewrite the function for you—you already know what you need to do (swap >= for >, and add .upper() to the country string). Instead, let’s talk about how to make this logic truly ‘Production Ready’.

The Architect’s Verdict:

For financial decision trees, the code must be deterministic and mathematically precise. Moving forward, avoid using raw floats for currency. While Python’s if/elif/else branching is highly optimized and will scale beautifully under load, the data passing through those branches must be heavily sanitized. You should implement strict type hinting (e.g., using typing.Dict or typing.Mapping) and consider parsing the incoming payload with a schema validator before it even reaches this business logic.

Risk Assessment:

  1. Type Mismatches: If the upstream service sends amount as a string ("5000"), Python 3 will throw a TypeError when comparing it to an integer, causing a 500 Internal Server Error and failing the transaction entirely.
  2. Missing Keys & Defaults: You handled missing keys well with .get(), but defaulting new_account to False means if the upstream API drops that field, we default to the less secure assumption. In risk/security contexts, it’s often safer to fail closed (default to the higher risk state) than to fail open.

Recognition:

Excellent job utilizing .get() with fallback defaults, and fantastic work combining the Medium Risk checks into a single, clean elif branch using or and and. You avoided the trap of deeply nested if statements, keeping the cyclomatic complexity low and the readability high. This is clean, functional routing. Fix those operators, normalize the string, and ship it.

—

⚡ Coding5s Mentor System — Eliminating Epistemic Debt & Shipping to Production

Scroll to Top