Starter Template

---
title: "LLM Wiki README"
owner: "Knowledge steward"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "monthly or when the wiki scope changes"
audience: "humans and AI agents"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# LLM Wiki README

## Purpose
Act as the front door for humans and AI agents by defining the wiki scope, reading order, ownership, and safe starting workflow.

## What To Write
- Name the domain this LLM Wiki covers and the domains it does not cover.
- Link the first five pages a new maintainer should read.
- State where authoritative decisions, policies, runbooks, and open questions live.
- Include a one-paragraph quick start for humans and a one-paragraph quick start for AI agents.

Example:

This wiki covers the Acme Billing Platform: product context, system architecture, release operations, support procedures, decisions, policies, and approved agent instructions. It does not contain secrets, customer records, raw incident chat logs, legal advice, or unreviewed strategy drafts.

## Owner And Review Cadence
- Owner role: Knowledge steward
- Review frequency: monthly or when the wiki scope changes
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Read this first. Use it to decide whether the wiki is in scope for the current task, then follow the linked index, governance, and agent rules before making edits.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "LLM Wiki Index"
owner: "Documentation lead"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "every approved content change"
audience: "humans, AI agents, search systems"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# LLM Wiki Index

## Purpose
Provide deterministic navigation so humans and agents can route through the wiki without scanning every file.

## What To Write
Create sections for organization, products, architecture, operations, decisions, policies, agent rules, and onboarding. Each entry should include path, summary, owner, status, sensitivity, last reviewed date, and related pages.

Example row:

| Path | Summary | Owner | Status | Sensitivity | Last reviewed | Related |
|---|---|---|---|---|---|---|
| architecture/SYSTEM_OVERVIEW.md | Current system boundaries and service map. | Platform Team | authoritative | internal | 2026-04-28 | architecture/SERVICES.md, decisions/DECISION_LOG.md |

## Owner And Review Cadence
- Owner role: Documentation lead
- Review frequency: every approved content change
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Use this as the routing table. Select the smallest useful page set before opening deeper files, and update it whenever durable pages are added, renamed, archived, or reclassified.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "LLM Wiki Governance"
owner: "Knowledge governance owner"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "quarterly and after governance changes"
audience: "maintainers, reviewers, contributors, AI agents"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# LLM Wiki Governance

## Purpose
Define ownership, review, approval, archival, and escalation rules for the wiki.

## What To Write
Document page ownership, required reviewers, approval thresholds, review cycles, archival rules, and what counts as a high-impact change. Name who can approve policy, security, privacy, architecture, production, and public-facing changes.

Recommended sections:
- Ownership model
- Review cycles by page type
- Approval matrix
- AI-generated edit policy
- Deprecation and archive process
- Escalation path

## Owner And Review Cadence
- Owner role: Knowledge governance owner
- Review frequency: quarterly and after governance changes
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Use this to decide whether an edit can be made directly, proposed as a draft, or blocked until a human approves it.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "LLM Wiki Trust Model"
owner: "Governance and security reviewers"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "quarterly or when labels change"
audience: "humans, AI agents, auditors"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# LLM Wiki Trust Model

## Purpose
Explain the trust labels, sensitivity labels, source-of-truth rules, and agent permissions used across the wiki.

## What To Write
Define these labels and how agents should interpret them:
- authoritative: current source of truth inside this wiki.
- working-draft: useful but not approved.
- proposal: candidate future state.
- needs-review: stale, incomplete, conflicting, or ownerless.
- historical: context only.
- deprecated: superseded and unsafe to follow for current work.
- external-reference: useful outside source, not owned by this wiki.

Also define sensitivity labels such as public, internal, confidential, restricted, and never-store.

## Owner And Review Cadence
- Owner role: Governance and security reviewers
- Review frequency: quarterly or when labels change
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Use labels exactly. Never treat a draft, proposal, historical note, deprecated page, or external reference as approved policy.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "LLM Wiki Contributing Guide"
owner: "Documentation lead"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "quarterly or when workflow changes"
audience: "contributors, maintainers, AI agents"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# LLM Wiki Contributing Guide

## Purpose
Tell humans and AI agents how to propose useful changes without turning the wiki into an unreviewed dump.

## What To Write
Describe the contribution path:
1. Read README, INDEX, GOVERNANCE, TRUST_MODEL, and relevant page owners.
2. Classify the change as correction, update, new page, archive, policy change, or sensitive change.
3. Preserve citations and provenance.
4. Add or update related links.
5. Request the correct reviewer.

State what is not accepted: secrets, customer records, unapproved policy rewrites, uncited claims, and vague bulk rewrites.

## Owner And Review Cadence
- Owner role: Documentation lead
- Review frequency: quarterly or when workflow changes
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Use this before changing files. Prefer narrow edits, preserve citations, add review notes, and avoid mixing unrelated fixes.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "LLM Wiki Changelog"
owner: "Knowledge steward"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "every release or approved change batch"
audience: "maintainers, auditors, AI agents"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# LLM Wiki Changelog

## Purpose
Record durable wiki changes so future maintainers can understand what changed, why, and who reviewed it.

## What To Write
Use dated entries with changed pages, reason, reviewer, source references, and follow-up tasks.

Example:

## 2026-04-28
- Updated architecture/SYSTEM_OVERVIEW.md to reflect the new billing-worker boundary.
- Added decision DEC-004 on asynchronous invoice retries.
- Reviewer: Platform Team lead.
- Follow-up: update operations/RUNBOOKS.md before the next release.

## Owner And Review Cadence
- Owner role: Knowledge steward
- Review frequency: every release or approved change batch
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Append entries. Do not rewrite history except to correct factual mistakes with a note.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "LLM Wiki Glossary"
owner: "Domain owner or documentation lead"
status: "working-draft"
trust_level: "reviewed"
last_reviewed: "YYYY-MM-DD"
review_cycle: "monthly and when terminology changes"
audience: "new humans, AI agents, reviewers"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# LLM Wiki Glossary

## Purpose
Define organizational terms, acronyms, product names, service names, roles, and domain concepts in a way agents can cite.

## What To Write
Each entry should include term, plain definition, owner, related pages, and forbidden interpretations.

Example:

## Ledger Event
Authoritative definition: An immutable event emitted by the billing ledger after validation.
Owner: Billing Platform Team.
Do not infer: A ledger event is not the same as a payment gateway webhook.
Related: architecture/DATA_FLOWS.md, operations/RUNBOOKS.md

## Owner And Review Cadence
- Owner role: Domain owner or documentation lead
- Review frequency: monthly and when terminology changes
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Use glossary definitions when interpreting ambiguous names. Flag unknown or conflicting terms instead of guessing.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "System Overview"
owner: "Platform or architecture owner"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "quarterly and after major architecture changes"
audience: "engineers, operators, AI agents"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# System Overview

## Purpose
Describe the current system boundary, main components, data flows, dependencies, ownership, and known gaps.

## What To Write
Include:
- Current system purpose and non-goals.
- Component map with owners.
- Critical data flows.
- External dependencies.
- Deployment environments.
- Current constraints and known gaps.
- Links to architecture decisions and runbooks.

Do not bury current state and history together. Use separate sections for current architecture, historical context, and planned changes.

## Owner And Review Cadence
- Owner role: Platform or architecture owner
- Review frequency: quarterly and after major architecture changes
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Use this for high-level orientation, then open service, data-flow, dependency, and decision pages before making implementation claims.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "Architecture Decisions"
owner: "Architecture owner"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "when decisions are proposed, approved, superseded, or retired"
audience: "architects, engineers, AI agents"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# Architecture Decisions

## Purpose
Keep durable architecture decisions close to the system pages they affect.

## What To Write
Use one entry per decision:
- ID and title
- Status: proposed, accepted, superseded, deprecated
- Date
- Owner and approvers
- Context
- Decision
- Alternatives considered
- Consequences
- Related pages

Agents may draft new decision records, but acceptance requires human approval.

## Owner And Review Cadence
- Owner role: Architecture owner
- Review frequency: when decisions are proposed, approved, superseded, or retired
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Use this to avoid re-litigating settled tradeoffs. Preserve rejected options and supersession notes.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "Decision Log"
owner: "Decision owner or accountable lead"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "whenever a durable decision is made"
audience: "humans, AI agents, reviewers"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# Decision Log

## Purpose
Record product, policy, operational, and architecture decisions that should survive chat history, tickets, and personnel changes.

## What To Write
Each decision should include:
- Decision ID
- Date
- Status
- Decision owner
- Problem
- Decision
- Rationale
- Rejected options
- Follow-up work
- Related pages

Use explicit statuses: proposed, accepted, superseded, rejected, blocked, reopened.

## Owner And Review Cadence
- Owner role: Decision owner or accountable lead
- Review frequency: whenever a durable decision is made
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Use approved decisions as constraints. Do not collapse open disagreement into a fake consensus.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "Open Questions"
owner: "Relevant domain owner"
status: "working-draft"
trust_level: "working-draft"
last_reviewed: "YYYY-MM-DD"
review_cycle: "weekly during active work; monthly otherwise"
audience: "owners, reviewers, AI agents"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: false
---

# Open Questions

## Purpose
Keep uncertainty visible instead of letting agents invent answers or treat gaps as settled facts.

## What To Write
Track:
- Question
- Why it matters
- Current owner
- Needed evidence
- Blocked pages or decisions
- Target review date
- Resolution when closed

Agents may add questions when sources conflict, owners are missing, or a requested action lacks approval.

## Owner And Review Cadence
- Owner role: Relevant domain owner
- Review frequency: weekly during active work; monthly otherwise
- Human review required for updates: false
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Check this before answering uncertain questions. If a page depends on an unresolved issue, cite the open question.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "Operations Runbooks"
owner: "Operations owner"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "monthly and after incidents or process changes"
audience: "operators, support staff, AI agents"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# Operations Runbooks

## Purpose
Provide safe, current operating procedures with triggers, steps, checks, rollback paths, and escalation rules.

## What To Write
Each runbook should include:
- Trigger
- Severity or scope
- Preconditions
- Step-by-step procedure
- Verification checks
- Rollback or stop condition
- Required approvals
- Escalation path
- Last successful use

Make dangerous actions explicit and state which actions require a human.

## Owner And Review Cadence
- Owner role: Operations owner
- Review frequency: monthly and after incidents or process changes
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Agents may summarize or check runbooks. They must not execute production actions, approve releases, or bypass human authorization.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "Agent Instructions"
owner: "AI governance owner"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "monthly and after agent workflow changes"
audience: "AI agents and maintainers"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# Agent Instructions

## Purpose
Define how AI agents should read, cite, update, and respect the LLM Wiki.

## What To Write
State:
- Required first-read pages.
- Which paths are read-only.
- Which paths are writable by agents.
- How to identify authoritative pages.
- How to handle stale, conflicting, deprecated, or draft content.
- Final response requirements.
- Actions requiring explicit human approval.

Agents must preserve citations, flag uncertainty, avoid secrets, and never treat drafts as approved policy.

## Owner And Review Cadence
- Owner role: AI governance owner
- Review frequency: monthly and after agent workflow changes
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
This is the operational contract. Read it before editing. Follow the retrieval, update, citation, and safety boundary files it links.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "Agent Retrieval Guide"
owner: "AI governance owner"
status: "working-draft"
trust_level: "reviewed"
last_reviewed: "YYYY-MM-DD"
review_cycle: "monthly or when navigation changes"
audience: "AI agents and retrieval-system builders"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# Agent Retrieval Guide

## Purpose
Tell agents how to choose the smallest useful page set and how to route through the wiki before answering.

## What To Write
Define the retrieval order:
1. README
2. INDEX
3. Trust model
4. Relevant authoritative pages
5. Related decisions and policies
6. Raw sources only when needed

Describe how to handle contradictions, missing pages, draft pages, deprecated pages, and external references.

## Owner And Review Cadence
- Owner role: AI governance owner
- Review frequency: monthly or when navigation changes
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Read INDEX first, prefer authoritative pages, include citations, and open raw sources only when compiled pages are insufficient or need verification.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "Agent Update Rules"
owner: "Knowledge governance owner"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "monthly or when permissions change"
audience: "AI agents, maintainers, reviewers"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# Agent Update Rules

## Purpose
Define when agents may edit, propose, stage, or refuse wiki updates.

## What To Write
Allowed without approval:
- Fix broken internal links.
- Add missing related links.
- Add clearly labeled open questions.
- Draft source summaries from approved sources.

Requires human review:
- Policy changes.
- Security or privacy guidance.
- Architecture decisions.
- Production runbooks.
- Pages marked authoritative.
- Any edit involving sensitive data.

Forbidden:
- Adding secrets.
- Inferring permissions.
- Silently rewriting approved policy.
- Removing disagreement to make text cleaner.

## Owner And Review Cadence
- Owner role: Knowledge governance owner
- Review frequency: monthly or when permissions change
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Apply these rules before writing. If an update crosses a policy, security, privacy, legal, production, or source-of-truth boundary, ask for human approval.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "Agent Citation Rules"
owner: "Documentation lead"
status: "working-draft"
trust_level: "reviewed"
last_reviewed: "YYYY-MM-DD"
review_cycle: "quarterly or when citation standards change"
audience: "AI agents, reviewers, auditors"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# Agent Citation Rules

## Purpose
Make answers and updates traceable by requiring page citations, source paths, and uncertainty labels.

## What To Write
Citation requirements:
- Cite the wiki page path for every important internal claim.
- Cite the source-summary or raw path for evidence-sensitive claims.
- Do not cite memory, vibes, or "common knowledge" for policy, architecture, security, privacy, legal, model, benchmark, or production statements.
- When sources disagree, cite both and label the conflict.

Answer format:
Claim. Source: `architecture/SYSTEM_OVERVIEW.md`; evidence: `raw/architecture/2026-04-platform-review.md`.

## Owner And Review Cadence
- Owner role: Documentation lead
- Review frequency: quarterly or when citation standards change
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Cite local wiki pages for internal knowledge, cite raw/source records for evidence, and state when a claim is unsupported, stale, or contradicted.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "Agent Safety Boundaries"
owner: "Security and governance owners"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "monthly and after incidents or policy changes"
audience: "AI agents, maintainers, security reviewers"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# Agent Safety Boundaries

## Purpose
Protect sensitive data, permissions, production actions, and high-impact decisions from unsafe agent behavior.

## What To Write
Agents must not:
- Store secrets, credentials, private keys, customer records, employee records, or regulated data.
- Infer access rights from page visibility.
- Execute production actions or approve deployments.
- Rewrite authoritative policy without approval.
- Publish drafts as approved guidance.
- Remove uncertainty, disagreement, or source caveats.

Define escalation contacts for security, privacy, legal, production, and governance boundaries.

## Owner And Review Cadence
- Owner role: Security and governance owners
- Review frequency: monthly and after incidents or policy changes
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Treat this as a stop-sign file. If the requested action touches a boundary, ask for explicit human approval or refuse the unsafe part.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.

---
title: "AI Usage Policy"
owner: "AI governance and legal/privacy owners"
status: "working-draft"
trust_level: "authoritative"
last_reviewed: "YYYY-MM-DD"
review_cycle: "quarterly and after policy changes"
audience: "all contributors and AI agents"
sensitivity: "internal"
agent_use: "allowed-with-citation"
human_review_required_for_updates: true
---

# AI Usage Policy

## Purpose
State how people and agents may use AI with the wiki, including review, attribution, privacy, and prohibited uses.

## What To Write
Cover:
- Allowed AI uses: drafting, summarizing, link checking, linting, template filling, and source triage.
- Prohibited uses: secrets processing, unapproved legal advice, private customer data, unreviewed policy publication, production action approval.
- Review requirements by page type.
- Disclosure or attribution requirements.
- Data-handling and redaction rules.
- Incident response if sensitive information is accidentally added.

## Owner And Review Cadence
- Owner role: AI governance and legal/privacy owners
- Review frequency: quarterly and after policy changes
- Human review required for updates: true
- Mark this file `needs-review` if the owner is unknown, the review date is stale, or the content conflicts with a more authoritative page.

## How An LLM Should Use This File
Use this to determine whether AI assistance is allowed for a task and what review is required before output becomes durable knowledge.

## Update Prompt
When updating this file, preserve sources, note uncertainty, update the review date only after human review, and add related pages that a reader or agent should inspect next.