This is the practical LlmWikis profile for a source-governed, AI-navigable wiki. It defines the minimum contracts that make a wiki safe for humans, search, retrieval, handoff, OKF-compatible bundle exchange, and agent-assisted maintenance. It is not a universal standards claim and it does not replace UAIX for UAI-1, AI Memory, Project Handoff, schemas, registries, validators, or conformance language.
Internal-first default
Most LLM Wikis are internal team or company systems. They exist to preserve product knowledge, architecture, decisions, runbooks, support history, source summaries, and agent operating context behind normal access controls. Public LLM Wikis, public evidence wikis, and private-to-public promotion packets are special publication profiles, not the default path.
Specification boundary
Use these requirements when a project wants to claim it follows the LlmWikis handbook profile. Use UAIX.org for canonical UAI-1 and Project Handoff definitions. A project can adopt part of this profile without claiming certification, endorsement, hosted validation, or automatic write support.
Profile contracts
| Contract | Required behavior | Failure if missing |
|---|---|---|
| Layer contract | Separate immutable raw sources, reviewed wiki pages, index/log navigation, and optional derived graph/search/cache artifacts. | Agents cannot tell evidence from compiled truth. |
| Page contract | Every durable page has title, canonical URL, owner, status, source status, last reviewed date, sensitivity, agent-use rule, and source trace when it makes factual claims. | Search and agents over-trust fluent but unowned pages. |
| Navigation contract | Index, log, breadcrumbs, children, typed related links, aliases, redirects, sitemap, and llms.txt agree on canonical routes. | Readers land on duplicates, stale pages, or orphaned evidence. |
| Trust contract | Authoritative, reviewed, draft, stale, contradicted, deprecated, archived, and blocked states change reader and agent behavior. | Status labels become decorative and unsafe. |
| Source contract | Raw evidence remains preserved or linked; compiled claims cite source pages, source records, or canonical external routes. | Useful synthesis becomes unverifiable. |
| Routing summary contract | Durable reports, coding standards, architecture records, best practices, and handoff-preservation pages expose stable paths, clear headings, one-paragraph routing summaries, review status, last reviewed dates, source/evidence links, checksum or source identity, and discovery through index, source-memory guide, sitemap, llms.txt, route manifest, or equivalent retrieval map. | Agents cannot decide what to load without bulk-scanning raw archives. |
| Agent contract | Agents read the smallest useful page set, cite pages, stage risky updates, preserve uncertainty, and stop on authority, privacy, security, legal, production, or destructive-change boundaries. | Agent work becomes silent rewriting. |
| Operational proof contract | Agents check layered memory, redacted credential inventory, authority scope, target site/domain, deploy capability, route-renderer map, live proof, stale-evidence policy, and storage warnings before claiming deployment or completion. | Build/package evidence, credentials, or stale reports get mistaken for live completion. |
| Renderer coverage contract | Every public claim identifies static root file, API route, shortcode/component, page template, fallback endpoint, and cached/public route coverage when those paths can serve the claim. | One renderer gets updated while the live route keeps serving old guidance. |
| Search contract | Search results expose canonical pages, descriptions, freshness/status signals where available, and route users back to reviewed pages before retrieval or graph layers. | Search becomes a prettier document dump. |
| Validation contract | Lint blocks duplicate canonicals, broken links, private discovery leaks, missing required metadata, unresolved unsafe claims, and generated artifacts posing as authority. | Bad structure compounds across sessions. |
Human guidance for proof and authority
An agent can infer likely routes, likely source files, and likely next checks from instructions and manifests. It cannot infer permission to deploy, permission to use private memory, reviewer approval, paid entitlement, retention authority, or live production state from confidence, local files, or credential presence alone.
| Evidence | What it proves | What it does not prove |
|---|---|---|
| Deploy package built | The package artifact exists locally or in a release path. | The public site is live, uploaded, cache-refreshed, or serving the new markers. |
| Credential exists | A secret-bearing configuration may be available in a named scope. | The agent has authority to use every system feature or expose the secret. |
| Submitter-scoped token | The agent may submit or preview within that token scope. | Reviewer/operator approval, retention/archive repair authority, org-wide private memory search, or paid MATM entitlement. |
| Old audit or proof file | A past check happened. | The current target route, renderer, cache state, or live API/site content is correct now. |
Layered memory and proof order
- Current prompt/session instructions and newest human request.
- Workspace manifest/coordinator, including
workspace.uai,AGENTS.md, package model, and deploy instructions. - Hot
.uai/ AI Memory / Project Handoff. - Project reports, ledgers, package manifests, release notes, and test reports.
- Crawlable LLM Wiki, MATM, NeuralWikis, AIWikis, or other durable memory.
- Live API/site proof from the authoritative target before completion claims.
Deployment rule
Memory and credentials are different. If deployment is requested, check workspace instructions and credential inventory before claiming no deploy path exists. Do not print secret values; record redacted locators, owners, scopes, status, expiry, and hashes or fingerprints only.
Renderer coverage requirement
Every public claim must identify all render paths that can serve that claim. A feature is complete only when every relevant renderer includes the same required markers.
| Renderer path | Required marker proof |
|---|---|
| Static root file | Root-file or package output includes the marker. |
| API route | Machine-readable endpoint includes the matching field or marker. |
| Shortcode/component | Rendered component output contains the guidance. |
| Page template | Template path used by the route includes or calls the updated marker source. |
| Fallback endpoint | Fallback or alternate endpoint does not serve stale contradictory content. |
| Cached/public route | Live URL readback after cache refresh shows the marker. |
Machine-readable operational fields
Public and private LLM Wiki records that make deploy, renderer, authority, or live-completion claims should expose these fields when applicable: memory_layers, credential_inventory, authority_scope, deploy_capability, live_proof, stale_evidence_policy, route_renderer_map, storage_warning_policy, and authority_request_route.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://llmwikis.org/spec/llm-wiki-operational-proof.schema.json",
"title": "LLM Wiki Operational Proof Record",
"type": "object",
"required": [
"memory_layers",
"credential_inventory",
"authority_scope",
"deploy_capability",
"live_proof",
"stale_evidence_policy",
"route_renderer_map",
"storage_warning_policy",
"authority_request_route"
],
"properties": {
"memory_layers": {
"type": "array",
"items": { "enum": ["current_prompt_session", "workspace_manifest", "hot_uai_memory", "project_reports", "crawlable_wiki_matm_memory", "live_api_site_proof"] }
},
"credential_inventory": {
"type": "array",
"items": {
"type": "object",
"required": ["locator", "owner", "scope", "status", "fingerprint"],
"properties": {
"locator": { "type": "string", "examples": ["workspace-secret://deploy/production"] },
"owner": { "type": "string" },
"scope": { "type": "string" },
"status": { "enum": ["present", "missing", "expired", "request-pending"] },
"fingerprint": { "type": "string", "pattern": "^sha256:[a-f0-9]{8,64}$" },
"secret_value": false
}
}
},
"authority_scope": {
"type": "object",
"properties": {
"token_scope": { "type": "string", "examples": ["submitter-scoped"] },
"reviewer": { "type": "boolean" },
"operator": { "type": "boolean" },
"retention_archive_repair": { "type": "boolean" },
"org_private_memory_search": { "type": "boolean" },
"paid_matm_entitlement": { "type": "boolean" },
"required_phrase": { "const": "request-pending is not approval." }
}
},
"deploy_capability": {
"type": "object",
"properties": {
"package_built": { "type": "boolean" },
"target_site_domain": { "type": "string" },
"deploy_path_known": { "type": "boolean" },
"live_after_deploy": { "type": "boolean" }
}
},
"live_proof": {
"type": "object",
"properties": {
"route": { "type": "string" },
"checked_at": { "type": "string" },
"renderer": { "type": "string" },
"required_marker": { "type": "string" },
"cache_state": { "type": "string" },
"evidence_hash": { "type": "string", "pattern": "^sha256:[a-f0-9]{8,64}$" }
}
},
"stale_evidence_policy": { "type": "string" },
"route_renderer_map": {
"type": "object",
"required": ["static_root_file", "api_route", "shortcode_component", "page_template", "fallback_endpoint", "cached_public_route"]
},
"storage_warning_policy": {
"type": "object",
"properties": {
"thresholds": { "items": { "enum": ["25%", "10%", "9% through 0%"] } },
"required_actions": { "items": { "enum": ["inform_human", "streamline_memory"] } }
}
},
"authority_request_route": { "type": "string" }
}
}Failure-prevention validation checklist
- Credentials exist outside environment variables: agent checks workspace guidance and credential inventory before saying no deploy path exists.
- A route uses a different renderer: route-renderer map catches the missing shortcode/component, template, API, fallback, static root, or cached route marker.
- Stale proof files are present: agent labels them stale and requires current target readback.
- Live site has cached old content: agent reports the cache blocker and affected route instead of claiming done.
- Current token lacks reviewer/org/retention authority: agent reports the exact missing authority and does not self-grant. request-pending is not approval.
OKF-backed LLMWikis profile
Open Knowledge Format is the portable bundle layer. LLMWikis conformance adds governance behavior on top of that layer. A project can be OKF-readable but still fail LLMWikis conformance if ownership, source status, review, privacy, or agent permissions are missing.
| Requirement | Behavior | Failure if missing |
|---|---|---|
| Bundle root | wiki/ is the OKF bundle root for reviewed concept files. |
Agents cannot distinguish compiled wiki pages from raw or proposal material. |
| Reserved root files | Root wiki/index.md may contain only okf_version frontmatter and should answer where to go next; root wiki/log.md keeps level-local workspace activity and points to project logs in multi-project bundles. |
The routing and history surfaces become ordinary pages, mixed metadata dumps, all-files catalogs, or all-project noise. |
| Concept frontmatter | Every non-reserved .md file under wiki/ has frontmatter with non-empty type. |
The file is not OKF-compatible as a concept document. |
| Governance overlay | Concept pages carry llmwiki_status, llmwiki_owner, llmwiki_source_status, and llmwiki_agent_use. |
OKF validity is mistaken for authority, source trust, or edit permission. |
| Raw-source separation | raw/ preserves source evidence outside the compiled OKF concept graph. |
Compiled answers become indistinguishable from unreviewed source dumps. |
| Unknown-field tolerance | Readers preserve unknown frontmatter keys and custom local metadata. | Migration destroys local governance, search, or platform fields. |
| Link severity | Broken local links warn by default and fail under strict publication checks. | Draft repair work cannot happen without tolerant OKF consumption. |
| Non-claim boundary | OKF compatibility does not imply certification, hosted validation, automatic sync, public MCP, public write API, or publication approval. | Agents overstate support and act beyond permissions. |
Universal wiki profile invariants
All LLMWikis profiles inherit the same base Markdown wiki contract, including ordinary internal wikis, public handbook wikis, handoff-ready wikis, long-run agent wikis, OKF-compatible packages, promotion-ready dogfood wikis, and governed MATM Wiki extensions.
| Invariant | Required behavior | Why it matters |
|---|---|---|
| Markdown concept files | Every non-reserved Markdown concept file under wiki/ has YAML frontmatter with a non-empty type. MATM Memory Events and Memory Records do not replace concept-page frontmatter. |
Concepts remain inspectable pages instead of opaque memory blobs. |
| Reserved index/log files | wiki/index.md and wiki/log.md are reserved routing and history surfaces. In multi-project roots, the root index names namespaces and project-level index/log counterparts; the root log records workspace coordination and points to project logs. Child indexes/logs carry detail for their own scope. |
Root files route the workspace without becoming all-files catalogs or all-project activity dumps. |
| Tolerant readers | Readers preserve unknown frontmatter keys and custom local metadata. Broken local links warn during draft repair and fail strict release or publication checks. | Migration can repair imperfect wikis without losing local governance or source fields. |
| Client/workspace/project partitioning | Scale by tenant or client, workspace, and project or site namespace, for example wiki/{client}/{workspace}/{project}/index.md, wiki/{client}/{workspace}/{project}/log.md, and wiki/{client}/{workspace}/{project}/concepts/. Shared roots route to project-level counterparts; project detail, evidence, and MATM retrieval context stay inside the authorized project boundary unless explicitly escalated. |
Large or multi-site wikis stay navigable and do not leak private or unrelated project memory. |
Conformance profiles
| Profile | Minimum artifacts | Appropriate claim |
|---|---|---|
| Profile A: internal file-native wiki | raw/, wiki/, wiki/index.md, wiki/log.md, README, source policy, sensitivity labels, access-owner notes, and owner/status metadata. |
The project has an exportable internal source-backed wiki skeleton. |
| Profile B: internal agent-ready wiki | Profile A plus AGENTS.md or CLAUDE.md, agent read order, update rules, citation rules, stop conditions, staged-write policy, local route manifest, private-file exclusion, and review checklist. | Humans and agents can use the internal wiki under explicit access, source, and review boundaries. |
| Profile C: public handbook or public knowledge wiki | Profile B plus canonical public routes, sitemap, llms.txt, metadata descriptions, redirects, noindex/archive policy, license review, correction route, and public/private exclusion tests. | The rare public surface is crawler-readable, source-aware, and publication-reviewed. |
| Profile D: graph/retrieval-ready wiki | Profile B or C plus stable IDs, typed relations, claim/source-span policy, contradiction records, graph lint, retrieval filters, and abstention rules. | Internal search, graph views, retrieval caches, or public search surfaces can be derived from reviewed pages. |
| Profile E: handoff-ready wiki | Profile D plus hot/cold memory boundary, AI Memory or Project Handoff pointers when used, transfer evidence log, and archive manifest discipline. | Durable internal wiki memory can safely feed compact handoff context. |
| Profile F: governed MATM extension | Profile E plus the universal wiki invariants, proposal-only Memory Events, curator reports, scoped Memory Records, retrieval policy, privacy controls, and negative fixtures. | Multiple agents can reuse reviewed agent experience without direct worker writes. |
| Profile G: dogfood promotion-ready wiki | Profile F or a narrowed Profile D/E plus promotion gates, public-safe rewrite records, source possession evidence, durable copies, redaction review, lane review, supersession records, enhanced entity pages, and release notes. | Private agent-memory lessons can become public guidance only through reviewed, source-traced, non-claim-aware promotion packets. |
| Profile H: OKF-compatible package | Profile A/B plus okf.profile.json, OKF-compatible wiki/index.md and wiki/log.md, concept frontmatter with type, LLMWikis governance overlay fields, and validation or migration scripts. |
The wiki can be exchanged as an OKF-style Markdown/YAML bundle while preserving LLMWikis review and source boundaries. |
Optional MATM Wiki extension profile
A MATM Wiki is an optional extension of the LlmWikis profile, not the default endpoint for every wiki. Use it only when multiple agents produce reusable operational experience that later agents should retrieve with scope, source status, permissions, citations, abstention, curation, adoption preview, rollback, and audit evidence. If the project mostly needs reviewed human documentation, static source summaries, or one-agent preference memory, stop at the ordinary LLM Wiki profile.
| MATM Wiki requirement | Required evidence | Failure if missing |
|---|---|---|
| Base wiki contract | The MATM extension inherits required type frontmatter for concept files, reserved wiki/index.md/wiki/log.md, unknown-field preservation, broken-link warning/strict behavior, and client/workspace/project partitioning. |
MATM becomes a separate memory silo that bypasses the wiki’s navigation, metadata, and scale rules. |
| Fit decision | llm-wiki/matm/MATM_WIKI_DECISION_GUIDE.md or equivalent page explaining why ordinary LLM Wiki is insufficient, what shared agent experience exists, and who owns curation. |
MATM is added because it sounds advanced, not because the system needs governed shared agent memory. |
| Lane map | Documented split between human education, agent exchange, builder guidance, canonical standards authority, protected mutation, and operator evidence. | One surface tries to teach humans, route agents, host schemas, accept submissions, expose evidence, and imply runtime authority. |
| Public profile | Machine-readable MATM profile with version, canonical routes, capability truth labels, source authority, support boundary, storage status, and explicit non-claims. | Agents cannot tell which MATM surfaces are public guidance, previews, protected routes, or production claims. |
| Route taxonomy | Every endpoint or file is classified as public GET discovery, public non-mutating preview, protected submitter route, protected reviewer decision, protected reader route, operator evidence, or storage truth label. | Visibility is mistaken for credentials, trust, write permission, authorization, or production readiness. |
| Proposal-only write path | Memory Event schema, negative direct-write fixture, quarantine or proposal queue, idempotency rule, provenance, and review-pending status. | Worker agents can silently create durable memory. |
| Curator decision path | Validation, redaction, dedupe, scope routing, source-quality checks, conflict preservation, disposition, reviewer triggers, and audit log. | Schema-valid but unsafe, private, unsupported, duplicated, or contradictory records become trusted memory. |
| Retrieval policy | Scope, sensitivity, status, freshness, conflict state, authorization, citations, ranking, and abstention requirements before a consumer uses memory. | Retrieval becomes authorization, and stale or private records influence later agents. |
| Adoption and rollback | Sandbox/adoption preview, Memory Firewall controls, no blind import rule, rollback token or equivalent reversal evidence, and quarantine path. | External packets or agent trajectories can change durable state without a tested reversal path. |
| Evaluation boundary | Separate MATM research evidence, curator simulation evidence, and deployment field evidence; include leakage, conflict, citation, utility, latency, cost, and review-burden metrics. | Research claims, local tests, and production readiness are flattened into one unsupported claim. |
The dogfood pattern is the NeuroWikis, NeuralWikis, and LLMWikis lane split: NeuroWikis is human-facing education, NeuralWikis is the private governed agent-memory and exchange dogfood lane, and LLMWikis is public builder guidance. The spec lesson is portable even when a project uses different names.
Profile G: dogfood promotion-ready contract
| Contract | Required behavior | Public boundary |
|---|---|---|
| Source possession | Every promoted lesson names the private or public source, owner, source scope, durable-copy location, timestamp, and evidence hash. | Do not publish private source content or imply public access to the private resolver. |
| Durable-copy evidence | Promotion does not rely on chat memory. A copy, hash, source identity, or canonical source route must survive outside the session. | The hash proves traceability; it is not permission to expose the source. |
| Memory-kind and scope taxonomy | Classify candidates as fact, decision, procedure, risk, preference, hypothesis, evidence, deprecation, or conflict and label source scope before escalating target scope. | A session or project observation cannot silently become public guidance. |
| SPO claim discipline | Public claims should be split into subject, predicate, object, scope, source span, reviewer, status, and contradiction fields where feasible. | Graph-shaped claims remain page metadata or derived exports, not a public graph database claim. |
| Redaction and withheld details | Private names, credentials, traces, private URLs, regulated data, hidden reasoning, and exploit paths are removed or summarized in a withheld-detail register. | Public examples must teach patterns, not leak the case. |
| Lane review | Decide whether a claim belongs to LlmWikis, UAIX, NeuralWikis, NeuroWikis, AIWikis, a source site, or a local repo before publication. | LlmWikis does not claim UAIX conformance, NeuralWikis runtime support, or source-site authority. |
| Supersession and temporal review | Promotion packets include last verified date, freshness rule, supersedes/superseded_by links, contradiction state, and release note impact. | Stale promoted lessons stop acting as current guidance. |
| Enhanced entity pages | High-value people, projects, routes, packages, standards, concepts, or tools get canonical entity records with aliases, claims, relations, and non-claims. | Entity pages are reviewed records, not endorsement or certification. |
| Tool execution and idempotency | Protected tool submissions use proposal-only writes, idempotency keys, source-event hashes, replay disposition, negative fixtures, and reviewer decisions. | LlmWikis guidance does not imply a public MCP server, write API, or automatic repository writer. |
Required artifact set
| Artifact | Role | Validation question |
|---|---|---|
README.md |
Front door for scope, owner, audience, and first route. | Can a new reader tell what the wiki covers in one minute? |
raw/ |
Immutable source evidence, exports, summaries, checksums, and manifests. | Can a claim be checked without relying on chat memory? |
wiki/ |
Reviewed concept, guide, reference, runbook, decision, source, and contradiction pages. | Are durable answers stored as inspectable pages? |
wiki/index.md |
Route map for hubs, page types, owners, statuses, high-value tasks, and project index/log counterparts in multi-project roots. | Can agents route before broad reading? |
source-memory guide |
Crawlable routing surface for durable report, coding-standard, architecture, best-practice, and preserved handoff records. | Does each durable record say why to open it and where source evidence lives? |
wiki/log.md |
Append-only ingest, query, lint, review, correction, and archive record at the right scope; multi-project roots should point to project logs for detail. | Can future work see what changed and why without flooding the workspace root? |
AGENTS.md or CLAUDE.md |
Agent operating contract, read order, allowed paths, stop conditions, and checks. | Can an agent avoid guessing permissions? |
TRUST_MODEL.md |
Status labels and their human/agent meaning. | Does each label change behavior? |
SOURCE_POLICY.md |
Source admission, citation, redaction, review, and canonical authority rules. | Can weak or private sources be stopped? |
llm-wiki/matm/ optional extension |
MATM Wiki fit decision, base wiki contract inheritance, policy, Memory Event schemas, curation, retrieval, security/privacy, evaluation, migration, and negative fixtures. | If MATM is enabled, can agents prove proposal-only writes, protected review, scoped retrieval, storage truth labels, adoption preview, and rollback without bypassing type frontmatter, reserved index/log files, tolerant readers, or client/workspace/project boundaries? |
matm-profile.json optional manifest |
Public machine-readable profile for MATM route classes, source authority, support boundary, templates, schemas, capability truth labels, and non-claims. | If MATM is enabled, can an agent distinguish public discovery from protected mutation or runtime authority? |
llm-wiki/promotion/ optional Profile G package |
Promotion plan, gate checklist, public-safe rewrite template, redaction checklist, lane review matrix, evidence-hash manifest, supersession record, and release-note template. | If private dogfood evidence is used, can a reviewer prove only public-safe guidance was published? |
promotion-gates.schema.json optional schema |
Machine-readable shape for source possession, durable copy, redaction, lane review, claim shape, freshness, and release-note gates. | Can tooling validate promotion packets without exposing private source material? |
okf.profile.json |
Machine-readable OKF compatibility profile for bundle root, reserved files, governance overlay, helper scripts, and non-claims. | Can a visiting tool understand the OKF layer without mistaking it for write permission? |
scripts/llmwiki-okf-validate.js |
Local validation helper for OKF syntax, reserved files, link severity, log ordering, and LLMWikis governance fields. | Can a starter bundle prove its own OKF shape before publication? |
scripts/llmwiki-okf-migrate-frontmatter.js |
Dry-run migration helper for adding OKF and LLMWikis fields from existing page metadata. | Can an existing LLM Wiki move toward OKF compatibility without dropping custom metadata? |
page-registry |
Canonical URL, aliases, redirects, page type, owner, status, and discovery state. | Can duplicate canonicals be detected? |
route manifest, optional llms.txt and sitemap.xml |
Internal route discovery by default; public AI/search discovery only when the wiki deliberately publishes public routes. | Are private files, archives, and generated package mirrors excluded from every discovery surface? |
Minimal page record
---
type: "Runbook"
title: "Deployment Process"
canonical_url: "https://example.com/operations/deployment-process/"
description: "Reviewed deployment workflow, approvals, rollback path, and agent boundaries."
resource: "raw/releases/2026-05-process-review.md"
tags: ["operations", "deployment"]
timestamp: "2026-05-24T00:00:00Z"
llmwiki_status: "authoritative"
llmwiki_owner: "Platform Team"
llmwiki_source_status: "source-linked"
llmwiki_agent_use: "read-cite-propose"
page_type: "runbook"
owner: "Platform Team"
status: "current"
source_status: "source-linked"
last_reviewed: "2026-05-24"
review_cycle: "after each release process change"
sensitivity: "internal"
agent_use: "read-cite-propose"
source_trace:
- "raw/releases/2026-05-process-review.md"
typed_relations:
part_of:
- "/operations/"
depends_on:
- "/reference/security-privacy/"
supersedes: []
contradicts: []
source_for: []
---Search and retrieval requirements
- Search should prefer canonical reviewed pages over aliases, archive pages, raw files, package mirrors, and generated history.
- Result cards should expose a useful title, short description or excerpt, route, and freshness/status signals when the platform can show them.
- Durable report, coding-standard, architecture, best-practice, and handoff-preservation pages should expose routing summaries, source/evidence links, checksum or source identity, and discovery surfaces so agents can choose what to load next.
- Search should help users recover from broad queries with route shortcuts for specification, metadata, repair, source policy, AI Memory, and the setup wizard.
- Retrieval, vector search, graph traversal, or GraphRAG should consume reviewed wiki pages and source summaries, not private intake folders or raw unreviewed dumps.
- Answers produced from search should cite the pages or source records used, preserve contradictions, and abstain when evidence is missing, stale, private, or blocked.
Integration proof ladder
Selected-client proof means proving the exact client, wrapper, credentials, and operation path that will be used, not merely proving that a server or schema exists somewhere.
| Proof layer | Question | Evidence |
|---|---|---|
| Server MCP catalog readiness | Does the authoritative server advertise the intended capability and boundary? | Catalog route, tool schema, status label, and support boundary. |
| Generated config readiness | Does the generated config point at the selected server, scope, and mode? | Generated file diff, manifest entry, and scoped settings. |
| Installed client wrapper readiness | Does the actual local or selected client resolve and call that config? | Wrapper inspection, dry run, or capability readback from the installed client. |
| Credential scope readiness | Do credentials grant only the intended client/workspace/project capability? | Redacted credential-scope proof and denied out-of-scope fixture. |
| Idempotency readiness | Are retries, duplicate submissions, and same-key mutations safe? | Replay fixture, duplicate result, or explicit no-op/audit decision. |
| Operation readback readiness | Can the actual operation result be read from the authoritative target? | Readback route, evidence link, audit record, or durable blocker. |
Validation gates
| Gate | Blocks publication when | Typical check |
|---|---|---|
| Discovery gate | Private files, archives, admin URLs, package mirrors, duplicate aliases, or noindex drafts appear in public discovery. | Compare sitemap, llms.txt, robots, public routes, and route registry. |
| Metadata gate | Required page fields are missing or invalid. | Validate frontmatter/page registry against the metadata standard. |
| OKF conformance gate | Non-reserved Markdown files under wiki/ lack frontmatter or a non-empty type field. |
Run node scripts/llmwiki-okf-validate.js wiki. |
| OKF reserved-file gate | Root wiki/index.md carries metadata other than okf_version, nested index.md files carry frontmatter, or wiki/log.md is not newest-first. |
Validate reserved-file semantics before packaging. |
| Metadata harmonization gate | OKF fields and LLMWikis fields disagree or a migration would drop unknown local keys. | Dry-run scripts/llmwiki-okf-migrate-frontmatter.js and review the diff. |
| Link/citation severity gate | Broken local links, missing resources, or missing citations appear in a public or strict release package. | Warn during draft validation; fail strict publication validation. |
| Canonical gate | Two pages claim the same concept without a winner, redirect, or archive decision. | Duplicate title, duplicate intent, and duplicate canonical URL scan. |
| Source gate | Factual claims lack source trace, canonical external route, or review status. | Claim/source-span and source-policy lint. |
| Safety gate | Secrets, private data, regulated material, or privileged operational detail can leak to public pages or portable packets. | Secret patterns, sensitivity labels, redaction review, and export review. |
| Agent gate | Permissions, stop conditions, destructive-change rules, or targeted checks are unclear. | AGENTS.md/CLAUDE.md plus task-specific verification checklist. |
| Integration proof gate | A page or package claims tool readiness from only a server schema, generated config, or successful preview without selected-client readback. | Walk the proof ladder: server catalog, generated config, installed wrapper, credential scope, idempotency, and operation readback. |
| Proof-of-use intake gate | Dropped reports are marked processed after reading, summary, or memory copy only. | Require disposition, real work or durable blocker, memory update or no-change reason, evidence links, checks, and archive/removal/keep-active decision. |
| MATM fit gate | A project enables MATM without a written fit decision, curator owner, lane map, and proof that ordinary LLM Wiki retrieval is insufficient. | Check MATM_WIKI_DECISION_GUIDE.md, route map, source policy, and setup packet. |
| MATM route gate | Public discovery, public preview, protected submit, protected review, protected read, operator evidence, and storage truth-label surfaces are mixed together. | Validate the MATM profile manifest, route registry, headers/footers, sitemap, and llms.txt. |
| MATM trust gate | Validation, profile visibility, preview success, HMAC attestation, retrieval visibility, or payment state is treated as durable trust or authorization. | Review negative fixtures, curation reports, reviewer decisions, retrieval policy, and support-boundary copy. |
| MATM rollback gate | Packets, trajectories, or Memory Records can affect durable state without sandbox/adoption preview, rollback evidence, quarantine, and audit logs. | Run adoption-preview fixtures and verify rollback/quarantine evidence before durable admission. |
| Private-memory source gate | A public page is based on private memory but lacks source possession, durable copy, evidence hash, source scope, or reviewer owner. | Validate the promotion packet before rewriting public guidance. |
| Public-safe rewrite gate | Draft copy exposes private traces, customer/repo identifiers, hidden reasoning, exploit details, or public runtime claims. | Run the public-safe rewrite checklist and withheld-detail review. |
| Lane review gate | The page makes UAIX, NeuralWikis, NeuroWikis, AIWikis, source-site, product, certification, or conformance claims from the wrong authority lane. | Route the claim to the canonical owner or rewrite it as non-normative guidance. |
| Temporal gate | Time-sensitive claims lack last verified date, freshness rule, supersession links, conflict status, or release-note impact. | Run supersession and freshness lint before publication. |
| Tool/idempotency gate | Protected submissions can be replayed, duplicated, mutated under the same key, or treated as durable writes before review. | Check idempotency keys, source-event hashes, replay dispositions, negative fixtures, and reviewer decisions. |