Agreed on 2026-08-08 after a full decision-tree review, this page serves as the durable, harness-independent record for all content curation and agent-driven documentation on this wiki. Any agent executing content work on this wiki must strictly adhere to these rules unless the operator explicitly changes them.
This deep-dive reference exists to ensure that both automated systems (like Retrieval-Augmented Generation (RAG) agents) and human readers extract maximum value from the corpus without suffering from keyword bloat, stale procedures, or misaligned taxonomies.
Agent retrieval quality (System A) and personal working reference (System C) are our joint primary objectives. Search Engine Optimization (SEO) (System B) is pursued explicitly, but only via moves that cost retrieval and reference nothing.
In real-world applications, a keyword-stuffed page might temporarily draw equivalent search traffic worth $10K/month, but if it breaks the RAG pipeline for the primary autonomous agents by flooding the context window with irrelevant matches, the architectural cost exceeds $50K in lost developer productivity and wasted LLM inference tokens.
We measure keyword relevance using probabilistic retrieval frameworks like BM25.
As the equation illustrates, padding a document (D) with excessive keywords artificially inflates the document length (|D|). Because the term \frac{|D|}{\text{avgdl}} acts as a penalty in the denominator, stuffing generic text to satisfy SEO directly hurts the BM25 score of highly specific, technical terms that actually matter to agents. Therefore, search-phrased titles are acceptable as tiebreakers, but keyword-stuffed summaries are strictly forbidden.
Taxonomies naturally drift as domains expand. However, we mandate targeted cleanup only; never engage in big-bang re-clustering. For instance, successfully splitting quant-finance from machine-learning was a targeted, high-value move. Conversely, attempting to rewrite the entire taxonomy of a 10,000-page wiki from scratch requires O(N^2) validation of link structures, inevitably leading to broken context boundaries and rendering existing embedding indices obsolete. This type of churn can cost a team upwards of $25K just in rebuilding vector search infrastructure and human review time.
We operate on periodic (quarterly-ish) domain-completeness seeding passes. Between these passes, the demand loop (real query misses) and project-anchored writing drive what gets written.
Syllabus-completeness alone is never a sufficient reason to write a page. Writing "just to have it" results in shallow, 200-word stubs that degrade overall corpus density. Instead, pages should only be instantiated when there is a concrete, observed operational need. When you do write a page, it must be deep, substantive, and highly actionable.
Content format must strictly map to the underlying shape of the knowledge:
type: articletype: runbookProcedural content requires the structured runbook: frontmatter block and emits HowTo JSON-LD for rich snippet indexing.
Crucial Caveat: Never dual-track one topic into both formats. Sibling pages compete directly in vector space retrieval. If an agent searches for "How to deploy Kubernetes," and both an article and a runbook exist with overlapping text, the cosine similarity between the two documents will be exceptionally high:
When similarity approaches 1.0, the retrieval system retrieves both documents. The LLM context window is subsequently flooded with redundant information, pushing out other potentially valuable context and increasing token costs unnecessarily by thousands of dollars over a year (e.g., wasting $1.2K annually on duplicate token consumption).
Not all knowledge decays at the same rate. We implement a bifurcated verification strategy:
mark_page_verified workflow.By isolating fast-decaying operational data from slow-decaying theoretical data, we drastically reduce the maintenance burden, saving roughly $40K per year in human and agent-driven audit overhead.
Practice and context clusters stay default-excluded from Knowledge Graph (KG) extraction until a concrete need appears. Extracting every noun phrase into a Knowledge Graph creates overwhelming noise. Graph traversal complexity grows exponentially with node density. If we inject thousands of trivial entities into the graph, multi-hop reasoning algorithms (like GraphRAG) will time out or hallucinate by drawing connections between completely unrelated technical concepts based on generic shared terminology.
The recurring maintenance checks live in the wiki-audit skill. This includes an under-served-query sweep and a tool-practice staleness flag. By actively monitoring what users and agents are searching for but failing to find, we create a closed-loop feedback system. See Wiki Audit Demand Loop for the operational runbook.
As stated in Decision 1, SEO is secondary to agent retrieval. We only implement SEO tactics that have zero impact on readability or algorithmic recall. Permitted tactics include:
Nothing beyond this is permitted. We will not sacrifice the precision of our internal agent corpus for a minor bump in external Google search rankings.
We utilize a publish-direct workflow with no draft gate. Edits are grouped into tranches of 6–10 pages. This ensures that per-page verification stays honest and thorough. Retrieval levers (per the wiki-content skill) dictate that the summary, title, cluster, and headings are embedded in every chunked vector. Keeping tranches small prevents catastrophic regressions in embedding quality that often occur during massive, automated bulk-publishing runs.
Our content policies are entirely data-driven, inherited from thousands of experimental automated queries and RAG quality evaluations.
A clean verify_pages lint is merely table stakes. It checks for broken links, missing frontmatter, and basic markdown syntax compliance. However, the live assemble_bundle check is the real retrievability gate. If a page passes linting but fails to surface during a simulated semantic search test, the page is functionally invisible to the agents and must be rewritten to improve its semantic density.
Content additions are not strictly additive; they can pollute the vector space. Every content edit must enrich the corpus with discriminating, highly specific vocabulary. Never use generic topic lists. In one measured instance, a mechanical enrichment pass that added "helpful" generic summaries to 500 pages caused our top-k recall metric on specific engineering queries to drop from 0.74 to 0.68. The generic text diluted the unique semantic signatures of the documents.
The industry frequently chases new retrieval fads. We have systematically measured and rejected the following techniques. Do not re-attempt these without substantially new empirical evidence:
By strictly adhering to these guidelines, we maintain a high-signal, low-noise environment. The ultimate measure of success for this wiki is not page views, but the speed and accuracy with which an autonomous agent or human engineer can extract exactly the information required to solve a complex problem.