Building the Federation Node Starter: One Template to Launch Every New Star

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 that 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.

Started with an audit of the 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 extract the universal core -- the architecture 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 machine-specific override file -- copy to install.json, fill in domain and environment, 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. Intentionally monolithic -- 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 path, articles by path, articles by slug (/article/slug/), categories by path, and 404. The record redirect system generates automatic 301s from redirect_from fields in content JSON -- no manual .htaccess entries needed for content URL changes.

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 CSS 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.

Three things stood out once the template was assembled.

First: the architecture was already consistent across sites. The inconsistency was at the start -- the blank slate before patterns were imported. The template eliminates that gap. A new site now starts with the correct bootstrap structure, the correct .htaccess security configuration, the correct AI endpoints, and the correct sitemap pipeline already wired.

Second: the token system changes the cost of visual customization. Because every color, font, radius, and spacing value in the CSS reads from CSS custom properties -- and those properties are sourced from design-tokens.json -- the entire visual identity of a new site 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.