Improving wiki.fftac.org Org And Llmwikis Org Guidance, Setup Wizard, And Site Structure - Source Excerpt 02 - Proposed information architecture and URL schema

Back to Improving wiki.fftac.org Org And Llmwikis Org Guidance, Setup Wizard, And Site Structure

Summary

This source excerpt begins near Proposed information architecture and URL schema and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Improving wiki-fftac.org and LLMWikis.org Guidance, Setup Wizard, and Site Structure.md.

**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Improving wiki-fftac.org and LLMWikis.org Guidance, Setup Wizard, and Site Structure.md

This diagnosis is reinforced by official documentation models that the current sites are already close to, but do not yet fully exploit. Microsoft’s information architecture guidance emphasizes consistent labels, contextual clues, and easy findability. MediaWiki’s categories form tree-like hierarchies and automatic indexes. MDN separates page types into reference, guide, and navigation pages, and requires front matter that includes core identifiers like title, slug, and page type. Those patterns match the goals of wiki.fftac.org and LLMWikis almost exactly. citeturn25view13turn25view9turn28view0

The setup wizard deserves a special mention because it is both a product feature and a content model. It already has the right ambition, but its current implementation reads more like an expert planning console than a guided entry path. Step two alone includes project stage, collaboration model, reader model, root URL, coding-standards path, workspace setup, target policy, known sites, Git health, runtime artifacts, and context budget. Later steps introduce graph strategy, handoff rules, large-file policy, and safety posture. That is powerful, but it is not yet optimized for first-run comprehension. citeturn32view0turn32view1turn32view3

## Proposed information architecture and URL schema

The solution should be built around a simple principle: **each domain should own a different content job**. LLMWikis should own the “how, what, why, standard, template, tool” layer. wiki.fftac.org should own the “source, evidence, provenance, review, archive, cross-site relationship” layer. This aligns with Google’s emphasis on helping users and search engines understand content, with Microsoft’s information architecture guidance, with MediaWiki’s category trees, and with MDN’s page-type discipline. citeturn25view0turn25view13turn25view9turn28view0

### Proposed site hierarchy

' ' ' mermaid
graph TD
    A["Knowledge ecosystem"]

    A --> B["LLMWikis.org<br>Canonical handbook"]
    A --> C["wiki.fftac.org<br>Evidence and provenance"]

    B --> B1["Guide"]
    B --> B2["Reference"]
    B --> B3["Tools"]
    B --> B4["Examples"]
    B --> B5["Comparisons"]
    B --> B6["Glossary and changelog"]

    B1 --> B1a["Getting started"]
    B1 --> B1b["Build"]
    B1 --> B1c["Govern"]
    B1 --> B1d["Operate"]
    B1 --> B1e["Agent guidance"]

    B2 --> B2a["Metadata"]
    B2 --> B2b["Content types"]
    B2 --> B2c["Trust model"]
    B2 --> B2d["Schema"]

    B3 --> B3a["Setup wizard"]
    B3 --> B3b["Starter bundle"]

    C --> C1["Sources"]
    C --> C2["Provenance"]
    C --> C3["Reports"]
    C --> C4["Coverage and indexes"]
    C --> C5["Cross-site relationship pages"]

    C1 --> C1a["uaix"]
    C1 --> C1b["llmwikis"]
    C1 --> C1c["protocol5"]
    C1 --> C1d["spiralist"]

    C2 --> C2a["Public source records"]
    C2 --> C2b["Recovered summaries"]
    C2 --> C2c["Archive evidence"]

    C4 --> C4a["Topic coverage"]
    C4 --> C4b["File coverage"]
    C4 --> C4c["Source coverage"]
' ' ' 

This hierarchy also matches what strong documentation systems do in practice. MDN distinguishes reference, guide, and navigation pages; Docusaurus can generate categories from folders; MkDocs can auto-build navigation from files but will default to alphabetical order if you do not define `nav`, which is exactly why explicit architecture is preferable; GitBook automatically preserves moved pages with 301 redirects; WordPress supports customizable permalinks. In other words, the required behavior is common across modern wiki and docs platforms even though the underlying stack here is unspecified. citeturn28view0turn25view16turn25view17turn25view15turn25view14

### URL schema options

| Option | Example | Strengths | Weaknesses | Recommendation |
|---|---|---|---|---|
| Flat title-first | `llmwikis.org/metadata-standard/` | Easy to publish quickly; short URLs | Weak section meaning; harder to scale; mixed page types at root | Keep only for a few legacy aliases |
| Section-based handbook | `llmwikis.org/reference/metadata/` | Strong information scent; supports breadcrumbs, sidebars, and governance | Requires migration and redirect mapping | **Recommended for LLMWikis.org** |
| Source-first evidence | `wiki.fftac.org/sources/llmwikis/recovered/llm-wiki-readme/` | Makes provenance and ownership explicit; avoids conceptual ambiguity | Longer paths; needs consistent taxonomy | **Recommended for wiki.fftac.org** |
| Hybrid report path | `wiki.fftac.org/reports/cross-site/relationship-audit/` | Clean separation for reports and audits | Requires controlled report taxonomy | Recommended for time-bound reports and audits |

### Recommended canonical URL rules

For **LLMWikis.org**, use a stable section-based scheme such as the following:

- `llmwikis.org/guide/what-is-an-llm-wiki/`
- `llmwikis.org/guide/build/`
- `llmwikis.org/guide/governance/`
- `llmwikis.org/reference/metadata/`
- `llmwikis.org/reference/content-types/`
- `llmwikis.org/reference/trust-model/`
- `llmwikis.org/tools/setup-wizard/`
- `llmwikis.org/examples/personal/`
- `llmwikis.org/comparisons/rag/`

For **wiki.fftac.org**, use a source-first and evidence-first scheme such as the following:

- `wiki.fftac.org/sources/llmwikis/public/`
- `wiki.fftac.org/sources/llmwikis/recovered/llm-wiki-readme/`
- `wiki.fftac.org/sources/uaix/public/`
- `wiki.fftac.org/provenance/llmwikis/starter-bundle/`
- `wiki.fftac.org/reports/cross-site/relationship-audit/`
- `wiki.fftac.org/coverage/topics/`
- `wiki.fftac.org/coverage/files/`
- `wiki.fftac.org/coverage/sources/`

The rule set should be strict:

| Rule | Recommended behavior | Example |
|---|---|---|
| Use lowercase and hyphens | Avoid casing drift and inconsistent tokenization | `llm-wiki-readme` |
| Make hierarchy semantic | Path should describe section and job, not just title | `reference/metadata/` |
| Do not use “Part 1 / Part 2” as canonicals | Use subject names; keep sequencing in subheads or local nav | `guide/migration-planning/` not `guide/part-2/` |
| Avoid dates unless the content is inherently time-bound | Reports and logs may use dates; concepts and guides should not | `reports/archive-transfer-2026-04-28/` is acceptable; `guide/build-2026-04-28/` is not |
| Keep file-system names out of handbook canonicals | A user-facing concept slug is better than a raw file name | `reference/readme/` can be an alias; primary page should be about the concept |
| Separate title from slug | Titles can evolve for readability without constantly changing URLs | Title tweak does not require URL change |
| Limit depth | Handbook paths should usually stay within 2–3 meaningful levels | `guide/build/setup-wizard/` |
| Generate aliases on rename | Preserve historical and common-name access paths | Old path becomes 301 alias |

Breadcrumbs should mirror this hierarchy. Google’s breadcrumb guidance is explicit that breadcrumb trails help users understand a page’s position in the hierarchy and explore the site effectively. On these sites, that means examples like **Home > Guide > Build > Setup wizard** for LLMWikis and **Home > Sources > LLMWikis > Recovered > LLM Wiki README** for wiki.fftac.org, with matching `BreadcrumbList` structured data. citeturn25view4

### Canonicals, redirects, and indexation policy

A simple policy works best:

- **LLMWikis handbook pages**: self-canonical, indexable, included in sitemap.
- **wiki.fftac.org unique provenance pages**: self-canonical if they add distinct evidentiary value.
- **wiki.fftac.org convenience duplicates of handbook content**: either cross-domain canonical to LLMWikis or `noindex,follow` if the page is mostly a retrieval convenience.
- **Large generated/faceted/search-result pages**: keep out of indexed surface unless they truly serve a browse use case; Google recommends careful handling of problematic and faceted URLs. citeturn25view3turn25view2

## Guidance and setup wizard redesign

The wizard should stop behaving like an expert checklist first and a setup assistant second. Structuring forms guidance from GOV.UK recommends knowing why you are asking each question, using branching questions, and starting with one thing per page so users can focus, recover from errors, and move through unfamiliar processes. That maps directly onto the current wizard’s biggest pain point: too many advanced decisions appear too early. citeturn34view0turn32view0turn32view1

### Proposed wizard flow