QKView LLM Wiki Runbook

⚠ Disclaimer

This documentation describes a tool built for internal use only. An F5 BIG-IP QKView file is an extraordinarily sensitive artifact — it contains running configurations, SSL certificate details, device serial numbers, registration keys, HA failover state, internal IP addressing, log entries that may include client traffic patterns, and in some cases plaintext credentials. Feeding a QKView into any cloud-hosted LLM service (free tier, consumer product, or shared API) means transmitting all of that data to a third party. Do not do this.

If you follow this pattern and build your own QKView analysis wiki, you should only run it against a Privately Hosted Local LLM (self-hosted, on-premises, no data leaves your network) or an Enterprise-Grade subscription with a vendor that contractually guarantees zero data retention, zero training on inputs, and zero human review of prompts (e.g., Azure OpenAI with a Data Processing Agreement, AWS Bedrock with appropriate safeguards, or equivalent). Read the terms of service carefully — most consumer LLM products explicitly reserve the right to train on your inputs. That is incompatible with QKView data. The author assumes no responsibility for data exposure resulting from misuse of this design pattern.

Important Note on Availability

This tool was built at work, for work. The actual QKView LLM Wiki repository — including all 20+ Python extractor scripts, the 72 wiki pages (and rising), the CLAUDE.md schema, and operational specifics that I will never be able to release. What I can provide is the complete design, architecture, operating model, and every lesson learned from building and running it — enough that someone following the same pattern against their own QKViews will arrive at the same result.

The Problem It Solves

F5 BIG-IP QKView diagnostic archives are the primary artifact for remote support cases and proactive health assessments. But analyzing them is slow, inconsistent, and heavily reliant on individual engineer experience. A QKView contains dozens of XML files, configuration dumps, log excerpts, certificate inventories, and hardware telemetry — and no two engineers will examine the same data the same way.

This wiki operationalizes a repeatable, documented analysis methodology:

• Consistency — every QKView gets the same check walkthrough, regardless of who (or what) is running it (I literally told Claude that the goal is to have the "Stupidest" Model available provide a detailed and actionable report)
• Completeness — checks cover filesystem, memory, CPU, HA, services, network, pools, certificates, logs, iRules, config hygiene, and tmctl statistics — nothing gets skipped
• Repeatability — deterministic Python extractors pre-parse XML so the AI reads structured, pre-judged results instead of raw data
• Improvement — every engagement that deviates from the playbook produces a lesson that gets generalized and filed back, making the next run more accurate
• Sterility — client data never enters the wiki. Engagement output lives in an external workspace. The wiki stays clean enough to share, version, and reuse across every engagement

How It Differs from the TMSH Wiki

Architecture

The Extractor Layer

The 20+ Python scripts in tools/ are the deterministic parsing layer that separates fact-derivation from interpretation. Each extractor runs against a specific QKView XML artifact and emits structured Markdown with:

• A leading result: ok|warn|crit|n/a line — the threshold judgment, already made
• Captured data tables with the raw evidence
• Drill-route signals (e.g., _usr_lv_branch: only_current_family)
• Verify sections posing the wiki's named possible causes as numbered questions

This design was added after a second engagement revealed that Claude was sometimes skipping analytical work by not fully parsing raw XML — and a Haiku-class model test showed fabricated all-clears. The extractors make hallucinated all-clears structurally hard: a model walking the playbook reads pre-computed result: crit lines rather than trying to interpret raw XML.

Sterility — The Prime Directive

The QKView Wiki has a sterility constraint that the TMSH Wiki does not. The TMSH Wiki has no client data to protect — it is purely F5 vendor knowledge. The QKView Wiki is used against real client device data on every engagement. The constraint is absolute:

Forbidden anywhere in the wiki repo, including frontmatter, log entries, lesson files, commit messages, and filenames:

• Client names, organization names, project codenames
• Hostnames, device names, FQDNs
• Device serial numbers, registration keys, license keys
• IP addresses from any real environment (RFC 5737 docs ranges only in examples)
• Certificate content, key material, fingerprints
• Verbatim configuration excerpts from a real QKView
• Engagement dates tied to a specific client
• Support case IDs, ticket numbers

During Refine, the generalize step is mandatory and comes first. A deviation note from an engagement might say "client's /var was at 88% with rapid fill rate." That cannot enter the wiki. It becomes: "For /var, fill rate dominates absolute %. The 80-89 warn band should escalate to crit when fill rate exceeds ~N%/day." If generalization without losing the lesson is impossible, the lesson is flagged and skipped until it can be reworded.

How It Was Created

The Execute / Refine Cycle

The core innovation of this wiki over the TMSH reference model. This is where the "self-improving runbook" actually improves itself:

The bi-directional nature of Refine — fixes route to either the wiki or the tools depending on whether the gap was interpretive or detection-based — is the project's central improvement mechanism.

Access Rules

Unlike the TMSH Wiki, the QKView Wiki does not have a simple trigger list. Its access is mediated entirely by the qkview-analysis-skill:

• During an Execute pass (via the skill): the skill walks the playbook, and each check page and drilldown page is read as part of the execution loop. No page limit enforced during Execute — the playbook walks all relevant pages systematically
• During Ingest, Refine, or Lint: wiki maintenance operations triggered manually against the wiki repo. Claude reads whatever pages are needed to correctly route and file deviations
• The skill is the enforcement boundary that keeps engagement data out of the wiki. The wiki is sterile because the skill always writes output to an external path — there is no mechanism within the skill for findings to flow back into the repo

Current State

Enhancement Opportunities

The extractor layer opens a design space the TMSH Wiki doesn't have. Because every check is backed by a deterministic Python script that emits structured Markdown, the system can be extended in ways a pure-knowledge-base cannot:

• Automated regression testing — run every extractor against the sanitized sample QKViews and diff the output. Drift in the check logic becomes visible immediately.
• CI pipeline integration — every Refine pass that modifies an extractor or a check page could trigger an automated test suite against the fixtures.
• Threshold calibration — the extractors emit the raw numbers alongside the judgment. Over time, the distribution of real-world results can be used to tune the warn/crit bands with evidence rather than intuition.
• Multi-device correlation — running the skill against both members of an HA pair and cross-referencing the deviation queues could surface asymmetric configuration drift.
• MCP conversion — the extractor scripts could be wrapped as MCP tool calls, making the QKView analysis capability available to any agent, not just Claude Code sessions pointed at the wiki repo.

Details

Reference

Andrej Karpathy's GitHub Article: LLM Wiki

Related Project: TMSH LLM Wiki Brain — the static reference companion that shares the same vault architecture

Related Project: iControl LLM Wiki Brain — the REST API companion (in progress)