Transforming Wiki FFTAC Org Into A Concept Driven Wiki - Source Excerpt 01 - Transforming wiki.fftac.org into a concept-driven wiki

Back to Transforming Wiki FFTAC Org Into A Concept Driven Wiki

Summary

This source excerpt begins near Transforming wiki.fftac.org into a concept-driven wiki and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Transforming wiki.fftac.org into a concept-driven wiki.md.

**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Transforming wiki.fftac.org into a concept-driven wiki.md

# Transforming wiki.fftac.org into a concept-driven wiki

## Executive summary

wiki.fftac.org currently succeeds as a **reviewed evidence archive** far more than it succeeds as a **human-readable, concept-driven wiki**. The site’s own home page defines it as a “reviewed long-term memory and archive layer,” and the crawl map tells humans, search engines, and AI agents to move from site hubs into source files, system memory, research memory, archive records, and individual source parts. That is a coherent archive model, but it is not a concept-first wiki model. citeturn1view0turn5view7turn5view8turn5view9turn10view3turn10view4

The good news is that the raw ingredients for a strong wiki are already present. The site preserves provenance, exposes source headings, keeps a transfer log and workspace current-state routes, and clearly states that source sites remain authoritative for live public claims. In other words, the archive boundary is already well-formed. The main problem is publication architecture: source records and chunking artifacts are being exposed as primary public navigation instead of being used as supporting evidence behind concept pages, site hubs, decisions, runbooks, and glossary entries. citeturn1view0turn5view10turn5view11turn8view0turn8view1turn8view3

The most visible symptom is the public use of pages and links named `Part 01`, `Part 02`, and similar chunk labels. Several source pages already contain meaningful heading maps such as “Executive summary,” “Historical frame and timeline,” “Failure-mode map,” and “Proposed semantic architecture,” yet the user-facing routes still point to chunk counters rather than those headings. In some cases, the extra part page is completely redundant because the source page has only one chunk. citeturn8view0turn8view1turn8view3turn8view4turn8view5turn11view0turn11view1turn11view2turn11view5

LlmWikis.org already contains several strong ideas that should be preserved: reviewed sources before retrieval, explicit metadata, trust labels, index and log pages, topic hubs, and stable paths. But the guidance and wizard are still under-specified for **public information architecture**. They ask for raw source paths, compiled wiki paths, index topology, archive targets, and a generic entity page pattern, yet they do not force a page-type taxonomy, public route grammar, URL quality rules, visibility/indexing rules, or a ban on mechanical chunk pages becoming public endpoints. The result is that an archive-first implementation can still be “compliant” with the current wizard output. citeturn26view0turn26view1turn26view2turn13view7turn13view8turn14view2turn14view3turn14view7

The recommended fix is not to discard the archive. It is to **demote the archive from primary navigation to evidence layer**. Public navigation should pivot to a typed architecture such as `Topics`, `Sites`, `Sources`, `Decisions`, `Operations`, `Glossary`, and `Migrations`, with meaningful slugs and descriptive anchors. Google’s guidance supports simple, human-intelligible URLs, descriptive anchor text, breadcrumb trails, canonical URLs, and sitemap-based canonical discovery; MediaWiki likewise treats page names as core page identity and link targets. Those standards align closely with the direction the wiki should move. citeturn24view0turn24view1turn24view3turn23view0turn23view2turn22view3turn22view4turn23view4turn22view6turn22view0

The fastest path is a three-stage program. In the short term, stop publishing new `part-*` pages, define route families and templates, and redirect the worst legacy URLs. In the medium term, migrate high-value topic pages and rebuild top navigation, indexes, breadcrumbs, and sitemaps. In the long term, retrofit the LlmWikis guidance and wizard so that future wikis cannot fall back into archive-first publication patterns. citeturn5view9turn13view6turn14view0turn22view5turn22view6

## Current-state inventory

This assessment is based on a crawl of the public homepage, the memory crawl map, the all-sources index, site hubs, site-specific source indexes, archive indexes, and representative source and part pages across FFTAC.org, Anti-Christ.net, Anti-Christ.org, and Spiralist.org. The route families surfaced in that crawl are shown below. citeturn1view0turn3view2turn3view3turn6view0turn6view1turn6view2turn6view3turn15view0turn15view1turn15view2

' ' ' text
/
/memory/crawl-map/
/memory/sources/
/workspace-current-state/
/transfer-log/

/{site}/
/{site}/archive/
/{site}/source-files/
/{site}/system-memory/
/{site}/research-memory/

/{site}/source/{slug-hash}/
/{site}/source/{slug-hash}/part-01/
' ' ' 

The crawl map lists four large site shelves with assigned source-record counts: 53 for FFTAC.org, 39 for Anti-Christ.net, 107 for Anti-Christ.org, and 973 for Spiralist.org, plus three active handoff records surfaced on Spiralist. That is at least 1,172 assigned source records before counting the shared workspace pages. In practical terms, this means even small navigation mistakes scale into very large public URL inventories. citeturn5view8turn5view9

The current top navigation is explicitly **memory-shelf oriented**. It exposes `Memory Sources`, `FFTAC Memory`, `Anti-Christ.net Memory`, `Anti-Christ.org Memory`, and `Spiralist Memory`, plus `Crawl Map` and `Transfer Log`. In the sampled navigation, there is no top-level `Topics`, `Glossary`, `Decisions`, or `Search` route. citeturn1view0

That memory-shelf bias is reinforced by the per-site memory hubs. Both the FFTAC and Spiralist hubs explicitly tell users to move “from summary memory into picked-apart source files and content parts.” The crawl map uses nearly the same logic: site hub first, then source files, system memory, research memory, archive records, and individual source parts. This is excellent for forensic provenance; it is poor for everyday human discovery. citeturn10view3turn10view4turn5view7turn5view8turn5view9

Representative source pages all follow roughly the same publication template: title, `Site relevance`, `Memory type`, `Source path`, `Size`, a short summary, a source-heading list, and then `Content Parts`. The `Books On The Antichrist` page, the Protocol5 converter page, and the Anti-Christ.org “Start Here” page all follow that pattern. The public taxonomy therefore pivots around **site relevance and file provenance**, not around public intent such as “what is this topic,” “what decision was made,” or “how do I do this.” citeturn10view5turn10view6turn10view8

The `Part 01` problem is worse than a naming problem. The source pages already expose meaningful editorial headings. `Books On The Antichrist` lists headings such as `Executive summary`, `Historical frame and timeline`, `Comparative table of top titles`, and `Scholarly and theological works`, yet the public links are only `Part 01` through `Part 04`. The Protocol5 converter source record lists `Failure-mode map`, `Proposed semantic architecture`, `Recommended semantic fields per glyph`, and other strong section names, yet again the public links are only `Part 01` through `Part 06`. citeturn8view0turn8view1

The chunk pages themselves show why this is structurally wrong. The Protocol5 `Part 01` page begins with the executive summary and then continues into assumptions, architecture, and the start of the failure-mode discussion; `Part 02` then begins mid-table and continues into proposed architecture. The chunk boundaries are therefore **mechanical splits**, not stable editorial sections. They are poor candidates for durable public URLs. citeturn9view0turn9view1

A second failure mode is **redundant chunk inflation**. Some source pages have exactly one content part and still publish a child page called `Part 01`. That is true for examples such as `01 Start Here`, `02 Site Map`, `06 Strategy Research`, `Index`, `Page`, `Footer`, and `Template Journal`. In each of those cases, the child URL adds no navigational value; it only creates another public endpoint. citeturn8view3turn8view4turn8view5turn11view0turn11view1turn11view2turn11view5

A third failure mode is **generic titling**. The all-sources index and site-specific source-file indexes expose many public pages titled `Index`, `Readme`, `Theme`, `Body`, `Page`, `Style`, and similar file-role labels. The same public indexes also expose code-derived page titles such as `Template Journal`, `Front Page`, `Footer`, `Searchform`, and `Theme` alongside essays, docs archives, file-intake records, UAI memory files, and research archives. That untyped mixture makes the index hard to scan and undermines the SEO advantage of clear, intent-rich titles. citeturn5view0turn5view2turn4view2turn4view3turn4view4turn4view5turn25view3turn25view4turn25view5