You will be able to explain when hand-written rules do the job well and when learning from examples does it better.
When you file your income tax in Singapore, the amount you owe is worked out from a table. IRAS publishes the income brackets, each slice of your income is taxed at a set rate, and two people with the same income and the same reliefs get the same tax bill.
You want a tax calculation that follows the rules exactly every time, and nobody wants one with a "feel for the job". Your email spam folder is a different case. Nobody could write down the rules for it, because spam changes every few weeks and spammers study the filters and work around them. These two jobs need different kinds of system, and you can learn to tell which kind a task needs.
A rule-based system is a set of instructions a person writes in advance, in the form "if this happens, do that". Rules work well when two things are both true: the task stays the same over time, and every case can be described in full.
Income tax brackets pass both tests. So does checking whether a leave application asks for more days than the employee has left, or whether a claim is over the limit in the company's expense policy. The logic for tasks like these can be long, but it is complete. A person can read it, test it and explain any answer it gives.
The main strength of rules is traceability. When a payroll system deducts the wrong amount, someone can find the exact line that caused it and fix that line, with no guessing.
Rules struggle when a pattern is fuzzy, when it keeps moving, or both. A moving pattern changes over time, often because the people on the other side adapt to whatever is stopping them.
Spam is both fuzzy and moving. Say a rule blocks emails that say "you have won a prize". Spammers switch to "you have been selected", so that gets added as a rule. Then spammers use images instead of text, or misspell words on purpose. After a year there are hundreds of rules, some of them block real emails from your bank, and the filter is still a step behind.
Card fraud behaves the same way. A rule such as "flag any card used in two countries within an hour" catches some fraud but annoys every traveller passing through Changi. Fraudsters learn the rule and keep their transactions within it.
Handwriting is fuzzy but does not move. Writing rules to read a handwritten 7 is very hard. Some people cross it, some don't, and some slant it until it looks like a 1. You can recognise a 7 easily, but you can't say how you do it. A fuzzy pattern is one people can recognise but cannot fully describe in rules, and many everyday skills are like this: people can do them but cannot list the steps.
Machine learning, as described here, takes a different route. Instead of writing rules, you collect many examples with the correct answer attached, such as thousands of emails already marked spam or not spam, and let the system find the pattern itself. Module 2 shows how a system finds that pattern from labelled examples.
The difference is clearest when something changes. Under rules, a person has to spot the gap, write a new rule and check that it doesn't break the old ones. Under learning, you gather fresh examples of the new trick, label them and retrain, which means training the system again on those examples. The system then adjusts its own pattern to fit.
For a bank's fraud team, a new scam under a rule-based setup means meetings, a change request and weeks of testing. Under a learned setup, it means collecting recent cases marked as fraud and retraining. Retraining still costs money and still needs skilled people, but it keeps up in a way that thousands of hand-written rules cannot.
The rest of this course keeps coming back to the trade-off between the two. Rules give you control: you know what the system will do, and you can explain any decision it makes. A learned system gives you flexibility, but by default you lose both predictability and explainability. You can't always predict what it will do with a case it has never seen. Its decision may have no line you can point to, because its pattern lives in a large set of numbers and not in sentences anyone wrote. Builders can add tools that help explain a learned system's choices, but that takes extra work.
Many real systems combine the two. A bank might use a learned model to score how suspicious a payment looks, then apply fixed rules on top of that score. Anything above a set level goes to a person, and some kinds of transfer are always held. The learned part handles the fuzzy pattern, and the rules cover the parts that must be predictable.
For any task, the useful question is whether it is stable and fully describable, which suits rules, or fuzzy and shifting, which suits learning. Most jobs contain both kinds. Approving a claim against a fixed policy table is the stable kind. Spotting which customer emails are politely worded complaints is the fuzzy kind.
Take a couple of your own tasks, from your work email or the jobs you do each week, and sort them this way. It's a habit you'll use again when you build your capability map in Module 8.
Pick two tasks from your job. For each, write a short note on whether fixed rules or a system that learns from examples would handle it better, and why.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).