Building the Federation Node Starter: One Template to Launch Every New Star
A follow-up to Building the Real SEO™ Life Content Engine: what happens when you stop rebuilding the same setup from scratch every time.
Three things stood out once the template was assembled.
What was measured.
Three readings about the cost of adding one more site. That cost is what decides whether a network grows or quietly stalls.
Before, every launch was a memory exercise against whichever site you happened to remember last. After, it is copy and find-replace.
The template was not invented. It is the intersection of three properties that already worked, which is why it carries no single site's one-off decisions.
The AI endpoints, the .htaccess, the bootstrap functions, and the sitemap wiring all ship in the scaffold instead of being remembered separately.
The short version.
Every Keep-tier site in the AI Digital Karma Federation shares the same PHP JSON architecture. Until now, every new launch still started from scratch. This case study documents the build of the Node Starter, a 26-file template package that takes a new federation site from zero to launchable with the AI foundation layer already wired in.
The idea is simple: if the constellation is going to grow one star at a time, the launch process has to be repeatable.
Explain it to me like I'm ten.
You know how a grandma sometimes has a recipe that is not written down anywhere? She just knows it.
That works fine until somebody else needs to make it. Then it is a guessing game, and it comes out a little different every time.
That is how we were launching new websites. Every time, somebody had to remember all the pieces and copy them from whichever site they happened to think of.
So we wrote the recipe card. One folder with twenty six files, already set up, with everything a new website needs.
We did not invent the recipe. We looked at three websites that already worked and kept what all three of them had in common. That way it is not just one site's habits.
Now launching a new one takes a single sitting instead of rebuilding it from memory.
What was the system?
The AI Digital Karma Federation runs across roughly 14 Keep-tier properties. Each one is built on the same flat-file PHP JSON stack: front controller, bootstrap singleton, JSON content layer, AI endpoints, reusable sitemap workflow.
The problem was the process. Every new site was assembled by hand, pulling patterns from whichever existing site happened to be freshest in memory. krisada.com for the routing logic. RealSEOLife.com for the admin panel shape. AgeBetterToday.com for the content engine patterns. NaturalHerbLibrary.com for something else.
Inconsistency compounds. A pattern that works well in one repo does not make it into the next one unless you happen to remember it. A bootstrap function that was written cleanly for krisada.com might exist in a different, worse form two sites later.
The only template file that existed was a single sitemap generator: one file out of the thirty-plus a new site actually needs.
So the question became: what does a launchable federation node actually require, and can that be packaged once and copied forward?
The answer to both: yes.
What changed?
Started with an audit of the three most mature sites in the federation: krisada.com (the most feature-complete), RealSEOLife.com (the most mature admin panel), and AgeBetterToday.com (the most generic content engine structure).
The goal was not to copy any one site. It was to pull out the shared core: the structure every new site needs before it can do anything else.
The audit produced a gap map:
What the template had: one file (deploy/generate-sitemap.php). What a launchable site needs: 26 files across 9 directories.
The build proceeded in logical layers:
Layer 1: Foundation files (.gitignore, .htaccess, robots.txt, llm.txt) The files that make a site behave correctly before any PHP runs. The .htaccess handles canonical domain enforcement (HTTPS + www), static asset routing, front controller wiring, and security, blocking direct access to config, content, templates, storage, and deploy directories. robots.txt explicitly allows the AI endpoints. llm.txt provides the plain-text site identity for LLM ingestion.
Layer 2: Configuration (config/) Five JSON files that define the site's identity without touching code. site.json holds the site name, domain, navigation, footer links, contact, locale. design-tokens.json maps to CSS custom properties injected at render time: colors, fonts, radii, content width, header height. routes.json defines named routes and template defaults by content type. feature-flags.json controls optional features (admin panel, downloads, sidebar). install.example.json is the bot-specific override file. Copy it to install.json, fill in domain and environment, and never commit it.
Layer 3: Content scaffolding (content/) Five directories, pre-structured. pages/ ships with home.json as a working starting point. articles/, categories/, and sidebars/ are empty with .gitkeep files so the directories exist in git. redirects/ ships with an empty but valid redirects.json so the bootstrap does not throw on first load.
Layer 4: Bootstrap core (bootstrap.php) This is the engine, and it is monolithic on purpose: all routing, JSON loading, content resolution, URL normalization, sidebar resolution, output helpers, and design token injection live in one file. The site_app() singleton loads site.json, routes, tokens, flags, and all content collections on first call, then caches the result for the request lifetime. The site_resolve_request() function handles redirects first, then pages by URL, articles by URL, articles by slug (/article/slug/), categories by URL, and 404. The record redirect system generates automatic 301s from redirect_from fields in content JSON, so content URL changes need no manual .htaccess entries.
Layer 5: Front controller (index.php) Minimal by design. Loads bootstrap, calls site_resolve_request(), handles the redirect case immediately, renders 404 via the error layout, and for all public content types builds the $view array and loads the default layout. Template resolution: checks for a named template file first, falls back to templates/default.php.
Layer 6: Templates (templates/) Two layouts (default.php and error.php) plus one partial (sidebar-block.php). The default layout reads navigation, sidebar blocks, breadcrumbs, and JSON-LD from the $view array, all driven by config/site.json and the content records. No site name, contact details, or footer links are hardcoded.
Layer 7: Assets (assets/) A complete base CSS file (style.css) and the hamburger nav script (nav.js). The CSS uses custom properties throughout (color-bg, color-accent, color-text, font-display, header-height, content-width), all mapped from design-tokens.json. Default token values are sensible neutrals. Overriding the whole visual identity is a one-file JSON edit.
Layer 8: AI foundation (ai/) Three JSON endpoints that every federation node ships with from day one: catalog.json (content index), health.json (domain health signals), manifest.json (directory of AI endpoints). Stubbed out with placeholder values on install, updated after first content push.
Layer 9: Deploy and CI (.github/workflows/sitemap.yml, deploy/generate-sitemap.php) The sitemap generator already existed. The GitHub Actions workflow calls the federation-level reusable sitemap workflow: one calling file, no duplicated CI logic. The federation workflow handles BOM stripping, PHP execution, and committing sitemap.xml back to the repo.
What did the evidence show?
Three things stood out once the template was assembled.
First: the architecture was already consistent across sites. The inconsistency was at the start, in the blank slate before patterns got imported. The template closes that gap. A new site now starts with the bootstrap structure, .htaccess security configuration, AI endpoints, and sitemap pipeline already wired correctly.
Second: the token system changes the cost of visual customization. Because every color, font, radius, and spacing value in the CSS reads from custom properties sourced from design-tokens.json, a new site's entire visual identity is configurable without touching a stylesheet. The template ships with neutral defaults. Overriding them takes one JSON edit.
Third: the content record redirect system is the feature most likely to save real pain six months post-launch. Every content JSON can include a redirect_from field. The bootstrap reads those at load time and automatically builds a redirect index for the request resolver. URL changes do not require .htaccess edits. They require a one-field update in the content record.
What the template deliberately does not include: an admin panel, a directory/catalog template, article or category page templates. These vary by site topology and business purpose. The admin panel on RealSEOLife.com has capabilities that would be irrelevant on a static content site. A directory site needs a different layout than a publication. These are added per-project.
The template is the floor, not the ceiling.
What can be reused?
The constellation expands one site at a time. The question is how much it costs to add each star.
Before the template: every launch was a memory exercise. Pull patterns from whichever site you remembered last. Hope the bootstrap functions match. Rebuild the .htaccess from scratch. Remember to add the AI endpoints. Wire the sitemap workflow.
After the template: copy, find-replace YOURDOMAIN, fill in five config files, add your first content record.
The gap between a blank repo and a launchable node is now a one-session setup.
Keep Browsing the Case Library
Move from this evidence file back into the full proof system.