Series note: This is not a daily or weekly build log. I will publish an update when the project reaches a meaningful milestone, produces something measurable, or teaches me something worth sharing.

In short: The first article was about why I decided to turn my portfolio into an AI product. This one is about the less glamorous work that now makes that idea real: Sanity as the content source, FastAPI and PostgreSQL as the operational backbone, deterministic chunking and embeddings, Qdrant retrieval, and a test set that checks whether the system can find the right source instead of confidently improvising.

The blueprint has started turning into a machine

In Part 1, I wrote that the portfolio was still more blueprint than machine.

That is no longer completely true.

There is still no polished “Talk to Mahad” assistant generating answers in my voice. The ML query router is not trained yet. LangGraph is not orchestrating anything yet. Voice is still a later phase.

But the layer underneath those features now exists.

The portfolio has a managed content system. It has a FastAPI backend. It has an operational PostgreSQL schema. It can extract approved content from Sanity, normalize it, split it into traceable chunks, generate multilingual embeddings, store the canonical records in PostgreSQL, index vectors in Qdrant, retrieve candidates, hydrate the full source text, and evaluate whether the correct document appeared.

That is a long way of saying: it can now build and search a real knowledge base.

And honestly, this part has been more interesting than adding a chat box would have been.

First, I had to decide what “the truth” means

The portfolio uses three different storage systems, which sounds excessive until each one has a clear job.

Sanity is the authoring source of truth. It is where I manage projects, case studies, articles, experience, education, skills, FAQs, architecture decisions, personal stories and examples of how I write. The website reads its public content from there, and the RAG ingestion pipeline starts there too.

Neon PostgreSQL is the operational source of truth. It stores normalized source documents, chunk manifests, versions, hashes, ingestion runs and the relationships needed to verify what was indexed. Later it will also support consented chat sessions, redacted messages, retrieval events, feedback and model-release metadata.

Qdrant is the rebuildable vector index. It is optimized for similarity search, not for owning the canonical copy of my content.

That distinction matters.

If Qdrant disappeared tomorrow, the system should be able to recreate it from the approved Sanity content and the PostgreSQL manifest. Losing a search index should be annoying, not existential.

The relationship looks like this:

1. I publish approved content in Sanity.

2. The ingestion pipeline extracts and normalizes it.

3. PostgreSQL records the canonical document, chunks, hashes and embedding metadata.

4. Qdrant stores the vectors and compact filtering metadata, linked by the PostgreSQL chunk UUID.

5. Retrieval searches Qdrant first, then loads the authoritative chunk content from PostgreSQL.

This is one of those architectural choices that is invisible in a demo, but very visible the moment something fails.

Sanity is not just feeding the website

I originally wanted a headless CMS because I needed an easy way to keep adding projects and articles without editing code every time.

Once RAG entered the picture, the CMS needed to do more than store page copy.

Every indexable document now carries metadata such as:

• whether RAG indexing is enabled;

• which audiences it is relevant to;

• whether it is public or restricted;

• the human-readable citation label;

• its canonical website path;

• the date it was last reviewed;

• and whether it is published, in draft, or archived.

This gives content governance a place in the architecture before the LLM ever sees a prompt.

For example, INDKOM can appear on the website while remaining excluded from RAG if I do not want the assistant retrieving it. Draft or restricted material should not quietly enter the public knowledge base just because it exists in the CMS.

It also keeps the frontend and the assistant from developing separate versions of my story. A project description should not say one thing on the website while the chatbot cites an old Markdown file stored somewhere else.

One approved source. Different consumers.

Then came the backend plumbing

The FastAPI service now has the kind of foundation that is easy to skip when building an AI demo:

• typed settings through Pydantic;

• structured JSON logs and correlation IDs;

• liveness, readiness and version endpoints;

• an explicit CORS allowlist;

• request-size limits;

• stable error responses;

• provider interfaces and test doubles;

• and an OpenAPI artifact checked in CI.

The database layer uses async SQLAlchemy and Alembic migrations. Route handlers do not directly reach into ORM models. Repositories and services own those boundaries.

None of this makes an LLM answer sound smarter. It does make the system easier to test, replace and debug.

The project also runs migrations against a non-production Neon branch and tests that a clean database can be created from the migration history. I wanted the database schema to be reproducible, not something that only exists because my local environment accumulated tables over time.

This was the point where the portfolio stopped feeling like a frontend with an ambitious architecture diagram.

Building the ingestion pipeline properly

The ingestion pipeline is offline and deterministic. That is intentional.

I do not need an LLM to rewrite my portfolio content before indexing it. I need predictable transformations that I can inspect and repeat.

The current pipeline:

1. Fetches approved documents from Sanity.

2. Resolves their referenced content.

3. Converts Portable Text into structured normalized text.

4. Preserves headings, lists, captions, code and canonical paths.

5. Normalizes whitespace and Unicode without damaging Urdu text.

6. Computes a SHA-256 hash for the source document.

7. Splits it using a heading-aware recursive chunker.

8. Computes deterministic chunk hashes and ordering.

9. Generates embeddings in batches.

10. Writes the document and chunk manifest to PostgreSQL.

11. Skips unchanged content on the next run.

The chunks target roughly 350 to 500 tokens with 50 to 75 tokens of overlap. A chunk retains the project identity and heading path it came from. The chunker also tries to keep a list introduction attached to its list, and it never combines content from two projects into one chunk.

Those details sound small until a retrieved passage begins halfway through a list, loses the name of the project it describes, or merges two unrelated case studies into one confusing piece of context.

Chunking is not just “split every N characters.” It is a set of information-design decisions applied to text.

That part felt surprisingly familiar coming from product design and UI/UX. Good interface structure helps a person understand context. Good chunk structure helps a retrieval system preserve it.

Why Multilingual E5?

The embedding model is intfloat/multilingual-e5-small, with the model and tokenizer versions pinned.

The multilingual requirement is not decorative. I naturally switch between English and Roman Urdu, and visitors from Pakistan may do the same. A query such as:

CardioScan mein stress aur rest images kaise use hoti hain?

should still retrieve the relevant English project content.

The implementation follows E5's expected query: and passage: prefixes and stores normalized vectors. More importantly, the same embedding model and version are used at indexing time and query time. If those drift apart, similarity scores stop meaning what we think they mean.

I chose the small model because the system is designed around strict free-tier and CPU constraints. The goal is not to select the largest embedding model I can name. The goal is to establish a measured baseline that fits the actual deployment environment.

If a larger model later produces a worthwhile improvement, I can test that claim. Until then, smaller and reproducible wins.

Qdrant finds candidates. PostgreSQL verifies them.

Retrieval uses a two-stage pattern.

First, the query is embedded and Qdrant searches for the top 12 vector candidates. Metadata filters can narrow the search by document type, project, audience, language or active version.

Then the service takes the returned point IDs and hydrates the canonical chunks from PostgreSQL.

At that stage it rejects records that are inactive, missing, or tied to the wrong embedding version. It deduplicates adjacent or near-identical chunks and selects up to five chunks within a configurable context budget.

This separation keeps the Qdrant payload compact. It only needs enough metadata for filtering and debugging, including a short preview. The complete source content stays in PostgreSQL.

It also prevents the system from treating a vector hit as unquestionable truth. Qdrant answers, “these points look similar.” PostgreSQL answers, “these are the active canonical records they refer to.”

Both answers are needed before context goes anywhere near an LLM.

I accidentally designed a benchmark for a portfolio that did not exist

The most useful lesson in this phase came from the retrieval evaluation dataset.

The first draft contained questions about projects, capabilities and metrics that were not actually present in my approved portfolio content. Some facts were assumed. Some projects were not published. Some questions described CardioScan as ECG analysis when it actually works with myocardial perfusion images.

The JSON looked professional. It was also testing fiction.

That is a dangerous failure mode because an evaluation pipeline can produce very respectable numbers while measuring the wrong thing.

So I rebuilt the dataset around the content that is genuinely published and RAG-enabled.

The current benchmark contains 60 queries:

• 50 in-domain questions;

• 10 out-of-domain or refusal cases;

• 43 English queries;

• 17 natural Roman Urdu queries;

• coverage across the portfolio itself, CardioScan AI, Busyfile, Legal AI and the first article in this series.

It includes straightforward questions, technical questions, limitations, implementation status, product decisions, privacy requests and prompt-injection attempts.

The evaluation script measures Hit@1, Hit@3, Hit@5 and mean reciprocal rank across several similarity thresholds. For out-of-domain questions, it also measures whether the retriever correctly returns no citations instead of attaching an unrelated project to a question about weather, recipes or private information.

This is not yet an evaluation of final answer quality. There is no LangGraph answer-generation path at this stage. It is specifically a retrieval benchmark: did the correct source appear, how high did it rank, and did irrelevant questions stay out?

That narrower claim is important.

Rebuildability is part of the feature

Qdrant's free cluster can be suspended or deleted. Instead of pretending that cannot happen, the project treats recovery as a normal operating scenario.

There is a guarded full-rebuild command, explicit confirmation flags, batch upserts and deletion retries. The local/test collection was deliberately removed and rebuilt to verify that PostgreSQL and the ingestion pipeline could restore it.

There is also a retrieval inspector CLI that shows a query, filters, ranks and sources. That gives me a way to debug retrieval directly instead of blaming “the AI” when the wrong chunk appears.

This is becoming a recurring theme in the project: if I cannot inspect it, reproduce it or recover it, I do not want to call it production-oriented.

What exists today

As of this update, the following phases are complete and gated:

• the product scope, personas, success criteria and architecture decisions;

• the Next.js portfolio foundation and quality checks;

• the Sanity Studio schemas and live CMS integration;

• the FastAPI and Neon PostgreSQL operational foundation;

• deterministic extraction, normalization, chunking and embedding;

• Qdrant indexing, two-stage retrieval and PostgreSQL hydration;

• the 60-query retrieval benchmark, threshold evaluation and index-recovery path.

The public interface is intentionally plain: white, near-black, neutral grays, Plus Jakarta Sans and a lot of breathing room. I am not trying to distract from incomplete engineering with animation.

The repository currently contains the working knowledge layer, but not the finished conversational product.

What comes next

The next milestone is the automated CMS-to-index lifecycle.

Right now, the ingestion pipeline works, but a published Sanity change still needs a robust incremental path. The next phase will handle create, update, unpublish and delete events; preserve the previous active version when a run fails; reconcile differences across Sanity, PostgreSQL and Qdrant; and trigger targeted ingestion through a signed webhook and CI workflow.

After that comes the in-process ML query router:

• a reviewed label system;

• English and Roman Urdu training examples;

• group-aware dataset splits to reduce leakage;

• a TF-IDF plus Logistic Regression baseline;

• MLflow experiment tracking and error analysis;

• later comparison with a compact transformer;

• and ONNX export only if the candidate earns promotion.

Then LangGraph can sit on top of a retrieval system and router that have already been tested independently.

That order matters to me. I do not want an agent graph hiding weak retrieval behind a fluent answer. I want each layer to prove that it works before the next layer makes the system more complicated.

The main thing I learned

The first article was about a big idea: make the portfolio itself demonstrate the work.

This phase was about accepting what that idea actually requires.

RAG is not a vector database plus an LLM call. It is content ownership, access rules, normalization, chunk boundaries, versioned embeddings, canonical records, filtering, hydration, evaluation, recovery and honest limits. The generated answer is almost the last part.

That is probably why I am enjoying this build so much. It combines the system thinking I developed in product design and UI/UX with the engineering discipline I am now building in AI systems.

The portfolio still cannot talk like me.

But it can finally find the right things to talk about.

That feels like the correct place to end Part 2.

Repository: mahadbaig2/mahad-ai-portfolio

Most portfolios are wrappers around the work.

You build a few projects, take some screenshots, write case studies, add an About page, and put everything inside a polished website. The portfolio points toward the interesting things, but the portfolio itself is usually not one of them.

I wanted to try something different.

Instead of building a website that says I understand AI products, I am building a website that has to prove it.

The final portfolio will have a conversational assistant that knows my work, retrieves evidence from my actual content, explains why it chose an answer, and eventually speaks in something close to my own conversational style. Behind that relatively simple interface will be a complete RAG pipeline, a trained query-routing model, LangGraph orchestration, evaluation, observability, voice input and output, and a content system I can keep updating without rebuilding everything.

It is intentionally over-engineered (very much).

That sentence normally sounds like a confession. In this project, it is the point.

This is the first entry in an update-based build series. I am not committing to a daily streak or manufacturing a weekly update when nothing meaningful has happened. I will write when a phase produces something worth explaining: a decision, an experiment, a failure, a benchmark, or a working piece of the system.

How I got here

My route into AI engineering has not been linear.

I spent nearly six years working in product design and UI/UX, much of it on enterprise SaaS products. I worked across discovery, user flows, information architecture, design systems, complex dashboards, implementation handoff, and the less glamorous parts of product work that appear after a clean Figma prototype meets an actual business.

One of the most formative projects was Busyfile. I joined as its founding product designer and worked on a system that evolved from a consumer business-formation product into a larger B2B platform for accounting firms. The work eventually covered hundreds of screens, different entity types, state-specific flows, operations tooling, and more than twenty services.

That kind of project teaches you a useful lesson: the interface is never the entire product.

Every apparently simple screen is connected to rules, data, permissions, failure states, operational processes, and people who need the system to behave consistently. I kept finding myself interested in those connections. I wanted to understand not only what the product should do, but how it could actually do it.

That curiosity gradually moved me closer to engineering.

At Techomatrix, I worked on AI automation workflows and LLM-powered features using tools such as Python, n8n, Groq, databases, APIs, prompt workflows, and internal knowledge systems. I also started building and experimenting independently with RAG, agents, LangGraph, FastAPI, vector databases, ML and deep learning.

My final-year project, CardioScan AI, pulled me further into applied machine learning. We worked with rest and stress myocardial perfusion imaging, trained CNN architectures including VGG16, DenseNet121 and ResNet50V2, and explored an ensemble for coronary artery disease classification. The results were not magically perfect, which was useful in its own way. Working with limited medical data makes it very difficult to pretend that model selection is just importing a larger architecture and waiting for accuracy to happen.

Other projects pushed me toward agentic and retrieval-based systems: enterprise knowledge assistants, evidence-grounded question answering, workflow automations, and AQL, an enterprise AI workspace concept built around permission-aware knowledge and cross-tool actions.

Somewhere in that transition, “product designer learning AI” stopped describing what I was trying to become.

The direction that makes more sense to me is AI Product Engineering: understanding the user and product problem, designing the interaction, building the AI system, measuring whether it works, and dealing with the operational reality after the demo.

I am still learning large parts of that stack. This portfolio is how I plan to make that learning concrete and inspectable.

The original problem with my portfolio

I already had projects. I already had design case studies. I could have made a conventional portfolio, added a chatbot powered by a large prompt, and called it AI-enabled.

But that would demonstrate very little.

Anyone can send a résumé and a question to an LLM API. The difficult parts begin after that:

• How does the system know which information is trustworthy?

• What happens when the answer is not present in the source material?

• How is content updated without manually rebuilding prompts?

• How are documents divided without destroying their meaning?

• How do PostgreSQL and a vector database divide responsibilities?

• How do I measure retrieval quality instead of saying it “looks good”?

• Which questions need retrieval, an agent, a deterministic response, or no LLM at all?

• Can a smaller trained model save latency and inference calls?

• What happens when a free service is asleep, rate-limited, or unavailable?

• Can someone inspect why the system produced a particular answer?

• Can the whole thing remain online without giving me a surprise bill?

Those questions became more interesting than the idea of the portfolio itself.

So the concept changed from a portfolio with an AI feature to an AI product that happens to be my portfolio.

The working centerpiece is called Talk to Mahad (Working name).

The visitor should eventually be able to ask questions such as:

What did Mahad actually do on Busyfile?

Which of his projects involved RAG?

Why did he move from product design into AI engineering?

Show me the architecture of this portfolio.

Explain the same answer for a recruiter instead of an engineer.

The system should answer using approved sources, show citations, expose useful execution details, and admit when the available material does not contain an answer.

That last behavior matters. “I do not have enough evidence to answer that” is a product feature, not a failure.

What the finished system is supposed to demonstrate

The project is split into layers because I want every technical choice to demonstrate a specific production concern.

1. A real content layer

Projects, case studies, articles, experience, FAQs, personal stories, architecture decisions, and carefully selected writing examples will live in Sanity.

Sanity will be the authoring source of truth. I should be able to publish or update a project from the CMS without changing application code.

Not every field will automatically become AI knowledge. Content will include publishing, sensitivity, audience, review, and RAG eligibility metadata. A public page and an assistant knowledge base have overlapping requirements, but they are not exactly the same thing.

2. A complete offline RAG ingestion pipeline

The RAG system will not embed random page text during a user request.

An offline pipeline will:

1. Extract approved documents from Sanity.

2. Normalize Portable Text while preserving headings, lists, code and source paths.

3. Generate deterministic document hashes.

4. Split documents using heading-aware recursive chunking.

5. Attach project, audience, language and source metadata to every chunk.

6. Generate multilingual embeddings.

7. Store canonical documents and chunk manifests in PostgreSQL.

8. Store searchable vectors and compact metadata in Qdrant.

9. Skip unchanged content on later runs.

10. Support deletion, re-indexing and full index reconstruction.

The current embedding candidate is intfloat/multilingual-e5-small, partly because the assistant needs to handle English, Urdu and Roman Urdu content without introducing a large hosted embedding bill.

The initial chunking target is roughly 350 to 500 tokens with controlled overlap. That is a starting hypothesis, not a sacred number. Retrieval evaluation will decide whether it survives.

3. PostgreSQL and Qdrant doing different jobs

I do not want the vector database to become a mysterious second source of truth.

Neon PostgreSQL will hold operational and canonical records: source documents, chunk text, hashes, versions, ingestion runs, model releases, consented sessions, retrieval events and feedback.

Qdrant will hold the derived vector index used for similarity search.

The relationship is simple: a Qdrant point ID maps back to a PostgreSQL chunk ID. Retrieval finds candidates in Qdrant, then the API hydrates and validates the canonical chunk from PostgreSQL. If the vector collection disappears, it should be rebuildable from known source content and manifests.

That separation adds work, but it demonstrates the difference between durable product data and a disposable search index.

4. A small ML model before the large language model

One of my favorite planned parts is a custom query router.

Before calling an LLM, the system will classify what kind of request it received. Possible routes include portfolio retrieval, navigation, casual conversation, unsafe or irrelevant input, and questions that require clarification.

The plan is to start embarrassingly simple with rules and a TF-IDF baseline. (Claude recommended TF-IDF but maybe I'll use Logistic Regression as a baseline). Then I can train a compact transformer classifier, compare it against the baseline, track experiments in MLflow, export the chosen model to ONNX, and run it inside the FastAPI process.

The point is not to add machine learning because the architecture diagram had empty space.

The hypothesis is that a cheap local classifier can avoid unnecessary LLM calls, reduce latency, create more deterministic routing, and provide a proper ML lifecycle to evaluate. If the baseline performs just as well, that is also a valid result. A complicated model does not win by being complicated.

5. Agentic orchestration with boundaries

LangGraph will coordinate the request workflow.

A typical grounded question may move through classification, retrieval, context validation, answer generation, citation checking, and a limited recovery path. The graph will use typed state and explicit conditional edges so the flow is inspectable.

This will not be a collection of agents talking to each other until something sounds plausible.

Some steps should be deterministic. Some should use tools. Some should call an LLM. Some requests should stop early. “Agentic” only becomes useful when the autonomy is connected to a clear job and bounded by observable state.

6. Two separate observability stories

MLflow will track the traditional ML lifecycle: datasets, features, training runs, hyperparameters, classification metrics, artifacts, ONNX exports and model versions.

LangSmith will cover the LLM and agent workflow: traces, prompts, retrieval context, tool calls, latency, evaluation datasets and regression checks.

I deliberately want both because MLOps and LLMOps overlap, but they are not interchangeable.

7. Voice that is more than a microphone button

The voice layer will begin with push-to-talk.

Audio will be transcribed using Groq Whisper, passed through the same assistant graph as typed input, and returned with a visible transcript. Voice output will remain an isolated service so a failure in speech synthesis does not take down chat.

The experimental plan includes OpenVoice V2 for personalized speech. I will only use recordings for which I have explicit rights and consent. The assistant should also disclose that the voice is synthetic.

The goal is not to trick anyone into believing they are speaking to me. It is to explore a personalized, bilingual voice experience, including the English and Urdu code-switching that appears naturally in how I speak.

8. A zero-surprise-bill constraint

The permanent system is being designed around free or hard-capped services.

That constraint affects architecture. It means quotas, timeouts, retries, circuit breakers, caching, graceful degradation, service sleep behavior, and fallbacks cannot be postponed until after deployment.

If AI capacity is unavailable, the portfolio must still work as a portfolio. If voice fails, text chat should survive. If chat fails, the case studies should remain accessible. Complexity is acceptable here; fragility is not.

What exists today

Right now, the repository contains the foundation, not the finished AI system.

The project lives at github.com/mahadbaig2/mahad-ai-portfolio.

So far I have:

• Defined and scope-locked the first version.

• Written the target personas and measurable product success criteria.

• Created a milestone-based TASKS.md that separates automated work from tasks requiring my review.

• Added architecture decision records for the CMS, relational database, vector index, API deployment, ML router, observability, voice isolation and streaming approach.

• Scaffolded a pnpm monorepo for the web app, Sanity Studio, FastAPI service, voice service, shared packages and offline pipelines.

• Built the first Next.js portfolio pages using strict TypeScript and Tailwind CSS.

• Established the intentionally plain visual direction: white, near-black, neutral gray, Plus Jakarta Sans and a lot of breathing room.

• Added the initial Home, Work, case-study, Blog, About and Contact structures.

• Added unit-test, Playwright, accessibility and Lighthouse foundations.

• Added dependency automation and secret scanning.

• Documented local PostgreSQL and Qdrant development services through Docker Compose.

• Created a free-tier audit runbook because “free tier” and “impossible to bill” are not the same promise.

The current repository is also in a useful, slightly uncomfortable stage: the first frontend implementation exists, but the Phase 1 quality gate is not approved yet.

During review, I found missing or unfinished connections, including a shared data module, a chat route that is linked before the interface exists, placeholder contact details, and a résumé asset that still needs to be added. The validation pipeline also needs to prove linting, type checking, tests and the production build before I call the phase complete.

This is exactly why I added gates to the build plan.

A checked task list is not evidence that the software works. The repository has to pass, and I have to manually approve the content and experience assigned to me. Until that happens, Phase 1 remains open.

Why the interface is deliberately boring right now

I have a product design background, so it would be very easy for me to spend the first month polishing cards, transitions and a heroic hero section.

I am refusing to do that.

For now, the UI is black, white and neutral gray. There are no accent colors, dramatic gradients, glass panels or decorative AI particles floating behind the heading. The layout is minimal, breathable and easy to scan.

That is partly a design preference and partly scope control.

The first job of the interface is to make the content usable and the system states understandable. It needs accessible navigation, visible citations, readable transcripts, honest loading and failure states, and progressive disclosure for people who want to inspect the engineering details.

There will be time to refine the visual identity later. A beautiful shell around an unreliable assistant is not the portfolio piece I want to build.

How I am building it without pretending I know everything

This project is also a learning system for me.

Each phase introduces a limited set of concepts. I learn them, implement them, test them, document what happened, and only then move forward. The roadmap starts with the conventional portfolio, then adds managed content, the API and relational model, offline ingestion, vector retrieval, the ML router, LangGraph, evaluation, chat, voice, deployment and operations.

The order matters.

It is difficult to evaluate retrieval before defining good source documents. It is difficult to build reliable agents before the underlying tools behave deterministically. It is difficult to claim MLOps knowledge if there is no dataset lineage or reproducible training run. And it is difficult to debug a voice assistant if text chat is not stable.

I am using Antigravity to help execute the build, but not as an excuse to remove myself from it. The task system assigns implementation work to the agent and reserves factual approval, credentials, content decisions, voice consent, evaluation judgments and milestone gates for me.

The objective is not to see how much code an agent can produce while I watch. The objective is to use an agentic coding workflow while remaining accountable for the architecture, learning, review and final product.

What comes next

The immediate next step is not LangGraph, voice cloning or an impressive chat demo.

First, I need to close the frontend foundation properly:

• Repair the current build blockers.

• Replace placeholder personal information.

• Remove or label claims about features that are not implemented yet.

• Add complete CI checks.

• Review the site on desktop and mobile.

• Approve the Phase 1 gate manually.

After that, Phase 2 is the Sanity CMS.

I will define schemas for projects, case studies, articles, experience, education, skills, FAQs, architecture decisions, personal stories, style examples and site-wide settings. I will add explicit controls for which content can enter the RAG pipeline, connect the Next.js pages to typed GROQ queries, and verify that a CMS edit can update the public site without a code deployment.

That phase should produce the next article in this series because it raises an interesting product question:

How do you design one content system for human readers, portfolio pages, and an AI knowledge base without letting those responsibilities collapse into each other?

Once the content foundation is reliable, I can begin the API and data model. Then the RAG pipeline becomes real rather than theoretical.

The broader experiment

I am building this because I need a portfolio, but I am also using it to answer a larger question about my own career.

Can the habits I developed in product design - understanding context, reducing friction, structuring information, handling edge cases, and thinking from the user's perspective - make me better at engineering AI products?

I think they can.

AI systems have enough technical uncertainty already. They do not also need vague goals, confusing interfaces, invisible failure states and features added because they sound impressive.

At the same time, product thinking without technical depth reaches a limit. If I want to make meaningful decisions about retrieval, latency, model behavior, evaluation, architecture and cost, I need to understand and build those systems myself.

This portfolio is where those two sides meet.

It is currently more blueprint than machine. That will change one verified milestone at a time.

If you want to inspect the work as it develops, the repository is public:

mahadbaig2/mahad-ai-portfolio

The next update will come when there is something real to show, measure, or break.