Build Your AI Portfolio

This post is where the day stops talking and starts shipping. The cover sets expectations clearly: this is code-heavy, and the snippets are meant to be copied and adapted. After three posts of principles, the reader has earned a concrete, runnable example of what a portfolio-grade piece actually contains.

The framing around three artifacts — model card, API, test plus CI — is deliberate. It tells the reader that 'a portfolio piece' is not vague; it's a specific, finite set of things you can produce this week. Naming them upfront turns an intimidating goal into a checklist.

The three-artifacts breakdown is the spine of the post. The model card proves you understand what your model does and where it fails — a maturity signal most beginners skip entirely. The serving API proves you can ship, not just train. The test and CI prove the thing stays working without you babysitting it. Together they cover capability, deployability, and reliability.

The reason to name exactly these three is that they map to the gaps reviewers most often find. Plenty of candidates can train a model; far fewer can document its limits, serve it behind a typed interface, and prove it keeps working. Producing all three on a single project instantly distinguishes you from the tutorial-follower who stops at a notebook cell.

The model card is the trust document, and this template shows what a credible one contains. Intended use scopes the model honestly. The data section names the source, size, and timeframe so reviewers can judge representativeness. Metrics report the right number against a baseline — PR-AUC for an imbalanced churn problem, not misleading raw accuracy. Limitations and ethical notes show maturity that no accuracy number can convey.

The limitations section is the part beginners omit and experts respect most. Stating that the model underperforms on new accounts and isn't validated outside its segment signals that you understand your model rather than just trained it. A reviewer reads that and concludes you'd be safe to trust with a real system, which is exactly the impression a portfolio exists to create.

This snippet captures the single most important serving pattern: load the model once, at startup, not on every request. The `joblib.load` call runs a single time when the process boots, and the resulting object is reused for every prediction. Loading per request would re-read the file and re-initialize the model each time — needlessly slow and a clear sign of someone who hasn't served a model before.

The Pydantic model alongside it does the second critical job: defining a typed, validated contract for inputs. The `Field(ge=0)` constraints mean malformed requests are rejected before they ever reach the model, returning a clear error instead of a cryptic crash deep in your prediction code. These two ideas — load once, validate at the door — are the foundation of competent model serving.

The prediction endpoint shows the actual inference path, and it's deliberately small because good serving code is small. The handler assembles the validated fields into the feature array the model expects, calls `predict_proba`, and returns a clean JSON response with both the probability and a boolean decision. The `float` and `round` calls ensure the output is JSON-serializable and readable.

The design choice to return both the raw probability and a thresholded decision reflects real-world serving needs: some consumers want the score, others want the call. Exposing both makes the API more useful without complicating it. The commented uvicorn line reminds the reader that this is a real, runnable service, not pseudocode — they can copy it and have a live endpoint in seconds.

This test is what elevates the project from 'works on my machine' to 'verifiably correct.' Using FastAPI's TestClient, it spins up the app in-process, sends a realistic request, and asserts both that the call succeeds and that the output is a valid probability between zero and one. It's a smoke test — not exhaustive, but enough to catch the breakages that matter.

The deeper signal a test sends is about professionalism. A reviewer who sees a test file concludes you think about correctness and regressions, not just getting a model to run once. The specific assertion on the probability range also demonstrates that you understand your output's contract. A single well-chosen test communicates engineering discipline far more efficiently than any claim on a resume.

The CI pipeline diagram shows what automation does for your portfolio: every push triggers an install, a test run, and a green-or-red verdict. The badge that results sits on your README as continuous, public proof that the project actually works right now, not just when you last touched it.

The value here is twofold. First, it catches your own regressions before a reviewer does, so a stranger never clones a broken main branch. Second, the green badge itself is a signal — it tells visitors, before they run anything, that you practice the same automated verification real teams use. That small green checkmark does a surprising amount of trust-building work.

This GitHub Actions workflow is the minimal, real configuration that produces the green badge. It triggers on pushes and pull requests, checks out the code, sets up a pinned Python version, installs dependencies, and runs pytest. There's nothing fancy here on purpose — a clean, minimal CI file is more impressive than an over-engineered one because it shows you know exactly what's needed.

Pinning the Python version with `python-version: "3.11"` is a small detail that signals reproducibility awareness. The whole file is short enough to understand at a glance, which is itself a quality signal. A reviewer who opens this sees that you've automated verification with the same tooling production teams use, reinforcing that your work is reliable rather than a one-time demo.

The repo-layout tree shows how the artifacts physically organize into a project a stranger can navigate. README and MODEL_CARD at the top are the two documents reviewers read first. app.py holds the serving code, train.py the training, tests/ the verification, and the workflows file the CI. The structure is conventional on purpose — reviewers can find what they expect where they expect it.

The clarity of the layout is itself part of the portfolio. A flat dump of twenty files signals disorganization; a clean, predictable structure signals that you think about maintainability. Separating training from serving, and isolating tests, mirrors how real production repos are arranged, so the layout quietly communicates that you've worked on or understand professional codebases.

The why-these-artifacts summary ties each piece back to the signal it sends, so the reader remembers the purpose and not just the code. The model card proves you understand limits. The typed API proves you can ship. The test and CI prove durability. One-command run proves verifiability. And together they say 'professional' rather than 'tutorial' — which is the entire goal of a portfolio piece.

The value of mapping artifacts to signals is that it keeps you from cargo-culting. You add a model card not because a checklist said to, but because it demonstrates maturity. You add CI not for its own sake, but to prove durability. Understanding the why behind each artifact is what lets you adapt the pattern to your own projects rather than copying it blindly.

The CTA closes the loop by pointing to the final post on mistakes. Having just seen what a strong piece looks like, the reader is perfectly primed to learn the failure modes that quietly sink portfolios — many of which are the inverse of what this post just demonstrated.

This hand-off completes the day's How-It-Works-then-Code-then-Mistakes progression. The teaser promises a list of avoidable failures, framing the last post as the protective layer: now that you know how to build a piece, here's how to keep yours from joining the silent pile of portfolios that get clicked and closed.