How to document, interpret, and present your machine learning project

Across more than 50 machine learning projects, I've seen the same pattern repeat itself: the model works, the metrics are solid, and yet the project generates no impact. Not because the model is bad — but because nobody outside the technical team understands what it means, how to use it, or why to trust it.

A study on arXiv on ML explainability for external stakeholders documents that the lack of a shared language between those who build models and those who use them is one of the main obstacles to ML systems being adopted in high-impact environments (Bhatt et al., 2020, arXiv 2007.05408). It's not a precision problem. It's a communication problem.

This article is the complete roadmap for what comes after training the model: how to interpret results for different audiences, how to write and defend the project, and how to turn it into a career asset. Each section of this roadmap has its own sub-pillar with full depth.

Table of contents:

• The problem nobody solves: the model works but nobody understands it
• Is your project stuck at this stage?
• The complete framework: three stages after training
• Signs that your project needs work in these three areas
• Reference projects in this framework
• Frequently asked questions

The problem nobody solves: the model works but nobody understands it

Most machine learning resources end when the model does. There are tutorials for preparing data, selecting algorithms, tuning hyperparameters, and evaluating metrics. But almost none of them answer the question that comes right after: so what do I do with this now?

Google explicitly states that ML project deliverables include design documents, experimental results, and production-ready implementations that other teams can understand and audit (Google Developers — ML Projects Stakeholders). That last requirement is precisely the one most often ignored.

I've seen this pattern in academic projects and in business projects alike. The technical team knows the model is good. But when it's time to explain it, defend it, or use it to get a job, the blockage appears — not because the work is bad, but because the audience was never considered.

Is your project stuck at this stage?

If you already have a trained model but don't know how to explain its results, how to structure the documentation, or how to present it in an interview or defense, I can review your project and give you a clear diagnosis of what's missing and in what order to address it.

No commitment. No sales pitch. Just clarity on the next concrete step.

I want you to review my project →

The complete framework: three stages after training the model

The documentation, interpretation, and presentation phase is not a single task. It's a three-stage system that must be worked through in order, because each stage depends on the one before it.

Stage 1: Interpret — what do your results actually mean?

The first problem isn't technical: it's one of translation. You have metrics — accuracy, F1, RMSE, AUC — but those metrics don't speak for themselves. What matters is what they mean for whoever is going to make decisions with the model. A ROC AUC of 0.85 can be excellent in one context and completely insufficient in another. The right interpretation depends on the audience, the domain, and the real cost of each type of error.

→ How to interpret and explain your ML model's results

Stage 2: Write and defend — how do you document and present the work?

Once you understand what your results mean, you need to structure them into a document or presentation that others can evaluate. This looks different for an academic thesis versus a business project, but there is a base structure that works in both contexts: problem statement, data decisions, model justification, results analysis, and honest limitations. The oral defense adds an additional layer: knowing how to answer questions you didn't expect.

→ How to write and defend your ML project or thesis

Stage 3: Grow professionally — how do you turn the project into a career?

A well-documented, well-presented project is also a career asset. Recruiters don't evaluate the code: they evaluate whether the candidate can talk about the project, explain the decisions they made, and connect the results to the business problem. Transforming a notebook or a thesis into a README that tells a story, an interview presentation, or a LinkedIn post that demonstrates authority — these are distinct skills with their own technique.

→ How to use your ML project to grow professionally

Signs that your project needs work in these three areas

These are the concrete situations that indicate the technical project is done but the communication isn't:

• Your advisor or committee asks you to "explain the results better" without telling you exactly how.
• You present the project and the first question from the audience is "what is this actually useful for in practice?"
• Your GitHub README has working code but no context about the problem it solves.
• You know the model works but couldn't defend it fluently in a 20-minute technical interview.
• You finished the thesis and don't know how to put it on your CV in a way that matters to a recruiter.
• You submitted the report and the client or stakeholder asked "what do we do with this number?" — the clearest sign that the results weren't translated.

Each of these signals corresponds to a specific stage of the framework. The first and sixth point to interpretation. The second and fourth, to writing and defense. The third and fifth, to professional growth.

Reference projects in this framework

The three communication problems this framework describes appear in real projects with very different characteristics. Some examples from my portfolio where these three blockers were central:

• Project #36 — Lab arbitrators: the classification model worked correctly, but the results had to be presented to a committee with zero technical knowledge. The challenge wasn't the model — it was translating the confusion matrix into concrete operational decisions the committee could approve.
• Project #41 — Domestic violence: the model's positive results had legal and ethical implications. Documenting the limitations correctly, in language a legal committee could evaluate, was more complex than building the model itself.
• Project #52 — Innovation: the academic project was well evaluated, but turning it into something presentable to employers required completely rewriting how the problem, the decisions, and the impact were described.

Frequently asked questions about documenting and presenting ML projects

Why bother documenting an ML project if it's already working?

A model that works but nobody understands generates no impact. Documentation allows other teams to audit it, enables non-technical stakeholders to make decisions with it, helps defend it in a thesis or interview, and turns it into a career asset. Google states that ML project deliverables include documentation that other teams can understand — not just a running model.

What is the difference between interpreting results and reporting them?

Reporting means presenting the numbers. Interpreting means explaining what those numbers mean for whoever makes decisions. A data scientist can report "ROC AUC of 0.85" without that telling a stakeholder anything useful. Interpreting means translating that metric into domain language: what decisions it enables, what errors the model makes, and what consequences those errors have in the real context.

How do you defend an ML project in front of a non-technical committee?

By avoiding jargon and connecting each result to a concrete decision or action. A non-technical audience doesn't need to understand the algorithm — they need to understand why the result matters for their goals. This means talking about impact: what problem it solves, how much better it is than the previous alternative, and what limitations exist that the committee should know in order to make informed decisions.

Do I need GitHub to get a job in data science?

For technical ML roles, yes — it's practically necessary. But what matters isn't the volume of repositories, it's the quality of how they're documented. A project with a README that clearly explains the problem, the decisions, and the results communicates more about a candidate's capabilities than twenty notebooks with no context.