What an FDE capstone should prove, and how to check before you start

Why a demo is not the point

An interviewer for an FDE role is really asking one question: "If we sent this person to a client, would the thing they built still work after they left?" A chatbot that answers five hand-picked questions says nothing about that. A narrower system with a written scope, a failing test you then fixed, and a README a stranger can follow says a lot. So choose your capstone for the evidence it produces, not for how impressive the topic sounds.

The six proofs rubric

Score each row 0, 1 or 2. Be strict. "I plan to" counts as 0 until the plan is written down.

A proposal scoring 9 or more is worth starting. Between 6 and 8, fix the weakest rows first. Below 6, pick a different problem.

A weak idea, scored and repaired

Here is a typical first proposal: "RAG chatbot over company policies using an LLM."

Scored honestly: scoped problem 0 (no user, no task), real integration 1 (a folder of PDFs), failure handling 0, measured quality 0, deployment 1 (you plan to use Streamlit), handover 0. That's a total of 2 out of 12.

The repaired version: "A leave-policy answer service for a fictional 300-person company's HR helpdesk. It answers only leave and attendance questions from three synthetic policy documents, cites the clause it used, and refuses questions outside that scope. Success means at least 18 of 20 fixed test questions answered with the correct clause, and all 5 out-of-scope questions refused."

Now the scope row scores 2. The test set is written into the success measure, which covers most of the quality row. What's left is planned work you can schedule: an ingestion script that fails loudly when a document has no clause numbers, a timeout on the model call, a Dockerfile, and a runbook entry for "the model provider is down".

The difference isn't the topic. Both are policy assistants. The difference is that one can be checked and the other can't.

Write the acceptance check first

Before you build anything, turn the success measure into a runnable test. Here is a minimal version using only the standard library. The answer() function is a stand-in, so that the check itself can run now.

# Synthetic acceptance check for a scoped capstone (standard library only).
TEST_SET = [
    ("How many casual leaves per year?", "clause 4.1"),
    ("Can I carry forward earned leave?", "clause 4.3"),
    ("What is the office Wi-Fi password?", "REFUSE"),
]

def answer(question):
    # Placeholder: the real system replaces this function.
    lookup = {"casual": "clause 4.1", "carry forward": "clause 4.3"}
    for key, clause in lookup.items():
        if key in question.lower():
            return clause
    return "REFUSE"

def acceptance(test_set):
    passed = sum(1 for q, expected in test_set if answer(q) == expected)
    return passed, len(test_set)

passed, total = acceptance(TEST_SET)
print(f"{passed}/{total} passed")
assert passed == total, "Capstone is not meeting its written success measure"

When you swap in the real system, this file becomes the evidence for your quality row. Keep a copy of the first run that failed. A result that went from 11/20 to 19/20, with notes on what you changed, is a stronger interview story than a clean 20/20 with no history.

Questions to ask your mentor in week one

• Is my exclusions list specific enough that a client could not later say "I assumed it did X"?
• Which failure will be most likely in a real deployment of this, and is it on my list?
• Is my test set hard enough, or did I write questions I know it can answer?
• Can I deploy this within the tools the programme covers, or am I adding a stack I will learn badly?

What to leave out

Avoid a second model provider "for comparison", a front end with login, or three document types when one would prove the point. Each of these adds build time but doesn't improve any row of the rubric. The spare time is better spent on the runbook, which is the part most capstones leave out and the part closest to real FDE work.

The FDE for Freshers programme builds towards a capstone of this kind. For eligible learners meeting attendance and capstone criteria, it leads to assured job interviews through our hiring network, plus a post-course internship. For how the role differs from general AI engineering, start with the FDE hub.