Improving wiki.fftac.org Org And Llmwikis Org Guidance, Setup Wizard, And Site Structure - Source Excerpt 03 - Required metadata for all public pages

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

Summary

This source excerpt begins near Required metadata for all public pages 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

| Proposed step | What the user decides | Core output | Advanced branches |
|---|---|---|---|
| Site role | Is this a handbook, evidence hub, or mixed internal workspace? | Domain role, canonical ownership, audience | Mixed/internal only |
| Scope and audience | What topics belong here, and for whom? | Scope statement, primary audiences, exclusions | Legal/compliance or confidential modes |
| Content model | Which page types will exist? | Page-type set, templates, review classes | Provenance/report/log variants |
| Navigation and taxonomy | Where should content live? | Section map, categories, tags, breadcrumbs | Multisite and workspace variants |
| URL and naming policy | How are pages titled, slugged, aliased, and canonicalized? | Slug rules, redirects, canonical rules | Legacy migration mapping |
| Governance and review | Who owns and approves content? | Roles, review cadence, stale rules | Multiple teams/vendors |
| Generate package | What scaffolding and policies should be created? | Templates, schema, redirect map, starter files | Graph/export modules if explicitly enabled |

The wizard should also become **branching and progressive**. The default path for a new public handbook should not ask about GraphRAG, WordPress runtime artifacts, multi-repo Git health, or archive-transfer patterns unless the user has already signaled that those features apply. Those are valuable advanced branches, but they should be conditional, not foundational. citeturn32view0turn32view1turn32view3turn34view0

### Required metadata for all public pages

LLMWikis already has a solid metadata standard. MDN similarly requires core front matter like `title`, `slug`, and `page-type`, and its page structure model shows the value of explicit page-type architecture. The next step is to make that metadata richer and more operational by connecting it to taxonomy, canonicalization, and navigation. citeturn24view0turn28view0

| Field | Required | Why it matters | Example |
|---|---|---|---|
| `title` | Yes | Human-visible identity and search title basis | `Metadata standard` |
| `summary` | Yes | One-sentence purpose; basis for snippets and cards | `Required frontmatter and review metadata for LLM Wiki pages.` |
| `page_type` | Yes | Drives template, taxonomy, and navigation behavior | `guide`, `reference`, `tool`, `provenance`, `report` |
| `slug` | Yes | Stable canonical path segment | `metadata` |
| `section` | Yes | Primary hierarchical parent | `reference` |
| `canonical_owner` | Yes | Clarifies which domain owns the topic | `llmwikis.org` |
| `canonical_url` | Yes | Prevents duplicate-intent ambiguity | canonical path on current domain or cross-domain |
| `aliases` | Recommended | Preserves old titles, common spellings, and migrated paths | `metadata-standard`, `page-schema-standard` |
| `owner` | Yes | Prevents ownerless authority | `Documentation lead` |
| `status` | Yes | Separates authoritative, draft, historical, deprecated, etc. | `authoritative` |
| `last_reviewed` | Yes | Freshness and stale detection | `2026-05-01` |
| `review_cycle` | Yes | Enforceable review cadence | `quarterly` |
| `audience` | Yes | Navigation and search filtering | `humans, AI agents, search systems` |
| `sensitivity` | Yes | Prevents unsafe exposure | `public`, `internal`, `restricted` |
| `agent_use` | Yes | Clarifies AI permissions | `allowed-with-citation` |
| `category` | Yes | One primary browse home | `Reference` |
| `tags` | Recommended | Secondary discovery facets | `metadata`, `governance`, `templates` |
| `related_pages` | Recommended | Contextual discovery and graph links | list of sibling/next pages |
| `source_url` | Conditional | Mandatory for evidence/provenance pages | upstream source record |
| `source_site` | Conditional | Mandatory for wiki.fftac.org source-derived pages | `llmwikis.org` |
| `breadcrumbs_override` | Optional | Needed only for atypical hierarchy | explicit breadcrumb path |

The wizard should collect a **small core set first**: `site role`, `scope`, `audience`, `page type`, `section`, `title`, `summary`, `owner`, `review cadence`, `canonical owner`, and `URL policy`. More specialized fields should appear only when relevant. That follows GOV.UK’s “know why you’re asking every question” rule and keeps the setup experience legible. citeturn34view0

### Automated taxonomy suggestions and slug generation

The setup wizard should generate suggestions from a single source-of-truth registry, following the pattern LLMWikis already uses for starter templates, where the visible examples and downloadable bundle come from the same canonical registry. That is exactly the right model to extend to sections, page types, tags, skeleton files, and URL rules. citeturn40view0

The automation logic should work like this:

- infer **page type** from user intent and selected site role;
- suggest **section** from page type and summary;
- propose **slug** from normalized title, but enforce the site’s section-based path policy;
- generate **aliases** from prior names, file names, and common query forms;
- suggest **related pages** from same section, same tags, and same entities;
- create a **meta description** from the summary and page metadata, because Google explicitly encourages unique, human-readable, and even programmatically generated descriptions for large sites when done well. citeturn35view3turn35view4

Autogeneration should remain **assistive, not authoritative**. Docusaurus and MkDocs both show why: they can generate navigation from the filesystem, but MkDocs will auto-sort by filename if navigation is not explicitly defined. That is convenient for scaffolding and dangerous for long-term information architecture. Use automation for suggestions, then require editorial confirmation for final taxonomy placement. citeturn25view16turn25view17

## Content templates, naming conventions, and discovery

A scalable wiki lives or dies by page types and naming rules. MDN explicitly distinguishes guide, reference, and navigation pages. Wikipedia’s title guidance says good titles are recognizable, natural, precise, concise, and consistent, and it also recommends creating redirects for names readers may reasonably search for. MediaWiki’s category system exists precisely to support browseable hierarchies and automatic indexes. Those three models should anchor the content policy here. citeturn28view0turn27view2turn25view8

### Recommended public page types

For **LLMWikis.org**, the primary types should be:

- **Guide**: explanatory, task-oriented, sequence-based content such as getting started, build, governance, and operations.
- **Reference**: standards, metadata, trust model, schema, page-type definitions, and naming conventions.
- **Tool**: setup wizard, starter bundle, checklists, validators.
- **Example**: personal wiki, team wiki, and worked page examples.
- **Comparison**: LLM Wiki vs. RAG, LLM Wiki vs. AI Memory.

For **wiki.fftac.org**, the primary types should be:

- **Source overview**: public source context per upstream site.
- **Recovered summary**: provenance-oriented page about a specific source object.
- **Provenance record**: source, archive, and duplicate-resolution information.
- **Report**: audit, relationship analysis, coverage, migration report.
- **Coverage index**: topic, source, and file coverage hubs.

This structure also corrects a current imbalance. Some wiki.fftac.org pages are compact and probably should remain public records, but not every recovered item deserves equal indexable prominence. The handbook should explain; the evidence site should prove. citeturn14view0turn14view1turn30search12

### Naming conventions

Canonical naming rules should be simple and enforceable:

- Use the exact brand casing for site names: **wiki.fftac.org**, **LLMWikis**, **UAIX**.
- Use **sentence case** or another single editorial standard consistently across public page titles, except where brand names require special casing. Wikimedia governance guidance favors sentence case where possible. citeturn17search12
- Do not use **“Part 1,” “Part 2,” “revised publication report,” “set,”** or internal workflow labels as the canonical title for evergreen concept pages.
- If the content is a true report, label it as a report. If it is a concept page, title it as the concept.
- Use dates only for genuine logs, releases, or time-bound reports.

Examples:

- Prefer **`wiki.fftac.org navigation improvements`** over **`Part 2 of improving wiki.fftac.org`**.
- Prefer **`Relationship audit`** or **`Cross-site relationship audit`** over **`Relationship Audit Set 2026-04-29`** as the evergreen concept page; the dated run can remain a child report.
- Prefer **`What is an LLM Wiki`** as the canonical concept page and **`Publication review of What is an LLM Wiki`** as a separate report page.