knowbase

# Method

knowbase publishes 10 Knowledge Objects. This page states how they are built and what the labels on them mean, so a reader — human or machine — can decide how much weight to give an answer.

## What a Knowledge Object is

One concrete failure, resolved. Not a tutorial, not an overview, not a listicle. Each entry carries seven things, and an entry missing any of them does not publish:

  1. 01 The error as it actually appears, plus the codes and phrasings people search for
  2. 02 The problem in plain terms
  3. 03 Root causes, ranked, each with a cheap test that tells you whether it is yours
  4. 04 The fix, as ordered steps with real commands
  5. 05 The exact technologies and version ranges it applies to
  6. 06 The primary sources that prove it, and which claim each one backs
  7. 07 The date it was last checked against those sources

Entries also carry a Not Applicable To section. Naming the near misses is what stops an answer from being applied to the wrong failure — the most expensive kind of wrong answer.

## How entries are sourced

Research starts from primary material and works outward, in this order: official documentation and specifications, then source code and enhancement proposals, then issue trackers and pull requests, then release notes, then vendor knowledge bases.

Documentation-retrieval tooling is used to locate the right primary document quickly. Its output is never published. Every claim on this site is written after reading the original source, and the source is cited so you can check the reading yourself.

Reachability of every cited URL is machine-checked. A link that rots turns a verified claim back into an assertion, so it is treated as a defect rather than a cosmetic issue.

## Evidence rulesenforced at build time, not by convention

  • Every entry cites at least one primary source — official documentation, a specification, or source code. Blog posts and forum answers cannot carry an entry on their own.
  • Each source states what it supports. A citation that does not say which claim it backs is decoration.
  • Confidence is gated by evidence. A build fails if an entry claims more confidence than its sources justify.

## What the confidence labels mean

high
Three or more sources, at least one primary. Every substantive claim traces to a document rather than to experience. Where a claim does not, the entry says so in its confidence note.
medium
Two or more sources with a primary among them. The mechanism is documented; some specifics — thresholds, defaults, edge behaviour — rest on fewer sources.
low
A single source, or a reproducible behaviour that documentation does not yet describe. Useful, but verify before acting on it in production.

## Why entries expire

Technical knowledge decays at very different rates. A SQLSTATE code is stable for decades; a scheduler default changes between minor releases. Each entry therefore sets its own review interval, and the page reports its real age against that interval rather than a vague “last updated” line.

An entry past its interval is labelled review-due, and well past it, stale. The label is computed when the page is served, so a neglected entry admits it instead of looking current.

## What this site does not do

✗ Publish anything generated from a model’s recollection without a source behind it.

✗ Pad entries for length. Everything here is written to be read in under a minute.

✗ Hide the answer behind a preamble, a newsletter prompt, or a cookie wall.

## License and reuse

Content is CC-BY-4.0. Copy it, quote it, feed it to a model, ship it in a product. Attribution is the canonical URL of the entry.

There is no API key and no rate limit. If you are building on this and need something the current renditions do not give you, the JSON body is versioned so it can grow without breaking you.