LLMWikis Org Feature And Ui Ux Design Report

LLMWikis.org already has a strong conceptual foundation. The current public site presents itself as a handbook and starter system for “human-readable, machine-consumable knowledge systems,” with explicit routes for St...

Metadata

Field	Value
Source site	llmwikis.org
Source URL	https://llmwikis.org/
Canonical AIWikis URL	https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-432d7901/
Source reference	raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-03/Improvement/setup-wizard-pass/LLMWikis.org Feature and UI UX Design Report.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-03T21:26:52.7586022Z
Content hash	sha256:432d79019c7d38619ed671f04bb8706ddf5e484b61fd70bad6d4c9497e8b3de5
Import status	unchanged
Raw source layer	data/sources/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-03-imp-432d79019c7d.md
Normalized source layer	data/normalized/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-03-imp-432d79019c7d.txt

Current File Content

Structure Preview

• LLMWikis.org Feature and UI UX Design Report
• Executive summary
• Current product posture and design principles
• Personas and information architecture
• Feature roadmap and rationale
• Core features
• Secondary features
• Future features
• Detailed UI specifications
• Discovery and reading
• Content creation and editing
• Collaboration, review, and moderation
• Identity, onboarding, and operations
• Cross-cutting standards
• Accessibility and inclusive interaction
• Search architecture and LLM integration
• Privacy, security, and operational safety
• Internationalization and localization
• Wireframes, flows, and tradeoffs
• Wireframe sketches
• Workflow diagrams
• Design options and trade-offs
• Open questions and limitations

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 45158
• Preview characters: 11989

# LLMWikis.org Feature and UI UX Design Report

## Executive summary

LLMWikis.org already has a strong conceptual foundation. The current public site presents itself as a handbook and starter system for “human-readable, machine-consumable knowledge systems,” with explicit routes for Start, Build, Template, Architecture, Operations, Governance, Agents, and Explore. It already exposes core concepts that many documentation products add only later: stable metadata, trust labels, a source policy, a navigation contract built around `index.md` and `log.md`, a starter bundle generated from a canonical registry, and a two-step ingest pipeline that separates analysis from writes. At the same time, the site explicitly says it does **not** currently claim open editing, live benchmarks, public MCP, certification, or multilingual support. citeturn0view0turn1view1turn2view0turn2view1turn2view3turn2view5

The best product direction is therefore **not** “make it a generic public wiki.” It is to grow LLMWikis.org into a **trust-first, review-driven knowledge platform** with three layers shipped in sequence: a best-in-class reading and discovery experience; a structured contribution and review workflow; and then an agent-aware search and assistant layer that never outruns the site’s evidence model. That approach is consistent with the current handbook, which tells agents to start from the index, cite local sources, stage updates for review, and stop when permissions or evidence are missing. It is also consistent with the current source policy, trust model, and security guidance. citeturn0view0turn2view1turn2view2turn2view6

The most important product choices are these. First, default to **review-gated contributions** rather than open live editing on authoritative pages. GitBook’s change-request model and merge rules show a strong precedent for documentation workflows that feel familiar to software teams, while Confluence’s live docs show where real-time collaboration is valuable for drafts and workshops. Second, build **hybrid search** rather than choosing between keyword search and an LLM answer box: lexical retrieval, facets, and strong metadata should produce the candidate set; semantic reranking and answer synthesis should sit on top of that candidate set, with visible citations and confidence boundaries. Third, make the page itself do more work: every page should expose owner, status, freshness, sensitivity, allowed agent use, source links, contradictions, history, and related pages in a compact, consistent layout. MediaWiki’s history, diff, categories, watchlist, patrol, and anti-abuse model are still the best benchmark for durable collaborative knowledge systems, while GitBook and Confluence offer better patterns for modern editor ergonomics, review flows, and collaborative context. citeturn17view2turn17view3turn17view4turn17view15turn17view16turn15view5turn12view6turn12view8turn12view12turn28view0turn16view2turn16view4

The direction also matches the themes in your uploaded notes: optimize for **fast helpfulness and durable depth**, and keep durable wiki truth distinct from executable skills or agent capabilities so the information architecture remains governable. fileciteturn0file2 fileciteturn0file3

## Current product posture and design principles

The existing handbook already tells us what the UI should protect. Its metadata standard requires fields like `title`, `owner`, `status`, `last_reviewed`, `review_cycle`, `sensitivity`, and `agent_use`, explicitly so the system can tell humans and agents what a page is, how current it is, who owns it, and what downstream actions are allowed. Its trust model uses a deliberately small set of operational labels such as `authoritative`, `working-draft`, `proposal`, `needs-review`, `historical`, `deprecated`, and `external-reference`, and explicitly says labels should exist only when they change reader or agent behavior. citeturn2view0turn2view1

Its navigation guidance is equally opinionated. The site says a good LLM Wiki should not make the model brute-force every file; instead it should offer a compact catalog, an append-only action log, stable frontmatter, and explicit wiki-links so both humans and agents can route with predictable cost. The navigation contract pairs readable entry points for humans with machine-routable summaries, status panels, and typed links for agents. citeturn2view3

Its ingestion and publication model is also clear. The two-step ingest pipeline separates hash/register, analyze, stage, review, write, and lint so interpretation and edits can be reviewed before the wiki changes. The source policy says AI-assisted drafts and notes are not public truth by default, and that reviewed public content still needs source status, authority labels, review date, and a path for readers to verify important claims. Security guidance is equally explicit: do not store secrets, credentials, raw customer data, employee data, regulated records, or privileged legal and strategy materials in the wiki. citeturn2view5turn2view6turn2view2

Those documents imply six product principles for LLMWikis.org:

| Principle | Product implication |
|---|---|
| Evidence before convenience | Every page needs source traceability, visible status, and freshness. |
| Review before authority | Drafts, proposals, and AI-generated changes stay out of the authoritative layer until reviewed. |
| Dual audience by default | All major screens must work for readers and for agent-mediated retrieval. |
| Small, explicit navigation beats corpus search | Hubs, typed links, summaries, owner/status rails, and faceting matter as much as full-text indexing. |
| Trust labels are UI primitives, not back-end metadata | Status, freshness, sensitivity, and allowed agent use should be visible in-page and in-search. |
| Private-by-design operations | Auth, permissions, re-authentication, audit logs, and upload validation are first-order product features, not hidden admin settings. |

That is also why a “generic wiki” design would be a category error here. The current site is closer to a mix of MediaWiki’s durability model, GitBook’s documentation workflow, and Confluence’s collaboration utilities than to a loose community wiki. MediaWiki remains the benchmark for revision history, diffs, categories, watchlists, patrol, page protection, and anti-abuse tooling. GitBook demonstrates a modern documentation workflow with markdown plus block editing, PR-like change requests, merge rules, permissions inheritance, AI search, cited answers, and contextual assistant behavior. Confluence demonstrates stronger patterns for inline comments, live collaboration, page-level permissions, labels, user profile summaries, and content analytics. citeturn17view2turn17view3turn17view4turn17view14turn17view15turn17view16turn9view0turn8view2turn15view5turn14view4turn12view12turn28view0turn16view2turn16view4turn16view10turn16view12turn16view14turn16view8

## Personas and information architecture

The present handbook already names three reader paths: **personal builder**, **team maintainer**, and **technical writer**. Because the site has an explicit “For AI agents” pathway and agent rules, it should also name a fourth primary persona: the **agent integrator or tool builder**. I recommend making all four first-class in the product navigation and onboarding. citeturn1view0turn0view0

| Persona | Primary goals | Critical tasks | UX implications |
|---|---|---|---|
| Reader and researcher | Understand a topic quickly, verify claims, follow related concepts, export a citation | Search, compare sources, inspect freshness, copy citations, save pages | Fast search, high-quality summaries, visible trust panel, compact TOC, strong mobile reading mode |
| Contributor and subject-matter expert | Improve content without breaking trust | Draft edits, add sources, comment, respond to review, track changes | Dual-mode editor, template assistance, citation helper, low-friction comments, autosaved drafts |
| Maintainer and knowledge steward | Govern truth, freshness, permissions, and structure | Approve changes, patrol edits, mark stale content, lock pages, manage templates | Review queue, merge rules, patrol tools, status controls, audit logs, analytics |
| Agent integrator and developer | Use LLMWikis content safely in retrieval and assistants | Query sources, inspect page metadata, expose docs to assistants, use structured exports | Stable schema, cited answer mode, llms.txt and API endpoints, machine-readable permissions and status |

The information architecture should use a small number of explicit content object types. The current site already organizes around routes and source maps; the next step is to make the object model visible in the UI and queryable in search. citeturn0view0turn2view3

**Recommended content objects**

| Object | Purpose | Public UI form |
|---|---|---|
| Topic page | Primary durable knowledge page | Article page with trust panel, sources, related pages, history |
| Source record | Raw or canonical evidence object | Source drawer and source page |
| Template | Reusable structured page starter | Template gallery and insert-template modal |
| Change request | Review unit for edits | PR-like screen with overview, comments, checks, diff |
| Collection or hub | Navigation layer | Landing page with child pages, tags, counts, health indicators |
| Decision or contradiction note | Governance and unresolved truth management | Small structured subpage or attached panel |
| User or team profile | Ownership and reputation | Profile page with expertise, contributions, badges, watches |
| Review or moderation item | Patrol and governance queue item | Admin and steward queue views |

**Recommended top navigation**

The global nav should shift from the current handbook-centric route list toward task-centric navigation:

- **Explore**
- **Topics**
- **Sources**
- **Templates**
- **Compare**
- **Ask or Search**
- **Contribute**
- **Review**
- **Profile**

For anonymous visitors, “Review” and “Contribute” should collapse into a single “Sign in to contribute” entry. For signed-in stewards, “Review” should surface queue counts and stale-page alerts. GitBook’s home view is instructive here because it emphasizes open change requests, discussions, comments, and recent page edits; LLMWikis should do the same, but with stronger trust and freshness signals. citeturn8view13turn8view14

```mermaid
flowchart LR
    A[Global nav] --> B[Explore]
    A --> C[Topics]
    A --> D[Sources]
    A --> E[Templates]
    A --> F[Compare]
    A --> G[Ask or Search]
    A --> H[Contribute]
    A --> I[Review]
    A --> J[Profile]

    C --> C1[Topic hub]
    C1 --> C2[Topic page]
    C2 --> C3[Source drawer]
    C2 --> C4[History]
    C2 --> C5[Related pages]
    C2 --> C6[Comments]

    H --> H1[New draft]
    H1 --> H2[Editor]
    H2 --> H3[Change request]

    I --> I1[Review queue]
    I1 --> I2[Diff]
    I1 --> I3[Approve or request changes]
```

## Feature roadmap and rationale

The roadmap should be explicitly phased because the current site itself states that open editing and multilingual coverage are not yet claimed. That means phase order matters more than breadth. citeturn0view0

### Core features

| Feature | Why it belongs in core |
|---|---|
| Universal search with Ask mode | Discovery is the front door for both humans and agents; current LLMWikis structure and GitBook/MediaWiki benchmarks both center routing and search. |
| Trust-aware topic page | The page is where authority must become visible: owner, status, freshness, sensitivity, source trail, contradictions, and citations. |
| Structured source and citation system | LLMWikis’ own model is source-first; citations are not optional chrome. |
| Dual-mode editor | Writers need both rich editing and markdown literacy; GitBook and MediaWiki strongly validate this combination. |

Why This File Exists

This is a memory-system evidence file from llmwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: LLMWikis.org Feature and UI UX Design Report; Executive summary; Current product posture and design principles; Personas and information architecture; Feature roadmap and rationale; Core features; Secondary features; Future features. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-334 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "LLMWikis Org Feature And Ui Ux Design Report",
    "source_site":  "llmwikis.org",
    "source_url":  "https://llmwikis.org/",
    "canonical_url":  "https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-432d7901/",
    "source_reference":  "raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-03/Improvement/setup-wizard-pass/LLMWikis.org Feature and UI UX Design Report.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:432d79019c7d38619ed671f04bb8706ddf5e484b61fd70bad6d4c9497e8b3de5",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-03T21:26:52.7586022Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-334",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}