We are our own case study

There is a test every platform eventually faces: does your method work on you?

We reached it this week. Wellness & AI now publishes daily case studies, blog posts, resources, prompt scripts, and done-for-you bundles across a dozen health domains and two audience tracks. The content library outgrew the category grid. Visitors were missing things that were built for them — practitioners scrolled past individual resources, individuals never saw practitioner bundles that solved the same problem from a different angle.

The obvious move was to install a recommendation widget. The honest move was to build one ourselves, using the same 3-Layer methodology we sell.

the research layer: mapping the signal space

Every piece of content on this site already carries taxonomy metadata — domain (sleep, metabolic, hormones…), audience (individual or practitioner), and layer (research, ledger, protocol). That taxonomy is the signal space. A visitor who reads two sleep case studies and one protocol blog post has told us, without a form or a login, exactly what they care about.

We mapped every content type — case studies, blog posts, resources, DFY bundles — into that shared taxonomy. No new tagging system. No vendor schema. The structure we already had was enough.

the ledger layer: recording what matters

We created a lightweight signal table. Every page view writes one row: session ID, content type, slug, domain, audience, layer, and a weight. Views score 1. Purchases score 5. Dismissals — the X button on every suggestion card — score −3.

For anonymous visitors the session ID is enough. For logged-in users the profile persists across sessions and enriches over time. When an anonymous visitor later signs up, the profiles merge. No data is lost.

the protocol layer: scoring and serving

The scoring algorithm builds an affinity profile per session: how strongly does this visitor lean toward sleep vs metabolic, individual vs practitioner, research vs protocol? It then ranks every eligible content card against that profile, excludes anything already dismissed, and caps type diversity — no more than two case studies or two resources in a single strip — so the suggestions never feel repetitive.

The result is a 'Suggested for you' strip that appears on every major page: homepage, case studies, blog, resources, done-for-you. It updates with every interaction. It learns from every dismissal.

why we published the playbook

Because the best proof is the one your visitor can inspect. If we teach practitioners to build AI-augmented workflows and then outsource our own personalisation to a black-box vendor, we have a credibility gap. If we build it ourselves, document the architecture, and publish the playbook as a premium resource — the gap closes.

The AI Recommendation Engine Playbook is live in the resource library. It includes the signal taxonomy, the database schema, the scoring algorithm, the dismiss-to-learn loop, and the daily analytics pipeline. Everything we use, exactly as we use it.

the admin side

Every morning at 6 AM UTC, a cron job aggregates yesterday's impressions, clicks, and dismissals into a trends table and emails the admin team. The admin panel shows domain affinity heatmaps, most-dismissed content, and click-through rates. If a piece of content is consistently dismissed, that is a signal to retire or rework it — not to force it harder.

where the line is

This is not surveillance. We do not fingerprint. We do not sell data. We do not build shadow profiles. The signal table records content interactions — what someone read, what they dismissed — scoped to a session or an authenticated account. That is it. The architecture is open because the method is honest.

Eat your own cooking. Publish the recipe. Let the visitor decide if the meal is worth paying for.