Skip to content
wiki.fftac.org

Transforming Wiki FFTAC Org Into A Concept Driven Wiki - Source Excerpt 02 - Guidance and wizard gap analysis

Back to Transforming Wiki FFTAC Org Into A Concept Driven Wiki

Summary

This source excerpt begins near Guidance and wizard gap analysis 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

A fourth failure mode is **duplicate and hash-heavy exposure**. The current public inventory contains duplicated or near-duplicated titles and multiple preservation variants with long generated names, including repeated `Spiralism` and `Researching Spiralism And Its Contexts` entries, plus hashed preservation variants for the same Protocol5 report artifacts. There is also a source record whose visible title and path duplicate a phrase in the source filename, producing a title such as `Current Websites, Organizations, And People Supporting The Antichristcurrent Websites, Organizations, And People Supporting The Antichrist`. citeturn7view2turn18view5turn4view6turn10view7

A fifth failure mode is **visibility confusion**. The Anti-Christ.org source-files page publicly lists internal docs such as `10 Launch Runbook` and `11 User Ai Architecture`, and their summaries explicitly say they are not public site content or are internal architecture guides. That is a strong sign that the publication model needs explicit `visibility` and `indexing` controls, not just a generic archive pipeline. citeturn25view2

There are also important things to keep. The home page’s boundary statement is correct: source sites remain authoritative for live claims, and the wiki should be used as durable background evidence until facts are reviewed and promoted. The site already preserves routeable evidence, each source page already extracts headings, and the workspace current-state page plus transfer log are the raw materials for better changelogs and dashboard pages. The transformation should therefore preserve the archive and its provenance discipline while rebuilding the public reading path on top of it. citeturn1view0turn5view10turn5view11turn8view0turn8view1

## Guidance and wizard gap analysis

LlmWikis.org gets several foundational things right. The build guide says to define scope, create starter structure, add metadata and trust labels, seed authoritative pages, establish review workflows, and only connect retrieval after the source is curated. The navigation page explicitly says a good LLM Wiki needs readable entry points, topic hubs, next-step links, stable frontmatter, concise summaries, and explicit wiki-links; the metadata and trust-model pages add owner, status, freshness, sensitivity, agent-use, and related-links requirements. Those are strong foundations. citeturn26view2turn26view0turn26view3turn26view4

The problem is that the current handbook is stronger on **governance and repository structure** than it is on **public publication architecture**. The structure guide emphasizes predictable file paths and a deliberately “boring” folder model; the build guide allows the root index in a single codebase to list every durable page or file; the wizard focuses on raw source path, compiled wiki path, archive target pattern, log path, source collection, and a generic entity page pattern. That combination is enough to produce a sound internal archive, but it does not force a public concept model. citeturn26view1turn26view2turn13view7turn14view2turn14view7

Some of the current FFTAC problems are cases where existing guidance is already correct but not enforced. LlmWikis’ duplicate-file policy says exact duplicates should be detected before promotion, one canonical source path should be chosen, aliases should be preserved in metadata, and duplicate generated copies should be kept out of indexes unless provenance is needed. Yet the live wiki still exposes multiple generated preservation variants and duplicate-looking entries in public indexes. Likewise, the metadata standard and trust model already call for owner, last reviewed date, status, sensitivity, and related pages, but the sampled source pages do not expose those signals. citeturn13view6turn7view2turn18view5turn26view3turn26view4turn10view5turn10view6turn10view8

Other problems come from true gaps in the handbook and wizard.

### The handbook needs stronger publication rules

The `Content Types` page defines orientation, architecture, operations, decisions, policies, and agent rules, which is useful; however, it does not define the public distinction between **topic pages**, **site hubs**, **source records**, **raw chunk pages**, **migration records**, and **developer/internal references**. Because that page-type taxonomy is missing, archive-derived source pages can slip into public navigation without an intervening editorial layer. citeturn26view5

The metadata standard is similarly strong but incomplete for a public wiki. It requires `title`, `owner`, `status`, `last_reviewed`, `review_cycle`, `sensitivity`, `agent_use`, `human_review_required_for_updates`, and `related`, but it does not currently require `page_type`, `canonical_url`, `visibility`, `indexing`, `breadcrumb_parent`, `source_records`, `derived_topic_pages`, or `legacy_redirects`. Those extra fields are what separate a governance-ready page from a publication-ready page. citeturn26view3turn26view4

The handbook should therefore add explicit **hard publication rules** like the following:

' ' ' text
A public page must have:
- a human-readable title,
- a declared page_type,
- a canonical URL,
- a visibility value,
- an indexing value,
- a breadcrumb parent,
- an owner role,
- a last reviewed date,
- and at least one contextual internal link.

No public page may be published as:
- a mechanical chunk name such as Part 01,
- a raw file mirror,
- a duplicate hash variant,
- or a generic filename such as Index or Readme unless the page intent is specifically developer reference.

Raw chunks may exist for retrieval or preservation, but they must not be primary public navigation pages.
' ' ' 

Those rules do not contradict the existing LlmWikis philosophy; they operationalize it.

### The wizard needs to model public architecture, not only storage topology

The current wizard already asks useful questions about setup path, scope, audience, context budget, large-file policy, root index topology, long-memory update policy, graph strategy, review cadence, and support boundaries. It also outputs a setup packet with an `entity_page_pattern`, `episodic_log_pattern`, archive target, and evidence log. The issue is not that the wizard asks too little about storage; it is that it asks too little about **public page intent and URL shape**. citeturn13view5turn13view6turn13view7turn13view8turn14view0turn14view7

The wizard should add a required **public model gate** before it generates any route packet:

' ' ' text
What kind of wiki are you building?
- Public concept wiki
- Internal operations wiki
- Source archive / evidence repository
- Mixed public concept wiki + evidence archive
- Multisite knowledge hub
' ' ' 

That single decision should drive the rest of the packet.

The wizard should also add a **page-type planner** that requires maintainers to declare which public page families exist:

' ' ' text
Select required page types:
- topic
- site hub
- source record
- decision
- operations
- glossary
- migration record
- developer reference
- raw chunk
' ' ' 

The packet should then emit route patterns for each selected page type, instead of only a generic `wiki/{topic}.md` pattern. The current generic entity-page pattern is too abstract to prevent archive-shaped outputs. citeturn14view2turn14view7

### Long-source handling rules need to become editorial, not merely technical

The current wizard’s large-file policy says to publish a summary, heading map, bounded preview, checksum, and raw-source pointer for large files rather than inlining them into public wiki pages or hot memory. That is a sound preservation rule, but it is not enough for public publishing because it does not specify what happens when the heading map already contains strong editorial subdivision. citeturn13view6

The long-source logic should be upgraded to something like this:

' ' ' text
If heading_count == 0:
  create source record only; raw chunks stay non-public or noindex.
If heading_count >= 1 and chunk_count <= 1:
  publish the content directly on the source record or canonical page;
  do not create a Part 01 child page.
If heading_count >= 2:
  create named anchors or child pages from the headings;
  do not expose Part 01 / Part 02 labels publicly.
If a chunk spans multiple major headings:
  map the legacy URL to the closest parent concept page first,
  then create a dedicated child page if search intent warrants it.
' ' ' 

The current wiki’s own pages prove why this rule is necessary: several pages have only one content part, while other pages already expose rich heading maps that could have been the public structure from the start. citeturn8view0turn8view1turn8view3turn8view4turn8view5turn11view0turn11view1turn11view2turn11view5

### URL, anchor, and publication linting must become first-class
Website health report