Framing a problem with real Nepali data

What “framing” means

Framing answers five questions about your project, in order. Get all five answers down on one page before you load any data.

1. Who is the user? Specifically. Not “microfinance organisations” — which organisation, whose job is improved?
2. What decision will the model inform? Concretely. A prediction the user already wishes they had?
3. What is the prediction target? A specific column you can compute from data you have access to.
4. What does success look like? A metric and a threshold, both defensible.
5. What are the failure modes and who bears the cost? Names and consequences.

This sounds bureaucratic. It is not. It is what separates a small finished project from a six-month sprawl.

A worked framing — microfinance default prediction

The aspiration: “Use AI to reduce defaults at our microfinance institution.”

The problem with the aspiration: it doesn’t tell us what to build. We frame:

1. Who is the user?

The loan officers at one specific microfinance institution in Tarai. There are about 12 officers across 4 branches. They each review 15-30 loan applications per day. The model is built to support their workflow, not replace it.

Specific. Has a count and a workflow context.

2. What decision?

For each new application, the officer needs to decide: approve, decline, or escalate to senior review. They currently make this decision by reading the form, asking questions, and judging. The model will produce a default-probability score the officer can use as one input — not as the decision itself.

The model is assistive, not autonomous. A profoundly important framing choice. We’ll return to it.

3. What is the prediction target?

defaulted — a binary column in our historical loan database. defaulted = True if the loan was either (a) more than 90 days overdue on at least one payment, or (b) formally written off. We will exclude loans currently active but younger than 6 months (because we don’t know yet whether they’ll default).

Specific definition. The exclusion rule is important — without it, recent loans are systematically labelled “no-default” by virtue of not being old enough, and the model would learn nonsense.

4. What does success look like?

Recall on the default class above 75%, with precision above 60%, evaluated per-branch and overall. Stakeholders will compare the model’s flags against current manual escalation rates — if the model catches more defaults than current process at a similar review burden, it ships. If officers report “too many false flags,” we adjust the threshold.

A specific metric with a specific threshold. A specific user-facing comparison. A specific operational lever for adjustment.

5. Failure modes?

(a) The model could miss real defaulters, costing the institution money — measured by recall. (b) The model could falsely flag good borrowers, wasting officer time and slowing approvals — measured by precision. (c) The model could be systematically biased — e.g. worse for borrowers from a specific district — disadvantaging a sub-population. We must report per-district performance and stop deployment if the gap exceeds an agreed threshold. (d) The model could embed and amplify historical lending bias. We will not use protected characteristics (caste, ethnicity, gender) as features; we will audit for proxies.

Four failure modes. Three are technical. The fourth is ethical. Each has a name and a check.

That five-question template, applied honestly, takes about an hour. It is the highest-leverage hour of any ML project. Almost every “we built it but no one uses it” story comes from a project that skipped this step.

A small inventory of well-shaped Nepali ML problems

To give your imagination some shape, here are eight project ideas, each properly framed for a weekend-to-month-scale effort.

1. NEPSE direction predictor. Predict whether tomorrow’s NEPSE close will be higher or lower than today’s. Target: binary up/down. User: a small retail investor browsing the news. Success: better-than-coinflip recall, evaluated chronologically (TimeSeriesSplit). Failure mode: model becomes a “buy signal” without disclaimers.

2. Microfinance default flag. The worked example above.

3. SMS spam classifier (Nepali). Build on Chapter 2 Section 3. Collect 500 mixed-language SMS yourself. Target: spam/ham binary. User: yourself first. Success: 90% recall on spam with under 5% false alarms. Failure mode: privacy of sender contacts.

4. School dropout risk. Given a student’s attendance, grades, and basic demographics, predict whether they’ll drop out next year. Target: binary stayed/left. User: a school counsellor. Success: per-group recall and explanations the counsellor can act on. Failure mode: bias against specific groups, self-fulfilling-prophecy effects.

5. Tukcha (homestay) review sentiment. Classify Nepali-language hotel/homestay reviews as positive/negative. User: a small homestay owner monitoring online presence. Success: 85% precision on each class. Failure mode: misclassifying constructive criticism as “negative” and ignoring it.

6. Kathmandu rent estimator. Chapter 3’s worked example, refined for production. User: a small real-estate broker. Success: MAE within Rs 5,000. Failure mode: stale data (rent changes seasonally and annually).

7. NEPSE next-day volatility classifier. Predict whether tomorrow’s intraday volatility will be high. Target: binary high/low. User: a more sophisticated investor. Success: improved over baseline. Failure mode: market regime changes that the model wasn’t trained on.

8. Vendor/transaction fraud flag. Given Khalti transaction history, flag transactions that look unusual. Unsupervised or weakly supervised. User: a small business owner monitoring their own books. Success: precision on flagged transactions.

Pick one. Frame it on a page. The whole rest of this chapter walks through the build.

Writing the framing down

The deliverable from this section, before you write any code: a one-page framing document, saved as docs/framing.md in your project. The structure:

# Project: NEPSE Direction Predictor

## User
A small retail investor in Nepal who reads the morning paper and decides
whether to check their portfolio more closely today. About 200,000
active retail investors on NEPSE.

## Decision the model informs
For each upcoming trading day, suggest "likely up" or "likely down" so
the user knows whether to expect a calm or volatile day. Not a buy/sell
signal — explicitly framed as a directional hint, not advice.

## Prediction target
Binary: `direction = sign(close_tomorrow - close_today) > 0`. Trained on
the last 5 years of daily NEPSE closes. Evaluated chronologically.

## Success metric
F1 score above 0.55 on a chronological holdout, with no calendar-month
period showing F1 below 0.45 (consistent performance across regimes).

## Failure modes
1. The model becomes a tacit buy signal; mitigate by always showing
   probability + disclaimer + historical accuracy on the UI.
2. The model misses market regime changes (e.g. policy announcements);
   mitigate by retraining monthly and flagging large probability shifts.
3. The model could be used by hostile actors to time announcements;
   keep deployment to authenticated users only.

That’s a complete framing. Half an hour to write. Saves weeks of confused work.

Check your understanding

Quick check

—

A teammate proposes a project: 'use ML to help our hospital.' What is the most useful next question, in the spirit of this section?

1. AWhat library should we use?
2. BWhich specific person at the hospital — by role and workflow — and which specific decision do they make today that the model would inform? Until we can name a user and a decision, we cannot frame a meaningful project. ML projects without a named user and decision routinely build sophisticated tools that nobody uses.
3. CHow much data do we have?
4. DShould we use a neural network?

Check answer→

Quick check

—

A team frames their loan-default project with success metric 'maximise accuracy.' What's wrong with this success metric, given Chapters 4 and 5?

1. ANothing — accuracy is the standard metric.
2. BFor an imbalanced problem like loan default (typically 3-8% default rate), accuracy can be 95%+ for a model that catches no defaults at all — the model just predicts 'no default' for everyone. A better framing names specific precision and recall targets, and probably specifies per-group constraints. The framing should also name the operational threshold for go/no-go ('recall above 75% with precision above 60%, per-district reporting'). Without that specificity, the technical team has no real target to hit.
3. CAccuracy is fine for any imbalanced problem.
4. DUse unsupervised learning instead.

Check answer→

What comes next

The framing is done. The next section is the build itself — from framing document to working model, end to end, on whichever project you chose. You will use everything from Course 02 (data preparation) and Course 03 Chapters 1-5 (training, evaluating, tuning). The shape will feel familiar because it is.