Starter Bundle

---
title: "LLM Wiki README"
owner: "Knowledge steward"
status: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
last_reviewed: "YYYY-MM-DD"
review_cycle: "every approved content change"
audience: "humans, AI agents, search systems"
sensitivity: "internal"
agent_use: "allowed-with-citation"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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.

For one codebase, this INDEX can be the all-files catalog. For a multisite or multi-project LLM Wiki, keep this root INDEX to sub-wiki directories, links to each sub-wiki INDEX, and global-only files such as coding standards, organization policy, governance, source maps, and workspace.uai. Put each site's all-files catalog inside its own sub-wiki index.

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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
last_reviewed: "YYYY-MM-DD"
review_cycle: "quarterly or when labels change"
audience: "humans, AI agents, auditors"
sensitivity: "internal"
agent_use: "allowed-with-citation"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
last_reviewed: "YYYY-MM-DD"
review_cycle: "quarterly or when workflow changes"
audience: "contributors, maintainers, AI agents"
sensitivity: "internal"
agent_use: "allowed-with-citation"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "reviewed"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "working-draft"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: false
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "reviewed"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Agentic Orchestration Runbook"
owner: "AI governance owner"
status: "Proposal/Draft"
trust_level: "reviewed"
source_status: "starter-template"
canonical_url: "/"
last_reviewed: "YYYY-MM-DD"
review_cycle: "monthly and after orchestration workflow changes"
audience: "AI agents, orchestrator operators, reviewers"
sensitivity: "internal"
agent_use: "allowed-with-citation"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# Agentic Orchestration Runbook

## Purpose
Define how agentic agents and orchestration layers should use the LLM Wiki before, during, and after a run.

## What To Write
Before an orchestrated run:
- Name the task boundary: answer, draft, code change, audit, release, or wiki update.
- Read README, INDEX, TRUST_MODEL, AGENT_INSTRUCTIONS, RETRIEVAL_GUIDE, and SAFETY_BOUNDARIES.
- Build a compact task packet with facts, constraints, owners, source links, forbidden actions, and review gates.
- Declare whether agents are read-only, proposal-only, staged-write, or human-approved write.
- Name where run notes, tool outputs, traces, evaluations, proposed changes, and open questions should be saved.

During the run:
- Keep working notes separate from reviewed wiki pages.
- Cite wiki pages, raw sources, and canonical external sources for important claims.
- Preserve stale claims, contradictions, missing owners, and uncertainty as task state.
- Treat runtime traces, tool outputs, and agent messages as evidence inputs until reviewed.

After the run:
- Stage reusable answers or syntheses as wiki drafts with source links and review status.
- Save trace, evaluation, or tool outputs only in approved evidence locations.
- Promote facts into reviewed wiki pages only after source, privacy, owner, contradiction, and freshness checks.
- Keep public MCP, A2A, write API, trace exporter, live evaluation, adapter, SDK, CLI, certification, and managed-service language marked as planned unless current public evidence exists.

## Owner And Review Cadence
- Owner role: AI governance owner
- Review frequency: monthly and after orchestration 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 orchestrated runs. Build a compact task packet, preserve trace and tool outputs as evidence inputs, stage proposed wiki updates, and stop at review boundaries.

## 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: "Agentic Task Packet Template"
owner: "AI governance owner"
status: "Proposal/Draft"
trust_level: "reviewed"
source_status: "starter-template"
canonical_url: "/"
last_reviewed: "YYYY-MM-DD"
review_cycle: "monthly and after orchestration workflow changes"
audience: "orchestrator operators, AI agents, reviewers"
sensitivity: "internal"
agent_use: "allowed-with-citation"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# Agentic Task Packet Template

## Purpose
Provide a compact, reviewable packet for one agentic run without loading the whole wiki or hiding review boundaries.

## What To Write
Use one task packet per orchestrated run.

## Task Boundary

- Run name:
- Requested outcome:
- Task type: answer, draft, code change, audit, release support, wiki update, other
- In scope:
- Out of scope:
- Stop conditions:

## Required Reading

- Wiki pages to read:
- Raw/source records to inspect:
- External canonical sources:
- Pages explicitly not needed:

## Permissions

- Agent mode: read-only, proposal-only, staged-write, human-approved write
- Writable paths:
- Read-only paths:
- Human approval required for:
- Forbidden actions:

## Context Packet

- Current facts:
- Constraints:
- Owners:
- Sensitive-data boundaries:
- Known contradictions:
- Stale or source-needed claims:

## Evidence Destinations

- Run notes path:
- Proposed wiki updates path:
- Tool outputs path:
- Trace or evaluation path:
- Review queue path:
- Roadmap or open-question path:

## Completion Report

- Pages read:
- Sources cited:
- Artifacts changed or proposed:
- Evidence produced:
- Checks run:
- Review questions:
- Follow-up tasks:

Do not treat this packet as durable truth by itself. Promote useful facts only after source, owner, privacy, contradiction, freshness, and verification checks.

## Owner And Review Cadence
- Owner role: AI governance owner
- Review frequency: monthly and after orchestration 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
Fill this before an orchestrated run. Keep it small, cite wiki/source paths, name permissions, and record where evidence and proposed updates should land.

## 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: "Agentic Support Escalation Checklist"
owner: "AI governance owner"
status: "Proposal/Draft"
trust_level: "reviewed"
source_status: "starter-template"
canonical_url: "/"
last_reviewed: "YYYY-MM-DD"
review_cycle: "monthly and after support workflow changes"
audience: "AI agents, orchestrator operators, support reviewers, maintainers"
sensitivity: "internal"
agent_use: "allowed-with-citation"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# Agentic Support Escalation Checklist

## Purpose
Give agents and reviewers a bounded support path when an orchestrated run hits conflicts, missing authority, privacy limits, stale sources, or tool failures.

## What To Write
Use this when an orchestrated run needs support instead of more autonomous work.

## Escalation Triggers

Escalate before continuing when the run hits:

- A conflict between reviewed wiki pages or canonical sources.
- A source-needed, stale, deprecated, or ownerless claim that affects the answer or edit.
- Secrets, private transcripts, customer data, regulated data, or unclear consent.
- Security, privacy, legal, production, financial, medical, or policy decisions.
- Tool failure, partial execution, missing logs, missing tests, or unverifiable output.
- A requested action outside the task packet or outside current agent permissions.
- A claim about public MCP, A2A, write API, trace exporter, live evaluation, adapter, SDK, CLI, certification, managed service, or official support without current public evidence.

## First Response

- Stop the unsafe or unsupported action.
- Preserve current notes, tool outputs, citations, and error messages in the approved evidence destination.
- Name the trigger in plain language.
- Separate known facts from assumptions, proposals, and open questions.
- Do not edit reviewed wiki pages until the escalation is resolved.

## Support Packet

- Run name:
- Task packet path:
- Trigger:
- Pages read:
- Sources cited:
- Tool outputs or traces:
- Sensitive-data concern:
- Contradiction or stale claim:
- Proposed next action:
- Human reviewer needed:
- Checks already run:
- Follow-up owner:

## Resolution Paths

- If sources conflict, stage both claims with citations and ask the owner which source wins.
- If authority is missing, create an open question instead of inventing policy.
- If private data appears, stop, minimize exposed detail, and ask the data owner or privacy reviewer.
- If a tool fails, record exact command, output, environment, and retry status before proposing another run.
- If the request widens support claims, keep the language planned, candidate, or blocked until implementation evidence exists.
- If the task is complete but reusable, stage a reviewed wiki update with source links and checks.

## Completion Note

End the escalation with:

- Resolution:
- Artifacts updated:
- Evidence preserved:
- Wiki pages proposed:
- Human approvals:
- Remaining blockers:

This checklist is support guidance for governed wiki operations. It does not create a public runtime, support service, MCP server, A2A implementation, write API, trace exporter, live evaluation integration, SDK, CLI, certification, endorsement, or managed-service claim.

## Owner And Review Cadence
- Owner role: AI governance owner
- Review frequency: monthly and after support 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 when a run cannot safely continue. Preserve evidence, classify the issue, stop unsafe work, and ask for the right human review instead of widening support 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: "Agent Update Rules"
owner: "Knowledge governance owner"
status: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
last_reviewed: "YYYY-MM-DD"
review_cycle: "monthly or when permissions change"
audience: "AI agents, maintainers, reviewers"
sensitivity: "internal"
agent_use: "allowed-with-citation"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "reviewed"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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: "Proposal/Draft"
trust_level: "authoritative"
source_status: "starter-template"
canonical_url: "/"
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"
namespace: "wiki/global/"
workspace_scope: "global"
human_review_required_for_updates: true
typed_relations:
  part_of:
    - "llm-wiki/INDEX.md"
---

# 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.