--- title: I am building a private synthetic wiki factory. Here is how and why. date: 2026-07-08 topic: AI Systems summary: 2.6B tokens later, 1,669 synthetic wiki-style articles for a fairly technical field — how I built the factory that makes them, what broke along the way, and where it's going. slug: i-am-building-a-private-synthetic-wiki-factory-here-is-how-and-why --- # I am building a private synthetic wiki factory. Here is how and why. 10 min read 2,562,449,811 tokens. 1,669 synthetic wiki-style articles for a narrow technical field. Still work in progress, but now autonomously (mostly). --- I'm building Membranium, a gateway to lightweight architecture and a hub for all things tensile fabric structures. It uses AI at every layer: material selection, project scoping, spec drafting, supplier matching, and much more. But membrane structures are a narrow field, and the knowledge is spread across manufacturer datasheets, engineering standards, academic papers, associations, and more than 4,600 companies worldwide. One of the main issues emerged fast: ask an LLM what a flying strut is and looks like and you get an answer that sounds fine, but that any specialist would not trust. Basically, you get a decent answer wrapped in AI slop and vague language. That was the core problem. Every time I used an LLM inside Membranium modalities like search, research, chat, and scout, I was re-explaining the same background in every prompt: what ETFE is, how a catenary behaves, what a keder clamping does. Each call rebuilt that knowledge from scratch. It cost real money and the answers kept changing. So I needed a solid knowledge base under the product. Something the AI could draw on instead of make up. ## The Grokipedia moment Then I saw how Grokipedia covered a lot of ground: a synthetic encyclopedia built for both people and AI to read, put together on purpose instead of scraped. The idea clicked. I would build my own private version, a synthetic wiki for tensile fabric structures, a source of truth for Membranium, written by AI and checked by me before any of it went live. I called it membranes.wiki and started building the article factory to fill it. ## Getting the topics right first The first important step was steering article generation with a better topic set. Before writing anything, I needed to know what the wiki should cover. I had Codex generate the first topic catalog, and it came back crude and grug: 5,809 entries that read like a database dump instead of a map of what a specialist actually cares about. I tried fixing it with better instructions, but that adjusted maybe a quarter of the list. The rest still sucked. So I built a manual review screen into the admin UI and went through topics by hand, grading each one on plain readability and common sense and sorting it into its own bucket. That kinda worked, but with thousands of entries it was slow going. In the end I stopped doing it myself. I handed the job to Fable and told it to spawn agents that would review the catalog and generate as many useful concepts as it needed: real user queries, FAQs, user stories, even the multi-turn chat scenarios a client might actually walk through. It spawned 102 agents, drained my usage, and took four resets to finish. But it cooked, and it cooked well. That one run turned 5,809 flat topics into the 10,342 concepts the factory runs on today, each carrying its own search, FAQ, glossary, and discovery intent. What it produced is good enough that I'm sticking with it. ## The output read well and was wrong Then I started generating. I set up a Codex pipeline with the 5.5-medium model and ran it across the first batch of topics. The output was bad in a specific way: fluent, organized, and wrong at the edges, real grug. Articles would correctly name a membrane system and then describe it in a way that sounded right but was subtly off. Glossary definitions were smooth but generic, too vague to be much use to a specialist, and nowhere near reliable enough to be the backbone for a dedicated AI agent. Then I built a no-slop policy and a skill: a list of AI phrasing patterns, stock headings, and weak wording to block, wired into the review gate. Output got maybe 5% better. I changed the article format several times, reworking how the model got its brief, what sections it had to write, and in what order. Another few percent. It was still not good enough to publish in bulk. ## Claude wrote better articles and cost too much I switched the writing model to Claude Sonnet 4.6 medium inside a Claude Code routine. The quality jump was immediate. The articles read like someone with a deeper understanding of the field wrote them, and knew what a reader needs. The problem was practical: each one took about 20 minutes end to end, one at a time, and the token cost did not make sense for bulk work. At that rate, building a wiki big enough to be useful would take most of a year and cost too much. Something in the architecture was wrong, not just the model choice. ## The hybrid pipeline The fix was to stop looking for one model that could do everything. Instead I matched each stage of the article cycle to what each model is actually good at. The Codex-first path works like this. A Codex thread on 5.5-medium writes the v1 research draft: bulk text, fast, broad, generates a small set of deeper questions related to the topic to explore further and align better. It then calls the Claude CLI for v2 'claude -p', using Claude's better writing and layout. Then a new call to Codex CLI on 5.5-high runs the v3 gate and repair pass, checking scope, sources, required sections, and slop. Finally the main Codex thread on 5.5-medium does the cleanup: line it up with the database, strip any slop left, and merge it in. The Claude-authored path runs the same steps in reverse, with Claude doing most of the writing and Codex doing the structure passes. ```mermaid flowchart TB subgraph A["Codex-first route"] A1["5.5-med: research v1"] --> A2["Claude CLI: prose v2"] A2 --> A3["5.5-high: gate and repair v3"] A3 --> A4["5.5-med: DB merge and cleanup"] end subgraph B["Claude-authored route"] B1["Sonnet 4.6: research v1"] --> B2["Codex CLI: structure v2"] B2 --> B3["Sonnet 4.6: gate and repair v3"] B3 --> B4["Local: DB merge and cleanup"] end A4 ~~~ B1 ``` Each model does the one thing it's good at. The slow, expensive pass runs once per article, on one stage, not across the whole pipeline. A full Codex-path article now takes around 6 to 10 minutes. That's a number I can work with. Most of those minutes go to the v3 gate. Before a draft can move on, it has to stay inside its approved concept and include the required sections: terminology, follow-up questions, related articles, sources, and tags. Named entities and shaky claims stay flagged, not stated as fact. Made-up related links are blocked. Important SEO pages have to hit a longer minimum length. AI phrasing and stock headings get rejected. New terms go into a glossary queue instead of straight into the wiki, so the glossary grows without every phrase the model invents becoming a definition. They are still slop, but much better slop: not generic bad slop, but tuned slop I can work with. And I'm okay with it. It is much better than any native single API call output from any model provider. ## What broke after that With a steady 8-minute step, I wanted more articles running at once. The routine system I started on only fired once an hour, and I needed a cycle well under 10 minutes. So I tried running three Claude CLI processes on a background cron. It was a mess. Jobs would stall with no error, output would land in the wrong state, and there was no clean way to rescue a half-written article. I killed it. Some of this is hardware. I'm running it on my main machine with Windows 11, which limits what local computer-use tooling can do. Running things in parallel through background shell processes is far more fragile on limited hardware than it looks on paper. I'm currently setting it up on my other Linux machine with a dedicated set of accounts. What works now is simpler: two paths that run step by step, with Claude as the chief editor over the Codex workers. Codex handles the volume. Claude writes the articles that need the best prose. ## The evening feedback loop The pipelines also improve themselves. Once a day, in the evening, a `/goal` automation grabs a random sample: 10 Claude articles and 20 Codex articles. An agent runs a dedicated analysis on each batch, then the main thread pulls that into further edits, each scored for relevance between 0 and 1. Anything above 0.9 is accepted on the spot. The rest waits (for me). It also puts the two batches side by side. Claude's results become written feedback for Codex: targeted notes on where its style falls short. Then the run hands off into two Codex threads, one per pipeline, to fold the day's findings back into the Claude-first and Codex-first prompts. The system edits its own instructions based on what worked that day. The timing is lopsided on purpose. A Codex run takes 6 to 10 minutes, so I schedule it every 8 minutes, basically nonstop. Claude only runs once an hour, so I stopped fighting that and use it mostly as an editor and for the articles that need its writing. ## What the ledger holds The factory is not a chat history. Every run is tied to a SQLite database, which is what lets me resume a run instead of redoing it. If a process dies mid-run, the record of it is still there, and the next run picks up where it left off. ```mermaid flowchart TB FR["factory_runs"] -->|owns| FJ["factory_jobs"] CO["concepts"] -->|seeds| AC["article_candidates"] AC -->|has| AV["article_versions"] AV -->|gets| VR["version_reviews"] AV -->|carries| CL["claims"] CO -->|names| CA["concept_aliases"] CO -->|lanes| IP["intent_payloads"] CO -->|asks| SQ["search_queries"] AV -->|yields| GC["glossary_candidates"] ``` Each concept spreads into two big tables. `concept_aliases` holds every other name a topic might go by: product names, field nicknames, standard references, buyer phrases. `intent_payloads` holds the search, FAQ, glossary, article, and discovery lanes for that concept. Across 10,342 topics, those two tables add up to 35,218 aliases and 55,831 intent payloads. I haven't paid enough attention there yet, but that's why membranes.wiki can point both a buyer's search phrase and a technical standard at the same article. Article versions have their own trail: `version_reviews` for gate findings, `claims` for statements that still need a source, and `glossary_candidates` for terms the v3 pass turned up. Jobs get picked up in order and checked out one at a time. When an article is finalized, it's written back with everything it needs to live in a graph rather than sit as a standalone page: follow-up questions, tags, related articles, and glossary terminology. That's what turns a pile of pages into a relationship graph the product can walk, and it's what makes the internal backlinking work. ## Where it stands Numbers as of July 5, 2026. The factory has worked through 10,342 concepts and produced 822 active articles. Yes, I made 1,669 articles in total; the first 847 are currently archived. The pipeline is in good shape. Writing runs well ahead of review, not the other way around. Of the 822 candidates, 715 have cleared the v3 gate and sit in the review queue. Another 39 are queued for writing, 27 are at v1, 25 are at v2, and 16 are flagged for a rewrite. The review passes have also filled a glossary queue of 1,575 candidates. ## Where this is going Right now membranes.wiki is private. It feeds the retrieval layer under Membranium today, and eventually it will be part of the training data for the domain models I want to build on top of that. But it is not going to stay the same. The plan is to release it free, with clear attribution back to Membranium. The SEO structure is already in the database. Every concept has its alias list, its intent lanes, its internal links back to related articles. That is not just organizational hygiene; it is how a static site built out of AI articles ends up cited by both crawlers and language models. Each alias maps a buyer phrase, a trade nickname, a standard number, and a field term to the same article. Each intent lane describes a search shape the article should answer. When that is rendered and live, the site reads correctly for a search crawler and for a language model doing a retrieval pass on the same question. The goal is for membranes.wiki to become the public discovery layer for Membranium: not a blog, not a brochure, but the place the field actually goes for reference. And the base that agentic searches pull when someone, or something, asks a membrane structures question. Anyone who finds an answer there has a clear path back to the platform that built the knowledge. The release isn't happening until Membranium is in beta. That's the next thing, and when it ships I'll write about that too. ## What I actually learned The slop was never really about wording. I spent decent time, days, tuning the word-level policy, and it got me maybe 5%. The real problem was deeper: the model kept making topics and claims it couldn't back up, then covering the gaps with confident writing. You know that feeling, right? You are one paragraph into an AI-generated article and your brain just stops paying attention. What actually helped was a combination of models working together: Claude making a decent base for an article, Codex reviewing it and providing feedback with final adjustments, and then a gate that checks concept scope, source state, and required sections before a draft can move on. Not a longer list of banned words or a pile of skill files. Topic quality is its own separate problem and you have to solve it before you solve article quality. The first Codex-generated catalog was flat and machine-first and no amount of prompt tuning was going to fix that, because the model had no instinct for what a specialist in this field actually wants to know. Handing the topic review to Fable agents was the right call: they could internalize what good looked like and generate at the breadth and nuance a person doing it by hand couldn't sustain. I tried the manual route first. It showed me what the bar was. The agents cleared it at scale. Splitting the work across models worked better than looking for one that could do it all. Claude writes better in this domain. Codex is faster at bulk structure. Calling the Claude CLI inside a Codex thread felt backwards the first time I set it up. It turned out to be the reason the pipeline works at all at this size. The factory is running. I am happy with where things are and how they are evolving. Thanks Codex!