Start With the Content: Building Ask Eric, Part 2

This is the second post in a series about building Ask Eric, an AI-assisted way to explore the writing on this blog.

The first Ask Eric phase ended with a content baseline and a move to .NET. Neither milestone produced a chat response. That was intentional. Before I could ask an AI to answer from this blog, I needed confidence that the application understood the blog itself.

The phase had three goals: define what published content means, capture a testable baseline, and move to the application stack I wanted to use for the rest of the project.

Define What the Application May Read

The application reads published posts from src/content/blog, plus an explicit allowlist of public pages. It did not crawl every Markdown file in the repository and assume it belonged in a reader-facing answer. It parsed YAML front matter, Markdown text, headings, dates, and canonical URLs without changing the source files.

The small details matter. Future-dated and unpublished posts are excluded. A missing explicit permalink fails instead of guessing a slug from the file name. Resolved paths must remain inside the posts directory, and linked directories are rejected. Markdown is content to parse, never instructions to execute.

Output of the sample ingestion command beside the Astro post it parsed, showing the source path, title, canonical URL, headings, and clean text

dotnet run --project src/BlogAsk.Ingestion -- sample src/content/blog/2026-09-02-where-ive-been-and-why-im-excited-about-ai.md
dotnet run --project src/BlogAsk.Ingestion -- inventory

Capture a Baseline Before Changing the Stack

The initial baseline recorded title, URL, date, headings, clean text, source path, and front-matter fields for all 14 eligible posts. The inventory had to return zero errors and zero unexpected exclusions. The blog has since moved to Astro; that migration repeated the parity and retrieval checks rather than treating a new site layout as proof that the content pipeline was still correct.

That gave me something better than “the parser seems fine on a sample post.” It gave the project a contract with the existing site. Every later change could be checked against the same captured corpus.

Change the Stack With Proof

The prototype began in Python. Before adding chunking or paid model calls, I moved the implementation to C#/.NET 10: a shared core library, a console ingestion application, and an xUnit test project. The move was not complete until every captured post matched the original output and the live inventory still matched the baseline.

I chose .NET because the eventual API and the ingestion workflow could share a language, configuration approach, and tests. More importantly, I made that change before building more features on top of the prototype.

Conclusion

The first phase established three things: a clear publication boundary, a verified content baseline, and a proven transition to .NET. None of it was flashy, but it made the later work safer.

In the next post, I will cover the ingestion phase: turning those verified documents into stable, traceable chunks for retrieval.

As always, keep learning and keep building.

Ask Eric about this post

Answers are AI-generated from Eric's published blog posts and may be incomplete. Check the cited posts for the original context.

Your question is sent to an AI service to write the answer. Please don't include personal information. How questions are handled

Questions are limited to 2,000 characters.