Content properties — two domains, two jobs, two keyword universes

Decision (operator, 2026-06-01; blog model revised 2026-06-09 — WordPress removed): run two distinct publishing properties so they rank for different intents and never cannibalise each other. They cross-link, so authority flows both ways.

Property	Platform	Publishes	Ranks for	Publish path
temerarii.com	Duda (keep)	Campaigns + scientific papers	Commercial / services queries + formal authority (research, consent-first data / SIE, marketing-science)	Duda CMS (existing)
temerarii.xyz	Static HTML + the Lab front door	Knowledgebase: the actual business + experiments	Practitioner / technical / build-in-public queries (how we built X, tooling teardowns, agent + render pipelines, WebGL experiments, model evals)	`temerarii.xyz/blog` (static, served by the Lab)

The split is deliberate: .com owns the commercial + formal-research universe; .xyz owns the technical / build-in-public universe. No query should be a fair target for both.

Blog model (operator-locked 2026-06-09): the daily blog is a static HTML article generated into apps/lab/public/blog/<slug>/index.html and served at temerarii.xyz/blog/<slug> — no CMS, no WordPress. The weekly curated pick still publishes to Duda on .com (the canonical for campaigns/papers). Cadence: 1/day static (.xyz/blog) + 1–2/wk Duda (.com).

temerarii.xyz topology

temerarii.xyz/              → the Lab (R3F cinematic front door, Vercel SPA) — UNCHANGED
temerarii.xyz/blog          → the static knowledgebase index
temerarii.xyz/blog/<slug>   → individual static posts (apps/lab/public/blog/<slug>/index.html)

Subdirectory (not subdomain) so all ranking authority consolidates on the one apex. The Lab stays the hero at /; the knowledgebase rides underneath at /blog as static files in the same Vercel deploy.

Vercel config (apps/lab/vercel.json)

No proxy/rewrite is needed for the blog — /blog/<slug>/index.html are real static files in the Lab's public/, so the existing SPA catch-all serves them directly. No WP_ORIGIN, no /build rewrite.

temerarii.xyz knowledgebase IA (the /blog clusters)

Pillar → cluster, internally linked, EEAT — same architecture as the .com Insights, different territory:

The content machine — how the engine works: goal → stages → gates, the 4-4-5 calendar, drift-proofing, the 9-output matrix. (build-in-public of this repo.)
Agent + automation workflows — Claude-Code-orchestrated pipelines, MCP wiring, swarm patterns, n8n→Claude migration notes.
Render + media pipelines — Remotion / HyperFrames, ffmpeg GPU, ComfyUI/Blender, storyboard→animatic.
The Lab experiments — R3F/WebGL write-ups, the cinematic front door teardown, shader/motion notes (each experiment ships a build-note here).
Tooling teardowns + model evals — fal/replicate/kie/Higgsfield comparisons, freshness/flag audits, what we adopted vs left.

Each post links up to its pillar and across to the relevant .com paper/service (and .com papers cite the .xyz experiment that produced the data). That reciprocal linking is the cross-property authority play.

Operational unlock — the engine writes static HTML directly

The daily blog is generated as a self-contained static article (the office's render_publish_view._seo_article renders the full SEO anatomy — meta/canonical/JSON-LD/keywords/internal+external links/FAQ) and written to apps/lab/public/blog/<slug>/index.html. No CMS round-trip, no plugin, no auth token — it ships in the same Vercel deploy as the Lab. Pipeline:

engine content (HTML/MD) → SEO article template (brand-locked, from governance/brand.json)
   → apps/lab/public/blog/<slug>/index.html → temerarii.xyz/blog/<slug>

Status / blockers

Yours: nothing — the static blog ships with the Lab deploy.
Mine: wire the daily static-article writer into the publish stage; author the /blog cluster pillars; keep the Duda weekly canonical in engine/integrations/duda.py.