The Domain Layer

🎯 What You'll Learn

Distinguish between technical skill and domain knowledge
Explain why algorithmic thinking must precede coding
Identify the "domain layer" in any ML project
Apply context-aware design to real-world problems
Evaluate when tools (like LLMs) are insufficient without human judgment

📋 Before You Begin

Basic understanding of what machine learning is
Familiarity with the concept of training data
No prerequisites — beginner friendly

The Problem: Building Without Understanding

⚡ Beginner ⏱ ~3 min

Imagine a student walks into your classroom. They've built a fake news detector. It works. Clean interface. Quick demo. Done in a few hours.

Then you ask one question: "How does it decide what's fake?"

Silence.

💡 The Core Issue

The student built a tool that produces a number. But the tool has no idea what truth is. It has the shape of a solution without any of the substance.

Student

I built a fake news detector! It uses a news API and an LLM. Text goes in, score comes out.

Instructor

That's impressive. Walk me through what happens inside. How does it decide the score?

Student

... The LLM handles it.

The silence that follows isn't about not knowing. It's about realizing the foundation was never examined.

This scenario isn't isolated. It's becoming the norm. Students can use tools. Very few can think in algorithms. Even fewer understand the domain their tools are entering.

Algorithmic Thinking Before Typing

⚡ Intermediate ⏱ ~4 min

The first skill every ML engineer needs isn't coding. It's thinking before typing.

When students start a project, they hit a wall immediately. Not a code wall. A clarity wall. They can't answer:

What exactly are we solving?
What are the steps, in order?
What does "done" actually look like?

⚠️ Common Pitfall

An idea in your head is not an algorithm. An algorithm is an idea decomposed — broken into logical, executable units.

Key Concepts

Click each card to flip and reveal the definition:

Algorithmic Thinking

Tap to flip

The ability to break down a problem into clear, logical, sequential steps that can be executed — whether by a human or a machine.

1 / 3

From Thinking to Code

Here's what algorithmic thinking looks like in practice — decomposing a campus path analysis problem:

python

def analyze_campus_path(student_location, destination):
    # Step 1: Get all possible routes
    routes = get_available_paths(student_location, destination)
    
    # Step 2: Filter by time-based restrictions
    # Some paths are exit-only during peak hours
    allowed_routes = []
    for route in routes:
        if not is_restricted(route, current_time):
            allowed_routes.append(route)
    
    # Step 3: Calculate optimal path
    best_route = find_shortest_path(allowed_routes)
    
    return best_route

Output

Best route: Gate A → Library → Science Block → Gate C
Estimated time: 8 minutes
Restrictions avoided: Exit-only path (9-11 AM)

⚡ Advanced ⏱ ~5 min

Every technical project sits on top of what I call the domain layer. Most students never touch it. Some never know it exists.

The domain layer is the layer of human understanding that must exist before the system can be designed.

Examples Across Projects

Domain Layer: Knowing how students actually move — not how the map says they should. Understanding which paths flood after rain. Which shortcuts are informal but heavily used. What "exit-only between 9–11 AM" means in practice.

Without it: Your app suggests routes that don't exist or are blocked. The data is technically correct but practically useless.

Domain Layer: Knowing what psychological care actually requires — its frameworks (CBT, ACT), its ethics, its vocabulary, its limits. Understanding the difference between psychoeducational and clinical interventions. Knowing the names of people who spent their lives studying human psychology.

Without it: You build an expensive mirror — something that feels like therapy but is just reflecting the user's words back with a calming color palette.

Domain Layer: Understanding how arguments are constructed. Knowing when a claim is stated without evidence. When evidence is selectively chosen. When a headline contradicts the body. When correlation is dressed up as causation. These are logic concepts — ancient ones.

Without it: You have a score, not understanding. A fake fake-news detector — something that detects the presence of news, assigns it a number, and calls the number meaning.

How Domain Knowledge Flows Through a Project

🧠

Domain Expert

📋

Requirements

💻

ML Engineer

🤖

Model

Domain Knowledge

1 Domain Expert provides context: "Students avoid Path B after rain due to flooding"

2 Requirements encode this as: "Path B has time-based and weather-based restrictions"

3 ML Engineer implements: is_restricted(path, weather, time) function

4 Model learns: Path B should be excluded from recommendations during rain

💡 The Critical Insight

Before you design the system, study the world the system will enter. Know its history. Know its failures. Know the names of the people who spent their lives trying to understand it before you arrived with a framework and an API key.

Context Must Be Designed

⚡ Intermediate ⏱ ~4 min

Here's something no textbook tells you: Your Python program doesn't understand your university.

When students built the campus path analysis app, they assumed feeding in GPS coordinates was enough. It wasn't.

The program had no idea that Path B floods after rain
That shortcut is exit-only between 9–11 AM
That Building C has no ground-floor access

Context is not in the data. Context is designed by the engineer.

python

# Without context — just coordinates
path = {"start": (28.6139, 77.2090), "end": (28.6129, 77.2070)}

# With context — engineered understanding
path = {
    "start": (28.6139, 77.2090),
    "end": (28.6129, 77.2070),
    "restrictions": [
        {"type": "time", "path": "B", "hours": "9-11", "direction": "exit-only"},
        {"type": "weather", "path": "B", "condition": "rain", "action": "floods"},
        {"type": "access", "building": "C", "floor": "ground", "available": False}
    ]
}

Output

Without context: Suggests Path B (technically shortest)
With context: Suggests Path A (actually usable)

This is one of the hardest lessons in applied ML — and one of the most important. Your job isn't just to collect data. It's to make the data mean something.

What the LLM Cannot Give

⚡ Advanced ⏱ ~5 min

Trainers are now being evaluated against AI. Not officially. But in the minds of students who can open a browser, describe a project, and have a working prototype in the same afternoon.

The question they're quietly asking: "What does this person give me that the tool does not?"

Student

I can build this with an LLM in a few hours. Why do I need days of foundational learning?

Instructor

Because the LLM can generate an idea. It cannot tell you whether the idea is worth pursuing.

Student

But it built the whole app...

Instructor

It built something that runs. It cannot build judgment. And judgment is what makes the difference between an app that runs and a solution that works.

💡 The Answer

The answer cannot be speed. We lost that. The answer cannot be syntax, or framework knowledge. We are losing that too.

What remains is the capacity to teach someone to think about a problem before they build for it.

An LLM can scaffold an application. It cannot tell you what the application will do to a real person who uses it. An LLM can produce a number. It cannot produce judgment.

And judgment — the capacity to reason carefully about a hard problem, to hold a claim up to the light and ask whether it is true and by what standard — is a human capability.

Test Your Understanding

⚡ Intermediate ⏱ ~5 min

1. A student builds a fake news detector that assigns a credibility score to articles. What's the most critical missing piece?

2. What does "algorithmic thinking" mean in the context of ML education?

3. You're building a campus path analysis app. What does the "domain layer" include?

4. Why can't an LLM replace the domain layer?

5. What is the trainer's role in the age of AI-assisted development?

0 / 5

Keep practicing!

Key Takeaways

Technical skill ≠ Domain knowledge: You can build fast without understanding deep. The best solutions require both.
Algorithmic thinking precedes coding: The first skill is thinking before typing — decomposing problems into logical units.
Context must be designed: Your program doesn't understand your world. You must engineer context into the data.
The domain layer is non-negotiable: Before designing the system, study the world the system will enter.
LLMs can't provide judgment: They can build what you describe, but can't tell you whether it's worth building. That's the trainer's role.