I Built PGIS Recipes Because Food Systems Need Architecture

Last week I was looking at a stack of recipe slide decks and had the same reaction I have to too much useful clinical knowledge: this is good, but it is still trapped in the wrong container.

The recipes were already clear. The logic was already there. The PGIS framing was already there. But if the work only lives as scattered HTML exports in a local folder, it behaves like a private note pile, not a system.

That framing is wrong.

Food guidance usually fails at the architecture layer. We keep acting as if people need one more motivational sentence, one more macro chart, or one more generic post about healthy eating. Most of the time the problem is not inspiration. The problem is retrieval, structure, repetition, and context.

The Problem Was Never the Recipes

If a meal framework is worth teaching, it should be easy to browse, easy to revisit, and easy to extend. It should have a stable URL. It should live in version control. It should be simple enough to update without turning maintenance into a second project.

That is why I built PGIS Recipes.

The code lives here: github.com/chukwumaonyeije/pgis-recipes

The site is intentionally simple:

• static HTML, CSS, and JavaScript
• GitHub for storage and version control
• GitHub Pages for publishing
• Marp-exported recipe decks stored as durable library items
• a homepage that feels like a presentation archive, not a generic food blog

That last point matters more than it sounds.

I did not want a cheerful recipe-blog skin pasted on top of PGIS. I wanted the site to feel like the decks themselves: restrained, readable, slightly academic, and built for people who think in systems. The design language should tell the truth about the project. This is not lifestyle content. This is presentation-based nutrition work for metabolic health and performance.

What PGIS Recipes Actually Is

PGIS, for me, means Performance Glycemic Intelligence System.

It is a practical framework for asking better questions about meals:

• What kind of glucose curve is this likely to produce?
• Does this meal support recovery, satiety, and steady energy?
• Is it easy enough to repeat in real life?
• Can I explain the logic clearly enough that another person can use it without me standing beside them?

That is where the recipe library connects to the larger ecosystem.

I have been thinking about PGIS as more than isolated content. It is becoming a set of connected surfaces for self-regulation, metabolic awareness, and practical behavior design. One example is PGIS-Breathe, which sits on the breathing and regulation side of that work. PGIS Recipes sits on the food side.

Different surface. Same principle.

If the intervention matters, the delivery architecture matters.

That is true in medicine. It is also true in nutrition. A beautiful idea with weak delivery usually dies as aspiration. A modest idea with good architecture becomes a habit, a tool, or a protocol.

Why I Put It on GitHub

That is why I used GitHub instead of treating this like a one-off export folder.

GitHub does three important things here:

• it turns the recipe library into a durable asset instead of a local artifact
• it makes updates explicit and traceable
• it lowers the friction for future expansion

Now when I create another Marp recipe deck, I do not have to rebuild a custom site from scratch. I drop the exported HTML into a clean recipe folder, add one metadata object, commit, and push. That is the kind of workflow I trust because it respects maintenance.

Physicians who build need to care about maintenance.

We see this mistake everywhere in clinical software. People celebrate the prototype and ignore the upkeep. They get excited about the model and neglect the workflow. They admire the output and forget the system that has to carry it on an ordinary Tuesday.

I do not want to make that mistake in my own work.

So PGIS Recipes became a small exercise in disciplined infrastructure:

• one clear homepage
• one shared design language
• one searchable library
• one repeatable method for adding future decks
• one public URL that can keep growing over time

That may sound minor. It is not minor.

This is how durable knowledge compounds. Not by becoming bigger first, but by becoming structured first.

The Physician-Builder Point

I think physicians should build more of these small, durable systems.

Not because every doctor needs to become a full-time engineer, but because too much of our useful work disappears into folders, screenshots, slide exports, email drafts, and private notes. Then we wonder why nothing scales. The answer is usually simple: the knowledge never got a stable architecture.

PGIS Recipes is one response to that problem.

It takes practical meal logic and gives it a home:

• visible
• versioned
• expandable
• reusable

That is what I want more of across medicine, education, and self-tracking.

Build fewer isolated artifacts. Build more systems that can survive you.

That is the real physician-builder move.