Structure Standard

An LLM Wiki should separate orientation, ownership, organization context, product context, architecture, operations, decisions, policies, agent rules, and onboarding. The structure below is intentionally boring: predictable paths are what make the wiki useful to agents. When OKF mode is enabled, wiki/ is the Open Knowledge Format bundle root while raw/ remains immutable evidence outside the compiled concept graph.

OKF bundle rules

• wiki/index.md is the OKF routing entry. Its frontmatter may contain only okf_version.
• wiki/log.md is the history file and should use newest-first date headings.
• Nested index.md files are local route maps and should not carry frontmatter.
• Every other Markdown file under wiki/ should include YAML frontmatter with type plus LLMWikis governance fields.
• raw/ stores immutable source files, checksums, and source records; do not treat raw evidence as compiled OKF concept pages.

Recommended folder structure

README.md
AGENTS.md
SCHEMA.md
WIKI_STRUCTURE_PLAN.md
WIKI_MIGRATION_PLAN.md
frontmatter.schema.json
okf.profile.json
page-registry.example.json
redirects.example.csv
aliases.example.yaml
INTAKE_OUTCOME_LEDGER.md
LINT_CHECKLIST.md
REVIEW_CHECKLIST.md
FOLDED_RUN_STATE.example.json
llms.example.txt
scripts/
  llmwiki-okf-validate.js
  llmwiki-okf-migrate-frontmatter.js
llm-wiki/matm/
  README.md
  MATM_POLICY.md
  MATM_WIKI_DECISION_GUIDE.md
  MEMORY_SCOPE_MATRIX.md
  MEMORY_TAXONOMY.md
  MEMORY_EMISSION_CONTRACT.md
  MEMORY_CURATOR_RUNBOOK.md
  CURATION_DECISION_TABLE.md
  RETRIEVAL_POLICY.md
  SECURITY_AND_PRIVACY.md
  EVALUATION_PLAN.md
  MIGRATION_CHECKLIST.md
  schemas/
    memory-event.schema.json
    memory-record.schema.json
    curation-report.schema.json
    transactive-directory.schema.json
    retrieval-request.schema.json
    retrieval-response.schema.json
  examples/
    memory-event.example.json
    memory-record.example.json
    curation-report.example.json
    transactive-directory.example.json
    retrieval-request.example.json
    retrieval-response.example.json
    reference-api.openapi.yaml
  fixtures/
    invalid-kind.example.json
    invalid-scope.example.json
    missing-required.example.json
    direct-worker-write.example.json
    non-utc-timestamp.example.json
    secret-field.example.json
raw/
  README.md
wiki/
  index.md
  log.md
  knowledge-map.md
  global/
    index.md
    coding-standards.md
    organization.md
    governance.md
    source-map.md
  {Site}/
    index.md
    log.md
    source-policy.md
    review-gates.md
    concepts/
    runbooks/
    decisions/
  _templates/
    concept.md
    guide.md
    reference.md
    source-record.md
    evidence-log.md
    redirect-record.md

Legacy expanded example tree:
llm-wiki/
  README.md
  INDEX.md
  GOVERNANCE.md
  TRUST_MODEL.md
  CONTRIBUTING.md
  CHANGELOG.md
  organization/
    MISSION.md
    PRINCIPLES.md
    TEAMS.md
    GLOSSARY.md
  products/
    PRODUCT_OVERVIEW.md
    ROADMAP.md
    CUSTOMER_SEGMENTS.md
    FEATURE_INVENTORY.md
  architecture/
    SYSTEM_OVERVIEW.md
    SERVICES.md
    DATA_FLOWS.md
    DEPENDENCIES.md
    ARCHITECTURE_DECISIONS.md
  operations/
    RUNBOOKS.md
    INCIDENTS.md
    RELEASE_PROCESS.md
    SUPPORT_PROCESS.md
  decisions/
    DECISION_LOG.md
    OPEN_QUESTIONS.md
    TRADEOFFS.md
  policies/
    SECURITY.md
    PRIVACY.md
    DATA_HANDLING.md
    AI_USAGE_POLICY.md
  agent/
    AGENT_INSTRUCTIONS.md
    RETRIEVAL_GUIDE.md
    ORCHESTRATION_RUNBOOK.md
    TASK_PACKET_TEMPLATE.md
    SUPPORT_ESCALATION_CHECKLIST.md
    LONG_RUN_AGENT_STRATEGY.md
    PROCESS_QUALITY_CHECKS.md
    UPDATE_RULES.md
    CITATION_RULES.md
    SAFETY_BOUNDARIES.md
  onboarding/
    HUMAN_ONBOARDING.md
    AGENT_ONBOARDING.md
    QUICK_START.md

Multi-tenant project path

wiki/{client}/{workspace}/{project}/
  index.md
  log.md
  concepts/
  runbooks/
  decisions/

Use this shape when client, workspace, or project boundaries affect authorization, retrieval, review, or audit. Shared roots should route to these counterparts; they should not collect all client material into wiki/global/ or one broad site folder.

Root index topology

Use the root INDEX.md differently depending on the system. A single project can use it as the local routing index and retrieval map. A multisite or multi-project LLM Wiki should keep the root index narrow: list the sub-wiki directories, link to each project-level INDEX.md and LOG.md, and list only global files such as coding standards, organization policy, governance, source maps, and workspace.uai. Each sub-wiki owns its own scoped routing index and scoped activity log; as it grows, that project index should route to child indexes and high-value entry points instead of listing every file. For AIWikis-style public routes, every /{site}/ is its own AI Wikisite, /site/ is the directory, /org/ is the organization namespace, and root /files/, /concepts/, and /reports/ memory indexes are invalid.

Index/log context budget

Surface	Answer	Budget rule
wiki/index.md	Where should I go next?	Route to namespaces, child indexes, and high-value pages; do not list every file once the scope grows.
wiki/log.md	What changed at this level?	Record scoped coordination and point downward; do not collect every child event in the root log.
Child index/log files	What detail belongs here?	Carry the detailed route and change history for that client, workspace, project, or topic.

Global chrome budget

Header and footer chrome should route to tasks and directories, not flatten the wiki. In AIWikis-style multisite routing, primary navigation should stay close to Start, Search, Site Directory, Source Map, Topics, Reports, Org, and Contact. Full source-memory inventories belong in /site/, /org/source-map/, site-scoped source-memory guides, sitemap, and llms.txt. A footer can summarize grouped source-memory and source-site links, but it should not become a duplicate root index.

Why these folders exist

Folder	Job	Agent behavior
organization/	Mission, principles, teams, glossary, and shared language.	Use for orientation and term disambiguation.
products/	Product overview, roadmap, customer segments, and feature inventory.	Use to understand customer-facing context before implementation claims.
architecture/	System overview, services, data flows, dependencies, and architecture decisions.	Use before suggesting technical changes.
operations/	Runbooks, incidents, release process, and support process.	Summarize and check; do not execute protected actions.
decisions/	Decision log, open questions, tradeoffs, and supersession notes.	Preserve uncertainty and rejected options.
policies/	Security, privacy, data handling, and AI usage policy.	Treat as high-authority; require human review for edits.
agent/	Agent instructions, retrieval, update, citation, and safety rules.	Read before editing; follow permission boundaries.
onboarding/	Quick starts for people and agents.	Use for first-session context, not as full authority.